Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Monday, February 06, 2006

Starting GUI development

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.

Quite a lot interesting stuff! I want to see some screenshots and even GIF/MNGs of it! ;)
Very nice idea, it seems that it will be the first usable GUI for a multinetwork P2P client. I'm waiting for it!
Am i the only one who whould like a Protocol? O:)

There is where u can produce clean and cristal code ;)

Ps sorry i can't help on the problem u r talking, never develop GUI under that 2 Framework.

PS There is nothing i can say but: GREAT WORK!
I think the gui protocol is mostly done, it's cgcomm or I'm wrong? :)
Is it? O:)

i was under the impression that what take so much for a gui was that Madcat (may god love him a bit more ;) ) want to made a new protocol only for GUI...

But this r my wild wild speculations.

Wait until we get the royal response ;)
Yes! Yes! Yes! That's the most interesting part for us blog-readers...:P
The creation of the GUI will mean a new p2p app for the masses (Windows users) and I hope we will attract more module developers. I guess that a lot of mldonkey users will make the switch with the new GUI. We are better and we know it:)

Have fun Madcat!
Cgcomm protocol as currently implemented in cmod_cgcomm and libhncgcomm will stay as is, and will be expanded as needed to support things that GUI needs. Underlying protocol changes are simple since the GUI uses a well-defined C++ API, provided by hncgcomm library, to interface with the protocol, so scope and effect of changes is limited to that library (and ofcourse the core-side module).

Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?