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
Why exactly is Delphi "not acceptable"? You don't provide any examples. Ok, so it's not perfect, but it's far more stable and powerful than VB (unlike VB which is developed by C++ programmers, Delphi is written in Delphi). The GUI framework (VCL) has its problems, but is far more coherent than MFC. Delphi as a language sucks at times, but we're not discussing languages here. Anyway, CBuilder uses the same GUI framework if you'd prefer C++.
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
wxWindows I have found to be a nice XP GUI library/widget set. It's C++ only though, so that might be a problem for some. It takes advantage of GTK+ or Motif on *NIX. It also supports win32 and Mac.
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.
OK, it's time to end this line.
Turn her to stone. (Slurp!)
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
What makes a good GUI? The ability to use the KEYBOARD. Mice arne't easier to use -- they are a pain in the ass.
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
Yep gtk is the only choice, but its docs really
suck shit...
I mean common! what complete sloppy documentation, its pathetic! what a joke.
gtk.org page on doc project status, some docs have 50% complete status on them, you look at em, and theres hardly anything there...
grade: F for docs
B for code/api
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.
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."
Oh wait. But then you might have to learn a halfway decent language. Forget I mentioned it.
- 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.Following with true OOP, all of the core functionalities are mix in. If you want drag and drop in a window class, your window class simply inherits from LWindow and LDragAndDrop... Messaging is well defined, and window creation is extremly simple. (Made simpler because of resources on a macintosh)
Moreover, all of the framework code is very easy to see and fairly well organized. I would love to see a framework such as this attached on top of a good multiplatform underpinnning. While GTK and QT go a long way to improve straightup X11 programming, there is still a great deal of room for a really well written application framework.
Its very flexible, allows me to do whatever I need to, and is so goddamn simple I've never had a problem with comprehensibility, unlike other toolkits. Its so good, its been bound into languages like perl and python, can easily be called from C and C++... tk is the best.
I routinely write large C/C++ programs that call the Tcl/Tk library for the GUI and for portability (sockets and file handling.) 30-40K line programs compile unmodified on all versions of Unix and on Win95/98/NT. This allows me to do development on Linux, then ship an EXE file to the end user. Anything that savings me from having to program on a Win95/NT box is a winner in my book.
I've tried Java, GTk, and Motif, which I like in approximately that order. But none of them come close to the speed and ease of use that Tcl/Tk provides.
One other plus: The Tcl/Tk source code is the easiest to read and understand of anything I've ever seen in the Open Source world.
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.
I think GTK code is far too ugly and complicated. I'm worried that GNOME uses GTK and worst of all, C.
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.
What would be useful, is an intermediary between application and framework. such a thing would sit between the gui framework and the application, so that the application/os/user gets to decide what widget set to use to display the app... this could give X a more common interface (as users can select to use ONE framework throughout their system) and can opt for any framework that they like best, for whichever reasons. Also, it would allow compiling to be easier as you wouldnt need more than one widget set necessarily for all of your 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!
I have lately been working with VDK. It was largely written by Mario Motta. Home page: http://www.programmers.net/artic/Motta/vdk VDK is a C++ OO wrapper for GTK. The current version is 0.6.5. There is a RAD tool (VDKBuilder) also. The license is LGPL. VDK will probably become the major competitor to Qt. (I only know a little about Qt, so I can't do a point by point comparison of the two. Is there anyone out there who would like to post one?) My general impressions so far: Surprisingly solid for so early in its development. I have yet to have a crash due to VDK. (I have had a few due to some obscure bugs in GTK or possibly glibc, however these were easily worked around.) The class library (or application frame work, if you prefer) seems well thought out. There has been a tremendous amount of work done on this. However, it seems a bit short on the "excessively cute" features. This may be seen as a positive or a negative. It is very nicely OO conformant. The RAD tool is still too early to do serious development yet. I use it often to get a feel for what I would like to see, then hand code it. Coding in VDK goes quite easily and smoothly, once you get the hang of it. As with any class library / app. frame works / API, it takes some time to understand how the author "thinks", once you get it, you can easily interpolate to anticipate how other features work. I rather like VDK. The documentation is a bit on the bad side. English is not Mario's first language. He has written a concise Class Reference Manual, however this is a bit rough for people who have little experience with this sort of thing. I am currently writing an "Informal Introduction to VDK". Contact me if you wish: John Harris jkharris_NO_SPAM_@swva_NO_SPAM_.net_NO_SPAM_
One thing very few comments seem to have touched on is the users' perspective.
A wide variety of GUI frameworks is great from a programmer's perspective, but what about the poor user who has to learn yet another conflicting set of key bindings, menu layouts and controls?
I notice everyone is quick to argue about the internal aspects of software, but the fact of the matter is a powerful piece of software is of no value if nobody uses it.
People with complaints about GTK should look at VDK!!!! (See my earlier comment on VDK.) VDK is a C++ OO wrapper for GTK. GTK *is* slow to code and very messy. VDK is quick, clean and easy. Give it a try!!!! John jkharris_NO_SPAM_@swva_NO_SPAM_.net_NO_SPAM_
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.
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
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
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'
Vey nice. It is boring cause you have to pay for the software if you want to make money with it? How fucking professional -> I wanna make money but I don't want troll to be able to do exactly the same. You people are nuts - GPL will have to disapear for the simple reason that it promotes pure communizm -> we will all work for the good of as all, everybody according to their skills. It sounds nice on the paper but is completely unworkable. If you still don't understand why , time to take economy 101.
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.
Since the man obviously likes Java and Swing, but is concerned about speed, what is the current state of native Java compilers for Linux?
I have heard that Jikes (from IBM) is a fairly nice compiler, could someone more knowedgable shed some light on this topic? I haven't used it myself. Is it native?
The real speed issue comes from interpretation, I beleive. The language itself should be capable of running as fast as any other full-featured OO language, with a decent compiler.
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.
A good keyboard-use scheme and total keyboard configurability are indispensable for ANY program or environment, graphical or not, mousey or not. The problem with keyboard use on the Mac and in Windows is that they FORCE you to use proprietary, off-main-block keys and keystrokes. The GUI that allows 100% WordStar-like, vi-like, Emacs-like, or comparable keyboard-based operation is the GUI I will use. -- dski (gotta register on this account some time....)
One word: Threading God damn it, not a single GUI uses it. (or not enough) Doesn't it bother anyone that you get a 'grey square of anti-matter' whenever the process is busy? Never saw that on OS/2. Hell don't even think that happened on my old Amiga!
How funny. This guy sets out criteria, asks the question and then proceeds to provide answer (GTK) that is probably last compatible with his own criteria.
It would be very convient to create quick, easy to use apps, by using an HTML, javascript style system.
If only javascript didn't SUCK. And wasn't so SLOW. And had some sort of well defined, working implementation.
$stupidthing =~ s/JavaScript/perl/g;
Wishes again for perl and HTML without that *@#& CGI interface.
I've written a GUI Hierarchy for a program I'm writing. The basic idea behind it is one base class (GUIElement) which defines a number of virtual functions process, update, isRelevant which I can call to get the heirarchy to update. There are subclasses like pixelLayout which contains a list of other elements each stored at a specific offset from its reference whose standard functions it calls. There is also an action class which has many derived classes that can be passed to those objects which support it along with a Condition subclass which evaluated a specific input and determines if the action should be run. I think this is a pretty standard method of implementing a GUI, but I don't really have much experience in them so I've made most of this up on my own.
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 wish you people wouldn't sell Motif short all the time. Suns, SGIs et. al. all run CDE motif, and new application development is still fairly prevalent in the hard science/military sector.
Before everyone bitches at me, please recognize the following:
1) A lot of apps work well and look okay under Motif. You have to be knowledgable about resource management to make it look good.
2) It came out like 13 years ago. Before Linux. Before M$ windows (win 2.0 might have been out, not many people used it, and MS looked like shit compared to Motif). Before KDE. Before Gnome. Miguel de Icaza was like seven years old or something. Give some credit where credit is due, and maybe a little forgiveness.
3) It made life a lot easier for programmers, since they were able to work at a substantially higher level than Xt.
4) I like Doug Young's book. I can crank out Motif/C++ apps pretty fast now. Fully tested, in a few days. Granted, the quick ones are only several hundred lines of code, and I use a gui builder to do the geometry.
5) I'm regularly in a room with over 90 SGI/Irix workstations, running Motif/OGL apps, and they rarely crash. As in: They run for months at a time, no problem.
6) If you want to sell your apps, Motif or Borland are generally less expensive than KDE. I think you can distribute Motif apps statically linked for free, and the development CD is as low as $75 or so. With KDE, the development is free, but the commercial distribution rights are, what $1000?
7) Pro-level engineering workstations ship with Motif. There's something special about a $20K engineering workstation, they just don't feel like a junky 'ol PC. They have sauce, or something.
8) I prefer C++ (the language) but dislike it's zealots. They were never really that deep into C, if they actually hate it. A well designed struct, in a well designed environment is a beautiful thing.
Well, I guess that's it. Motif has been around for awhile, and has fallen from grace, but it was first, and remains pretty cheap for commercial application development. If anything, the Open Group missed the boat on Open Source, it's done wonders for Linux, KDE and Gnome, but that's a different issue.
I think some respect is due, others will disagree.
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
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
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.
So what could the Open Source Definition tell about free software? Free software is defined by RMS and according to him qt _is_ free software. Who cares about ERS's definition about Open Source anyway.
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
Maybe on Linux. But on Solaris, NT, and AIX it's been *ROCK SOLID*
My company runs a heavily trafficed server based on Java that has an uptime months (doesn't crash, just it's being updated with new features all the time)
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.
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.
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
Swing1.1.1 fixes a lot of the memory usage issues, and JDK1.3 (recently released beta on Win32 and Solaris) improves speed, startup time, and memory usage issues alot. see http://java.sun.com/products/jdk/1.3/docs/relnotes /features.html There is a *great* misconception among the Slashdot crowd about the speed of modern Java VMs. The 2D rendering library still has some performance problems, but the linear execution speed of raw Java is right up there with C++. Don't believe me? IBM rewrote Java's arbitrary precision arithmetic classes (the kind that can be used to build RSA cryptography for example), and the end result was a 5x speedup over the previous native C++ version. Only the GUI stuff is slow and only in certain areas, so it's merely a subjective impression that Java is slow. JDK1.2 with HotSpot, or IBM's VM will reach 90% C/C++ speed on raw execution speed (like say, an MD5 or DES algorithm)
Addition: All of the BeOS' APIs are multithreaded, by design. :) Before I learned C++, I had this mental concept of each object "living" by itself, (in it's own thread) and in BeOS, I'm getting really close to a virtual world of living objects, thanks to the threading and messaging. I could never love another OS like I love the BeOS. :D /Jonas Sundström, s96j1su@csd.uu.se home.beoscentral.com/mirilla
Anything that discriminates against commercial use is PER DEFINITION not Open Source software! Stop bending the rules.
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.
The Berlin project is said to be incorporating many of its concepts
Unfortunately, it's documentation, while very good is not extensive, there is no printing support, and it is said to have fewer widgets than some other libraries. It has only a few significant users and the current maintainter is not actively developing it.
Give it a try. I think you'll be quite impressed by one of its several demos in which can make a copy of a drawing editor with another copy and work its buttons, etc, after rotating the whole copy.
I hope someone can be found to keep it alive, improve its documentation, and help popularize it.
Find an intro page with much more info about it at Fresco page of Gary's Encyclopedia
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
Plus CORBA, and a host of other modern concepts. It mostly lacks extensive documentation and users. Find intro at Fresco page of Gary's Encyclopedia.
You're right, one of the cleanest apis (and languages :-) I saw. Look at www.gnustep.org, the GNU implementation of it. It's finally nearing usable state with the 0.6 "dawn" release. Good luck to them.
You're right, one of the cleanest apis (and languages :-) I saw.
Look at www.gnustep.org, the GNU implementation of it. It's finally nearing usable state with the 0.6 "dawn" release. Good luck to them.
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.
Sorry, if i'm Off Topic, but is GTK/Perl a good choice ?
I know WinAPI, and C++ but I'm a Perl Lover.
I wonder is Perl will be a good choice for coding under X small application (Like Database Front End)
I've been using FLTK (www.fltk.org) at work and find it really nice to work with. It provides all the features you want (c++ language, platform independence, a GUI layout designer - fluid) and creates extremely lean executables in comparison to everything else out there. Also it's integration with OpenGL is best I've seen. BTW. since version 1.0 it is pretty solid too.
Have another look at it.
Read the subject. I hate people when they claim that QT is free software. This kind of free sucks. I want to write closed software and to sell it to my granny. But now I have no motivation to do it. I think that development libraries and tools (OSes, make, gcc, etc.) should be free to use for anyone. But it's not a perfect world. Yet another example of wonderful UNIX fragmentation.
"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
- Widgets are butt ugly (on unix)
- the resource system sucks badly because of its incoherence -> you can't change the looks easily and reliably
- language bindings suck. Of cource there is SWIG but you still have to use intermediate tcl.
- the object model of tk sucks - simply no structure
- it is cross platform, but there are subtle differences between the different platforms which are not hidden from the programmer
these just came uo to my mind, i'm sure there are even more. tcl/tk IMO is only useful for small use once and throw away apps like installers or configuration panels but you don't want to use a tcl/tk app at daily work.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)
He asks what toolkit he should be using as if he is a newbie then proceeds to slam everything but Gtk+. It sounds like he is already familiar with programming and is using Gtk, and is just using this as a platform to FUD everything else.
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.
The guys doing Lazurus have done exactly this. You can use FPC to copile some delphi code for GTK on Linux, GTK on Win32 or a native Win32 interface.
It's a work in progress, but what they have, works. Have a seach on freshmeat for the home page
Why even use curses? You could bypass the whole screen manipulation and use straight print and let the screen scroll away.
Look: www.viewkit.com
As for the outdated appearance of Motif, all I can say is that a) it depends on the window manager (no, you don't need MWM), and SGI's demonstrate how nice Motif can look when you bother to use a nice color scheme. For some reason people will let ugly defaults slide with other toolkits, but not Motif.
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 like Motif, using ViewKit C++ wrapper. I need compatibility between work/home (Irix/Linux) and so I still use Motif. If it ain't broke, don't fix it. SGI's 4Dwm makes Motif apps look very nice, as well as using their color schemes.
This guy obviously made up his mind what toolkit he likes, and cuts down every other toolkit. He obviously knows the different toolkits yet Slashdot "editors" post this as a fake newbie question. What a load of FUD.
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.
Have you tried QXtWidget with allows mixing of Motif/Xt and Qt widgetsfor a smoother transition?
I'd be interested how well this works.
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
You're being cynical, are you?
In fact, the QPL is better for free software than the LGPL (free sw is preferred), and still companies are happy because they can get proper commercial support.
But, alas, anti-TrollTech trolls apparently never die...
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 really really really cannot believe how dumb you are. Does the GPL discriminate against commercial use? Can I use Linux to run a commercial website? Can I SELL my own Linux distribution?
If you can't see the difference between the QPL and the GPL I'm not goint to waste my time with you.
I dont think this can be disputed. Everyone who has had the pleasure to use the BeOS interface has fallen in love with how elegant and quick everything can be done. This is an example of what to do. It's very fast, very slick, and just gives you a nice warm fuzzy feeling. Gnome, GTK, etc are all a HUGE pain in the ass as far as Linux goes. I have yet to get an Enlightenment release working since DR10 due to lack of documentation and the fact GTK libs just wont install/cant be found anywhere. We need simple setup.exe programs for Linux before any of this can even be commented on being a good framework/gui. If 70% of the people cant install or use it, it just isnt worth it, IMO.
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.
enum Color { white, black, red };
struct Data
{
char name[64];
Color color;
int coffee : 1,
tea : 1,
water : 1;
};
And produce a string widget, a pop-down list and a serie of checkboxes. I once wrote such a thing, but it was a run-time affair, thus slow. A parser that produced a resource-like file that I only have to add struts and springs, and feedback functions, that'll be nice.
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.
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...
It's alive and well and living in South America: http://www.ambiencia.com
(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.
This pseudo-question is very unprofesional. If "ex" or whoever is a GTK bigot - his problem. But why pretend that one is asking a question when he/she already decided on the answer ?
Well, I once worked for a company that tried to use Galaxy to get their product out the door on time. I'm not about to blame Galaxy because the programmers were piss-poor, but Galaxy was also one lumbering giant of a system. The Columbus project was supposed to bail the company out of some serious problems, they were put together to create the "next generation" product in competition with whatever it was that our one competitor would produce. It didn't help much that the company was always late for marketing deadlines, and it didn't help much that there was no clear definition of what it was they were creating. It was decided that Galaxy was this wonderful product that would cut production time, enable rapid application development and just make things that much easier. I'll be the first to admit that the original product (before Galaxy) needed a Multi-processor Sparc20 or better, 512 to 1024MB of RAM, and some monstrous swap space (also between half to a GB.) Then Galaxy was added to the mix and suddenly the company didn't own a single machine that would *compile* the end result, much less run it. Yikes. Bloatware is not the word for it, more along the lines of everything *and* the kitchen sink. I took a look at Galaxy, or at least what Columbus had done with it. What I saw was incomprehensible. Oh yeah, and quite similar to the makers of Galaxy, the afore-mentioned company does not exist any more. alaric alaric@portone.com
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.
I'm actually Puppybane, but I forgot my password and have not been able to put up my mailserver yet (my hub died).
:)
email intelligent comments to:
My current address
email stupidity to:
An address at my old mailserver...
Someone already said it, but they were too bitter to extol the virtues to the ignorant... So I will.
The OpenStep AppKit Framework (as well as its FoundationKit framework) is very well designed and easy to use. Getting an application from algorithm to GUI usually involves little or no work.
1) The frameworks are in a very powerful, yet easy to use OO language: Objective C. HOWEVER, for those of you who don't wish to learn a language which has traditionally been the realm of NeXT developers, the frameworks now work in Java and C++. In fact, you can intermingle AWT and Appkit bits in your app. I would say that C++ support is not yet up to par, but it's coming soon (less than 1 year), and I think you're better of to use ObjC anyway.
2) Appkit is completely platform agnostic. The only big problem is that Apple owns the rights to the stuff, so the only hope right now for x-p stuff is either Darwin (Apple's open source stuff) or GNUStep, which is getting much closer to a fully functional system. OpenStep, though, still runs on Windows (95 or NT) and Solaris. (Rhapsody runs on PowerPC). The only thing you need to do to make your program run on the other platforms is tell the compiler to compile for them. You can even change the GUI depending on which OS will run it (so Windows users get "Exit" instead of "Quit", etc).
3) The AppKit is very easy to understand, with a clear inheritance hierarchy, and excellent modularity. Also, ObjC makes it easy to change any class you don't like, or need more functionality from. Just Subclass it! This is actually how you do a large portion of the specific interface code. If you write a Document-based application, you just subclass NSDocument (all of the AppKit classes start with NS...NeXTStep) class, implement 2 functions, optionally add some stuff to execute when the document is loaded, and it's done! The system is simple because it relies on sending specific messages to each object, and you can choose whether or not to intercept each message. Most of the boring stuff is implemented for you: New Document, Open Document, differences between Save/Save As... It blows me away everytime I use it.
4) Ummm... I don't know what MVC is, but writing an AppKit program is very straightforward.
5) The license, as I mentioned, is one sticking point. BUT, NeXT published the OpenStep standards a while back, so someone just has to wait for GnuSTEP to finish (Note, I'm too lazy to look up the exact capitalization for gnustep, openstep, nextstep). I do urge people who are interested to email Steve Jobs to devote serious time and money to find a good licensing strategy for the Windows version of the framework (Note: this is not a call for flames. Nothing good comes from weighing down a mailserver with malice). For the people interested in an X11/Linux version, visit The GNUstep Page
6) I know for certain that the AppKit is mostly thread-safe, and uses TCP/IP. Though that may also depend on the underlying OS, which has to use threads and TCP/IP. As for JPEG files, I don't know, though I bet that if it's not built in, OmniGroup probably wrote an add-on to do it for you...
Gosh, I've been going on forever here, but I only have a little more to go:
This Framework is very well documented. The native development tools allow easy access to the definitions and instructions for use for all of the classes in the AppKit (as well as the FoundationKit).
Anyway, as a disclaimer of sorts:
1) I am not a very experienced programmer (I didn't get serious about it until 3 years ago). I don't have experience with any other GUI framework, other than the normal Macintosh Toolbox, which is not OO.
2) I have only been using the OpenStep frameworks since April, 1999 (when I recieved my copy of MacOS X Server).
3) I have been a big fan of Macintosh since I was too little to understand the differences, and since Apple now owns this framework, I may be biased.
Ok. I'm done, now.
If all you do is propogate calls to another procedure (probably in a separate object file) then your maintenance becomes much simpler.
Somewhat, but it's still not much better. This still results in the GUI and the application being too tightly coupled. Event handlers the way they are typically used are evil. A lot of people think having an event handler function is a good OO design since they can make the handler virtual and override it in derived classes. This is WRONG! A much better approach is to use the Command pattern (see Design Patterns by Gamma et al.) This lets you abstract the call-back mechanism the underlying GUI uses and reduce coupling, not to mention getting rid of ugly if and switch statements.
Well, you can use Qt/Python.
Stephen Molitor steve_molitor@yahoo.com
When people want to prevent people from "highjacking" their code with a different license, why do they feel no qualms about doing it with other people's X11-type licensed code? It might be legal (though I have some good arguments why the way most people do it it isn't legal), but it sure is hypocritical.
I posted twice on this story about exa and both have disappeared (even on -1)... This is not an impartial "Ask Slashdot" by a newbie, btw...
I used to work for Zinc years ago. We had a very nice xplat toolset and framework. I would use it again. But my favorite system was the NeXT AppKit and FoundationKit, and the Interface Builder and Project Builder tools. This is where I first learned OOP, and what a joy it was to learn. It was harder to build an app that didn't conform to NeXT's delightful human interface specification than it was to build one that did. Part of the problem with Linux and its GTK, QT, etc., is that (1) they are not object-based and (2) their designers were more interested in flexibility than ease of use. This means competent programmers and sysadmin types can modify looks and feels to their heart's content, but that everyone else has too difficult of a time doing so. Linux has already surpassed the quality of most Unix kernels--now we need an open source object system that surpasses NeXTstep. [ kris magnusson ]
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
But does it support wrapping (multi-line) text in a cell yet?
The only drawback of Coral is that it does not currently have themes.
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?
I agree wholeheartedly. I could really go off on this, but no-one here is going to listen. If you step back you will notice how Apple and Microsoft have done their damage to all these people already. It doesnt HAVE to be the way it is now.
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
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"
Put away your toys, boys and girls, and upgrade to the WorkPlace Shell (WPS) GUI of OS/2 Warp. It's clearly the top GUI.
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
What C++ code have you written? If you did seriously use the two toolkits you would know that Gtk-- is just a lame wrapper upon Gtk+, not a fully integrated set of classes. Wrappers suck, even the Gtk-- authors said so.
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.
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
I'm not going to say it, you figure it out.
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
The one that Swing stole most of its ideas from was written in C++!
Instead of learning from what's been done before.
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.
Anything reasonable that can be done in C++ can be done in C
Yeah, and evrything that can be done in C can be done in Assembler. Please refrain from posting such BS until you get a clue what you are talking 'bout.
Anyone else know any other unavoidable performance hits in C++ that are language related as opposed to compiler related?
have a look at kuck & assoc. website. they have a few code snippets that most C++ compilers choke at while the C compiler does well right away. it has to do with the complex data dependencies and integrity that the C++ compiler has to preserve and that prevent aggressive optimization. its kind of the same reason why simple numerical kernels are way faster in FORTRAN than their naive C conterparts.
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.
Hmm.
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).
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.
You may find this Galaxy critisism harsh, but keep in mind our company shelled out over $100,000 for this garbage library...
To say the C++ interface was clunky is a huge understatement -- it sucked ass bigtime. I doubt you guys at Visix even knew you could pass arguments to C++ constructors. Also, nice vsCRAP and vstring "classes" - the only string class in the C++ world you had to clean up after. Your object memory model was completely baffling - no-one ever knew what you were responsible for destroying or what the toolkit was resposible for: I guess this was in large part due to the extremely poor documentation. I could go on and on forever on how bad this GUI library was, but I doubt Slashdot has the disk capacity.
In the end Visix died because of their complete abandonment of their C and C++ support (even for _paying_ customers!) and due to the creation of the lame-ass "Vibe" product which no-one wanted to use because it was contaminated with Galaxy.
Thank you for posting.
I've never had such a good laugh as when I read your Galaxy post. Your strings and struts are not welcome here.
Now that's what I call "write once run as slow as crap everywhere!" Do they just make shit up as they go along at Sun or do they actually have a plan?
I don't see why Delphi is in any way superior because it's written in Delphi. Delphi strength: it handles window resizing very well, unlike VB. Oh, and it compiles to Intel code. VB strength: Intellisense code completion is way more usable than the Delphi equivalent. Plus, COM integration is way easier (though less granular). -Kevin
Tcl/Tk slow!!!? I was a VB and Delphi programmer until I saw the light of tcl/tk. My development times went up by an order of magnitude, and the apps definately are not ugly, or slow. I have a host of apps running day in, day out on multiple platforms that really buzz along. Methinks you need to look again. GordonJ
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--
right on brother ! galaxy - great gui layout tool - piss poor set of c++ classes wrapped around a set of c libraries ( vchar, vstr , etc ... ) - dog slow interprocess communication via vscrap classes
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--
Pete, is that you?
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--
Again, Gtk-- is crap. The API sucks. Just because it is C++ does not make it a good API.
That is why it is good ;-)
Almost every other platform has recognized this and hardly any code GUI apps in C anymore. As far as signals, Qt had that *years* before Gtk existed.
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--
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--
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--
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"
Dude! D00D!!!#$*! Tcl/Tk may cut down initial development *time* for small to medium sized apps. The results are very often shoddy products. But he real drawback comes, when the time has come to extend the code and the original programmers are no longer at hand. Tcl/Tk simply doesn't cut the cheese here. Its total lack of structure is a nightmare. Its semantics are straight outta hell. BTW, these "features" make Tcl/Tk the favotite baby of commercial "software consultants". Its easy to come up with s/th that alomst gets it right (low initial cost for the consultant) and later guarantees you the joys of endless code fixing for the customers.
Re:sorry, but ARE YOU ON CRACK??? by Anonymous Coward on Friday August 27, @01:10PM EDT (#) The relevant question is not whether companies run their business with this or that software. The relevant question is how well the software works when companies run their business with it. And from all I have heard, Tcl/Tk cuts development time way down and works nearly flawlessly. Needless to say, the same cannot be said for Windows. Ironically, that smooth operation may be part of the reason that Tcl get so little publicity. It seems to me that most or all of the other "GUI frameworks" discussed in the original article are based on what are known as "systems programming languages," such as C++ and Java...
Dude! Java and C++ are no "systems programming languages". Get a clue what you are talking about.
John Ousterhout (the originator of Tcl) wrote an excellent paper explaining why scripting languages are becoming more and more important, and not just for "throw-away" apps.
John Ousterhout is a dumbass in this respect. He just wrote a shameless plug for his newborn commercial baby. And you are an even bigger dumbass if you actually really buy his words. Scripting languages are not the solution for complex program systems with big data structures and complicated UIs. Scripting languages are for scripting small programs that get the task at hand done, and for doing it quickly. Thats why they are interpreted and highly dynamic, and don't enforce good programming style because everything else would only get in the way for this purpose.
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.