Ask Slashdot: What is the Best GUI Framework? 432
The following is from Slashdot Reader, exa.
I wonder which GUI frameworks are the cheesiest to code with and what makes a GUI framework good. Previously, I've been involved with GUI programming on GNU/Linux, Solaris, Amiga and Windoze 9x/NT platforms. It is then not so surprising that I ask /. about GUI programming ;)
In particular, I'm pursuing GUI programming for X11. To give interested hackers a boost, I present the following remarks on how a framework should look like (in no particular order):
- In general, a robust and scalable GUI framework, in C++ or a prominent OO language like Ada9x, is very desirable.
- XFree86 is all pretty good. But times can change, so a framework with platform independence has its pros. (And multi-language capabilities count as well)
- Many libs don't have a good design. A great GUI framework must attain design goals such as uniformity, modularity and comprehensibility.
- For a good design, it should make use of certain design methodologies. For instance it might adhere to a design pattern like MVC.
- The license does matter.
- The framework, where applicable, must support standard stuff. At least it should not disallow use of them. For instance, you'd want threads, you'd really want TCP/IP, you'd like reading in JPEG files.
I also wish to make some comments on a few of the popular GUI frameworks:
- Motif based stuff such as BXPro: I use free software, and on my system Motif progs just look antique. What's more, they are lightning-crash-and-slow-motion. I don't possess a Motif 2.1 product and I don't plan to. How perfect they might be, I am skeptical about them. (I did write with pure Motif, and I'm outta the game)
- QT: This lib forces you to write in a certain style. The keywords introduced by means of moc are not a proper C++ extension. CPP macros, thus signal/slot mechanism is ad hoc. A fatal error is in their failure to recognize standard C++ library. And the license is boring.
- Java swing: The successor to awt has several advantages over the previous. Although I basically dislike Java language, the GUI subsystem features a somewhat nice design.
- GTK+: A framework that has a well defined run-time system. The types give a formal way of handling a general OO design. Multiple language bindings. (C++ bindings are cool)
- JX: After seeing how Code Crusader performed, I abandoned work on it. But still, something that works.
- Other Stuff: freshmeat lists other "widget sets" too, like the FLTK and TOAD which are LGPL'ed. By the way, don't even think of MFC. It is the worst GUI lib that has ever seen the light of sun. It is *not* designed. (I worked with it over a year... :-
Note that I'm not concerned with the user interface, docs, distribtion, etc. of the applications written with a particular lib. Thus, I'm not suggesting a GNOME/KDE flame war. The only purpose is to assess the quality and performance of the software that underlies graphical applications. In this sense, I don't ask how a user interface should be designed. In addition to this, I don't ask what tools are available for the software (like GUI builder). The two chunks of comments above determine my primary questions:
- What are the aspects of the ideal GUI framework?
- Among the available software, which GUI frameworks for X11 are preferable and why do we pick them?
Ed: This is a heavy topic, so I'm hoping for some good discussion. If you feel the need to discuss GUI systems available on other platforms (X11 is rather limiting, other platforms may do it better!) feel free. I don't want to stray too far from the original question, but I would like to know what you all think the best GUI framework in existance is. I got quite a few submissions similar to this one so to those of you that them in, I hope this topic covers what you were asking. If it doesn't, you can always send those burning questions back to me by re-submitting them.
GTK+ (Score:1)
I like QT/KDE (Score:1)
Swing rocks. (Score:2)
[HT][X]ML (Score:3)
The biggest advantage being 'Open Source'. And, yeah, it's probably not so appropriate for a Word Processor, but I just see so many apps that are just list/edit/text/combo/whatever boxes put on a form. You should be able to do that with HTML/XML.
It may also be a way to seperate the GUI from the actual application better, because still too many programmers embed the entire app right in all the GUI code.
Visual Basic, Delphi and C++Builder are nice examples of environments that stimulate that behaviour.
Well, heat-shield up, Breace.
GUI/API programming... (Score:1)
wxWindows ins't a framework, but (Score:1)
Its scripting language bindings are especially impressive.
-Billy
IBM Open Class Lib (Score:1)
The new Java one, definitely (Score:2)
Curses library is by far superior. (Score:2)
Re:[HT][X]ML => for some stuff, he's right! (Score:1)
Problem: it was a web-based app which could have been completed several months faster (and just as easy to use) if we had done the GUI in HTML instead of XML-defined Java (the XML part was cool, and would have translated well to dynamic HTML, but using Java instead for the actual interface was pretty pointless).
So sometimes HTML is better.
Sounds like you've already made up your mind... (Score:2)
I was going to mention Qt since I find it to be a very clean interface, but you've already decided. But I find it curious: you first say that license doesn't matter, then you blast Qt for having a "boring" license. What gives?
p.s. If you're worried about the so-called new "keywords" in Qt, take a much closer look at them. They aren't keywords.
Be (Score:2)
Also, I don't mind that all of the GUI classes for things like buttons, lists, and scroll bars are consistent and clean.
All of the above is basically highly opinionated personal preference, of course. Also it helps if you don't hate C++.
-jwb
Sounds like you didn't read the article (Score:1)
If you read the article, he says that the license does matter.
-jwb
FOX (Score:1)
http://www.cfdrc.com/FOX/fox.html
It is under the LGPL too.
Re:NO! MAE LING MAK NAKED AND PETRIFIED (Score:1)
I once saw... (Score:1)
Galaxy
Galaxy had its problems. The C++ interface was clunky. It tried to be a virtual OS instead of a GUI toolkit (maybe a feature for you, maybe a bug). It could be really slow, especially with the object-factory and RPC functionality built on top of the object-factory stuff.
But in terms of "I need to smack a professional-looking interface on my product in 5 days" it was really sweet.
3 things to value in a GUI framework (Score:1)
2. Language independance. I want perl bindings, C bindings, your-language-here bindings. I don't care if you wrote the GUI interface in C++, just don't make me use the bloody language if I don't want to.
3. Simplicity. I want a toolkit, not a whole platform. Let me define my own data structures. Don't try to get me to use YourToolkitULONG when unsigned long works just fine. One thing that's annoyed me about some toolkits is that they want to "take over" the whole program in that way.
Swing & Delphi (Score:1)
Mozilla XPFE (Score:3)
- XML based (XUL)
- XUL can include arbitrary HTML elements (want an MPEG in your menus? That's easy)
- Write UI code in any supported scripting language (currently only Javascript though) using standard event model
- Dynamically modify UI via standard DOM interfaces
- Fast, powerful dynamic layout engine
- Seamless Web integration (duh)
- UI talks to backend components through language-independent XPCOM
- Runs on all important (and many unimportant) platforms in various toolkit combinations (potentially KDE/GNOME agnostic)
- Skinnable using CSS
- Fully open source
- Leveraging Web standards means it will grow with the Web (e.g. JPEG2000, MathML, SVG)
Well, that's the plan. There's still some distance to go, but the basics are all there and working.Re:[HT][X]ML (Score:2)
HTML is a bit limiting. Using tables to lay out widgets is Ok, but missing progress bars, and hot beng able to give user feedback except as the result of clicking a submit button is a big big disadvantage.
The only thing with a real GUI I have done in years is a MP3 jukebox player (streaming mp3's over HTML into mpg123). As it selects songs randomly (baised on user ratings) it needs to display the song title (and disc name, and the band, and the current rating, and blah blah). It also wants to display a progress bar. Oh, and of corse it wants to play the sound on the machine with the speakers, not the server in the machine room.
I did do a GUI mock-up in HTML, and that was pretty good. Actually a friend did a set in HTML after I did one or two in pencil. That was very helpful. Showing off the HTML one to a few potential users was much more useful then showing my cruddy pencil drawen one.
I imagine many other GUIs have similar problems. I expect alot of them would also be doable in HTML with varying degrees of suckage.
If you want it done right, do it yourself (Score:1)
Platform independence is not hard to achieve if you just want to port among *nix systems, just have your widgets draw themselves using X and GL, or your own software rendering. I don't know about other OSs (I dislike greatly the win32 API).
Anyways, that's my 2 cents. I built my own toolkit that'll compile on any *nix system using X, and C++ in about two weeks. I do not consider myself a genious when it comes to programming (yet, heh), so to anyone not satisfied with current toolkits, build your own!
Note: I don't suggest starting out on this if you have no prior GUI programming experience.
Yet Another Note: When it's a little more mature I'll open source it (around christmas).
A framework isn't a toolkit... (Score:1)
-Billy
Re:Tk of Tcl/Tk is (not) best (Score:1)
It's utterly bound to Tcl, for one thing. You have to link Tcl in in order to use Tk.
There are many better toolkits, you just have to give them the same chance you gave Tk back when you first learned it.
-Billy
TurboVision (Score:1)
Anyway, what's good about my lib/turbovision is it's (general) ease of use and extensability. Coding for either is actually fairly clean. IMHO, Borland did a good job of designing TV and I feel that I copied their good bits and added a few of my own. For anyone who's interested, the dos/text version is availabe on my webpage (via the editor link), or you can email me.
Re:[HT][X]ML (Score:1)
My thoughts as a user not a programmer (Score:1)
we like. In my opinion motif sux and is a dinasour
java has potential but is still slow on my machine
and then there is Qt and GTK. How i see them is
something that is good for those who program but
it is not pretty from a user's standpoint. I am
a linux only user just to note but windoze has a
far superior feel than any of the X stuff. I
mean KDE and Gnome are good but not drag all over
and pretty as hell graphics. Dont make me out to be one sided on the issue, i think win has all kinds of problem. But i do feel that the look and feel of X is far behind.
doh. (Score:1)
...
Interviews and Fresco (Score:1)
The "Design Patterns" book is based in part on the experience with Interviews.
well.. (Score:1)
Re:If you want it done right, do it yourself (Score:1)
Re:GTK is the only choice (Score:1)
On the mac: PowerPlant (Score:2)
I wish there was a framework that good on X...
Motif: Blech. Proprietary and ugly.
Lesstif: Well, it's free, but it's still ugly and non-themable. I haven't looked into the API though.
Qt: Looks ugly. I've heard bad things about the "keywords" it adds.
Athena, Xlib, Xt: Yeah right... Maybe in the 70's.
Gtk: I personally write programs in GTK. I don't really like its use of its own types but I relize that it kind of is necessary. The GUI looks respectable and is themable. But GTK is SLOOOW and a resource hog, especially when combinded with Imlib. The C interface is object-oriented - and as I C++ programmer I don't see the value of object oriented C, with all of the complexity that it adds. I know that there are other language bindings but they probably don't support multiple inheritance, and they definatwely stick with Gtk's concepts... i.e. packing boxes instead of aligning things on a grid in an interface builder.
Java: Well, a very different solution. You need to learn a new language, although most people with Java experience say they would never go back to C++. The GUI toolkit sounds OK, and there are interface builders but AFAIK they are all proprietary (not acceptable). Java is still slow, regardless of what Sun claims (this is the present). And the Java software for Linux/BSD seems pretty weak. But Java is naturally cross-platform, and may be a C++ killer in 5 years. If so, the Java coders will already have the killer apps.
Re:I once saw... (Score:1)
>>layouts as data that an object factory would then instantiate.
So kind of like an XML file then?
>>A functionality-to-widget binding method that did not require
>>the code to find a particular dialog item. You just needed to know
>>the name of the widget and you bound your functionality to its name.
Berlin guys were discussing the "tasket" concept which seems to be
what you are describing here. You may have valueable knowledge
for that project.
Abstract the toolkit (Score:2)
Then isolate the GUI code into its own classes as far from your main code as possible. When I started a project in 1997 there was no GTK, QT was much more restrictive than it is now, and everything looked like shit. A year into the project, GTK was finished and QT was relicensed but still very restrictive.
A second year into the project direct GTK and QT access was phased out in favor of yet another layer above the toolkit. Now instead of interfacing the toolkit you really should interface a desktop library: Gnome lib or Kde lib. Now if you don't want to be stuck with one desktop you need to code that extra abstraction layer between your GUI code and the desktop library. Who knows how long KDElib and Gnomelib is going to stick around.
MFC vs QT (Score:5)
Firstly let me say I have nothing against GTK, I have little experience with it, but I constantly hear good things about it, and I've used some very nice GTK based apps.
Personally I choose to use a C++ based library over a C library, (and I'm unimpressed with bindings in general). To give you some idea of where I coming from I have experience with QT and MFC, I use both on a daily basis at the moment, have about a years experience with MFC (spread over 3 years) and about 6 months experience with QT. (I also have about 3 months experience with each of Java AWT, raw WIN32 & WIN16 api programming, and the Harlequin Lisp GUI toolkit).
QT is vastly superior to MFC. By coincidence the free software QT based development I have been doing is similar to (just from a GUI point of view) to the MFC development I have been doing, and this has given me the opportunity to compare the two.
Here are some observations.
Layouts
QT has good support for layouts, MFC has none. This means it is much easier to create resizeable dialogs in QT than it is in MFC. This means i18n support is easier in QT than MFC (no need to tweak your dialog for each language you support).
I especially like the QT grid layout that supports mutli-cell entries.
Tooltips.
Tooltips in MFC are a bit screwed, the MFC CToolTipCtrl isn't useful as is and you have to derive a class from CToolTipCtrl in order to use tooltips. This derivation isn't application specific exactly the same code is need in each app. Why? Quoting programming windows 95 with MFC "Late in the beta cycle, the Windows 95 designers recognized this problem and added some intellignece to tooltip controls so that the designers could do their own subclassing. Unfortunately, this feature was added too late to be incorporated into CToolTipCtrl". MFC programming tends to be like this, every simple little things requires a dozen lines of work before you start doing anything application specific. (There is a very good open source web site www.codeguru.com that has a collection of such code). QT doesn't suffer nearly as severely from this problem, QToolTip::maybetip lets you decide when to show a tooltip, where to put it, and what to put in it, just hook one up to a widget.
Documentation.
The documentation that comes (free) with QT is excellent, better than the MFC documentation I have. The 12 stage QT tutorial is excellent compared to say the MFC Scribble tutorial, I get the feeling that QT really is a toolkit whereas MFC is a framework. The QT class documentation has decent see also links (very useful!), and inline example code. Basically it is just of a higher quality than the MFC documentation. The QT source code itself is very readable and is a great source of documentation. (The MFC source code is not so useful)
Signals/Slots
The QT toolkit pioneered this concept and it is a good one. Basically they can be used to reduce code coupling and make it easier to create independent components. For high level stuff you don't have to derive a class and override a virtual method with a one line implementation, just connect a signal to slot. People hassle QT for extending the C++ language and this is a valid criticism, however in actual practice this has no drawbacks (you can still debug your programs with gdb and run make to compile all your source). MFC has a signal/slot equivalent "message maps", syntactically they are much uglier.
QTL vs STL
I'm all for standards, I really am. Neither MFC nor QT support the STL as a first class citizen. Unforunately there are compelling reasons for this when using (e)gcs. The egcs STL implementation is bloated and slow compared to the QTL. Syntactically the QTL is much simpler (eg container classes expose begin() and end() methods as well as providing external iterator classes). Still if you already know the STL this is an extra thing to learn.
High quality widgets
QListView is an awesome control unifying the TreeCtrl and ListCtrl concepts. In general QT widgets are done right.
Basically using QT has helped me understand why people complain so bitterly about MFC, and proven to me that there is a better way.
OpenStep (Score:2)
Warning though, the default bindings are in Objective C, an OO C derived language distinct from C++; ObjC has a distinctly Smalltalk flavor about it.
GNUstep [gnustep.org] is a GPLed clone. I haven't tried it so I can't comment on the quality.
Somewhat off-topic, the OpenStep Enterprise Object Framework is the best toolset/framework for working with databases I've seen.
GNUstep (Score:5)
I strongly encourage you to take a look at the Mac OS X Server programming tutorials [apple.com] on Apple's developer web site (in particular the Discovering OPENSTEP [apple.com] tutorial), and then at the state of GNUstep [gnustep.org]. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.
From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).
One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.
I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.
GUI framework.. (Score:1)
Re:[HT][X]ML (Score:2)
Re:OpenStep (Score:1)
Also, OpenStep doesn't have "bindings" -- OpenStep is built in and for Objective-C explicitly. Other languages can connect up to OpenStep via the Objective-C runtime, but it's fundamentally an Objective-C framework.
Finally, GNUstep is LGPL'd, not GPL'd. Big difference. :)
Otherwise, right on! OpenStep and GNUstep are the way to go.
Sounds like OpenStep (was Re:I once saw...) (Score:1)
GNUstep [gnustep.org] is an Open Source (LGPL) implementation of OpenStep.
Also, OpenStep's Objective-C programming interface is really elegant, and it performs pretty well.
And since Objective-C is a strict superset of ANSI C, interfacing with C (and C++ code) and wrapping an interface around other code is really easy.
Re:GUI/API programming... (Score:1)
FUD. You obviously have never written a Win32 program, and have no idea what you're talking about. Either that, or you write 10 lines of comments for each line of code.
If you don't know what you're talking about, keep your mouth shut. You just end up looking dumb. Win32 programming is a lot easier than making Xlib calls, and pretty comparable with GTK.
Heh (Score:1)
GTK C++ bindings cool ?? Better then QT ??
Have you actually tried QT ?? I doubt that.
You sound like somebody who mentions C++ simply because it is cool and hip but really at heart is a C programmer.
Re:GTK is the only choice (Score:1)
But you will learn, it will hurt but eventually you will learn
(hint
I wholeheartedly disagree (Score:1)
This is bad.
I'm not saying that every program should be cookie-cutter, but consistency is a virtue. Plus, don't forget that interfaces continue to evolve, and if you've used a standard toolkit, it is likely to evolve as well. Your program can probably take advantage of that evolution without needing to be manually updated.
IMHO, there are a few reasons to make a new toolkit:
1) There isn't a good one available (Motif probably started because of this)
2) None of those available do what you need (Probably why Qt started). Nowadays, this argument doesn't hold water; with C++ toolkits, you can extend the toolkit easily, and with open-source toolkits, you can modify the source and benefit the whole community.
3) None of those available have an acceptable license (Gtk).
There are also a few reasons NOT to make a new toolkit:
1) It would be cool / fun. Instead, concentrate on making your app cool / fun.
2) It would be easy (as easy as using an existing toolkit? I doubt it). It's much more important for it to be easy for the user.
3) You want to be famous / change the world. Sorry bub, it ain't gonna happen.
Speaking from the standpoint of both a developer and a user, my advice is: stick with standards!
Over and out.
-TomK
Re:I like QT/KDE (Score:1)
You might want to try AcceleratedX - it is truly at least 40% faster than XFree.
But I completely agree with your comment about QT.
It is the best toolkit available for UNIX period.
Re:Be (Score:1)
Additionally, the C++ mechanisms are very nice and well thought-out. I'm not particularly fond of C++, usually because I feel like I'm adding another layer between myself and the real API, but with Be the core API interface _is_ C++. I really hope things work out for Be, but usually the coolest interfaces (programmer or end user) end up dying (read NeXT, OS/2, etc).
Re:XP and featureful! (Score:1)
> that might be a problem for some. It takes advantage of GTK+ or Motif on *NIX. It also
> supports win32 and Mac.
Actually it's not C++ only. wxPython [alldunn.com] is a Python binding for wxWindows and it ROCKS! Once the Mac version is done it may very well become the new de facto standard GUI toolkit for Python, kicking Tk out into the cold.
Re:On the mac: PowerPlant (Score:1)
Bad things about "keywords" ?? There is nothing bad about it... Really, you should try it just like you tried GTK.
Re:Tk of Tcl/Tk is (not) best (Score:1)
BTW, if you thought Tcl/Tk was slow, wait until you see Perl/Tk.
You can also use Tk directly from C / C++, although personally I've never done this because the documentation of how to do it was severely lacking.
-TomK
Reality Check (Score:2)
1. If you look at the software available for Unix systems now, you will see that 99.99..% of it is written in C or C++. Not Java. Not Pascal. Not Ada9x mentioned by the original poster. What does this mean? This apparently means that any GUI framework worthy consideration probably has to support C/C++.
2. If you look at any extensive GUI framework in C, you will immediately see that as the number of features grows linearly, the complexity of API grows exponentially. Both Motif and GNOME are good examples of this. Again, what is the cure? Well, C++ is the only known cure at the moment, AFAIK. Some people do not like C++, but it does help to organize GUI APIs better. Look at Qt/KDE, BeOS, or Borland C++Builder for examples. So, the suspicion is that whatever "best" GUI kit you choose, it should at least allow an extension into C++.
3. The license must allow a person to sell programs written with the GUI kit. Period. LGPL doesn't cut it. If money is charged for the GUI kit itself, it must be in $100US range to allow us, the mere mortals, to buy the kit (>$1000US charged by Troll for its commercial Qt license is a bitter joke on programming community).
4. It is really helpful to have some GUI designer or a layout tool. Fortunately, most widely used toolkits have got such tools by now.
What does it leave us with? Well, basically, with nothing. Of well-known GUI kits, we are left with:
1. Qt/KDE -- It's a very nicely organized C++ kit which definitely comes up on top (yes, I can live with MOC, it's ok), but it's LGPL/Troll/GPL licensing makes it difficult to write commercial software (commercial Qt license is beyond the reach of most "normal" people).
2. BeOS -- Also a very nicely organized C++ kit, but we are talking Unix toolkits now, so no BeOS.
3. C++Builder VCL -- One more nice C++ kit which may become a killer when ported to Unix (you can divide your code and GUI in C++Builder, it just requires common sense). So far, it is Windows-only though. Period.
4. GTK -- The toolkit has become overblown, IMHO, both complexity an speed wise. It may be a result of too many people trying to develop it (KDE lacks this problem), but I think that it is rather a limitation of C (as opposed to C++).
5. WINGS -- Very nice C-based toolkit, really easy to program with. Two problems here: 1) dependency on WMaker and 2) Lack of development. It is sure to hit the complexity threshold if it becomes extensive though.
6. Java awt/sling/whatever -- You really can't expect people to use Java programs. Slow. Unstable. Incompatible between releases of Java. Require megabytes of Java installed. How many of you have deleted a program off your Windows system after finding out it is written in VisualBASIC and requires MSVBVM.DLL (or whatever it is called)?
7. Delphi -- It is very nice. It is Pascal. Most contemporary programmers would expect compatibility with the C/C++ code though. So, use C++Builder. And still, Delphi is Windows-only.
8. XForms -- Simple, easy to program C-based toolkit. Same problem as with WINGS: lack of active development. Same warning: at some point, it may become to complicated and require switching to C++.
So, to summarize: There is still no ideal GUI toolkit for Unix right now. But Qt/KDE would probably quickly become and ideal toolkit if it allowed normal commercial usage, possibly for a modest fee.
Stability? (Score:2)
The original Qt toolkit was a beauty as far as stability goes- versions 1.4x were all pretty decent as far as looks go, and they were STABLE beyond belief. KDE 1.1 still runs for days at a time on my system. But, sadly, it's not that fast on older legacy hardware- which is the famous old "Only two out of three" rule at stake. If you run Slack/KFortune, you've probably seen the rule "You can have it done fast, you can have it done cheap, and you can have it done well. But you can only have two of those at once." I think that's pretty much generally true- because I run Qt-2.0 on my system, and it is much prettier than the old version- but it's sacrificed more speed. And it seems to be just as stable, although I have only tested unstable versions of KDE2.0preAlpha on it; I get the feeling that the actual toolkit is still as stable. The apps crash, though not as frequently as some of the GNOME 1.0 ones.
So it really comes down to what your pref is- I can live with stable/pretty. I know as well as everyone else here does, too- Motif sucks hard. It's none of the above- it's ugly, slow, and jittery like an old wooden rocking chair (regarding stability). Netscape, which IIRC is programmed with Motif, crashes hourly on my system- but then again, I'm waiting for the Opera browser to be released for Linux. Kfm is nice, and usable, but I like Java stuff and it seems to be kinda... Explorer-ish. Oh, and Mozilla, strangely enough, doesn't seem to like libc5/glibc2.07 (which is on my Slack system). Otherwise, I'd use it; but then again, personally I don't prefer the GTK+. (Could you tell?)
So you want that fast, pretty, or stable?
(Done right, done fast, or done cheap?)
-Chris
Re:GTK+ (Score:1)
But hell, what else you can expect from UNIX type of crowd who came up wiht original Athena stuff..
Re:GTK+ (Score:1)
Re:Agreed. (Score:1)
Re:Whoops! (Score:2)
But I still wonder why a "boring" license is a concern? Is Qt too boring? I mean, people used to pull out the heavy artillery everytime it was mentioned here
Don't hate me for this but... (Score:1)
Without looking at the programming aspects, I find Windows NT/9x the nicest interface. This doesn't really deal much with the question at hand... but I wanted to state that. The Windows widgets are small, yet work well (when the OS chooses to run anyway:).
I find too many borders and oversized task bars in Linux. I have a large monitor and run at 1280x1024 resolution... yet I still find the task bar and border space consuming.
I am sitting here on my workstation, and comparing the UI to my Windows laptop.. maybe it's the font support, maybe it's the icon size.. I can't put my finger on it.
And as far as the programming goes... I've really only used Perl/TK and hacked up various KDE apps. I have nothing to say about the code... I'd rather have my code fit in with the "window manager". That way one only needs to hack just one config file to make my apps look pleasing to them.
Oh for the love of god! (Score:1)
Why does every other slashdot post begin with this?! Just because you don't agree with somebody, or you have had different experiences, you don't have to attack them.
Re:Reality Check (Score:1)
However, your compain about QT having "restrictive" license is , excuse me, complete bullshit !
Lest's take a look:
- you can develop free software , right ?
- can have source code ( perfect when trying to implement your own widget ) !
No, but you want to develop commercial software and benefit out of it but you deny the same right to Troll. What the fuck is that ?? How the hell they are suppose to stay in business ?
I am absolutely sure that the they QT license is modified to allow free commercial usage, Troll people will have to start looking for other jobs ( which by the way woudn't be big deal for them as they are excelent professionals)
Re:MFC vs QT (Score:1)
By the way, most of the "software" written in GTK is bunch of 200 line frontends to varius command line tools.
Re:GUI/API programming... (Score:1)
Are you sure you aren't thinking of MFC? Using the Foundation Classes does make it possible to write a fairly compact program (compact source, anyway). These days it's common for many people to confuse MFC with straight Win32 programming, which isn't done very often anymore. I only use Win32 calls to read and write my software's
Re:Abstract the toolkit (Score:1)
No thank you..
Re:Reality Check (Score:1)
Can you elaborate on this point? (I don't code gui's, so I know nothing about gui specific problems. But I've always found C++ pretty slow & useless.) What's the scoop? What is an example of the problem & how does C++ solve it?
You're not using it right. (Score:1)
They're not supposed to go anywhere near your ass.
Re:Oh for the love of god! (Score:1)
hello.c: (win32)
#include "windows.h"
int WinMain(void)
{
MessageBox("Hello", "Hello", MK_OK);
ExitThread(0);
}
... or something like that. The parameters are close but not exact.
All the people yelling things like "use NCURSES!" are completely missing the point. The guy wants a *GUI* toolkit. GUIs have a place, as do CLIs.
---
Joseph Foley
InCert Software Corp.
Ah yes, I remember VIBE. (Score:1)
You know, I wonder if there's any chance that the source code to VIBE might be made available to the public? I remember discussing this possibility with one of the engineers a few years back when I was quite entrenched in using VIBE as a development tool, and he said there was some interest in doing this...
I suppose now with all the assets of Visix being traded around amongst banks and whatnot, the chances of this happening are pretty slim.
Still, it was indeed a great toolkit - it had springs and struts before pretty much any other toolkit for Java based development had 'em...
Re:Oh for the love of god! (Score:1)
Re:[HT][X]ML (Score:1)
It sounds like mozilla is shaping up to be a potential answer to this need. If nothing else, it's OSS, so it might end up being at least a base that could be used for this. Kind of an "app browser" if you will. I think it'll happen sooner or later, but maybe that's just me :-)
This is a religious question (Score:4)
First of all, I don't believe XML/whateverML/Mozilla to be the answer. I don't want my application written in a scripting language. Running everything through your browser is a bad idea, and everyone except MicroSoft thinks so. Frankly, I haven't seen a browser that doesn't suck (except Lynx!) and I'm not convinced I ever will. I'm not that impressed (yet) by the Mozilla efforts, tho I support them.
I'm only going to consider compiled widget toolkits, no Java. I'm sorry. Java sucks. It involves way too much typing, and it's slow. I don't approve of anything that makes code slow. The whole point is to be fast.
What does that leave?
1. Motif I once sat thru a college lecture on Motif. In an hour, the lecturer had managed to cover use of the clipboard. No function name was less than 20 characters, and it took 15 calls to get the most basic thing done. No wonder Netscape under Motif was ~1million lines. 'Nuff said.
2. MFC MFC isn't really so bad as a design. It can be annoying, and it often lacks flexibility, but it's not completely unusable. However, I find that using MFC (specifically in VisualC++, which conveniently writes the hard/annoying parts for you) is a good way to kill a project. It forces you to use their class heirarchy and objects, and if the generated code gets screwed up you can be in real trouble. The usability is also heavily dependent on spotty MS documentation -- if the documentation is bad (eg. the MDI multimedia devices in VC5) figuring it out can be a chore. A mediocre choice at best. At least it has nice built in database drivers.
3. Visual Basic has got to be the quickest way of throwing together a UI I've ever seen. I really like it, especially for prototyping. I have no speed problems (since it's compiled now and officially in my OK book), but BASIC can be a dreadfully limiting language. Writing the interface in VB and all the hard code in a DLL isn't a half bad idea, tho. At the very least useful for trying out interface designs on people.
Some built in database drivers.
4. PowerSoft Power++, Borland CBuilder I've only ever used Power++. It's really just a wrapper around MFC classes, but it cleans a lot of stuff up and does all the hard stuff. It still pushes you to use MFC-type objects, but they're quite a bit less ugly to work with, and the docs are better. But if the rest of you're code's not in Watcom, Power++ might cause compiler issues (which is why I eventually dropped it). I've never use CBuilder, but it's more popular than Power++ so likely as good or better. Both of these are probably very good, fast ways of getting an application written. Mad build in DB drivers.
5. Gtk+ A very nicely written, madly flexible widget toolkit with the added benefit of almost no baggage. In other words, at no point do you subclass some dialog box to start writing code. It's C dammit, there's nothing to subclass! This has great advantages, even for a bigotted C++ coder like myself -- it means that my application's structure, instead of the widget toolkit's, determines the structure of the code. The result is a much more maintainably laid out project. I also find gtk+ quite fast to work with. You can pack the dialogs in code and know exactly how they will turn out, write your handlers and you're done. Unfortunately there is no built in DB support anywhere -- it's a pure widget set, and you're on your own. You could always use direct SQL, or pick up one of several DB libraries I've never used (any recommendations?). Also, the function names are kind of long...oh well. Another plus: Gtk+ has a bajillion language bindings.
I've never used Qt so I'm afraid I can't comment...
I'll choose Gtk+ as the preferred widgetset. Applications written with it (rather than around it like some others) end up far more maintainable IMHO, and that's the most important thing for app developers.
One more note: GNUStep (Score:1)
It's called "Objectionable C" for a reason.
Go code in C++ you weenies!
(warned ya I was a bigot)
Re:Whoops! (Score:1)
Re:GNUstep (Score:1)
Considering I can't for the life of me figure out how to use a Mac (it doesn't have any nipples...it's not intuitive in my book and I couldn't find the man(1) command) I don't think I'd enjoy it.
Seriously, the Mac's a pretty limiting environment. It's a padded room. Is that really where you want to be coding? I sure don't.
Re:I once saw... (Score:1)
I was particularly fond of the spring and struts mechanism for putting together dynamically sizeable windows. The layout mechanism allowed you to specify fairly arbitrary constraints on any widget that got placed in a window or other component. I consider it an even better system than the fabulous layout managers we see in Java's AWT or Swing toolkits.
The GUI designer was a wonder to work with as well. I managed to prototype our entire user interface in what seemed like no time at all. We were then able to take some screen shots, clean them up in Photoshop, and drop them straight into our design documents. Our clients loved it. The docs looked great, described the interface far better than prose alone could have, and we hadn't even written a single line of code!
I see a great deal of potential along these lines with Glade (and libGlade). Storing the interface definition as an XML file is a fabulous idea. This gives you far more flexibility than Galaxy ever did, especially if you need to programmatically alter your interface, or perhaps translate it for internationalization purposes.
Now if only we can get springs and struts into GTK+...
Re:well.. (Score:1)
From my experience somebody who develops GUI based software and proclaims that is a mainly C coder, has never tried C++ and simply doesn't realize how easy is to do stuff using properly created C++ GUI API ( Qt comes to mind.)
C is perfect for some things but if you claim that one of them is GUI development then your are using wrong tool for the job.
Try it
Re:One more note: GNUStep (Score:2)
The same people tend to not like Objective C who don't like Smalltalk... there's a lot of lip service given to OO lately, but most folks have forgotten about the OO-est language that ever was.
FWIW, despite its popularity, there are some bogglingly-good coders out there who find that C++ is hackish and unreasonable, whereas Objective C is closer to being something usable. In terms of really being OO/providing the advantages that OO is meant to provide, Objective C is (arguably) a better solution. C++ is much more widespread, and (arguably) easier to learn. I guess it's all a matter of taste.
Either way, trying to turn C (portable assembler) into a messaging, OO language is one of those "impossible" computer science problems that will probably never be adequately solved. To wit: OO and compilers don't mix. First person to come up with a weakly-typed, late-binding, polymorphic cross-compiler, wins.
depends on application (Score:2)
As for the C/C++-based toolkits, none of them are particularly fun to use, and I think that's really the fault of the underlying languages. Neither C nor C++ are particularly conducive to writing GUI applications (but with enough effort, anything can be done). Among the C/C++ toolkits, I like GTK+ best. Qt isn't bad, but because it's C++ based, its uses are more limited.
OpenStep looks like a great system, and I have used small bits and pieces of it, but the lack of standardization of Objective-C and its limited availability make it an impractical choice for me.
MFC/Win32, however, wins the prize for being the uniformly worst designed and worst implemented GUI toolkit I have ever used, but its popularity makes it unavoidable sometimes.
So, I use multiple GUI toolkits, depending on what I need to do. And different people prefer different toolkits depending on their needs and constraints.
Merits of Java (Score:2)
The AWT was decent given the enormous stride JavaSoft was attempting in cross platform VM architecture. Swing is another giant leap forward. Perhaps many of the PERL types around here don't like having to operate in a pure MVC architecture. However, my experience is that Swing results in much less code and great reusability and ease of debugging. It is still slow, but not too slow.
I've implemented very large systems that hold up in a real-time environment in a major RBOC's network engineering and support center. Our Swing applications (not applets) function without flaw on Solaris, NT, BSD and RH Linux. We only had trouble with Macintosh.
What I think many around here don't fully comprehend as that these polarizing, religious positions being taken are exactly the same kind of fractionalizing that tore the BSD community apart. If you continue to drive out differing opinions you'll end up with a real kick-ass system that no one serious uses. I, for one, think I'll take my efforts and ideas somewhere else more tolerant of diversity.
Re:Whoops! (Score:2)
Re:Qt Comeliness (Score:2)
Post Qt2.0 has fantastic styles! I mean WOW! It comes standard with Motif, Windows, CDE and Platinum styles and additional styles are extremely easy to add. For examples, check out some of the KDE2.0 screenshots.
By the way, THEY'RE NOT KEYWORDS!!! If they were keywords, Qt apps wouldn't be able to compile under g++.
REALbasic approach (Score:2)
Essentially, the entry level is absurdly easy. RB has various controls that 'run themselves'- if you drag a button onto a project and immediately build it, the button knows how to be clicked, but doesn't do anything, and the project has a 'quit' menu item that has a 'command-Q' keyboard shortcut like a proper Mac app.
When you write code (and you could make an IDE where you'd write C code this way), you go and open a code window where all the control objects reside (and separate methods, 'properties' (variables), that sort of thing), and there's a listbox- you select the button and open a disclosure triangle and there are various events, such as Action (button was clicked), mouse enter and exit events, etc. You mostly use the main ones like Action.
Suppose you have a statictext object in the window, called StaticText1. You can give it characteristics in the IDE, but then to change it at runtime, you might have the button change it like so- in the Action event, it'd say-
StaticText1.text = "Note, assignment operator in RB is just ="
Then you just run the program and when you click the button that event fires and causes that code to execute. What happens after that is that the execution 'falls out the bottom of the method' and returns to the main event loop, and you never see the main event loop at all- to you, it's as if all the controls run themselves, and you write most of your code to work controls programmatically or be worked by them. Many programs end up totally centered around the 'Go' button, whatever that is- if there's a button that says 'Go' or 'Render' or 'Execute' then the bulk of the code is probably in there, the rest in methods, perhaps some in a separate thread (treated sort of like another control).
The framework assumes everything will be based off of the GUI controls, and that half the hassle is making the controls be controls- so it implements them all, has them fully functional even if you write _no_ code (they just don't _do_ anything at all but actuate) and then you reference them with other code like
if Checkbox1.value then
RadioButton4.enabled = false
end if
...that sort of thing. You can rename them- I just am using defaults to illustrate. The point is, everything is positioned as if it was a drawing application- nice slick GUI builder- then you can compile the mockup and actually run it, and begin adding code to controls bit by bit, constantly trying out the program to see how it's doing.
The essence of this approach is the terms to which it can be reduced- you can drag simple controls onto the project, you can use the controls' simplest methods to do simple tasks- and a heck of a lot of programming tasks (ESPECIALLY for Unix!) only require _simple_ controls. You could do amazing housekeeping things in Unix with a project window, a statictext control, a editfield control with scrollbar, a button control, a file class (aka 'Folderitem' in RB), and a read-text-file and write-text-file method on the file class...
This does gloss over some stuff- the string datatype in RB is very flexible and can dynamically scale up to gigs in size, in fact there IS no fixed length string, they are all the fancy dynamic (slower) type. But the point is approachability- and it's damned hard to beat REALbasic for approachability, even Visual Basic (somewhat the inspiration for RB) is far more cluttered with crud. RB is very clean- this limits, but it also makes simple tasks _real_ streamlined, and that has value too in an application framework. It's not going to be Mozilla- but it's worth seeing what it'll do.
Re:Whoops! (Score:2)
2) Source code. Yes.
3) Derived works. Yes.
4) Integrity of author's source sode. Yes.
5) No Discrimination against persons or groups. Yes.
6) No Discrimination against fields of endeavor. Yes.
7) Distribution of license. Yes.
8) License must not be specific to product. Yes.
9) License must not contaminate other software. Yes.
10) Example licenses. N/A
To quote Bruce Perens, "Troll Tech released a fully Open Source license for Qt".
So yes, I do still think that Qt is Open Source Software and I still think it is Free Software.
1 line, 6 seconds, no 'code', in REALbasic (Score:2)
*click in 'value' section*
*type 'Hello World'*
*run*
That's on a Mac, but there's no reason this style of application framework couldn't be used on Linux. All it takes is someone to code it and keep things clean and uncluttered. 'Hello world' is not hard in a proper GUI builder. It shouldn't require _any_ code.
If you want to get _competitive_ ;) (Score:2)
msgbox "Hello World"
That's it- in REALbasic. I mean, if you're going to use a _messagebox_ then I don't even have to drag any controls into the project window at all. But I think that's cheating, it's not useful enough
Crappy Quickdraw? You're nuts o_O (Score:2)
I can hardly be too affronted, tho- what do you consider preferable, MFC? X? Face it, all software sucks- if you can't code on a tightwire don't code C/C++ for Mac, as you _do_ have to get everything right, and you _will_ be going *bam*bam*bam*bam* on the reset button. Hey, at least the registry won't corrupt from all the reset-bouncing!
Re:Somebody has to say it (Score:2)
I realize that all the C preprocessor does is expand macros, include files, etc., but the word "preprocessor" itself is a bit more broad. A C compiler could be considered a preprocessor for an assembler.
More to the point, basically all this means is anything you could write in C++ you could really be writing in C, I hope that point isn't in dispute here. (and anything you could write in C++ or C you could really be writing properly in assembler, object oriented or not, GUI or not... It just might take a bit longer.
Re:GTK+ (Score:2)
(b) If you do care, try GTK themes. They can be slow, just like Windows, and can be made to look the same or better.
(c) Windows could benefit from some of the features of Motif. Tear-offs are a nifty idea, for instance, not that I use them much.
(d) Wouldn't it be nice if Windows gave you a *choice* of widget sets?
(e) Gosh, what do you expect from that original UNIX crowd that gave you *stable* server operating systems, and functional desktop machines with a GUI, mouse, and networking before that was cool. (is that cool yet in Windows, or are we waiting for the next release still?)
Gui frameworks and interaction models (Score:2)
For myself the key to a good GUI Framework is the interaction model, this should give the standard set of components, a standard model for the data and a standard interaction between the components and the data models (pet hate, why does windows have three different styles of file browser ?).
Example. On many systems there is a requirement for a list (or tree) on the left hand side and the data from that node on the right. Adding elements to the list (or at a given level on the tree) is standard, and the rule connecting the selected item to the view on the left is also straight forward (model x has view b). Thus provide a framework that makes it easy to use this method. By enabling developers to ignore having to write this component each time you force a specific look and feel and create a consistent interface that is simpler to learn.
When I wrote straight X I had to worry about pixels and windows and mice etc etc then Motif abstracted away to give a decent set of components with which to develop. The development of kits ontop of these components sets (which ever one you chose) was the next step. IMO the next is to ignore those sets more and more as the object model drives the screen design.
... Yes, consitent keyboard support ! (Score:3)
Qt's Licencing for Windows doesn't cut it. (Score:3)
What you're missing is that it makes you pay for a licence if you want to port your free app to Windows. Now, they've already put the work in to get Qt to work on Windows, I want to be able to wright my app once and have it portable to windows just by changing the direction of some slashes in the config file!
No, they realy want the money, and won't let you use Windows Qt without paying $1000+. If it weren't for this, I'd not have problems with Qt any more than I have problems with GPL'd libs (Not LGPL'd, GPL'd). The only reason that I can see to only give access to the X version is 'cause they know that a commerical propriatary lib won't cut it on Linux, but they think they can get developers to want to use Qt enough to buy a licence to port their... Argghhh!!! I'm just repeating myself now, but am tired, hungry, and this cheasy psudo-free library pisses me off! Paraphrasing RMS: "Propriatary librarys can cause more damage to the Free Software Movement than propritary Apps can".
No. Just No. (Score:2)
I can't walk into a contract job, inform them that I'll code their solution in Obj-C, and then do it and split. I'd be leaving them with something they have no prayer of maintaining or extending.
Java is unacceptable -- too slow, no particular reason for existence.
Obj-C is unacceptable -- if it's as good as Smalltalk, it probably belongs in the same catagory (along w/ML and others) of academic languages of no practical value.
Tell me what Obj-C does so much better than C++ that it's worth the cost of conversion.
Re:GUI/API programming... (Score:2)
That said, Win32 may be easier than Xlib - or maybe not - but the original estimate was more tied to reality than your "correction".
Re:Oh for the love of god! (Score:2)
Re:You can't write OO code in C (Score:2)
Anything expressible in C++ is expressible in C. This was an explicit design decision for C++. Therefore, C supports every feature C++ does, and if that's not enough to do OOP in C then it's not enough to do OOP in C++ either.
There's an old saying: a bad programmer can write bad FORTRAN in any language. I've seen C and even assembly code that is very object-oriented despite the limitations of those languages. OTOH, most of the worst and least OO code I've ever seen was in C++. We're talking about code that abuses statics and globals, that uses inheritance in unsavory ways (e.g. just to avoid having to type parameters) without any rational parent/child/peer model in mind, that uses overloading to make the code unreadable, etc.
Using C++ does not make code OO, and in some ways even interferes with that effort. Criticizing something for being C rather than C++, without adressing whether it is or is not good OO, is a sure way to prove that you don't even know the difference.
Re:Commercial Okay, Proprietary Not (Score:2)
Don't argue with me about it. Talk to Bruce Perens.
Re:Qt Free for Windows Too... (Score:2)
But you certainly can port the whole X version to Windows if you'd like. Nothing is forbidding this.
Just in case you don't know, there is a very, very important reason why the Windows version is not Free: Windows users don't pay for Free Software. If Troll Tech released it to Windows for free, their entire cash flow would disappear overnight. And don't talk about supporting it through support. Qt users don't need any support.
Re:GNUstep (Score:2)
That is exactly what Sun did with JFC/Swing. With Java 1.2, Sun also incorporated the OpenStep/DisplayPostscript imaging model, much of the WebObjects application server functionality, as well as extensive reflection capabilities.
Sun has hired lots of OpenStep/ObjC folks, and they also have a number of Smalltalk, Self, and CommonLisp experts, so Java carries on those traditions.
How about BeOS? (Score:2)
Can anyone comment on this?
Re:Qt doesn't solve all the worlds problems. (Score:2)
Re:GUI/API programming... (Score:2)
You, sir, are simply a liar and a troll.
Re:OO isn't a C language feature (Score:2)
That's sort of my point, actually. People have been doing the equivalent of virtual functions for years in C and even assembler, using function pointers and dispatch tables. Some other people think they're more advanced programmers because they use C++, but don't have the faintest clue what virtual functions are or what they're good for. That's just hogwash. C++ is not an option for kernel work in many environments - notably just about any flavor or UNIX, whereas NT actually supports in-kernel C++ quite well and even requires it in some cases (e.g. filesystems) - but it's still entirely possible to write very OO code in those situations.
Going back to what I said originally, criticizing a GUI framework for having a C rather than C++ style native interface, without addressing the usefulness of its object model (or whether it even has one) is - to borrow your own phrase - just wanking. If it's decently OO but expressed in C, C++ wrappers are a trivial exercise. If it's lousy OO but expressed in C++, there's no easy way to fix it.