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, August 08, 2005

Portable GUI programming - on Linux?

Ahh, the pleasures of Linux GUI programming. When you'r writing a "portable" command-line application, generally "portability" boils down to 3 platforms - Windows, Linux and Mac OS. When you'r writing a GUI application, you'r dealing with 8 platforms - Windows, Mac OS and 6 major linux distros, each and every one of which do things differently.

Take a simple example - we'r using a specific, commonly-available fixed-width font in the Console interface. On Windows, it's called "Terminal" (the same one used in command prompt), and must be used at size 10. On Ubuntu Linux, it's called "Console", and must be used at size 16. On Fedora Core 4, it's called "console8x16", and can be used in any size. On Mandrake 10.1, it's called "Console" and must be used at size 10. On SuSE 9.3, it's called "Misc Console", and must be used at size 10.

I'm not even going to the QT vs GTK war that we will have very soon around here anyway. "But I want it native in Gnome/XFCE4/etc". Yes, sure, but then it wouldn't be native in KDE :).

Seriously, the only way to provide a consistent look and feel of your application across the myriad of Linux distros and configurations is to have a fully skinned app. And then everyone just shoots you on general purpose - "But I want it native! You'r evil windows-dev! Go away!". Been there, done that, thank you very much :)

So anyway, here's the plan - based on Distrowatch, the top5 distros are roughly SuSE, Ubuntu, Fedora, Mandrake and Debian (not in any particular order). Hence, the plan is to support those completely, and everyone else needs to somehow manage as well - it's not humanly possible to support the gazillion of Linux configurations out there.

Now, since all our GUI stuff is being written using QT4, this puts GTK-based distros into a disadvantage - this includes Ubuntu and Fedora. I saw how it looks like on those distros, and I'm not happy; but then again, we have the same problem with Classic theme on Windows as well. So - either I figure a way to enforce Plastic skin (comes with QT) in those cases, or write some custom skin for that (doubt we have the time for the latter).


Anyway, enough ranting. Finally got the core/gui comm stuff moving again tonight, despite the fact that we still have some unresolved problems in the Console (log window is a performance hog when lots of log data is in there already) - namely we have initial downloadlist and updates monitoring capabilities. It's still very buggy, but it's progress.

Hydranode r1697: Windows Linux Source

Madcat, ZzZz

PS: Linux builds now also work on GCC4-based distros (e.g. FC4).

Thanks for the new binaries, Madcat!
I was still using 0.1.1. These new releases are so much better. Thanks!
MadCat, why just don't go another way? You use one boost lib for core, start use wxwindow or somthing like that? one standart gui lib, that ported on all possible OS?
We'r using 6 (six) dll-based boost libraries, plus about 20 header-only boost libraries in core, just for the record.

As for wxWidgets, I'v done wxWidgets programming in the past, and it's a piece of crap. You have to do a TON of platform-specific coding if you want slightly custom stuff, it doesn't support theming... If you compare them head-to-head, QT has much better API, very good feature-set, and is just as native as wxWidgets, and runs at the same amount of platforms as wxWidgets. And wxWidgets doesn't look native on KDE, just as QT doesn't look native on Gnome, so in the end it's still either one or another.

The decision was made several months ago, and this isn't going to change. If someone wants to write wxWidgets GUI, go ahead, the Core/GUI comm protocol is open.

Just a short suggestion about the daily builds: It would be nice if the windows build didn't just dump the files on your harddrive without any warning and without even letting you know where they will be. A plain Zip or .7z file would be alot simpler.
Huh! zip - suxx...
Huh? Zip? 7-zip?
Well, better zip then. At least it is decompressable by default on Windows and IIRC MacOSX.

To be blattform-independent use tgz/tbz2. It can be decompressed on any plattform, too (on WinDOS via WinRAR).

No compression algorithm pls, just provide both tarball and zip. Tarballs are decompressable on unices while zips are decompressable on win32s.
Post a Comment

<< Home

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