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.
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.
The new one in Java is based heavily on NextStep, has great tools (Inprise, IBM, others), is way too easy to program, is quite fast (it now takes advantage of what systems can do natively), and has a cool system that lets you dynamically plug a look and feel into a program (instantaneously make it look like Mac, Next, Windoze, Unix, ... whatever). And it's instantly portable to _anything_, including things far from Linux/BSD/UNIX. Seems pretty obvious to me. Besides, lately it's about the only one I've been allowed by contract to use when I code for the military, the medical industry, or whoever, mainly due to the portability.
The curses library has some distinct advantages for building a graphical user interface. It is incredibly simple, crash proof, lightning fast, and generally hard to go wrong with. It is when you go for the elaborate high-resolution graphical interfaces that you go wrong.
It sounds like you've already decided on GTK+. So why are you asking the question?
I was going to mention Qt since I find it to be a very clean interface, but you've already decided. But I find it curious: you first say that license doesn't matter, then you blast Qt for having a "boring" license. What gives?
p.s. If you're worried about the so-called new "keywords" in Qt, take a much closer look at them. They aren't keywords.
A Government Is a Body of People, Usually Notably Ungoverned
Also, I don't mind that all of the GUI classes for things like buttons, lists, and scroll bars are consistent and clean.
All of the above is basically highly opinionated personal preference, of course. Also it helps if you don't hate C++.
-jwb
- 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.PowerPlant is the best framework I've ever used. Pure, good C++, with multiple interitance and etc. It has a nice GUI builder which is not absolutely required but a real convinience.
I wish there was a framework that good on X...
Motif: Blech. Proprietary and ugly.
Lesstif: Well, it's free, but it's still ugly and non-themable. I haven't looked into the API though.
Qt: Looks ugly. I've heard bad things about the "keywords" it adds.
Athena, Xlib, Xt: Yeah right... Maybe in the 70's.
Gtk: I personally write programs in GTK. I don't really like its use of its own types but I relize that it kind of is necessary. The GUI looks respectable and is themable. But GTK is SLOOOW and a resource hog, especially when combinded with Imlib. The C interface is object-oriented - and as I C++ programmer I don't see the value of object oriented C, with all of the complexity that it adds. I know that there are other language bindings but they probably don't support multiple inheritance, and they definatwely stick with Gtk's concepts... i.e. packing boxes instead of aligning things on a grid in an interface builder.
Java: Well, a very different solution. You need to learn a new language, although most people with Java experience say they would never go back to C++. The GUI toolkit sounds OK, and there are interface builders but AFAIK they are all proprietary (not acceptable). Java is still slow, regardless of what Sun claims (this is the present). And the Java software for Linux/BSD seems pretty weak. But Java is naturally cross-platform, and may be a C++ killer in 5 years. If so, the Java coders will already have the killer apps.
Since there are so many frameworks on UNIX and they change so rapidly you're better off abstracting the toolkit from your applications with yet another layer.
Then isolate the GUI code into its own classes as far from your main code as possible. When I started a project in 1997 there was no GTK, QT was much more restrictive than it is now, and everything looked like shit. A year into the project, GTK was finished and QT was relicensed but still very restrictive.
A second year into the project direct GTK and QT access was phased out in favor of yet another layer above the toolkit. Now instead of interfacing the toolkit you really should interface a desktop library: Gnome lib or Kde lib. Now if you don't want to be stuck with one desktop you need to code that extra abstraction layer between your GUI code and the desktop library. Who knows how long KDElib and Gnomelib is going to stick around.
I think this article is baiting us, nevertheless here is my honest response.
Firstly let me say I have nothing against GTK, I have little experience with it, but I constantly hear good things about it, and I've used some very nice GTK based apps.
Personally I choose to use a C++ based library over a C library, (and I'm unimpressed with bindings in general). To give you some idea of where I coming from I have experience with QT and MFC, I use both on a daily basis at the moment, have about a years experience with MFC (spread over 3 years) and about 6 months experience with QT. (I also have about 3 months experience with each of Java AWT, raw WIN32 & WIN16 api programming, and the Harlequin Lisp GUI toolkit).
QT is vastly superior to MFC. By coincidence the free software QT based development I have been doing is similar to (just from a GUI point of view) to the MFC development I have been doing, and this has given me the opportunity to compare the two.
Here are some observations.
Layouts
QT has good support for layouts, MFC has none. This means it is much easier to create resizeable dialogs in QT than it is in MFC. This means i18n support is easier in QT than MFC (no need to tweak your dialog for each language you support).
I especially like the QT grid layout that supports mutli-cell entries.
Tooltips.
Tooltips in MFC are a bit screwed, the MFC CToolTipCtrl isn't useful as is and you have to derive a class from CToolTipCtrl in order to use tooltips. This derivation isn't application specific exactly the same code is need in each app. Why? Quoting programming windows 95 with MFC "Late in the beta cycle, the Windows 95 designers recognized this problem and added some intellignece to tooltip controls so that the designers could do their own subclassing. Unfortunately, this feature was added too late to be incorporated into CToolTipCtrl". MFC programming tends to be like this, every simple little things requires a dozen lines of work before you start doing anything application specific. (There is a very good open source web site www.codeguru.com that has a collection of such code). QT doesn't suffer nearly as severely from this problem, QToolTip::maybetip lets you decide when to show a tooltip, where to put it, and what to put in it, just hook one up to a widget.
Documentation.
The documentation that comes (free) with QT is excellent, better than the MFC documentation I have. The 12 stage QT tutorial is excellent compared to say the MFC Scribble tutorial, I get the feeling that QT really is a toolkit whereas MFC is a framework. The QT class documentation has decent see also links (very useful!), and inline example code. Basically it is just of a higher quality than the MFC documentation. The QT source code itself is very readable and is a great source of documentation. (The MFC source code is not so useful)
Signals/Slots
The QT toolkit pioneered this concept and it is a good one. Basically they can be used to reduce code coupling and make it easier to create independent components. For high level stuff you don't have to derive a class and override a virtual method with a one line implementation, just connect a signal to slot. People hassle QT for extending the C++ language and this is a valid criticism, however in actual practice this has no drawbacks (you can still debug your programs with gdb and run make to compile all your source). MFC has a signal/slot equivalent "message maps", syntactically they are much uglier.
QTL vs STL
I'm all for standards, I really am. Neither MFC nor QT support the STL as a first class citizen. Unforunately there are compelling reasons for this when using (e)gcs. The egcs STL implementation is bloated and slow compared to the QTL. Syntactically the QTL is much simpler (eg container classes expose begin() and end() methods as well as providing external iterator classes). Still if you already know the STL this is an extra thing to learn.
High quality widgets
QListView is an awesome control unifying the TreeCtrl and ListCtrl concepts. In general QT widgets are done right.
Basically using QT has helped me understand why people complain so bitterly about MFC, and proven to me that there is a better way.
Another library worth looking into is OpenStep; specifically the ApplicationKit. This toolkit is what NextStep has evolved into. Even though it is quite old as far as X11 toolkits go, it is surpisingly well designed, OO from the core up and very MVC.
Warning though, the default bindings are in Objective C, an OO C derived language distinct from C++; ObjC has a distinctly Smalltalk flavor about it.
GNUstep is a GPLed clone. I haven't tried it so I can't comment on the quality.
Somewhat off-topic, the OpenStep Enterprise Object Framework is the best toolset/framework for working with databases I've seen.
I strongly encourage you to take a look at the Mac OS X Server programming tutorials on Apple's developer web site (in particular the Discovering OPENSTEP tutorial), and then at the state of GNUstep. GNUstep is really picking up steam, and is an implementation of probably the most elegant object-oriented framework that ever made it into wide distribution.
From a technical standpoint, the OpenStep frameworks really leverage the dynamic nature of Objective-C. People have written interfaces for other languages (Perl, Tcl, Python, Apple even did Java) to the OpenStep frameworks but by and large the best way to write OpenStep programs is to just use Objective-C. Since it's a strict superset of ANSI C, that's not so bad; you can even interface it with C++ code (though mixing C++ and Objective-C in the same file isn't generally supported yet; Apple's gcc supports it, but the changes haven't been merged).
One of the best things about OpenStep is that your interfaces can be completely data-driven; you nevever have to write code saying "Put a window here, put a button in it, make the button send this message to this object..." You can code that way, but it's discouraged. NeXT's InterfaceBuilder generated "nib" files which could be read in with one line to create complete networks of interdependent objects that would just do the right thing. Work on an equivalent InterfaceModeller (which generates "gmodels" since Apple never specified the nib file format) for GNUstep progresses, and gmodels aren't too difficult to generate by hand.
I think the best way to succinctly describe OpenStep is to say it is to software developers what the Macintosh is to normal users.
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
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.
You don't *have* to use Objective C to write for GNUStep. It may still be preferred, but GNUStep will follow Apple's lead and you can do it in Java (if you must).
The same people tend to not like Objective C who don't like Smalltalk... there's a lot of lip service given to OO lately, but most folks have forgotten about the OO-est language that ever was.
FWIW, despite its popularity, there are some bogglingly-good coders out there who find that C++ is hackish and unreasonable, whereas Objective C is closer to being something usable. In terms of really being OO/providing the advantages that OO is meant to provide, Objective C is (arguably) a better solution. C++ is much more widespread, and (arguably) easier to learn. I guess it's all a matter of taste.
Either way, trying to turn C (portable assembler) into a messaging, OO language is one of those "impossible" computer science problems that will probably never be adequately solved. To wit: OO and compilers don't mix. First person to come up with a weakly-typed, late-binding, polymorphic cross-compiler, wins.
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.
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.
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
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
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.
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
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!
Umm... If it reads in C++ and outputs C, how could it be anything but a "preprocessor"?
:)
;) )
I realize that all the C preprocessor does is expand macros, include files, etc., but the word "preprocessor" itself is a bit more broad. A C compiler could be considered a preprocessor for an assembler.
More to the point, basically all this means is anything you could write in C++ you could really be writing in C, I hope that point isn't in dispute here. (and anything you could write in C++ or C you could really be writing properly in assembler, object oriented or not, GUI or not... It just might take a bit longer.
pb Reply or e-mail; don't vaguely moderate.
(a) Who cares?
:)
(b) If you do care, try GTK themes. They can be slow, just like Windows, and can be made to look the same or better.
(c) Windows could benefit from some of the features of Motif. Tear-offs are a nifty idea, for instance, not that I use them much.
(d) Wouldn't it be nice if Windows gave you a *choice* of widget sets?
(e) Gosh, what do you expect from that original UNIX crowd that gave you *stable* server operating systems, and functional desktop machines with a GUI, mouse, and networking before that was cool. (is that cool yet in Windows, or are we waiting for the next release still?)
pb Reply or e-mail; don't vaguely moderate.
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
This seems to be the most overlooked issue with the gui 'environments' for unix. Imagine if ^X ^C ^V were different in every app? Windows drives me crazy with different keys being mapped to nearly the same function between apps. The Mac gui seems to hate supporting the keyboard but at least there are a few keyboard shortcuts that are common between apps. (there weren't even arrow keys on the original macs!) I haven't used enough KDE/GNOME apps to see if they have a well thought out keyboard shortcut & navigation scheme but from what I've seen I'd have to say NO and that makes me very concerned. ( I can't even navigate the directory tree (+/-) in gnome using midnight commander. I want to simply tab to the tree structure and press my arrow keys to open/close directories. Am I missing something here? ) Common functions (cut/copy/paste/close-win/ min-win/cycle-wins/file-save,open/etc..) should all be the same in each app and it would be nice if the user could map the keys. Keyboard Nav (tab, text selection,menu nav, button press , etc...) needs to be consistent well supported. Modifier keys need to modify consistently. Not alt here, control here, shift-alt for no reason. And finally any GUI needs to remember where the windows were and what they looked like. (this needs to be built into the gui toolkit because programmers rarely support this) I don't want to search all over my file system in and open/save dialog because the programmer didn't want to keep track of the last used/visted directory. When I open a folder (or link to) the file manager should remember the window size and file layout. (even windud does this)
What you're missing is that it makes you pay for a licence if you want to port your free app to Windows. Now, they've already put the work in to get Qt to work on Windows, I want to be able to wright my app once and have it portable to windows just by changing the direction of some slashes in the config file!
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.
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.
Actually, 70+ lines is about right for a _Win32_ program. At the very least, you have to register your window class, create a window, do a message loop, write a window procedure that calls DefWindowProc (or whatever, it's been a while) and so on. Of course, if you're an MFC weenie, you may write a lot less code but MFC != Win32, and the most common way of using MFC via "wizards" in VC++ actually ends up generating a lot more than 70 lines of code for you.
That said, Win32 may be easier than Xlib - or maybe not - but the original estimate was more tied to reality than your "correction".
Slashdot - News for Herds. Stuff that Splatters.
I think he was talking about something that could become the basis for a real program, not some throwaway POS that only reveals the poor programming practices of its author.
Slashdot - News for Herds. Stuff that Splatters.
>C as a language doesn't support the required features to allow you to program in an truly OO manner.
Anything expressible in C++ is expressible in C. This was an explicit design decision for C++. Therefore, C supports every feature C++ does, and if that's not enough to do OOP in C then it's not enough to do OOP in C++ either.
There's an old saying: a bad programmer can write bad FORTRAN in any language. I've seen C and even assembly code that is very object-oriented despite the limitations of those languages. OTOH, most of the worst and least OO code I've ever seen was in C++. We're talking about code that abuses statics and globals, that uses inheritance in unsavory ways (e.g. just to avoid having to type parameters) without any rational parent/child/peer model in mind, that uses overloading to make the code unreadable, etc.
Using C++ does not make code OO, and in some ways even interferes with that effort. Criticizing something for being C rather than C++, without adressing whether it is or is not good OO, is a sure way to prove that you don't even know the difference.
Slashdot - News for Herds. Stuff that Splatters.
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 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
GTK, however, is being ported to Windows, and it's good enough already to use Gimp on Windows with it.
>I have an old Win32 FTP application I wrote that's right around 100 lines w/o comments. That's including the network code.
You, sir, are simply a liar and a troll.
Slashdot - News for Herds. Stuff that Splatters.
>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.
That's sort of my point, actually. People have been doing the equivalent of virtual functions for years in C and even assembler, using function pointers and dispatch tables. Some other people think they're more advanced programmers because they use C++, but don't have the faintest clue what virtual functions are or what they're good for. That's just hogwash. C++ is not an option for kernel work in many environments - notably just about any flavor or UNIX, whereas NT actually supports in-kernel C++ quite well and even requires it in some cases (e.g. filesystems) - but it's still entirely possible to write very OO code in those situations.
Going back to what I said originally, criticizing a GUI framework for having a C rather than C++ style native interface, without addressing the usefulness of its object model (or whether it even has one) is - to borrow your own phrase - just wanking. If it's decently OO but expressed in C, C++ wrappers are a trivial exercise. If it's lousy OO but expressed in C++, there's no easy way to fix it.
Slashdot - News for Herds. Stuff that Splatters.