Following my disgruntled post on Gnome and GtkSourceView last night protests broke in Europe (and even in France).Seriously, some people may think that I am talking nonsense and they are entitled to their opinion.
But I am considering rewriting the UI for ZeroBUGS using KDE. I am sick of this game of ever shifting APIs. Say what you want about Windows, but the Win32 API stayed backwards compatible for as long as I can remember.
Those folks do not get it: when you break the API you generate more work for developers like me: I have to carefully track the changes, decide whether to stay with one library or change my code to the new API? is the end-user going to have all the dependencies easily resolved or do I need to ship additional shared libraries? Merde.
Ed: Max wrote a very intriguing comment about http://www.fltk.org/. Worth considering, thank you kindly, sir!
6 comments:
You're free to do whatever you like, and there are probably benefits for you to switching to KDE. However, you realize that at the moment you're writing this KDE is currently working on KDE 4.0 where the API of ALL OF THEIR LIBRARIES are theoretically changing. And you single out one particular GNOME library that never guaranteed a high level of API stability (it's not in the GNOME developer platform, it's in the desktop release set -- see http://live.gnome.org/TwoPointNineteen), and use that as an example of how bad GNOME is? They even did the right thing and made it parallel-installable. There are libraries in existence that for one reason or another cannot give iron-clad stability guarantees. Yeah, it sucks when they break compatibility, but sometimes it happens. You're free to avoid them of course.
You are correct, and I should probably think twice about KDE.
But I just had to vent... I chose Gnome for my project a few years ago because I found it lightweight (by comparison to KDE).
But then the 1.2 to 2.x wave of changes came, and I had to keep up.
I had to come up with some crazy adapters so that I can build on older platforms such as RedHat 7.2 and 9.0 (yes, some companies are using those still).
So with every incompatible change it feels more and more like an uphill battle.
Personally I like FLTK ( http://www.fltk.org/ ) for GUI work, but they only offer GUI capabilities. You want anything else and you'll need to bring in another library (printing's the first that comes to mind, but I don't think that'll be useful for ZeroBugs).
Noticed your comment added to the original article. I learned about FLTK back when Stroustrup was teaching intro to programming classes at Texas A&M. It used to be possible to download the notes for the class even if you were not a student at the school. The GUI assignments use FLTK.
And I like the overall design of the library.
Max, I looked up the FLTK website. The widgets look nice and being cross-platform gets them a big star in my book.
One thing in favor of either GTK or KDE is that applications look more integrated with the desktop.
But it is good to know that there are alternatives out there. Thank you for the link!
My thanks to Max for mentioning FLTK. :)
I toyed with it these weekends.
Nice, cross-platform, lightweight... Big plus.
But it has a long way to go before it can be used in real production-scale software. Here's why:
1. No internationalization support. You must use libintl or similar library if you want your program internationalized. Strings in built-in dialogs must be internationalized separately (i.e., you hack the source code and get what you want). Compare to Qt's built-in internationalization support.
2. Big problems with non-latin filenames on both Linux and Windows. Built-in dialogs show accented garbage instead of cyrillic letters in Russian locale. For Windows, you can overcome this limitation with relative ease (just call Unicode versions of FindFirstFile()/FindNextFile(), and then convert Unicode to utf8). For Linux with non-utf8 locale, there is no simple solution.
Again, compare this to Qt's built-in support for Unicode. In Qt, there are absolutely no problems with ANY encoding in ANY language.
Post a Comment