On Graphical User Interfaces

Apple Inc. has always been the leader in graphical user interfaces. Apple have always know very well how to create intuitive user interfaces. Apple has always know the difference between a document and an application and has centered the user interface around the document while Microsoft has done the same around the unintuitive and computer specific software application.

Users should not need to know about applications (they do not need to know they have to open the spreadsheet application to create a spreadsheet document) they just need to know about documents or objects and actions (they just need to know that they can click somewhere to create a new document and just clicking on a document it is opened for viewing, editing or printing). Applications should be hidden totally from the user.

I really hate applications that use multiple document interface mostly because they force the user to understand what an application is, instead of just focusing on the object (text document, spreadsheet, image, video, song, ...). It seems Microsoft Office 2007 has finally done some progress to stay away of MDI but Excel still has an internal close button (x).

On Event Loops

Whenever you may have to do any Graphical User Interface development you should have had to learn about event-driven programming and the event loop the widget toolkit you are using has. Like:

• Glib Main Event Loop (can be used without GTK+)
  
• Java Event dispatching thread (can not be used without AWT)
  
• Microsoft Windows Message loop (can not be used without a MSWindows GUI)
  

One thing that everyone is told (but it is difficult to follow) is to never do blocking IO in the event dispatching thread because that will block the GUI thus making the application irresponsible for an amount of time that depends on the length of that IO.

Because not doing blocking IO in the event loop thread is difficult currently lots of applications in every widget toolkit have this problem. See this post by Havoc Pennington of GNOME fame "SYNCHRONOUS IO NEVER OK"

One way to fix this problem would be to have a way of preventing any blocking call from executing inside the event loop by either logging a warning or just aborting the application when debugging it.

Many people do not care too much about executing blocking code in the event loop because they think the call will run fast and the user will not notice the GUI has blocked. But that reasoning begins to break when the user has an scenario where files are on slow NFS, network or just slow permanent storage. Then the application has to be fixed for that scenario (like pidgin: stop doing blocking file IO and Non-blocking Logging Features)

One other problem is that even widget toolkits have some functions (or methods) that block for IO and are not even marked for so. There is also lack of good non blocking interfaces in operating systems (many still do not scale well enough with the number of events or are too messy to program)

Even functions as open() can block for IO since it has to either check for file existence and permissions for open and create the file entry if the file is open for writing. So, currently if you do not want to block your UI for IO you have to put all file management (open, read, write, close, ...) in a separate thread.

There is hope for better event based development with in kernel features like Kernel Asynchronous I/O (AIO) Support for Linux but that is only the first step since any kernel call inside the event dispatching thread should not block under any circumstances.

I personally think event-driver programming is the way to develop any program so I am committed to fix any issue that makes this problem fade.