After a few days of post-release wind-down period and some neccesery dev-systems reinstalls, I'm mostly back in development mood. So far I've managed to generate about 1000 lines of C++ code plus some 2kloc xml generated from qtdesigner. What I have up is main navigation and prelimiary layouts for system/search/transfer pages.
Basically, the UI will be pretty typical to other p2p client interfaces, with main navigational buttons at the top. Currently five pages are planned - System, Search, Transfer, Library and Statistics. In addition there'll be Settings page/window, but the contents of that are not yet fully decided currently.
System page will be the most interesting of the five; in addition to serving as "overview" page for all important information, it will also provide a tab-based (like in IE7 or FF) interface for plugin-specific data, such as server lists, newsgroup contents or IRC chat pages.
There are a number of things about GUI programming that personally I dislike. One major difference from code design / structuring point of view is that you'r using an existing
framework, NOT a
class library. There's a huge difference between those two. In simple terms, in case of a
framework, you need to subclass a lot of framework-provided classes in order to achieve your goals, while in case of a
class library, you get to choose your own class hierarchy, and use the library-provided classes as tools. Many C++ authorities recommend to
"prefer composition over inheritance", and I strongly agree with that point. This was the reason I chose Boost
class library for Hydranode engine, and the engine itself is also strongly biased towards that idea - plugins rarely need to subclass any of the engine classes.
The fundamental difference between using a framework and using a class library is that if you have a class library, a set of tools, at your disposal, you can set YOUR class hierarchy up the way you like it, the way you understand the problem/solution best, thus creating your OWN framework. However, in case of a
framework library, you are bound with THEIR class hierarchy. Consider that in case of search page, I had to subclass QTabWidget, QTabBar, QWidget (for content frame), QTreeWidget and QTreeWidgetItem. That's just stupid. Granted, I would be able to reduce the subclassing perhaps somewhat, but that was the logical thing to do (and for 3 out of the 5, it was absolutely required).
Another thing that somewhat annoys me is that when developing GUI-like things, one's focus switches from writing cool code towards producing the final product. You suddenly care less about what the underlying code looks like, and focus more on what the product itself looks/feels like. Technically, there's nothing wrong with this concept; however being somewhat a freak about having code look nice, this tendency annoys me. I think it can be accounted to the fact that when you'r writing GUI stuff, you'r lot closer to the end-user than you are when writing low-level, non-gui stuff; also, in case of non-gui stuff, the source code by itself becomes sort of an interface for the product for the developers, so they spend a lot of time making it pretty - since that's how they "use" the product most of the time - by looking at the code. It's no wonder very low-level things, such as Linux Kernel, have very nice and clean codebase - at least visually.
Madcat, ZzZz
--
PS: Screenshots will be available in a few days or so.
