I finally recieved my copy of The Definitive Guide to SWT and JFace that I won from Javaranch a few weeks ago durring a book promotion. After one day, I have made it through most of the book with what I call my "first pass". Basically I start at the beginning and flip through the pages only paying attention to sections that catch my eye at first glance. The next phase is to actually read the book from cover to cover. This is just how I read tech books.

As I was skimming I started wondering how SWT handles updating widgets and the event thread since SWT's event model is quite different from AWT's and the fact that we are talking about native widggets and not Swing drawn widgets. For a test I created the simple code shown below (I omitted the package and imports on purpose to save a bit of space):

public class Main 
{
    static Text text;
    static Button b;

	public static void main(String[] args) 
	{
	    Display display = new Display();
	    Shell shell = new Shell(display);
	    GridLayout layout = new GridLayout();
	    layout.numColumns = 2;
	    layout.makeColumnsEqualWidth = true;
	    shell.setLayout(layout);
	    
	    GridData data = new GridData(GridData.FILL_BOTH);
	    b = new Button(shell, SWT.PUSH);
	    b.setText("Push Me");
	    b.setLayoutData(data);
	    b.addSelectionListener(new SelectionAdapter()
	    {
	        public void widgetSelected(SelectionEvent event)
	        {
	            text.append("Testing Thread Update\n");
	            b.setEnabled(false);
	            try
	            {
	                Thread.sleep(1000);
	            }
	            catch(Exception e)
	            {
	                
	            }
	            text.append("Added something else\n");
	            b.setEnabled(true);
	        }
	        
	    });
	    
	    data = new GridData(GridData.FILL_BOTH);
	    text = new Text(shell, SWT.MULTI | SWT.V_SCROLL | SWT.WRAP);
	    text.setLayoutData(data);
	    
	    
	    shell.pack();
	    shell.open();
	    while(!shell.isDisposed())
	    {
	        if (!display.readAndDispatch())
	        {
	            display.sleep();
	        }
	    }
	    display.dispose();    
	}
}

I then created the exact same app in Swing, which I will spare the code simply because it's the same but with Swing widgets. Surprise, running the SWT app has different results than the Swing app.

In case you don't know, Swing is single threaded. GUI painting and updates happen in thier own thread and are always done last. So if you run the swing app, the button appears pressed and you wait the 1 second and then the text area is updated with both lines of text at the same time. to get around this you would simply create a new Thread in the event to update the GUI. Not really a big deal in this simple application, but can be a pain in much larger applications.

The SWT application performed as the code would imply. The first line of text is appended to the Text Area, we sleep for 1 second, then the second line of text is appended. The only similar detail that happened between both apps was the button appeared pressed through the entire event. That is why I disabled and enabled the Button in the SWT app; to hide this flaw. Disabling and enabling the Button in the Swin app is poinltess unless you spawn a new thread, as stated before, and do it there.

I have not read enough to know how the event model works in SWT yet and I am not real sure this book goes into enough detail that I could actually determine the difference between the SWT event model and the AWT event model. If anyone could explain it to me or point me to a resource to find out it would be appreciated.

I was reading a nice article today about HP delivering a Laptop with Suse 9.1 installed on it. This is cool stuff, I thought. As I continued to read I reached the section on A Few Complications and started thinking about the software install issue and why this is still an issue after how far Linux has come. And the reason that first popped into my mind was...The Desktop.

Avid Linux users, including myself, will all agree that having a choice in Desktops ranks right up there with being able to look at the source code for the ls command. We are geeks, and these are the things we like. But for the typical home PC users who are currently using Windows, mentioning choices of multiple desktops and source code will just cause their eyes to glaze over.

The problem, as I see it, is with different Desktops you also get different graphical toolkit libraries. Vendors who make Windows applications only need concern themselves with one API. But with Linux we've got KDE, GTK, GTK+, etc. And when providing an install, typically in the form of an RPM, vendors typically choose which desktop they wish to target. Gnome users might get a desktop and/or menu shortcut for the installed application, but chances are the KDE system is left hanging. And vice verca.

Now some Linux distributers have taken it upon themselves to "suggest" a specific desktop. So any software taken from that distributor (Redhat, Mandrake, Suse, etc) will more than likely work best on said desktop. What I think the Linux world needs is to do one of two things.

Choose one Desktop as the Linux Desktop

Change the way software installation occurs

I think the former is the simplest approach. Why can't the Linux world come together and support one desktop 100%? Make it that much easier for average PC users to migrate from Windows. The option for us fanatics will always be there to choose what desktop we want, create shortcuts on our own, and look at random source code. Linux has definately become easier to install and use over the years, but as long as the Desktop war is going on, typical PC users won't even consider switching over from Windows. That's my opinion anyway. What do you think?