Slashdot Mirror
The Superior Motif?
Janon writes: "There's a rather interesting interview with Antony Fountain, a Motif developer and reference manual author at O'Reilly. He makes some rather well-founded (or at least it seems so to me) claims that Motif has some rather important advantages over the likes of GTK+ and Qt, such as an open and superior component model." It's a great illustration of the split between open and closed development, too -- fans of the Bazaar may see only waste in Fountains assertion that "Millions of lines of Motif get written and not one word about it leaves the company doors."
I write a lot of my programs using Motif. However, it (along with Xt and Xlib which you must also learn to be an effective X/Motif programmer) is so involved to learn that I wouldn't have bothered had GTK or Qt been out when I started developing under X. If young developers -- the ones who often have cool, exciting ideas -- aren't learning Motif, it is for all intents and purposes dead.
That said, EditRES is very saucy. If you're running Netscape 4 now, fire up "editres", do a "Get Tree" on Netscape, and start changing colors, labels, and even layout and behaviors. [Then start coding that functionality for Qt or GTK.]
DanAt the time I used a memory debugger called "purify", that detected all sorts of memory errors (acesses out of bunds, buffer overruns, buffer underruns, acesses to dealocated blocks, memory leaks, etc.), and It reported thousands of errors inside the motif libraries.
There were all kinds of errors from memory blocks accessed after being freed to memory leaks.
The problem was so bad that even the documentation from "purify" had a paragraph explaining how to filter the error messages caused by the Motif code, because otherwise it was impossible to spot our own bugs.
I beleive that this problem still persists today and this is one of the reasons that explains why Netscape Navigator keeps crashing so many times.
Right now, I'm porting all my applications to GTK+ with the help of Glade.
So far, I'm using "njamd" as a memory debugger and it doesn't detect any problems ou memory leaks.
Previous /. Discussion here
Not to mention the fact that GTK+ (and almost the entire Gnome toolkit) is licensed under the LGPL. Which means that you can even create closed source commercial applications using those libs and never have to release a single solitary line of your own source. That's why GTK+ and Gnome are becoming the new supported desktops for the commercial Unixes and QT is not (it is licensed under the GPL).
Which is basically why Fountain is so cranky. GTK+ and Gnome are taking the place of Motif and CDE, and most new projects are already switching to these toolkits. And since he creates and sells a GUI designer for Motif... Well, you get the picture.
Even worse, newer versions of GTK+ fix most of the problems that he mentions (libglade for the component model, and I believe there is internationalization work as well). In the end technical issues like this aren't decided by whoever has the most elegant, stable, or easy to use solution. The solution that wins is the one that is "good enough" at the lowest price.
It's game over for Motif.
If an API makes you do 2 or more times as much work with little in return, it's of NO use to you. If an API takes up 2 or more times as much binary code without giving you something in return it's of NO use to you. You can use it because you think you're elite or because you enjoy hard work or don't mind inefficient code, but in the end it's not that it's useful that you're using it- it's merely because you WANT to use it.
Sorry to say, Motif makes you work harder for a UI that is both ugly and unwieldy. I know, I used to write Motif apps professionally.
Motif applications, tend to needt he whole library statically linked against your application under Linux- because not all apps work with Lesstif and some of them use Motif2 which isn't supported by Lesstif. That tends to make apps using it much larger than say a GTK+ or Qt application. This doesn't take into account the fact that I'm doing 2-10 times as much calls into the api which results in a larger app even if it's not statically linked.
Whether you like it or not, if I can get the same job done with less code (Similar speed of application operation) then the smaller, easier API wins hands down every time.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
In our in-house Qt applications we turn on Win32 appearance everywhere. The Motif look is ugly as sin, and since the widgets change size lots of stuff does not work.
I have to also rant against this belief that the users are confused if they don't have a "consistent user interface" between their programs. This is absolutely untrue, I have never seen anybody confused because the buttons in their programs look different, witness the game designers who don't seem very concerned about the appearance of buttons! What does confuse people is when their favorite application changes between platforms (or between versions). I have been killed here because I attemted to change our bindings to be Windows-like, people could not stand it (despite using this application on NT) and I had to change it back! Nobody seems concerned that Alt+X does cut in my program but it is Ctrl+X in other programs, they were totally frustrated by my attempt to change it to Ctrl+X. So I believe that consistency in an application is far, far, more important than between applications. And all attempts by toolkits to mimic the "theme" of the platform are mistakes that make the programs unportable and user unfriendly.
The problems of the inability to direct a FILE* to an in-memory stream (at least in a portable way) are well known and toolkit independent. You will be in exactly the same state if you call your binary library from GTK. Yea, libc should be fixed, however I have seen the nice ideas of iostreams be turned into an enormous bloated mess by people who have no clue (with "wide characters" and binary i/o and attempts to make a thing designed for byte streams into the do-all of stream input output), so I am not sure if we want them messing with FILE* (which I have been forced to return to because of the bloat and slowness of the modern template cio library).
You have to flush the output buffers. For cpio you can do "cout If a binary library writes to stdout or stderr, there is no way any toolkit can get this without modifying libc (actually there may be something that can be done with Glibc, but whatever it is is going to be toolkit independent).
Motif was written long before C++ so it is not suprising that there is no way to redirect cout to a widget. Motif also does not use C++ which means this could not be part of standard Motif (though easily in a C++ only header file).
The interview takes a rather dark tone WRT GTK and QT. It's clear that Fountain likes Motif, but at the expense of his own vision.
He doesn't offer any interesting insight why motif is neccessarily better, other than: "We can write proprietary applications and people won't talk about them".
Well, duh! You can write proprietary apps with any widget manager you like! GTK isn't encumbered with any legal virii.
If Joe Schmoe Corporation wanted to make a GTK interface for an internal CVS repository application, then they can.
He acts as if using GTK automatically entitles the GTK group to announce your application on Slashdot and toot their own horns. I'll give you a clue: It's the app builders that toot horns, not the GTK peeps.
If Joe Schmoe Corporation doesn't want their horn tooted, then they'll just keep the shut up!
The reality of the situation is that Motif only exists because of corporations that believe they have to use a proprietary, expensively licensed, widget library in their applications, or they won't be taken seriously.
I seem to recall that Netscape first built on Linux, unencumbered, when LessTif was stable enough to permit linking. That was because LessTif was trying to mimick the Motif API in Open Source. Then GTK came along and it seems the drive behind Lesstif is lessened.
Don't let the FUD mongers that want to see Motif remain a cash cow distract companies from using GTK or QT as their widget of choice.
Wow, um where to start. I can't believe this got on slashdot. On the question of Is Motif experiencing any kind of resurgence associated with the current Linux wave? he avoids it and talks about how linux people don't like licenses. From what I have been able to gather I don't know of where motif is being used now. gtk and qt have been put just about everywhere. With QT embedded running around why do you even need X any more let alone motiff!
s /k de/style/basics/index.html
i /i ndex.html
... wait for it... a commercial organization. There was also kde studio from the kompany, and that ptyhon qt linux/windows app who's name slips my mind.
Not to beat a dead horse and spit on it and drive over it with a druck, but motif is ugly. Always has been and always will be by default. Fountain talks about user interface, but he is such a hipocrit when the only thing gtk and qt people agree on is that the ui sucks for motif. If that isn't powerfull I don't know what is. While we are here, has he even done any research into the "No user design guides in linux" How about
http://developer.kde.org/documentation/standard
or
http://developer.kde.org/documentation/design/u
(Sorry don't know of any gtk ones off the top of my head) I think I should write an article that says that motif sucks and has no support and is dieing. It may not be true, but then again I didn't do any research so I can't say it is false! NEXT!
Componants, companants componants. Hmm would I rather have 650 componants or 30 well thought out componants. They may have 650, but that just would confuse the user don't you think? I would rather see less that are more standard. Whiel I am at it sense they have had time to make all those componants why don't they spend time on there damm ui and make it better. heck just the file dialog, anything! Even gtk's is better (qt is still better, but KDE's tops the cake) I could rant on this for a while but you all get the point.
there is no commercial GUI builder for Qt What rock has he been under. Ok so you don't have to count glade as a commercial vendor, but what about QT's, Designer??? Last I checked that was made by qt, who is
OK Internationalization. I know that as of 1.3 gtk had the internationaliation stuff in and working. And way back as of qt 2 all the char's were 32bit so that is that argument. Heck wait a sec he has none. There are powerfull translation tools for qt and gtk and from what I know they both do layout. It is only with netscape 4 that I remember having translation issues, wait wasn't that done in Motif...
Bla why am I even wasting my time. I just shake my head when I see stuff like this.
Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
I spent a couple of years doing heavy duty Motif development, and can assure you it's the most bug ridden piece of crap you can imagine. It's also got a lame widget set.
I downloaded Qt, and from knowing nothing about it was up and writing my own widgets in a few hours - it's an excellent API and widget set, not to mention QtDesigner vs things like the Motif designer UIM/X which was expensive as hell and followed in Motif's tradition of bugginess.
Sorry - experience says it's no contest. Qt wins.
Fountain claims that you can't write GTK apps which support multibyte character sets like Japanese needs. Obviously he's never used GNOME in Japanese or Chinese. When Pango is stable, his comments will no longer be merely wrong, they will be laughable.
perl -e 'fork||print for split//,"hahahaha"'
Take this quote, for example:
Indeed, there is no commercial GUI builder for Qt or GTK+.
WRONG!
How did Mr. Fountain miss the press release announcing Kylix from Borland? This is a commercial GUI builder and RAD development environment which relies on Qt.
I did Motif devel for 6 years, I switched to GTK about 3 years ago. Here's why:
... a very simple rewrite for GTK brought load times down by a factor of 10 (ten ... TEN)
API -- GTK has a much, much nicer programmer interface; if you're coding stuff by hand, it's about 1/2 the number of lines (guess)
speed -- Motif pays a huge price for Xt. One of my apps makes a whole bunch of widgets when it loads a file
open source -- developing for a widget set which you have the source to is just lovely. With Motif, if something didn't work the way you expected, you had to spend hours trying different stuff at random. With GTK, you can see what's wrong, and how to fix it.
simplicity -- GTK is much simpler than Motif, and it's much easier to write your own widgets. The object model is much better. Signals rock. Within a few hours of starting GTK, I subclassed one of the standard GTK widgets and modified its behaviour; fantastic. Xt makes subclassing widgets difficult.
range of widgets -- GTK has a much better range of standard widgets. At the end of the interview, Fountain says he's updated his new edition to cover the latest widgets, such as the ComboBox and the Notebook. Good grief!
portability -- amazingly, not all Motifs are equal. If you want to write an app which can run on most versions of IRIX, HP-UX, Solaris, etc. you can only rely on quite a small part of Motif. This is an incredible and enormous pain. With GTK, you can just say "needs 1.2.10 or better", and if the user doesn't have that, they can download and build. They don't need to go through their vendor to get the toolkit. This is less of a problem now that Motif has opened up a bit, to be fair.
portability -- because GTK wraps Xlib, I can recompile my app, and it'll run on Winders.
Fountain is right on i18n being a current lag point for GTK. GTK2.0 (due out fairly soon (less than six months? not sure)) will include stuff like pango. This will jump GTK quite a way ahead of Motif on i18n.
On introspection, GTK has had this for years, I'm not sure what Fountain is talking about here.
I've not used Qt, no doubt similar stuff can be said.
Athena is small, clean but ugly. It was only an example widget set to show how to use Xt. Xt's structure, with its resources describing every aspect from the GUI is very powerful. There are even add-ons that let you create your widget hierarchy (i.e. GUI structure) using some small external text file (a much much more productive way than using a WYSIWYG GUI builder).
Motif, one of the real-world widget sets on top of Xt, is horrible, as others have said in this discussion. It also walks over some basic Xt do's and dont's. In that respect, Suns OLIT (the open look widget set built upon Xt) was much nicer in every respect. Alas SUN lost the UNIX interface wars due to political reasons (only).
I hoped Qt and GTK would become the new standard unix GUI toolkit (one of them, at least) but I must say that I am very dissapointed if even "old stuff" such as editres are not there.
As long as there is nothing that replaces the network transparence of X, it is not going to be replaced! Even the Linux-PDA from agenda computing decided to put X in that tiny machine. Once you have made a TCP/IP connection via PPP from your Linux desktop, you can remotely display the agenda's X-window apps on your host computer, which is very cool and useful. Sending the whole screen bitmaps (a la laplink type of software for Windows) would be way too slow and would not take advantage of larger display size and resolution of your desktop. X-window does such things transparently.
I'm convinced that X-window will even be in embedded devices. There is no need for embedded Qt.
Of course, to be fair, a lot of the problem with the "Crappy old motif apps" is that they are just that -- old! Most of those things were designed before the concept of threads came along and many of them were simply kluged together in a time when you didn't demand a lot from a GUI. Motif was popular in the days of Windows 3.0. If you want to know the level of expectation for your applications, break out the old XT and fire it up. That's pretty much what we had to work with.
With some modern design principles, you can write an effective Motif program. However, I never found GTK lacking for my user interface code, and the stuff I've done has been pretty esoteric. I also enjoyed having the GTK community on hand if I ever ran across a problem. Between them and the source code, if I ever ran across something bothersome, I could damn well fix it myself.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
In the Motif Era (tm), David Flanagan produced a
library called "Motif Power Tools" (Xmt) which
included the most genuinely powerful, capable,
and just plain _right_ window layout manager I've
ever come across. Xmt's other capabilities
included the ability to make massive changes in
appearance and functionality to a Motif user
interface without so much as recompiling a single
line of code. This was a truly and genuinely
useful construct, and I still rue the day that I
eventually moved to another environment where Xmt
wasn't handy.
There's also an irony here. David Flanagan is
"somewhat famous" for his authoring of _Java in
a Nutshell_, which he'd admit he threw together
fairly haphazardly (and in any case, was pretty
cruddy). Meanwhile, his Xmt effort was an effort
of love, both at the source level, as well as the
documentation level... a genuine feat.
The irony is that _Java in a Nutshell_ made Mr.
Flanagan truly big bucks. _Motif Power Tools_
was a financial flop.
Ah well; them's the breaks.
C//
I'm sure lots of lines of Cobol are still being written behind closed doors, in dirty little rooms filled with sterile programmers and clamorous machines, but I wouldn't offer that as an argument for its relevance (or its superiority over Java). Popularity is often a red herring in a debate of merits; if it were one we bought into, we'd all be running Windows.
Whether Xt is still important/relevant is debatable. Heck, people argue that X is antiquated and not relevant to modern networks and desktop systems.
Ultimately, though, Qt and GTK/GNOME are in their infancy compared to Motif, as Fountain points out. The moral of the interview, component models and all aside, is that, yes, Motif is not dead, but, yes, it's stake is being usurped by the next generation. My grandma writes Motif.
Personally, my favorite quote in the interview is, "There are things Qt in particular does better than Motif: it is nicer to program with, for example."
Oh yeah, my grandma's dead, by the way.
However, to me, all that is water under the bridge. In practice, Motif was a messy and buggy toolkit that it took forever to get anything done in. Most corporate and defense projects I have seen dumped Motif as soon as they had an alternative, mostly for Tcl/Tk and web interfaces (but if you prefer to believe that the lack of press Motif is getting is some corporate conspiracy to keep the good stuff from you, I have some Internet stocks for you to invest in).
OTOH, I don't think Gtk+ or Qt will have the life span of Motif, for a variety of reasons. The only existing toolkit that seems to me like it's going to survive another two decades is probably Swing, which is pretty powerful, easy to extend, and still simple enough to develop for.