The Problem of Many

The open source world of "Applications" is a funny & paradoxical collection of illustrations. On one hand, people unite together to get away from the clutches of those who tend to constrict users, whilst on the other petty differences in opinions leads to the creation and availability of a multitude of applications performing the same task, albeit in slightly differing shades. Some folks look at this as "the freedom to choose". I look at it as the lack of a concerting effort to amalgamate the best of features, in turn, producing the best-of-breed applications.

Now, this does not mean that I am against the open-source concept or the proliferation of applications. I am just trying to explain a problem that I have noticed -- "The Problem of Many"

I have Fedora 7 installed my laptop, and like most users I have installed various media related applications that are not installed/shipped by Fedora - like MPlayer, Xine, Helix, Real Player. Similarly on the audio front I have Amarok^[1], XMMS. Now these are in addition to the default set of applications - Totem, GNOME-CD, Rhythm Box, Sound Juicer, etc.

Each application has its pros and cons and I definitely do not wish to get into a competitive analysis of each of these. What I would like to highlight is the cluttering of my menus. Currently my "Sound & Video" menu contains a plethora of applications (which of course I had installed) which pretty much do the same job^[2]. See the following image inset for details.


Now I have been thinking, what if we could collapse all the similar applications into one extended-menu-item ?

What I really mean by that is, what if my "Sound & Video" menu opened into top level extended-menu-items. These extended-menu-items could be used to execute the user-configured actions or could also be used to further drill down into options. The following images should highlight better what I have in mind.








When I say user-configured I am talking more on the lines of configuring your favorite application via one central UI -- like the current "Preferred Applications" UI in the GNOME install.

I guess my idea does not really solve the problem-of-many; it merely hides it, but I do believe that a solution such as the above could bring about an ease of application manageability within the desktop and of course I would happy with it :)

What do you think about it?

---

[1] - Amarok though shipped with the install media is not installed by default on a GNOME desktop

[2] - I am aware that most of the applications that I mentioned primarily target a specific media type, but my point is that this difference would soon be blurred out in the near future as each application tries to improve its support for the other media types.

Running Sun Secure Global Desktop (a.k.a. Tarantella) on your Fedora Core desktop

I have spent hours trying to understand why the Tarantella client does not work on my GNOME install. Every time I run the ttwebtop command, I would see a whole lot of warnings on the console and the end result was that I would not be able to type in anything in the login dialog.

After a lot of Googling and reading bugs, I chanced upon the possibility of a mismatch in the location of the XKeysymDB file. This file is available as part of libX11 which is present on the system by default. The client tries to load up this file from the location /usr/openwin/lib/XKeysymDB, but the file is actually present at /usr/share/X11/XKeysymDB. In order for the application to pick it up, you need to define this new location as an environment variable - XKEYSYMDB. Once you set this variable, the client loads up fine, and I can start working from home again :-)

As a solution, I have this variable defined in my ~/.bashrc file as follows

export XKEYSYMDB=/usr/share/X11/XKeysymDB

And I can start working from home again :-)

Note: The client in consideration is the Sun Secure Global Desktop version 4.2

Necessity is the mother of all inventions

Who ever said it, couldn't have been more right. I find myself building utilities and applications everytime I don't find the right one :) .. During the past few days, I built a similar utility plugin and I thought I might as well share it with the rest of the world.

A little background... I work on a myriad set of applications and technologies, and this requires me to keep doing a lot of activities on different applications parallely. So off-late I have been working on providing a JSF component that pulls in a user's presence information from a backend RTC server. In this case the backend happens to be Microsoft's Live Communication Server. As you might have guessed, I have a .NET component that is doing all the talking with the LCS instance and this component exposes its features as a set of WebServices which are then consumed by the Java layer and published to the application via a JSF component. No points for anyone guessing that this can be a mess to handle all alone :-p

Everytime I need to perform some quick and dirty work, Netbeans is the IDE of choice. One day I was trying out something on similar lines, I needed to import only a subset of the Java classes into a project. And I knew that the IDE did not present me a feature where I could pick and choose. The only option I had was to copy the files over manually outside the IDE and then delete those that I didn't require. That can be quite painful at times! I dearly wished I had an option where I could look at the files being imported in a tree structure, where I could just (un)select the files I wanted.... So I built myself one of those things :-D ... Here is a screenshot of the module in action..


As a part of my work, I ran into a hard-to-trace, intermittent bug that would cause the .NET layer to crash once in a while. One rather good thing that I did do was use Log4Net's logger within the entire .NET code. So I whipped out my IDE of choice, built the test-bed and began the debugging. Everything was fine and going smooth, except that I had to switch between two applications to keep monitoring the output. That is when I though... "How I wish I had a module that could tail this file and show me the data within the IDE itself!". I took a measure of the expected effort, realized it wasn't much, went ahead and built myself exactly what I wanted. Check it out in action....


Like what you see? Get it here.

Thats all for now, later!

Java6: GroupLayout and a small gotcha

The new layout manager, GroupLayout, which is part of the JavaSE 6 bundle is great and coupled with Netbeans' Matisse component, makes a killer combination. Today I would like to talk about an issue that I ran into and hopefully would be able to help others running into the same issue.

Anyways, if you try hand-coding this layout for your components, there is a rather subtle thing to remember. In Java 5, if you wanted to add a component to a container like JPanel, you would do something like:

 ....
 JPanel jp = new JPanel();
 JButton button = new JButton(...);
 jp.getContentPane().add(button);
 ....

The key point to notice is that you would explicitly get hold of the content pane and then add the component to it. Now with Java 6, the good old ways of adding a component directly to the parent are back (which internally ensures that the component is added to the content pane), i.e., the same example above could be simplified as:

 jp.add(button);

All this fine and nice. Now when using GroupLayout, the code might look as follows (in Java 5):

 GroupLayout layout = new GroupLayout(jp.getContentPane());
 jp.getContentPane().setLayout(layout);
 ... // add the component to the layout

Since I was working with Java 6, I decided to use the simplified notation and did the following:

 GroupLayout layout = new GroupLayout(jp);
  jp..setLayout(layout);
  ... // add the component to the layout

And was I in for a shock when I ran the code !!! I kept seeing the following stack trace on my screen :-O

 Exception in thread "AWT-EventQueue-0" java.lang.IllegalArgumentException: 
   GroupLayout can only be used with one Container at a time
         at javax.swing.GroupLayout.checkParent(GroupLayout.java:1095)
         at javax.swing.GroupLayout.invalidateLayout(GroupLayout.java:987)
         ......

It took me a while (which involved going through the source-code of GroupLayout) to figure out that the problem was actually with the way I am initializing the damn GroupLayout instance! The layout instance considers that it is being applied to the container ( JPanel in our case) whereas, the setLayout() method delegates the call to the content pane. And GroupLayout does a check to see that the host and owner are the same, if not, it throws a rather undecipherable exception like the one above. The key to getting it run was just simply to pass the content pane to the constructor of the GroupLayout instance.

 GroupLayout layout = new GroupLayout(jp.getContentPane());
  jp..setLayout(layout);
  ... // add the component to the layout

This experiment sure was good learning, but it would have been great if the implementation of GroupLayout threw a more meaningful exception stating the obvious rather than leaving us to figure out the obscure bits!

Thats all for now.