|
Which GUI library works best with Fluxbox?
Hi,
I am planning to develop an application that will have a GUI. The first priority is stability and second is performance. Portability and eye candy is not important. To fit these primary requirements the app will be run under and optimized for Fluxbox WM. What is the best GUI development kit such as Qt, GTK or FLTK that is best fit for such an app? I mean what is the most stable, reliable and fast GUI development library that works best with Fluxbox? Thanks in advance for answering this question. |
Most of my favorite applications are QT and work just fine. However from what I've seen most other people take preference with GTK.
|
I read through most of the GUI toolits related posts and I am convinced that GTK or Qt are more then capable. My concern however is the size of these toolkits. Would using a light-weight kit such as FLTK gain any advantage in terms of stability and performance for an app run under Fluxbox?
I come from windows/.NET background and I know that while it's easy to build a feature-rich GUI app in c# it quickly becomes very bloated and very slow. That's due to the sheer number of layers of libraries and the calls between the screen and the actual graphics engine, as well as because one control is inside another, inside another, ... By the time a mouse action gets to the OS graphics engine it's days. Not to mention the system resources consumed. I am just worried that if I build a screen with lists of widgets in Qt or GTK there might be a similar problem? (I am sure not to such extent) |
Hello,
I don't want it to sound offensive, but please stop being paranoid of the stability/performance of GTK+ and Qt. Those toolkits are developed by a lot of experienced people and were started a long time ago, and I've also never seen an application crash because of GTK+/Qt. As for the performance concerns, GTK+ or FLTK - it doesn't matter, at least on a modern computer. Cheers, Ivo Georgiev |
Thanks for the replies!
I just learnt which apps on my Fluxbox are GTK and which are Qt and I find that Qt apps look more modern with nicer icons, roundness and general eye candy. However the fonts are a bit washed out like there is too much antialiasing of as if the monitor resolition is not optimal. I compared all this with the GTK apps. The GTK applications look a bit arcane as in pre-Win XP look. However the fonts in the GTK and the general look and feel very crisp and they seem to load and respond a little bit faster. I can feel a little bit of a bloat in Qt: I can see how the wingets are being built and then populated with values a split second later, as well as some flickering when opening dialogs from menus. Because I dont need the modern looks and eye candy of Qt I am close to deciding in favour of the crisp and nippy GTK despite its outdated looks. The biggest problem I got with GTK is that its natively in C and its c++ wrapper might rob it off its performance advancage. If people could comment on this I'd gretly appreciate it. |
My only comment is that I think you are working to hard on this. As a user, when I install something, the package manager gets the required libraries--be it GTK, QT, or something else. I could not look at any of my apps and tell you what toolkit it was built with.
I would choose based on ease of use (during development) and licensing. |
There's no such thing as "optimized for Fluxbox." And the kinds of app that use GUI toolkits spend 99.99999999% of their time waiting for user input; the choice of toolkit makes no speed difference at all.
That said, I like Qt best. It's object-oriented, has extremely good documentation, and is as fast as anything as long as you're writing a Qt app and not a KDE app. Here's an article on how much though was put into its API: http://doc.trolltech.com/qq/qq13-apis.html And here's a KDE program I wrote. Using Qt didn't slow it down. Writing it in Python didn't slow it down. Making it a KDE program and not just a Qt program did make it take longer to load, but it ran at the same speed. http://www.vcn.bc.ca/~dugan/quetzalcoatl.html If your target platform is a Pentium 1 (speed differences between the toolkits aren't detectable otherwise), then use GTK1. It's faster specifically because it doesn't go through Fontconfig or Cairo do to font rendering. Which means you lose support for Unicode characters and decent font rendering, you only have access to font directories specified in xorg.conf (which is no longer present on many installations), and you need to specify fonts via variations of the mile-long names you see in xfontsel and xslfonts. Quote:
See: Quote:
It is very unlikely that you'll find even a technical speed difference between the current versions of GTK and Qt, because they both call the same sets of libraries (e.g. Fontconfig and Pango for font rendering, X to draw widgets) underneath. And no, launching a completed GTK app and then a completed Qt app doesn't tell you anything. Instead, write a Hello World program in GTK2, Qt4 and FLTK and see if you notice a speed difference. Quote:
http://qt.nokia.com/doc/4.0/qt4-arth...uble-buffering Quote:
|
I hate GTK style file pickers (like Woodsman iirc) but as an end user I much prefer GTK over QT. Most apps use GTK or another non-QT toolkit and I don't particularly like having both loaded. In addition, QT is a very large package and as someone not using KDE it loads many unneccessary libraries that take resources. Granted on new computers it doesn't make too much of a difference but that is my opinion, as someone who runs xmonad instead of KDE. If it's an app I won't be running 100% of the time then sure, QT is fine. If it's something I'm going to be leaving open then I would much prefer GTK since it'll be loaded on almost any system anyway due to the number of apps that use it.
|
I agree with Duganwhen - the GUI is not nesessserily is the bottleneck. What I said about some apps' dialogs loading slower in Qt is absurd actually. However there is another small difference between the two: I opened some apps written in GTK (GIMP and gFTP) and some from Qt (Korganizer and Kontact) Once loaded, I go to GTK GIMP's Open Image dialog and simply drag around the corner of the window reasonably fast - and the contents of the dialog are resizing instantly and crisply.. Same story for gFTP - when quickly resizing the window the contents responds instantly and very smoothly.
Now when I try dragging around the corners with Qt apps - the contents is being resized and redrawn with a signinficant lag. Please tell me if I am wrong but this is the sign of a (minor) bloat. I havent seen the Qt code but it seems like it's the case of Qt GUI objects being large and heavy, while GTK+'s are small and granular. Judging by this and from my .NET experience I suspect Qt has to be easier and quicker to develop, while DTK would be harder and a bit akward. However the performance seems to be on the GTK's side. What are the holes in my argument? Please comment. |
Korganizer and Kontact don't use Qt dialog boxes. They use KDE dialog boxes. There's a difference.
And if you're determined to choose the toolkit that performs better now (keep in mind this may change), then you should run formal performance tests that give you numbers to compare. And publish your findings because no-one's actually done that yet. EDIT: Found this. I don't know how relevant or current it is, but it's interesting: http://zrusin.blogspot.com/2006/10/benchmarks.html (Lots of interesting stuff on that blog, actually. Check out the front page). And here's some benchmarking information that I just came across: http://gtkperf.sourceforge.net/ http://pepper.troll.no/s60prerelease...tutorial5.html |
Thanks for the replies,
After another 2 days of research I chose FLTK. GTK and Qt are good for writing apps to be widely distributed. I need a light GUI front end controller for a heavy back-end processing app that will only be used on one machine. FLTK seems to be perfect for that. |
| All times are GMT -5. The time now is 05:42 PM. |