Thursday, July 15, 2010

QubLib Application Class

One thing that I never felt good about with Qt was the idea of the QApplication class. For some reason I just felt like that should be a given. When I create a Window type object, shouldn't the system just know that I want all of my system messages to come through that Window object? At this point I feel it is important to state that I am by no means a Qt, Gtk, WxWidgets, Swing, or .NET UI guru. I don't understand all of the ins and outs of UI Design or the different constraints that are placed on UI Library developers from a desire to create Cross-platform libraries. It's my hope that someday QubLib will be in the list that I just mentioned, and maybe when it is being used, I'll understand this problem a little better.

This morning I woke up with the idea that it is important for there to be such a thing as an Application class. My reasoning was that it isn't that hard to image a program that is executing in the background without a currently displayed window. If you're using a Windows operating system, I ask you to look in the bottom right hand corner of your screen. All those icons are actually programs running in the background. I also think of the QubVersioning system that I want to make someday, which will be a type of Svn/Cvs versioning system, but that it will all be done in the background so that you don't have to ask it to back up your changes. It will just do it. All of these are examples of background tasks. So, it makes perfect sense to me that I should have an Application class that does not require a visible window. Also, something that I thought of was a multi-windowed program, such as the one that is used commonly in Macintosh systems and in the Gimp paint editing tool. If anyone knows the correct term for this, please leave a comment so that I can learn it. Anyways, that is a popular technique to use for programs that have multiple windows and I think it would be relatively easy to implement if there was an Application object that you just added Window objects to.

However, the issue that I mentioned with Qt earlier was that if I only want to have a single-windowed application, do I really need to create an additional Application object? Shouldn't I just be able to create a Window object and then tell it to Run()? So, somehow an Application object should be able to contain window objects, but then a Window object should have some of the functionality of an Application object... And, I would imagine that a Window object should be able to create multiple sub-Window objects. It sounds like there is an interesting inheritance design sort of thing waiting in this mess, but I'll have to think about it more later.

1 comment:

  1. From what I've are a UI ninja...