Slashdot Mirror
Ask Slashdot: What is the Best GUI Framework?
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.
I'm not a programmer, but from my perspective (User) I like GTK+ most of all, and hate Motif most of all. Note that for my perspective I take into account speed and looks, since that's what matters to me. :)
I, personally, *like* QT/KDE. It makes programming GUI programs in C++ much easier. I'd like GTK+ to have something like it (with the attendant QString equivalent!). Sadly, it's also slow on my 486, and if it's slow there, well, maybe some work needs to go into making it faster....
. Define sqrt(x) as something really evil like (x / rand()), and bury it deep. Watch your coworkers go nuts.
Swing is really nice. It is the aggregation of every concepts in MVC GUI frameworks. Versions 1.0.x were quite slow, but they did quite a lot of optimisations in version 1.1.1; speed is now acceptable on Blackdown's JDK. On IBM JVM for linux, it flies. You don't have to say that you don't like the Java language just to look like a real unix guy... :-) The language is awesome; it is the implementation that could be better...
I'll prawly get flamed for this plenty, but I think for the majority of apps an HTML/XML GUI would be the best solution. And use any script language to actually interact with an app.
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.
I've worked in both windows and macintosh for quite some time, and I had a class using awt. I find that the horrible messaging system in windows basically forces you to write a plug in for windows, whereas the mac toolbox enables you to actually write code the way you want to. Aside from windows code being ugly as hell... As far as awt goes, there are a rich, reliable set of classes to be used there, but then you have to deal with the limitations/simplifications of java. (which kind of prohibits useful/messy down and dirty hacking) I think that java is too much like pascal and visual basic to really give you full control of what's going on. It basically insulates you from all the real api. I know thats the point, but the awt event model isn't any simpler. It doesnt seem to be much of a solution.
hyperpoem.net
wxWindows is a good multiplatform toolkit. There was even an ncurses binding for it (not enough interest, so it stopped being maintained, because it had special contraints)!
Its scripting language bindings are especially impressive.
-Billy
Any of you use VisualAge for C++ on AIX? I've meddled with VA C++ on OS/2 and OCL seems like a really nice framework to me. I've not used it much so I'm hoping to here from some OS/2, Windows, or AIX people that might have more experience with it. Especially since it went to v4.0 just some months ago.
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
The new one in Java is based heavily on NextStep, has great tools (Inprise, IBM, others), is way too easy to program, is quite fast (it now takes advantage of what systems can do natively), and has a cool system that lets you dynamically plug a look and feel into a program (instantaneously make it look like Mac, Next, Windoze, Unix, ... whatever). And it's instantly portable to _anything_, including things far from Linux/BSD/UNIX. Seems pretty obvious to me. Besides, lately it's about the only one I've been allowed by contract to use when I code for the military, the medical industry, or whoever, mainly due to the portability.
The curses library has some distinct advantages for building a graphical user interface. It is incredibly simple, crash proof, lightning fast, and generally hard to go wrong with. It is when you go for the elaborate high-resolution graphical interfaces that you go wrong.
A project I did a while back was (because the contract said so) the first major Java-and-XML-based commercial app around (IBM bragged about us because we were the first game in town using their tools).
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.
It sounds like you've already decided on GTK+. So why are you asking the question?
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.
A Government Is a Body of People, Usually Notably Ungoverned
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
If you read the article, he says that the license does matter.
-jwb
It looks like a very nice toolkit if you don't mind using C++. Check it out:
http://www.cfdrc.com/FOX/fox.html
It is under the LGPL too.
What the hell are you talking about?
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.
1. Portability. Across different OS platforms and architectures. This one's a must. No excuse in this day and age for any library, GUI or not, to only run on Wintel.
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 is a rather nice setup, and its lower level base, the AWT, is pretty logically laid out. Its a very nice system that is based on what Delphi uses. So why should one think Swing is nice, but Delphi bad? If you examine Delphi's GUI libraries and compare to Swing, you'll find the two are quite similar.
"Luncheon meats make the sawdust in your stomach explode."
- 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.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).
Intel transfer the difficult from Hadware to software, for get more power, programmer need more technology. -- chinaitn
The things you're asking for are attributes of a toolkit, not a framework. Be careful not to get the two confused.
-Billy
Tk is nice once you're used to it -- but it's terrible in many other ways.
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
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.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
My feelings are that we buy/use/maybe make what
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.
I guess you like coding programs that look butt ugly.
...
Bitchslapped? Give Rob a bitchslap from bitchslapped.com.
The "Design Patterns" book is based in part on the experience with Interviews.
it basically depends on the programmer. As a mainly C coder i'd love to see something like GTK with more motifish extensions/widgets and a more Java-like thread handling which would work with C or Java. Small, light, fast would be nice too.
would be nice if they documented nonworking calls to. i have at least 4 calls that were nonworking but produced no errors. searching geocrawler and the gtk mailing lists uncovered posts on them which confirmed they were broken. reference could be tidied up and tutorials need to be cleaned out. More help on the list would be nice too..i realise the GTK is under a lot of pressure to get the code out and stable..more developers needed i guess.
PowerPlant is the best framework I've ever used. Pure, good C++, with multiple interitance and etc. It has a nice GUI builder which is not absolutely required but a real convinience.
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.
Since there are so many frameworks on UNIX and they change so rapidly you're better off abstracting the toolkit from your applications with yet another layer.
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.
I think this article is baiting us, nevertheless here is my honest response.
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.
Another library worth looking into is OpenStep; specifically the ApplicationKit. This toolkit is what NextStep has evolved into. Even though it is quite old as far as X11 toolkits go, it is surpisingly well designed, OO from the core up and very MVC.
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 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.
I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. 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.
This is a heavy one,and by my reckoning is probably three steps out of my league. I can but try.. Even though you seem to take an early lean away from swing (and AWT) it really has most of the qualities that one wishes; it is clean, logical, is easily and infinitly extensible, and in most cases anything produced will be nearly portable in unchanged form. Downside to swing is the damn interpretive layer inherent to Java. I've done a little poking into GTK+ recently, and it is one hell bent little fifty-bladed Swiss Army knife. Perl and GTK? Okay! Let's meld a little Pascal into c and slap a front end on it? Sure! Smidge around the widgets based on user preferences? Why not! (And the way it just falls into a good OO design. Stop me before I wet myself.) Unfortunatly, some of the 'features' are still being developed, and the docs would be lucky to be called 'scarce' (I've contemplated donating time to them, but I'm lucky to get time to shower anymore.) Since the suggestion was passed to contemplate other OS GUI framework, (what is the proper plural?) I'll hand out the short bit of wisdom a PM once gave me: 'If you want it quickly, VB. If you need it to be functional, Visual C or Delphi. If you need it to be stable, why the hell are you writing it for NT!!'
.sig: Now legally binding!
GNUstep 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.
Dude, you list requirements that of all mentioned toolkits are best served by QT and then you dismiss it with couple sentences.
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.
Your comment clearly shows that you have never worked on sizable GUI based program using C. ... .. QT )
But you will learn, it will hurt but eventually you will learn
(hint
Probably the largest complaint about X (and certainly one of the most plainly obvious) is that every program looks like it was developed in a vacuum.
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
> 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 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.
Not that I think Tk is all that great (in fact, I think it is ugly and slow.. but damn fast to develop in)... but you are wrong that you have to use Tcl in order to use Tk. You can get Perl/Tk in order to get the Tk GUI on the much more useful foundation of perl.
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
Well, let us first perform a reality check on what was said here before:
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.
Ok, now I know I read it somewhere at the top. "I want speed and pretty graphics." But what happens when you get the speed, and the pretty graphics? I have yet to notice any toolkit which provides speed, pretty graphics, AND stability (which is my main point.) Stability, ladies and gents, is what it's all about. Who cares if your app is really fast and looks cool if it crashes in two seconds? (Nope, not making it up. gEdit refused to work for more than three seconds at a time until I removed GTK+ and reinstalled it.)
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
TCL is ugly like hell. It is like design straight from the hell ...
Sorry, I misread it.
:-)
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
A Government Is a Body of People, Usually Notably Ungoverned
First, let me say that KDE is my favorite thing currently out there. I like the widgets more than any other... er... I don't want to say window manager.
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.
- Hugh Buchanan
- Userfriendly.com
If you don't know what you're talking about, keep your mouth shut. You just end up looking dumb.
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.
grep -ri 'should work'
If you find that mice are a pain in the ass, can I humbly suggest that you re-evaulate how you're using your mouse?
They're not supposed to go anywhere near your ass.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Visix VIBE was one of the better JAVA-based quick development environments around 2 or 3 years ago. It really is sad that Visix went out of business before they could get VIBE brought up to modern JDK specs...
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...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
but I'll attempt to justify myself anyhow. I'm choosing to skip the whole display driver architecture question and focus on application programming.
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.
Ian points out I didn't consider GNUStep. I'll do so now:
It's called "Objectionable C" for a reason.
Go code in C++ you weenies!
(warned ya I was a bigot)
I will tell you what bothers them. They do not want to pay for commercial license and still be able to develop software and financially benefit from that. " I can do that but if troll want's to do that - uhrrdd, greedy bastards" - this kind of mentality I am talking about.
One nice thing for dealing with my users was that I could change single settings on their computers by sending them a .reg file with that setting. This wouldn't wipe out their other settings, as would happen if I sent them a new .ini file. Yes, I know this is very dangerous, but I tried to use my powers for good.
Heheheheh :) I thought that was you :)
;)
Ideally, you want some way of specifying standard keys for any given operation, and then have the system always bind that key in any app which can perform that operation.
But that's for advanced users only
si
Coming soon - pyrogyra
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.
I've programmed for years with Motif, and 2 years now with Qt. Using C-style callbacks with C++ is an intrinsic problem with all GUI toolkits, since by default C++ objects use a hidden "this" pointer which C callbacks do not support. So you have to do something to the effect of passing the object pointer as a parameter as a callback. The Qt toolkit hides all the details of this from the programmer in a nice way. Yes, moc is non-standard, but even Gtk+ in my opinion does not offer a better solution, because the amount of code required to make a GUI work with Qt is both easy to follow and small. As to Qt forcing you to program in a certain way, yes, that's true. A Qt program uses inheritance, abstraction and overridden functions in the way C++ should be used. This is the same way other toolkits, such as MFC++ and Borlands OWL for Windows work. If you're using C++ in any other way you're missing the point of OO programming. Our company is doing development using Qt for the additional reason that the apps we write can be quickly ported to/from Windows, Linux or other Unixes, and the executable is native to the OS as opposed to a Java type solution. Like it or not, that other OS is used by many people, and Qt gives us the ability to write for it using Linux, which is a by far better development environment. The HTML documentation for Qt is superior quality and highly usable. A new programmer can be up and running quickly and easily by following the tutorial. As far as KDE vs. Gnome, I don't have much experience with Gnome but I tried it on RedHat 6.0, thought it was OK but I prefer KDE. I admit I am biased, though.
it seems like a lot of nice toolkits (especially
fltk) are in c++ and force you to use c++. if
you write the tool kit (or framework) in c then
its users can use c or c++ (or python etc).
this is a practical issue when dealing when doing
things like writing a gimp plug in (which cannot
be done in c, thus you cannot use fltk).
id like to see a good GUI framework in c, themeable, and cross platform. fltk is light and
cross platform, but its c++. gtk is c, but its
heavy and only runs on unix. ok, so dont *really*
care for windows or the mac, i still like having that choice and a well written cross platform
toolkit could be good for things like berlin or Be.
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.
I have had no coding experience with either QT or GTK, but I have to say that being able to code a nice graphical UI in 200 lines sounds pretty good to me.
I agree mostly. Javascript needs to get much better. There needs to be some kind of mechanism for accesing the back end databases. There needs to be a little better control on the look and feel and positioning. Oh yea it's got to be browser independent (that's the killer!).
The Mozilla thing sounds awsome I hope they pull it off.
War is necrophilia.
why does the LGPL not cut it?
Qt2.0 (available now) is Free Software according to Richard Stallman, and Open Source according to Bruce Perens. You only have to buy a proprietary license if you intend to use it for proprietary applications.
A Government Is a Body of People, Usually Notably Ungoverned
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
May I humbly suggest that the systems you mention are no longer the defacto standards? I'm all for any system which lets me tab and alt-tab through the day and let's me alt-whatever any underlined action. I think windows did a fairly nifty job of implementing a consistent set of hotkeys - OS/2 did a better job - you could minimize and move windows with ALT-FKey combos... but to think of emacs, vi, and wordstar as the be all end all hotkey references is not neccessarily the best way o' thinkin', I think (but, if those hotkeys came into being as the defactos for modern GUIs, I would learn them. I'm not picky - I just like to be able to use my keyboard for ANYTHING.)
keeping the world safe for prematurely grumpy old men for oh, about 7 years now
Pre Qt2.0 used Motif or Windows style widgets. They were virtually identical to their counterparts. So don't blame Qt, blame Motif and Windows.
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++.
A Government Is a Body of People, Usually Notably Ungoverned
-------
CAIMLAS
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
because right now all implementations of it are still unreliable -- the reliability of application should be limited by its developer's stupidity, not by bugs in the language implementation, and in Java so far the user has better chance to get burned by the JVM bug than by actual flaw in the program, even when program is very buggy.
Contrary to the popular belief, there indeed is no God.
First, let me start off with saying I've only done a bit of raw Xt programming, some MFC, and Swing programming - so my experience with newer GUI toolkits other than Swing is definatley limited.
That said, I'll list a number of benefits of Swing that I found. I designed and wrote (with a small group of other people) a rather large web distributed Swing application (not quite an applet, but almost) in Java 2, and touched on pretty much every aspect of Swing during development.
Some of the benefits of Swing I found were:
* Very easy to extend and alter behaviour of custom components (combo boxes with custom colors per item straight from a database? Easy!)
* Extenions really are reusable, usually, and work well with other GUI components.
* Very easy to follow MVC model in Swing development.
* Layout managers (once understood) are great and make it easy to quickly build GUI's that will resize well.
* Swing provided a great set of most GUI components for a base.
* Swing and 1.2 was a very stable combination (once we rid ourselves of memory leaks, see below)
Our target platform - P90's with 32MB of RAM. I won't say it was the snappiest GUI ever on that platform, but it did run acceptibly.
The problems encountered:
* Memory - that Swing app did take up a good deal of memory.
* Memory Leaks - while we developed our Swing app, Swing did have a few memory leaks in the more fringe areas of use (like internal frames). We were able to work around and fix them though.
I think to really take off for application deployment, you really need some sort of launcher that would run multiple Java apps in one VM. With one VM, a number of Swing apps wouldn't really be a problem but without such a launcher more than two or three swing apps would probably be too memory intensive.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I can talk about the underlying structure of REALbasic, a rapid application development tool for the Mac.
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.
1) Free redistribution. Yes
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.
A Government Is a Body of People, Usually Notably Ungoverned
*drag statictext to project window*
*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.
With that interpretation of your post, yeah, I'd agree with what you said. Javascript would be cool if it weren't... err... javascript. First browser that lets me use perl to do UI stuff in the browser wins, hands down! And I don't mean embperl or anything server-side, I mean a way I can code perl functions into my html page and call them with event handlers. That'd be glory. Damn. That might not even be all that hard, now that I think about it. Whip up a little window creator in GTK/perl that does the basic html interpreting, and also allows me to eval code that it finds in the page... Anyone think this sounds sorta do-able? Even, at least, for a demo/prototype kind of thing?
There is no K5 cabal.
I am not the real rusty.
It seems that most of the people who've posted a reply here are either programmers or at least extremely computer savy. Who cares how good a toolkit is (ok, I do!), it's how good the UI is for computer illiterate users that matters, and how quickly you can get a usable product to market.
/. It also means most of the UIs that we use under X are no good to them. Some people can't handle Mac's, how the hell are they supposed to cope with AfterStep?
Then again, it all depends on your target audience. I'm into making software that makes me enough money to pay for all of my hobbies... that means targeting a mass audience. That means users who don't find computers intuitive like most of us on
I hate MFC (don't get me started on the programmatic problems with the design and API!), but I have to admit that it is really easy to write a UI that most people can use more easily. Most of the X UI's are just butt ugly (KDE, CDE, GNOME are changing things slowly) - has anybody been able to use X without a mouse (cursed thing)?? Doubt it.
Platform independent GUI toolkits lead to UIs that are ugly, un-functional compared to native UIs and a pain to develop. I had the miss fortune of working with Neuron (Moron) Data's toolkit for a while. Now I run screaming at the slightest word of it. Java UIs are very clumsy (I work with Java, so I know), and it takes a lot of work to make them useful to unwilling or illiterate users.
Open() //open event of app
:)
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
So quit yer-FUD. Yes, the VMs in the browsers suck, but JDK1.1.8 is super solid on Solaris and NT, and probably on all of IBM's platforms like OS/2, OS/390, etc.
Maybe safe-to-restart web backends can "survive" better than GUI applications. But show me _any_ implementation of Java that allows Hotjava to go through entire java.sun.com without crashing by some definitely not Java-level fatal error.
Contrary to the popular belief, there indeed is no God.
Since the VCL abstracts all the Win32 API calls, Borland should be able to wrap the VCL around a different API such as GTK+ or QT.
If they are smart about it, just about all pure VCL-based code (no Win32 API calls) could be ported over quite easily.
I can dream, can't I?
On another front, since VB and Delphi call the same framework, namely the Win32 API, you can't really call the development tool a GUI framework like QT, Motif, GTK+, etc . . . /. and UF help.
Being tied to NT at work, Delphi and Xnews and Mandrake at home are about the only things that keep me sane at times. . . Oh yeah, my daily doses of
Free Mac Mini. Yes, I'm
C as a language doesn't support the required features to allow you to program in an truly OO manner. The best that you can do is "object-based" programming. Unless you're doing lots of funky things such as using the preprocessor: which is one of the things that makes C/C++ bad languages for most programming. However, programming in C++ doesn't guarantee that you're programming in an OO manner either due to it's hybrid hacked together from C history. Bad non-OO programmers will still be bad. People who think ADTs are OO will still be object-based programmers, not OO ones.
Quickdraw rocks :) _somebody_ had to invent regions and fast graphics primitives! You do realise that _is_ where it all came from? Xerox PARC did _not_ have regions. ;P Do please stay away from MacOS. It doesn't like you either.
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!
"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."
Look at most of the good dialogs in an MFC application: there is no need to resize them. If you find that you have a crowded dialog that needs resizing: simplify it. KISS. I haven't written a dialog that needed resizing since I was an entry-level programmer, but I still think that I have a lot to learn about making useful UIs. I also don't believe in hard and fast rules when it comes to these kind of things.
I may be biased, but....
if you're into software development full time, USD 1000 will pay for your time and expenses for several DAYS.
If this is your hobby, use a free toolkit.
If this is your job, it just ain't that much money.
Remember that C++ was simply a preprocessor step for C orginaly
Wrong, this is an often repeated fallacy. The original C++ frontend, CFront, fully parsed the input, it was a compiler (or translator both are equally valid). It did produce C output but that doesn't imply that it was just a preprocessor.
Anything that discriminates against commercial use is PER DEFINITION not Open Source software! Stop bending the rules.
So Linux being GPL'd isn't open source software then?
You're either a BSD type license advocate or just plain dumb, I'm guessing the later as you clearly don't know the difference between commercial and proprietary.
Look at The Approved Licenses list http://www.opensource.org/licenses/
item number 7 is the QPL.
As someone who puts himself as being a GUI Designer on his CV (in the technical I write them rather than the draw pretty, useless, drawings on paper sort of way) one of the key things with all frameworks is a consistent interaction model, something many systems fall down on. When adding an element to the list the frame work should provide a list with a visible add method to which models can be added (yup I'm a firm fan of MVC) the system should be driven from the data. This doesn't mean database but the users view of the data. A Framework that allows the designer to specify the datamodel which then drives the interface in a consistent manner (because all Lists of Models use the same add method) means less hastle for the designer (who I assume is also the implementor) and the user. Too often GUI frameworks mearly provide a set of increasingly over colorized components that work in wildly different ways because someone somewhere thought it was a good idea and looked cool.
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.
An Eye for an Eye will make the whole world blind - Gandhi
So ok it is SGI's enhanced version.
--
Industrial space for lease in Flatlandia.
Umm... If it reads in C++ and outputs C, how could it be anything but a "preprocessor"?
Well, I think we agree CFront is a preprocessor. I am saying it is not just a preprocessor it is also a compiler.
A compiler or translator is a program that translates a file from one language (the source language) into another (the destination language). This is the computer science definition of what a compiler is. You should be able to find it in any good compiler book, and this should be one of the first things taught in a class on compilers.
The destination language need not be the machine language.
A compiler or translator should be able to check that the contents of a file is a valid string in the source language. Because CFront could do this it was (is) a compiler.
This is mentioned in D&E and I have heard Bjarne say it himself in person, in fact the propagation of this fallacy appears to one of his pet peeves.
If it matters I believe g++ was the first native language compiler for unix.
"I want to use software that doesn't suck." - ESR
"All software that isn't free sucks." - RMS
"I want to use software that doesn't suck." - ESR
"All software that isn't free sucks." - RMS
I know at least 2 app that use PowerPlant as a back end for a cross-platform development. One of these is Netscape...
On the other side, CodeWarrior is developped using PowerPlant, the Windows version being ported using Mac2Win from Altura Software and the UN*X version being ported using Latitude. This means that it is used as a front-end and that Mac API are emulated.
Other than that, once you understand how PowerPlant works, it is nice.
Hub
This seems to be the most overlooked issue with the gui 'environments' for unix. Imagine if ^X ^C ^V were different in every app? Windows drives me crazy with different keys being mapped to nearly the same function between apps. The Mac gui seems to hate supporting the keyboard but at least there are a few keyboard shortcuts that are common between apps. (there weren't even arrow keys on the original macs!) I haven't used enough KDE/GNOME apps to see if they have a well thought out keyboard shortcut & navigation scheme but from what I've seen I'd have to say NO and that makes me very concerned. ( I can't even navigate the directory tree (+/-) in gnome using midnight commander. I want to simply tab to the tree structure and press my arrow keys to open/close directories. Am I missing something here? ) Common functions (cut/copy/paste/close-win/ min-win/cycle-wins/file-save,open/etc..) should all be the same in each app and it would be nice if the user could map the keys. Keyboard Nav (tab, text selection,menu nav, button press , etc...) needs to be consistent well supported. Modifier keys need to modify consistently. Not alt here, control here, shift-alt for no reason. And finally any GUI needs to remember where the windows were and what they looked like. (this needs to be built into the gui toolkit because programmers rarely support this) I don't want to search all over my file system in and open/save dialog because the programmer didn't want to keep track of the last used/visted directory. When I open a folder (or link to) the file manager should remember the window size and file layout. (even windud does this)
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!
-- The act of censorship is always worse than whatever is being censored. Always.
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".
-- The act of censorship is always worse than whatever is being censored. Always.
I want it fast, pretty, and stable. GTK seems to be close enough to that for me!
-- The act of censorship is always worse than whatever is being censored. Always.
A language without excellent, maintainable, preferrably native C/C++ bindings is useless.
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.
I don't think that the X/Xt/Xaw framework has been improved upton by any of the relative new comers. We should go back to our roots.
> There is a *great* misconception among the
> Slashdot crowd about the speed of modern Java VMs.
Well, there is a reason for that: one year ago I developped a small application in Java/Swimg with the JDK 1.1.7 and then the Java2 platform, it's target was a P166 with 16 MB of RAM with Windows95 : it was toooo sloooow, I added 32 MB of RAM and it ran just slowly.
> The 2D rendering library still has some performance problems
Too bad, it's the part which is used by many application.
> Only the GUI stuff is slow and only in certain areas, so it's merely a subjective impression that Java is slow.
Sorry but we're talking about choosing a GUI toolkit here, so that's a bad point.
Oh BTW did I say that printing in Java2 was incompatible with the printing with JDK1.1.7, that it was really sloooooww (many times, I thought that the process was dead but it wasn't!) and that it is really hard to print non trivial thing in Java (such as a formatted text page with some images in it)...
Somehow I feel that even if I show you "an implementation of JAva that allows HotJava to go through entir...", most of slashdotters will find something else to complain about java. Somehow I feel even with a 100% reliable, and fast JVM they wouldnt even try to write a single line in Java. Why? Because is not C-or-Linux-or-Perl.
(I say *most* of them, not *all* of them)
---> Did you know Linux stands for Linux Is Not UniX ?
The VCL actually has the tightest integration of native windowing handles to objects I've ever seen (which is a requirement for a fast GUI framework). This is the part of any GUI framework that associates a native window handle with the framework's object handler. Various techniques can be used: a map, private window data, windows getprop/setprop, etc.
In the VCL, the association is done actually in the windowing class callback itself. Each window class gets its own snippet of assembler that is manufactured on the fly, and contains the VCL class pointer for dispatching. Thus, there is absolutely NO overhead for the lookup to dispatch any windowing message. Hence, the GUI part of Delphi blows the doors off of MFC and VB for performance. This technique is a key facet of the VCL that allows them to blend the numeric messaging identifiers into the Object Pascal language. I'm hoping they torque the language in the direction that pays off for ease-of-use under Linux as well.
Alas, this is the part that is going to make it tricky for tricks on Linux to relink with a Linux-based Win32 implementation. This technique will of course tie the implementation to Intel.
There are other parts of the VCL written in native assembler, most notably the native ref-counted string class. Those won't be hard to replace with pascal, but I'm hoping for performance they use conditional compilation for Linux/Intel.
An aside: here's one example where a proprietary language is a blessing: Borland owes nobody any explanations why they move the language forward to implement nice tie-ins with the deployment platform. VCL has the easiest COM integration, and window message syntax in method declerations. I'm betting they do a bang-up job making it just as easy to do Linux development.
I realize that NeXT is officially dead. I've been to the wake, I shed my tears, I moved on. However, I believe that a discussion about elegance of GUI frameworks MUST at least mention NEXTSTEP.
:^), and it made the acronym WYSIWYG true because the screen was rendered with the same engine as hard copy.
The framework was OO from top to bottom. All of the components in the framework were extensible by the developer, and the documentation didn't suck! Display Postscript allowed for some amazing flexibility (as long as you speak RPN
Swing is very good, I've been using it for a few months now, but the UI's created with it are dumb'ed down. The Swing framework is designed to make it easy to create a UI programatically. Bravo, it is very good at that, but the results look like shit. NeXT's 10 year old (yes, proprietary) GUI builder, InterfaceBuilder.app, is still better than any of the other products out there. I've used JBuidler and VisualCafe, and I've glanced at VisualAge, and none of those GUI builders stack up to what NeXT offered.
If you are looking for a good framework, check out what NeXT did over the last decade. It may be dead, but that doesn't mean it wasn't good.
- Dave
--
David Goodman
Citadel Investment Group, LLC
david_goodman@iname.com
They say they found that their ideal design for swing wasn't so ideal and have done a complete rewrite. I just hope that maybe we can get Linux versions soon. Granted, we don't have a 1.2 release yet; however, if 1.3 has lots of rewrites of 1.2 stuff maybe we can just skip over implementing it that redone part of 1.2 and get a 1.3 somewhat soon.
s playStories&xsl=comment.xsl&format=full&id =500300000000563
The article, change log, and some good comments are here.
http://www.javalobby.com/servlet/News?action=di
jawa is da one
Civ CTP is awesome! Thanks Loki!
Romans 10:9-10
Okay, I'm a bit of a Windows guy so this might be a tainted viewpoint, but there are some good lessons to learn from MFC and Visual Studio.
First, keep the framework simple - extensible is incredibly important but if the framework itself is easy to understand and doesn't require intense knowledge of the latest C++ tricks (like so many I've seen) then it will be a lot easier for programmers (especially folks who know C) to start using it.
The other important lesson is that good tool support is vital. Visual Studio isn't the tool you're going to use to maintain your classes in a million line mega-app, but it's an awesome tool for doing up quick GUIs for simple apps, or even medium-sized apps. And don't just make your GUI-builder dump out code, it has to be able to go back and let you make changes to it (add message handlers, etc). MFC isn't so good at this.
My two cents.
- Steve
The thing that irritates me about Motif is not the color scheme, but the way it handles radio buttons and checkboxes. Instead of drawing a nice easy to see dot or check or x in the checkbox or radio button, Motif makes the button look depressed.
It is much harder to tell what option you have selected with the "depressed" look rather than with the checkmark or x look. Especially in monochrome.
I've been using Perl/Tk for over a year now, and have co-written a 15,000 line Perl/Tk application for commercial use which is completely cross-platform. I would highly recommend Perl/Tk to anyone doing GUI development, especially if it needs to be portable. Just my thoughts on the topic.
R.M. Holston, Ph.D. Cyberneticist & Director of IT R&D RJL Systems, Inc.
In my mind, wxWindows is the best app framework out there. Uses C++ natively, but python bindings are available too. Supports everything you'd expect a modern app framework to have, plus a lot of extras people have added along the way. It's very similar in feel to MFC, with event tables and all, but the API is much cleaner, much more consistent. Best of all, it's cross platform: I can recompile and run my app without changing a line of code on Win32 and Linux, and there's Mac and Be ports on the way. The documentation is very complete and well organized (take that GTK), and my questions to the mailing list tend to be answered by one of the developers within a few minutes. It's distributed under a modified form of the L-GPL which allows you to build non-GPL applications using it, so long as you don't change any of the code in the library itself. Go to www.wxwindows.org and see for yourself.
Well I must be dumb then. The QPL does not discriminate against commercial use anymore than the GPL. I can use QT to run a commercial website (actually you really can QT supports networking). And you could SELL your own QT distribution.
I see no difference between the QPL and the GPL in this regard.
What are "springs and struts"?
I don't know, but it does sound a little bit like a feature of a GTK+ widget I am working on.
It is a GtkTable, where each row and column is weighted, like HTML relative widths. You can specify that one row is twice the width than another row, etc.
I have also subclassed the widget and added
resizebars between the rows and columns.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
One day they will run out of reserves and they'll have two choices. 1) Don't add any more features, no matter how important they may be or 2) break existing programs and change the layout.
or, 3) subclass the existing interfaces
Berlin-- http://www.berlin-consortium.org
DNA just wants to be free...
(For the fortunate souls who haven't used VC++, I'm referring to the dialogs that contain such things as the list of libraries to link.)
What really gets me is that I've talked to the MFC designers about this in the past. Their consistent response is:
Of course this is based on the implication that it's perfectly OK to cripple the tools available to the competent, experienced customer if it makes it easier to con more VB programmers into thinking that they too can be instant C++ programmers! After all there are more suckers and wannabes than there are real C++ programmers so the customer base is larger.
In my experience doing Tk/Python, the Tk API isn't too bad. 8.0 had some apparent problems, though, like not being able to deal well with very long strings.
Tk real appeal, of course, is that it's got a presence in X, MS Windows, and Mac OS--the three most popular window-systems.
-rozzin.
While we bicker and argue about Motif vs. Qt vs. GTK+ vs. ncurses, Microsoft weenies are still using the bloated yet ubiquitous MFC/Win32 API and still own the desktop. Is there a message here?
(d) Wouldn't it be nice if Windows gave you a *choice* of widget sets?
-----
0] Why are we suddenly ranting about how bad MS Windows is?
1] There are a few different widget-sets that function under MS Windows. They don't all come with the OS, but, ish..., I'm not going to go into that.
-rozzin.
I suggest you try writing such a monster!
See you in about 400 years....
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
Qt 2 free edition is fully free, not pseudo free.
Qt 2 free edition is not available for the Windows platform, or the Mac or Beos or OS/2 or Nextstep or the Commodore 64. QT 2 free edition won't house the homeless or feed the starving.
If Qt 2 free edition was distributed under the GPL or even the LGPL license the situation would be exactly the same.
If you really want QT free edition for windows port it, you are free to do so, however you will have to fork the development as troll tech will not support you.
Well, you can use Qt/Python.
Stephen Molitor steve_molitor@yahoo.com
If you search on the net, you'll find a page dedicated to GUI frameworks and toolkits. It lists millions of them! Unfortunately, I don't have the URL on me.
Also, there's quite a difference between a framework and a toolkit. GTK+ is a widget toolkit, whereas Swing, PowerPlant, and even MFC are application frameworks. They provide more than just graphical widgets for menus, buttons, and sliders.
I think it would be interesting to see an exact port of Swing to C++, say to X11 directly.
--
Marc A. Lepage
Software Developer
Yeah. And why development tools should be free ? ... you like to merchandise you pay.
And for that matter why anything should be free ?
I agree, I need source code most of the time but I don't mind paying for stuff. That's how market works you know
Of course you can create your own but you what happens most of the time - you end up with shity, half working imitation of the real thing.
But does it support wrapping (multi-line) text in a cell yet?
No.
You know C++ then why are you asking about C toolkit ?
Yeah, TK has some really great features.
I love how it does event binding.
(Scripting languages are the future.)
How about using Python (or for that matter perl) with one of the GUI toolkit bindings? Can you use them for "serious" apps, maybe writing in parts that need speed in C?
The **OLD** Qt license forbade commercial use, but the new one, called QPL, does not. Thus, it follows the Open Source Definition. No rules were bent.
Don't argue with me about it. Talk to Bruce Perens.
A Government Is a Body of People, Usually Notably Ungoverned
Yes folks, you heard me right. Qt is free for use on Windows. Not the Windows version though :-)
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.
A Government Is a Body of People, Usually Notably Ungoverned
Not exactly, Xlib is a bit more low level than Win32. If I had to compare Xlib to something under the "other" platform I'd say it's closer to GDI.
--
I disagree strongly with the assertion that 'speed is everything,' and if 'too much typing' were a concern to any developer, then I would wonder why anything but Perl would be used.
In truth, I've never seen OpenStep/GNUStep in action, and a quick glance at the tutorials for both show me a lot (albeit in Objective-C) of what I have already seen accomplished by Metwowerks Power Plant. Although it's platform (Mac) specific, it is an elegantly designed framework built from the ground (Mac Toolbox) up in perfectly readable C++. What browsing through docs need to be done is quick (all you need is written into a fat pdf 'Power Plant book' supplied to whomever buys the product) and easy. Moreover, Constructor lets you do that 'drag and drop' layout promised by OpenStep/GNUStep, so the details of implementing your program are neatly separated from managing the state of your program. I'm a big fan of that.
Just thought I'd put in a word or two for the lonely mac developers out there.
MFC sucks. Hard.
One of the major problems of HTML is the limited set of form objects. And HTML5 is going to attempt to fix this. HTML 5 will divide the HTML spec into several groups, including a completely reworked Forms architecture. This new forms architecture is suppose to allow new components to be called up, similar to loading applets up except they have the added bonus of interacting with the forms event and scripting system.
Of course, none of this has even hit the level of public spec, so we all have to wait and see.
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. Anything expressible C++ is also expressible in assembly. I don't think that the poster who said you can't code is OO in C was really talking about whether or not some or all OO features can be implemented in C, but rather whether they were implicit in the language. Virtual functions, for instance, would have to be layered on top of C with an entire application level framework to support it, and based on the arguments made in the C++ FAQS here, if you don't use or at least understand virtual functions, you're not working in OO, you're wanking.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
>Yeah, it's that "knowing what you are doing" bit that gets me.
What? Do you use the infinite monkeys with typewriters method of coding? You have to learn the language you're using.
In my experience C++ does not "hide" things from you, although depending on what environment you're coding in (VC++ with MFC [nudge nudge wink wink]) they you are going to find a lot of voodoo and black magic behind the scenes.
But the language itself and even the STL (if the implementation conforms to the performance requirements) does not do anything unexpected. You take a performance hit on virtual functions and sometimes on templates, mostly becuase of their extensive use of virtual functions (in my experience). If you're taking a performance hit on temporary variable initialization you're using a bad design. Most such temp vars occur on function call boundries and can be resolved with the effective use of const references in passed class paramaters and plain references in returned classes.
Anyone else know any other unavoidable performance hits in C++ that are language related as opposed to compiler related?
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
Perl/Tk is the exception which tests the rule, of course -- and the rule happens to hold. Look at the Perl source; what happens is that Perl tears apart Tcl and Tk sources to get the Tk into a state usable without Tk.
So you _can_ use Tk without Tcl -- if you use Perl OR if you're willing to tear apart the Tcl/Tk sources every time you compile.
-Billy
Just decided to throw my two cents in since I've been working on related code. I cannot comment on all toolkits I have seen since I only have so much time in my life. However, many of the frameworks I have seen seem to be almost the same thing, but packaged a little differently.
I beleive what is really needed is a new approach to the problem. Instead of requiring the whole program be encapsulated into the graphical interface, it would be much nicer if you could write your program first, THEN tie in the graphical parts.
After having worked with MFC, I have seen an approach that definately does not work. Its not that the document/view model will never work, but rather that it might not be the correct model for everyone. It makes it very hard to take an already existing program and transform it into a graphical counterpart.
Don't get me wrong, I love OOP. C++ is one of my favourite languages (Scheme is about the same rank). But instead of creating a framework that both the program, and the GUI must be wrapped around, it makes more sense to have a more distributed approach (i.e. only involve the GUI when it is needed, associate enough code with the widget set that it can act on its own, but limit it so that it is reusable for almost any situation).
And on a final note, the things wrong I have seen with QT: 1) deviation from C++. C++ is a very rich and expressive language. Not as expressive as PERL perhaps, but this can be a Good Thing (tm). Any time I see extensive uses of macros in C++, I will immediately give up on any hope (MFC and QT are the biggest offenders). 2) Virtual functions are cool. They're great in fact. But it seems a very limiting approach to use them to handle events. You are limiting yourself because you must handle those events regardless. You do have the ability to just do a return, but then theres a lot of extra code. Virtual functions are supposed to save us from work, not create more! There are other ways besides virtual functions (C has managed all this time).
It is annoying that the most programmer friendly APIs seem to produce the least friendly user friendly interfaces. MUI on the Amiga was, by far, the best GUI API I've ever seen.
I like the design of Swing (for Java). Fresco uses a novel design, but it is slow. GTK is slower than QT, so I prefer QT as a user, but GTK (IMHO) is more attractive.
Overall, I think we can count ourselves lucky that we have such a variety to choose from. The programmers for some OSes don't have the option to choose style over speed, or a nicer API.
Hey, why not CWorthy then?
(the old Novell Console interface)
"The number of suckers born each minute doubles every 18 months."
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
..and Qt is just a lame wrapper around Xlib. Using moc hacks and QTL to accomplish things that gtk-- does with standard C++.
/mill
Ahh, the joys of FUD. If I could only be so lame to hide my identity too.
I hear from others the BeOS is an EXTREMELY nicely designed environment to program in, since they had the advantage of wiping the slate clean and starting over. I hear that code is very reusable, and the applications can communicate through a messaging protocol, and that the toolkit is a very clean design. I hear that application development is very rapid and that usually the end product ends up running like a dream.
Can anyone comment on this?
Vidi, Vici, Veni
You need to learn more. It will come with the age. ,gtk C++ wrapper is wrapper around C which in turn tries to wrap Xlib and Win32 code. It is ugly and makes your fucking life miserable when things start getting out of hand ( it is generally around 10 000 line of code)
Moc is not a hack
Did you know that many large systems, including banks & power grids & embedded devices, are running under Smalltalk?
This also goes for Java. It was good enough for VISA international's smartcard system.
-Stu
a pattern that AppKit implements very well, I might add.
-Stu
At a guess, this would be NeXT/OPENstep. www.next.com aliases to Apple's Enterprise software site. If one can score an old machine or copy of the OS, Apple is giving out free updates to NeXTstep 3.3 or OPENSTEP 4.2. William
Sphinx of black quartz, judge my vow.
And for this "ugly like hell" language the
author (John Ousterhout) receives the ACM
Software System Award? Of course, we can
expect a level of noise in such unmoderated
discussions, but at least justifying your
comments would be appropriate. Perhaps it
is because you cannot?
I find Tcl to have a nice level of elegance
for a scripting language. It does have an
element of quoting hell, but once past this
(relatively minor) curve point, it is quite
easy and standard across the language. This
extends to Tk, with which one can write very
nice setups in almost zero investment time.
Tk is by no means tied to Tcl, which is why you see bindings for it in Python, Perl, Scheme, Guile, and a couple others. On the flip side, Tcl is easy to integrate with C or Java, which is why people have placed it in apps that use Motif, Gtk, MFC, etc...
Also, Tk is cross-platform and requires no recompiling, which none of the other mentioned toolkits can claim. There is an elegance and simplicity there that is just not matched.
Tk is ties to Tcl -- all of the languages you mention require Tcl to be installed in order to use Tk.
The exception is Perl, which does a massive parsing of the Tcl and Tk sources to hack its way into Tk.
(Programs written in) Tk does require recompilation, of course. I don't know what you could be attempting to say which could result in your statement being true.
And wxWindows works on FAR more platforms than Tk, and is smaller, simpler, and FAR faster.
Tcl/Tk utterly and completely lacks any approach to elegance and simplicity. We should all jump at a chance to get rid of the albatross of Tcl being linked into every program we distribute merely in order to do basic graphics.
-Billy
CFront and its ilk do *not* implement private members at the C level.
I am not saying it can't be done, I am saying that saying CFront did everything C++ requires in C is simply false.
Do yourself a favour and use one of the excellent DB libraries written by Konstantin Knizhnik, that you can find at http://www.geocities.com/SiliconValley/Orchard/580 2/
These are *gems* and not nearly as known as they should
I think he's referring to the fact that C++ tries to hide a lot of things from you with the intention of being "easy", but it often ends up doing things you hadn't intended.
Huh? Templates and virtual functions are completely orthogonal. The performance hit with templates tends to be more related to template bloat (ie: every instantiation is yet another copy of essentially the same code). Most of the template code I've seen actually made very little use of virtual functions.
I'm not sure how you're going to reduce temporary instantiation by returning plain references. I'd like to see an example of this. Do you mean passing plain references as "out" paramaters instead of having a return value? That works, but results in harder to read code in many situations, and essentially precludes the use of operator overloading.
A lot of these performance hits can be avoided. The problem is, often the clearest way of writing the code has serious performance problems that aren't even obvious to the average C++ programmer. Typical C++ programs are filled with unnecessary temporary objects. Removing them requires that you rewrite the code to be much harder to read. For example, a set of matrix and vector classes with + and * operators is only encouraging people to use a coding style that creates lots of useless temporary objects. Yes, it's bad design. Bad language design.
That said, I still use C++ for some of my own "solo" projects. I think C++, like Perl, is too nasty to use for large projects with more than one developer though. It just makes it too easy for people to create unmaintainable, or plain stupid code.
Java works well for larger projects. Yes, it isn't quite as fast as C or C++, but modern JVM's are very fast. A lot of the places where Java is marginally slower are places where it does things like array-bounds checking. I'm quite glad that it does do this though. I'd rather my software let me know when something's broke, rather than just acting weird, or opening up security holes (think buffer overflow).
Oh blah. Have you ever used the STL? It's AWFUL and it bloats the overall size of your program hugely. It generates god awful warnings, and it isn't all that fast. Have you used the QTL? It's really a godsend, and it will work on more C++ compilers. Blah :)
The revolution will be mocked
SGI changed how a lot of the Motif widgets look. Sun did too, but I think SGI's take on it is nicer. Unfortunately, if you just get the stock Motif like all linux apps are compilied with, it looks like crap.
If any of you ever tried the BeOS GUI API, we wouldn't even have this discussion.
Superior compact, well-designed C++ framework with hooks being handled in pure C++ by overriding virtual functions. It simply ROCKS!
BTW, i totally agree with the author in the MFC-issue, it's not even worth considering when looking for a descent GUI API.
Come on... The porting work has already been done. Troll Tech should play nice and share.
This is one of the major things about Free Software -> Work gets done *once*. If it gets done again it's to improve it. Porting X Qt to windows would just be a waste.
I highly doubt that Troll Tech is making very much money off of free software for Windows - The're making money off of *Commercial Software* for both Windows and X. I am going to make a token attempt to stay away from KDE until eithor Koffice gets RPM'd, KDE2.0 comes out, or Troll Tech releases Qt under Windows under the QPL for free software projects.
-- The act of censorship is always worse than whatever is being censored. Always.
Fýrst, it's been a long time since I posted this. The QT license was not revised (it's now DFSG compliant I guess) back then. And I say that the license does matter. GUI stuff is very basic and I'd like it the "free" way.
Second, I know it's been quite biased ýn favor of GTK, but I couldn't help. By the way, although GTK seems better designed, the implementation has a very steep learning curve, someone said it's a resource hog.
After I posted the question, it didn't appear for quite a long time, so I had to revise it. However, the rev. version is not here. Sorry. I had removed the "license is boring" part. And added that interpreted languages should be considered.
--exa--
I also think that tcl/tk helps us code decent GUI stuff. It seems that interpreted code is very suitable for GUI development. Gives you a quick dev. cycle.
Carl Sassenrath had said that interpreted languages for GUIs must be two-way: code->gui, gui->code. I suppose he meant it for the GUI libs of his language called rebol (and prononunced rebel)
--exa--
When you're doing it straightforward, QT is handy. A variety of applications were written with QT. Plus, it undergoes massive coding. I cannot catch up with all the new stuff in QT releases. I haven't been able to code with QT2.x at all.
But it's a bit restrictive. And the moc ýs no good. I don't like a preprocessor that limits the host language. From the C++ perspective, it's insufficient. And QString is a good idea only for a language which doesn't have a string class in its standard lib.
--exa--
I think you have a point in there. I also had to struggle with a framework: called MFC ;) I remember that in the technical report I had claimed that isolation (thus abstraction) of MFC dependency was an advantage.
Now, what about an abstraction library? A framework that categorizes and abstracts every known kind of object might be done. It could abstract away the desktop, messaging, GUI, multithreading, IPC.
I think some of the multiplatform libraries already have similar design. But I don't recall that an abstraction library with no particular toolkit in mind has been programmed. (except Java to a degree)
--exa--
Nevertheless, the swing developers wrote that Java Swing libraries manipulate the original design pattern so that you don't have a model, view and controller object but a model and UI delegate. Well, or something like that. I think they have a reason for that: this way you have many benefits of separating model and UI code but it's still pretty simple to write apps. Hope I approximated the main theme in that article.
Here's an article at javaworld that will do the job.
--exa--
Some prince would come up with this all new magnicient kiss to warp the whole GUI programming experience into a glorious age. Unfortunately, nothing like that.
Seems Java is armed and ready for a big bang of swing apps. On the other hand, ýnterpreted languages such as tcl/tk make a strong alternative.
The technical side of graphical programming is a huge problem space that is being constantly breached by the frameworks/toolkýts in question. For the free software developer, it is currently reasonable to tap into the CORBA'ed worlds of GNOME or KDE, while it is not clear which solution is better for the developer of non-free software. Besides, a better path may be that of abstraction more ambitious than even Java libs.
In addition to GNOME/KDE, there are many libs under development. Some day, one of the newer efforts mýght result ýn a framework richer and more efficient than we are used to. It may be the underlying components (object model, messaging, language bindings, ýmage processing, design patterns) that need to be revised.
Nevertheless, it's difficult to decide which GUI framework/toolkit to use on the X with the more traditional languages lýke C/C++. Perhaps, there lies an unsolved problem, a beauty that can't yet escape sleep.
--exa--
Some points I think should be reconsidered:
;) Beside the fun part, I think you can provide the almost "linear" growth in source code size by utilizing any true OO language. Any lang. that gives you properties of an OO lang. (like abstraction, inheritance, etc.) and some extra (like genericity) would do. I don't, for instance, see why Ada9x is incapable. Personally, I dislike Java, but then swing is really praised by many coders.
1) C++ is the leading OO lang., but nothing lives forever. That's why I wrote Ada9x, I didn't want to be a C++ snob. Though, I prefer C++ over any other lang. currently.
2) About that exponential growth, I might say it's an upper bound (as a CS person
--exa--
Because null pointer exception is not what Java program can generate by itself.
Contrary to the popular belief, there indeed is no God.
I see that I've skipped OpenStep project entirely, and I know I should've mentioned it. Hmm, though I never got to run any OpenStep app in working order. Perhaps they must take better care of install/build scripts and manuals.
I also think that the obj-c makes a great OO environment, but from what I read at apple's web sites on Mac OS X I remember that the whole interface is going Java. They don't really stress obj-c. I wonder if that's going to drive the OpenStep project and mac os x stuff in different directions. Just what I recall...
--exa--
I'm just trying to get people thinking over the subject. I did some brainstorming and wrote what popped up. I really want to sum it up better next time, because this is a question I'd like an answer to.
--exa--
It took me some years to realize that this question had to be asked, this is obviously not a newbie question and I already collected a lot of useful feedback. Please stay on topic.
--exa--
It was not my intention to promote GTK at all. I'd like to get an answer to my question, because I don't know it. That's basically why I posted this as a question and not a criticism/review of various toolkits/frameworks.
--exa--
VisualAge on Linux? Anything like that? It'd be great if we had a "free" version. Gotta look into that.
--exa--
True. The reasons make QT superior to MFC. At least I can do it on X11! But what about threads? In MFC threading is no big thing. you have both worker and ui thread models. Also, recognition of standard lib is important. The standard lib in g++ is vastly superior to anything that QT or MFC can supply.
--exa--
But it's abandoned I guess. Whould we really take off where it's left. It used to be in the motif distributions but now it's gone.
hey, and it's motif!! hmmm. convert it so that it supports multiple platforms (gtk+qt+mfc) might be nice...
--exa--
With an admittedly less than complete understanding of the nature of the problem, I still have to say I suspect much of that has to do with compiler design. Could you perhaps go into more detail on what is information must be preserved that prevents such aggresive optimization. Without an full understanding of the problem I might continue to labor under my misapprehension that C++ is a better language than FORTRAN.
Additionally, I'm not going to scour the Kuck & Assoc website for these snippets. If you're going to reference external info please provde an actual URL.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
By these metrics, Tk wins hands down. You can develop GUI applications 5-10x faster with Tk than with any other toolkit around (especially those based on C, C++, or Java). Check out http://www.scripti cs.com/people/john.ousterhout/scripting.html for data to back up this claim. Tk also contains canvas and text widgets that allow you to do surprisingly powerful things by associating scripts with graphical elements. I understand that GTK tries to emulate Tk's canvas widget, but without an interpreted scripting language you can't get the same powerful dynamic behaviors.
Tk also has other advantages such as portability between Windows, Unix, and Macintosh, but the big deal is that you can create powerful GUIs amazingly quickly.
Hmm. I've been writing an app. in wxGTK recently. I started out writing it in Java, with the calculating engine being in C++. I wanted the XP stuff (which is why I was looking at Java in the first place) but it just didn't look very good. I then thought about Tcl/Tk, because Visual Tcl is really quite cool and I've written quite a few apps. with it in the past. In the end I settled on wxWindows because it could all be in C++ and their coding style is pretty similar to my own.
I have to say it looks at least as good as any Tk app. I've ever written (and there's bits of it that are way way better). It was at least as quick to get the first frame up and running properly as in Java, too, which I found pretty impressive.
of course it can, you probably haven't done much java have you, here's one class test { public void main (String argv[]) { Object myObj = null; System.out.println(myObj.toString()); } }
There were other things, too -- such as plain segmentation faults.
Contrary to the popular belief, there indeed is no God.