Become a fan of Slashdot on Facebook


Forgot your password?

The Superior Motif? 155

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."
This discussion has been archived. No new comments can be posted.

The Superior Motif?

Comments Filter:
  • by Anonymous Coward

    And why does it need to be commercial, like that inherently makes it better?

    I agree that it does not make it inherently better but I can see where he is coming from. A lot of commercial vendors will not use/buy anything unless it is a commercial product because of the support issue. It seems from a management point of view that you always need somebody to blame.

    As an example at the place where I work we are currently evaluating bug tracking systems. This has been going on for a couple of months and I am getting sick and tired of it. So I offered to grab bugzilla, install it and get it working for our team, but the idea was vetoed purely because it wasn't commercial and there was no official way to get support. This is dispite the fact that it whoops the ass of a lot of commercial products.

  • by Anonymous Coward on Tuesday May 22, 2001 @05:56PM (#204345)

    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.]

  • by Anonymous Coward on Tuesday May 22, 2001 @05:00PM (#204346)
    I've been a Motif developper for more than 6 years (from 89 to 95) and at that time Motif was full of dynamic-memory bugs.

    At 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.

  • Netscape crashing: The problem most probably isn't
    a Motif one. While Motif makes Netscape bloated,
    the bugs stem most probably from the fact of a different memory-management on Solaris (where
    Netscape is developed on), which is very forgiving
    and uses different alignment. Other operating
    systems aren't. So there..

    Don't develop on Solaris if you want your code
    to run on other systems. A lot of bugs won't
    turn up on Solaris.
  • Yeah, but go ahead and look what an experienced developer would do with his machine once it got up and running..

    When I got a Sun Ultra 60 at my previous work, I installed KDE after few minutes - and that was much better then the butt-ugly CDE.

    Yes, companies like HP/Sun announce that the future for them will be GTK/Gnome - but that decision came from the bottom - when most of the engineers hates Motif and CDE, so they replace..

    You might want to look at the machines of most engineers in Sun are using - half of them use KDE and almost half - GNOME. Maybe 10% of them still use CDE (that number came up when I talked to several engineers from Sun from various departments).
  • Well, I'm sure that many people will tell you that the license is far away from a really open source.

    Go talk to the guys at about the license and see why they refuse to look inside the code..

    And even if I accept your statement that this is Open Source - then so? I would hardly recommend to any of my clients to buy Motif for their application - I'll recommend to use QT (specially if they want to port their applications) or GTK (if they write in C - the binding of GTK in C++ is nowhere near QT with C++)

    Motif is D.E.A.D - live with it!
  • ...why is everyone, including Sun and other big-name commercial UNIX vendors, switching from it to GTK?

    Granted, I *hate* GTK, from a programming perspective (let's take C and make it slow and ugly like C++!), but there's got to be some reason people are abandoning Motif.

    - A.P.

    Forget Napster. Why not really break the law?

  • *g*

    Isn't that a marvellous statement of a failure to have a clue about open source development? The whole concept of a 'key killing point' is irrelevant to OSS- if something doesn't suit a task, it'll sit around until somebody needs it- especially w.r.t Free software, which has basically infinite shelf life- if you EVER need routines that were once GPLed, they will be there for you to use.

    "Key killing point" is only applicable in an either/or, winner/loser code environment, namely proprietary software, where code competes for relevancy and that which loses is lost to the world. Which hardly leaves much 'successful proprietary software' to compete with the OSS ideabase...

  • As long as there is nothing that replaces the network transparence of X, it is not going to be replaced!
    Ummm... VNC []?
  • You are the first person I've seen mention Tcl/Tk in this discussion. What's up with that? It's been around for a long time, before Qt or GTK. It's portable. It has a fine license. So why didn't it become the defacto free widget library? Tcl seems to have encumbered it, but despite that many language bindings exist. I don't know if it has the best set of widgets, but I'm sure that could have been fixed. So what's so bad about Tk?
  • Is it hard to make new widgets in Tk (compared to Motif/Qt/GTK)? Or hard to distribute? Or is it just that the maintainers of Tk dropped the ball when it came to incorporating all the good widgets they should have?

    I mean, at some point GTK had less widgets than Tk did. So there must be some reason GTK got ahead.

  • that'll just about get you a working "hello world" program. It'll be very configurable though.
  • NONE of the major Unix vendors (Sun,HP,Compaq,IBM) have switched ANYTHING to GNOME. Sun and HP have announced they will provide GNOME 2.0 when it is released and STABLE.

    <sarcasm> So that's why the Sunrays attached to the loaner Daktari system Sun had in here last week had GNOME 1.2 on them...</sarcasm>

    News flash: Sun is shipping GNOME NOW.

  • I am amazed that such lame anti-Open Source FUD goes unquestioned. His argument against Open Source seems to be based on the idea that a company cannot privately use a piece of Open Source software. He talks as if the GPL mandates an announcement on Freshmeat and a submission to Slashdot. A company can, of course, use GTK or any other piece of Open Source code without telling anyone if they so-wish, within the constraints of the Open Source license (isn't GTK distributed under the Lesser GPL anyway?).

    And he cites the fact that there is no commercial builder for GTK as a disadvantage - what is wrong with Glade? Why does a builder need to be commercial?

    There is some other interesting info in there which I am not qualified to dispute, but his anti-Open Source comments sound like something you would expect from Redmond. It is unfortunate that O'Reilly didn't press him on these issues.


  • Exactly. The difference between Motif and the newer Free Software toolkits like QT or GTK+ is that someone is actively working on making QT and GTK+ better. It's been a while since this article was published, and it would appear that in this short time both GTK+ and QT have resolved the issues that Fountain raised. That leaves Fountain's only defendable reason to use Motif as "there is lots of legacy Motif code."

    In other words Motif is dead. People don't hang onto legacy software systems when their only reason to stay is that switching would be expensive. After all, the cost of migrating will only get more expensive with time (you will have created more content in the outdated system). The time to switch is now, while everyone else is still learning the new environment. Be careful though, chances are good that either GTK+ or QT will eventually dominate.

  • GTK new standard ?
    If so why do we even bother to try get rid of Motif.
    It is the same old crap !

    Ah, but it's not the same old crap. GTK+ is a lot less expensive crap, and it comes with source code so that it is possible to make it less crappy.

    You are making the same mistake that Fountain made. You suppose that technical merit has something to do with who eventually wins. Technical merit is somewhat important, but more important is being "good enough" at a lower price. GTK+ is certainly "good enough" (especially if it is being compared with Motif) and the price is right. You can even use it without paying royalties in your proprietary closed source applications. That's an important benefit that has already pushed the commercial Unix vendors towards Gnome, and away from KDE.

  • There are all sorts of ways to work around this problem. The easiest being to deliver the correct libraries with your application. A simple shell script wrapper will guarantee that the correct libraries get loaded and linked dynamically.

    Not that it matters. GTK+ is licensed under the LGPL, which permits linking (even static linking) with proprietary works. If this wasn't the case then the commercial Unix vendors would be sticking with Motif. They are not interested in a toolkit that would require them to release the source code to their software.

    Here is a link to the text of the LGPL. [] And here is a pertintent quote (emphasis added).

    As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
  • by Jason Earl ( 1894 ) on Tuesday May 22, 2001 @07:37PM (#204362) Homepage Journal

    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.

  • 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."

    Oh yeah, we're all going to need a million lines of code specific to some pharmaceutical app. Get a life, Timothy. Most of the code ever written is useful only to people in their industry, and more often only useful for a particular company.

    From the article:
    As commercial engineers, we don't plug our own names or reputations with the software that we sell.

    No wonder he's getting trashed here - some people actually just do their jobs, instead of engaging in endless self-promotion. What a concept.
  • Huh?

    Did you read the same article I did. The only real mention of commercial programming he made was simply to state that they don't bother to toot their own horns when they create something. As compared to Linux which someone makes a big announcement every time something is sold.

    He then goes on later in the article to point out why the Motif library is better in his opinion. It's somewhat technical, but he basically attributes this to the component model.

    You should go back and reread the article.
  • by Svartalf ( 2997 ) on Wednesday May 23, 2001 @05:24AM (#204365) Homepage
    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.
  • Then use Lesstif. The code is solid and doesn't have the memory leaks you mention. And I've also use the free Motifs available now and not faced the problems you talk about. I believe you; things have just changed.

    And as for Netscape crashing, I don't think Motif is at fault. When I ran Mozilla pre-Gecko (the version based off of 4.7), it crashed plenty and Motif wasn't the cause.

  • True, programs should read the Xresources, and I think both GTK and Qt are making a big mistake by not doing so.

    The X resources are stored with the server, which is very useful for getting the interface correct when you can run remote applications. In addition they allow the resources to be different per application, something none of the theme systems seem to address.

    However I very much disagree with the way Motif used it, where they turned it into a huge database that could not be programmed without intricate knowledge of the innards of the application (and often where the program was unusable unless several hundred correctly-set fields were in the database). I also disagree with their inane attempt to merge several (eventually dozens) of files by the application to get the database (ie the "appdefaults", searching for ".Xresources", etc) rather than leaving this to another program and only using the resources string from the server.

    The X resources should be on the level of the Win32 preferences settings, very general like they were intended when X was designed, things like "text background color". Not the Motif scheme where the color of every single button can be set individually. This sounds powerful, but is actually totally useless to any real user and makes the database obscenely complex.

    Basically Qt and GTK get it wrong by not reading their settings from the database, and Motif got it wrong by turning the database into a Windows-like "registry" with all the bugs needed.

    PS: You can easily emulate the X defaults on Windows, just read them from a file! You should also read the Win32 preference settings, it should be trivial to make the toolkit #ifdef in some code for this at the same point it reads the X defaults. With the design specified above there should be no reason to use the Xt or Xrdb functions, just parse the string yourself.

  • Ahem. Maya does not use Motif! And for good reasons, too.

    It is possible to be crappier than Windows. "different" and "better" are not synonyms. Analog computers are different too, maybe you should use them.

  • by spitzak ( 4019 ) on Wednesday May 23, 2001 @09:57AM (#204369) Homepage
    Except KDE sets something so that Qt is switched to Win32 appearance all the time. A very good idea. I wish Qt would just give up this stupid "Unix look" and make the default be the Win32. The could probably delete a lot of code, too (apparently this appearance stuff is sepearte from the newer themes stuff).

    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.

  • Although I also think Motif sucks, your arguments seem to indicate you don't know what you are talking about.

    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).

  • Indeed. Reminds me of a book "Practical Xview Programming" that I once read. The authors couldn't see that then (1994) Xview was on its last legs (to be killed by CDE/Motif) All the same arguments were there: more code being written in Xview, Xview is the standard, Xview more mature, etc., etc.
  • In the early '90s on Solaris (which was the only UNIX that counted in most places back then) Xview *was* the standard. Motif was practically nonexistent then. Then *boom* CDE became the standard on Solaris and Motif took off.
  • Yes, there's a jwz rant on Slashdot on the same subject that I can't be bothered to look up now,
    and an interview that I have searched for and couldn't find where GTK's authors say they did it that way because they wanted to learn about what was involved in writing a toolkit layer. (I can't remember wheher they said they would definitely have used Xt if they knew where it was going to end up, but I think at was at least more likely).

    But it's probably too late to be worth changing GTK to use Xt now.

  • 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.

    Many thousands of lines of Visual Basic are being written behind closed doors, too. Doesn't make it a superior language/environment, just popular. Motif was the defacto standard for "legitimized" *nix/X programming for quite a while, and the model is still good.

    However, more "modern" toolkits are going to catch on and take over, and I don't think Qt and GTK are going to be the end of it. Why? Because we live in a world informed by Visual Basic. Newcomer programmers are going to expect more and more of the busy work to be done with simple calls. It's a Good Thing, in that it allows the programmer to focus on the task at hand, but it is a Bad Thing, because in mastering the arcana, you master the basics whether you know it or not. (The Wipe-On/Wipe-Off effect.)

    Motif, unless it's redesigned and rewritten -- and genuinely opened -- is going to wither on the vine for better or worse.

    (Yeah. this is something of a "me too" post...)

  • Why was this moderated as funny? Insightful, maybe. But not funny.

    Xmt was very nice. In the mid 90s, I built and delivered a series of Motif applications that used Xmt. It was very nice. Hell, I even contributed some bug fixes. But, alas, Motif is showing its age. And Xmt, while being very nice, can't make up for the rest of the problems brought by Motif.

    Following David Flanagan's lead, I've been a Java programmer for 4+ years now. And, remembering the "good old days" when I could configure the entire GUI with Xmt using Xdefaults, I now encapsulate the GUI inside an external XML file. The GUI is completely separated from the business logic, allowing for automated testing. Internationalization involves simple changes to my GUI XML file. I can theme my applications by merely changing the GUI XML file. I tip my hat to David for leading me in this direction.

    But, seriously, this message wasn't (imho) intended to be funny. It was right on the mark. Interesting and insightful.
  • libGlade does a similar thing. You define the entire inteface of the application with an XML file. You can redesign the entire application with a change to XML files.
  • by Y2K is bogus ( 7647 ) on Tuesday May 22, 2001 @05:09PM (#204377)
    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.
  • Yes, instead they send out memos telling managers not to approve any more paper, paper-clip, staple, toner, coffee, keyboard, pen, telephone, tape, floppy disk, etc... purchases until the end of the quarter because well, "Our department has gone over-budget."
    I'm sure the 1.2 million in software licenses didn't help.
    Believe me, this does happen and happens often even at large companies.
  • by domc ( 11897 )
    IIRC, you can switch between desktops by using Alt-left/right arrow keys.


    Not that I like CDE though.
  • What Fountain was citing jackoff is that GTK didn't provide a means of object identification to programs. With Motif you can have a interface builder app say "What sort of widgets do you have?" and the Motif library or independent widget library spits out a list of widgets and whatnot. That sort of functionality is nice because you don't need shit hardcoded into your builder, you only need to code the ability to place some library's widgets and ask them what they are. He also is saying in the article that whenever some new Linux app comes out someone's usually patting themselves on the ass because they used GTK+ or Qt to make it. All the GPL mandates is that coders be commie pinkos.
  • When I'm admirered I get a rock solid erection.
  • if linux on the desktop is dead (see previos article) where does that leave the toolkits that run on the desktop...

    You know it has been my experience that motif has a small niche market that is probably smaller than the linux desktop. Qt and Gtk+ are both easier to program in even if they are not as complete. But then again motif is how old and has had how long to get where it is? Gtk+ is still imature (as I type this in Netscape 4 on UNIX which was done in motif).

    Personally I'd like to know of what NEW applications are developed in Motif tool kit?

    I don't want a lot, I just want it all!
    Flame away, I have a hose!

  • by IceFox ( 18179 ) on Tuesday May 22, 2001 @06:31PM (#204383) Homepage
    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!

    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 /k de/style/basics/index.html

    or /i ndex.html

    (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 ... 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.

    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.
  • The problem with Motif, though, everything else notwithstanding is that Motif is _butt_ugly._

  • Agreed, you can't. But while I concur that portability is a worthwhile goal, I don't think your GUI toolkit is the right place for it.

    The GUI is, or should be, part of the platform. Think about it, the real justification for spending system and programming resources on a sophisticated toolkit is usability, and for most people this strongly implies consistency.

    The other problem is that relying on a cross platform toolkit removes the incentive to cleanly separate the user interface from the backend, leading to less maintainable and portable code in the end (think Mozilla).

    If you really think the additional effort isn't worth it, for example if you have to keep hundreds of dialog boxes in synchronisation, you could still use an effort such as wxWindows. For most smaller applications, however, the effort in porting just the user interface (assuming that is possible) is probably less than the effort in cross-platform testing, which had to be done anyway.
  • Licensing, possibly. Some people like the fact that GTK+ is available under the GPL. I'm currently trying to find some time looking into GTK+ partly because of that reason. (Not that I'm a zealot in any way, but I do see some advantages)

    Also, while I completely agree that GTK+s design is pretty questionable and annoying for programmers who expect something else, the library itself is written fairly well and copies you get with recent Linux distributions tend to be more stable than the default Motif libraries found on many commercial Unixes.
  • Come on, this is a matter of taste. Personally I find a well configured Motif visually much more pleasing than almost any GTK+ theme. (Ignoring the horrible 2.0 Notebook widget for a moment---nobody uses that anyway).

    However, I agree it's very easy to completely mess up Motif interfaces if the programmer starts to enforce their weird colour prefences and to dump widgets all over the place without regard for user interface design considerations. GTK+ prevents that to some extent.
  • Based on programming for Motif and Qt (admittedly, this was two years ago), I liked the Motif widget sets and interfaces better.
    Also, at least at that time, it seemed the Motif was a lot more polished, and had what I needed built in, in addition, it worked more seamlessly out of the box on my Solaris boxen, as compared to being quite as Linux oriented as Qt was (is?).
    Is Qt a lot easier to use out of the box nowadays, on non-linux unix based platforms?
  • by SpinyNorman ( 33776 ) on Tuesday May 22, 2001 @05:53PM (#204389)
    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.
  • In this case, it would be good if the winner were picked by a long process of evaluation and development, followed by developers voting with their feet (well, fingers). Unfortunately that almost never happens. The fact that I run windowmaker, but can run qt/kde and gtk/gnome apps simultaneously means this will be a long, drawn out battle, with no clear criterion for picking the winner. Probably it will come down to dev tools or something not quite the true merits.

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.
  • I'm sorry, really I am. VNC is a great program, and I use it daily. However, it doesn't stack up against the way X does it's thing. It is possible for me to start a program on machine A, putting the windows which are opened on machine B, while I'm still sitting at machine C. And yes, this is useful, as it lets me help out people who are having issues with starting programs at all (and believe me, they ARE there, I work with them).

    VNC is wonderful. It doesn't provide all this same functionality, and as such, it's not got the usefulness of the basic X protocols. And that matters to me.

  • by divec ( 48748 ) on Wednesday May 23, 2001 @01:46AM (#204392) Homepage
    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.
  • No disrepect to the author of the reference manual which I seem to remember was a nice book along with the rest of the X set. But I would argue that motif is not "the native toolkit for the X Window System" It did later become the toolkit of the Common desktop environment. Thats another story

    Motif came to zenith as a windows look and feel, early 1.x implementations were extremely poor quality and the SDK was expensive but did promise faster gui development. Just around the time it became more stable up comes the browser and the
    rest was history. Well consigning motif to history at least. If openmotif was done earlier maybe things would be different but this product is from a bygone age of consortiums with the big cheeses like IBM, HWP, Sun. The closest I get to motif is Java and netscape, thats close enough for me

  • There's nothing wrong with Motif. It has been designed from scratch to be extensible and it can still get improvements over years.
    I've written Motif, QT, Gtk, Photon (QNX) and Fltk apps. They all work the same way. The basic widgets are the same, and when you've learn how to code one, you can easily move to another one. They all work on a hierarchical component model, with inheritable attributes, and an event-based system.
    For some apps, especially those who are dynamically building widgets, QT and GTK are easier to program. And libglade is something worth to look at. It goes one step further than other toolkits, because an user can build his own interface for any compliant app, not only customize an existing one with themes or colors. For widgets with dynamic content (lists, panes), Photon (on QNX) beats them all. It's easy to code, smooth and damn fast.
    The only problem with Motif IMHO is that it eats up a lot of memory. Especially when you are using nested scrolling panes. Properly using widgets and gadgets can reduce the memory footprint, but it's always huge. It's not the size of the Motif library itself, but the amount of dynamic memory it requires for itself and from the X server. I can't run more than 3 or 4 different Motif apps at the same time without running out of memory (128 Mb) . Other toolkits don't seem to need so much memory, even with complex themes.
    The FLTK toolkit isn't very popular. But it's really a very good one. It's LGPL'ed, and it has X, OpenGL and Windows backends. It's fast and lightweight. And it has many similarities with QT. If you want to write an applications with basic widgets in C++, try FLTK before QT. It's not easier to code, but your apps will run faster (at least the GUI part) . FLTK also comes with FLUID, an efficient interface builder. []
  • I personally think that abandoning some of the most basic X protocols was a huge mistake on the part of the Gtk+ and Qt hackers. I should be able to set resources in my .Xdefaults file, xrdb merge them in, and they should take effect. It's a beautifully simple, portable system. I can take my .Xdefaults file from my Linux box to my HP-UX workstation and it works perfectly for my xterm settings. Meanwhile Gnome and KDE both have their own methods for handling this because those camps decided to reinvent the wheel, and they've blown the beautiful simplicity I've come to expect from Unix out of the water. Thanks for nothing people.

    You should have built on top of X, not around it.

  • You seem to be the only one making that comparison....
  • by Danborg ( 62420 ) on Tuesday May 22, 2001 @05:19PM (#204397)
    Take this quote, for example:
    Indeed, there is no commercial GUI builder for Qt or GTK+.
    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.
  • Qt is a cross-platform toolkit. It runs on *nix, X-less *nix, MS Windows and Apple Macintosh.

    Now, explain to me how you would go about building a cross-platform toolkit "on top of X".
  • by The Musician ( 65375 ) on Tuesday May 22, 2001 @04:56PM (#204399) Homepage
    Yeah, the slashdot storyis about a year old! The interview was in April 200 (see here []).

    You can read two pages [] of responses [] to the interview, too!

  • My apps come w/ their own widget libraries. All hand coded in pure x86 assembly language. No need for portability. My platform is the ONLY platform. Have fun with your GTK+ QT Motif premade toolkits, script kiddie tools. C, C++, cobol. You are all a bunch of script kidides. Fucking posting an article that was already posted over a year ago here on slashdot. If you really gave a shit about motif, you would have known this is OLD news, and it is not news for nerds! Real nerds do not need premade tool kits. They do not even need X for that matter. But that is another article entirely. And fuck you anonymous cowards who can't post a netative comment under their real name. Fucking karma whores. Timothy is not off the hook either. He should have checked all the previous articles posted here on slashdot. But he didn't, and now we have a problem because we have a duplicate article. It's just another "my penis is bigger than yours" article anyways. So therefore, this post is ON TOPIC, and should be moderated accordingly. Thank you for your time.
  • Well, this was a couple of years ago, I guess it's better now.

    The thing that bit me was the form widget: the Sun Motif let you have circular dependencies if you kept horizontal and vertical links separate. The HP-UX one didn't, as I discovered when HP-UX people started complaining :-(

  • by jcupitt65 ( 68879 ) on Wednesday May 23, 2001 @02:24AM (#204402)
    I did Motif devel for 6 years, I switched to GTK about 3 years ago. Here's why:

    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 ... a very simple rewrite for GTK brought load times down by a factor of 10 (ten ... TEN)

    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.
  • Qt is so much nicer to core
    So, um, I take it Qt core dumps a lot, then, but it sort of feels good when it happens? ;^) ObNoFlamers: it was a typo, yeah, y eah. But I couldn't stop myself. ;^)
  • by Baki ( 72515 ) on Tuesday May 22, 2001 @09:40PM (#204404)
    Ouch. I have never really looked into GTK or Qt yet (I develop mainly server based software), the only GUI toolkits I know are Motif and Athena (both Xt based).

    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.

  • by Baki ( 72515 ) on Tuesday May 22, 2001 @09:48PM (#204405)
    Please, not again one of those anti-X rants. Some people only seem things to exist that they understand. X is too complex? It must die. The whole world should adapt to what your limited mind can grasp?

    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.

  • Motif sucks a fat one. I wouldn't really know, as I've never ever been unfortunate to do any programming with Motif, and have only toyed around with GTK and QT.

    As far as ease of use, I didn't find GTK or QT to be too difficult, and I NEVER, EVER, EVER, EVER __EVER__ do any GUI programming... ever... Well, except for like 4 or 5 years ago in Java 1.something. They both seemed pretty straight forward to me.

    Anyway, what I *DO* know about Motif from experience is that it is the ugliest fucking GUI toolkit I have *EVER* seen. Windows, Mac, GTK/QT blow it away it terms of both look AND feel. Even if you're a hardcore "looks don't matter" geek, the feel is still important, and God Motif is just so awfully disgusting! Then there's the matter of stability...

    I have only seen _ONE_ Motif app that is really stable, which would be Nedit BTW(the absolute greatest text editor in the world). Can anyone else think of another stable Motif app?

    Why is anyone still using Motif, why is anyone defending it? For the sake of all that is good and pure, throw that wretched thing away! = )

    Why oh why am I still awake?

  • Isn't it amazing how out of touch the author was. Even a year ago when the story was first posted you could tell that Motif was dying, and the past 12 months haven't made his assertions seem exactly full of insight.

    But I suppose it is to be expected, considering the author's investment in Motif.

  • by Greyfox ( 87712 ) on Tuesday May 22, 2001 @07:25PM (#204408) Homepage Journal
    I've done development in both GTK and Motif. I was able to do hella more with GTK. Motif seemed pretty awkward by comparason. Maybe they've redesigned the thing to take advantage of advances made in the development process in the past two decades, but I'd rather stick with something that doesn't have all that baggage. Of course, you could always snarf lesstif and check it out for yourself.

    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.

  • "Millions of lines of [Insert Your product here] Motif get written and not one word about it leaves the company doors"

    doesn't everyone know products that they wish word never got out about?
  • It amazes me that people are so shallow and caught up their blind hatred of MS that they won't use something because it reminds them of Windows.

    All GUI interfaces look pretty much the same, with buttons, scrollbars, cycle gadgets etc. etc. That goes for Windows, MacOS, GTK, QT, Workbench or Motif. Stick a nice theme on GTK or QT and either of them will look less like Windows than Motif ever will.

    What you are really saying is that you are prepared to burden yourself with 1980s technology so you can get off on how 100% pure Unix you are. You're also saying that you don't care how hard Motif is to program because you're so much cleverer than all us GTK/QT idiots.

    I hope you're coding in strict K&R C a PDP-11, because if not then you're betraying your true Unix soul.
  • "running against mostly unknown candidate ..."

    George Bush, son and namesake of former president, governor of third (population) / second (area) state in the nation, brother of governor of Florida was mostly unknown? bwahhahhahahha - where can I get some of your crack?

    "Makes you wonder what will happen if they have to fight without these advantages ... "

    How would you rate the advantages enjoyed by Bush V. Gore against those enjoyed by Clinton V. Bush? Or does your memory not go back that far?

  • " Yeah, but was he known to anybody else beyond Texas?"

    Yes, he was, and as the other replier said, unfortunately, name recognition can be more important in our nation than actual konwledge of candidates.Compare Bushes overall "unknown" factor with that of Bill Clinton at the time of his first election

    "Our national press was not exactly eager to cover his state reforms in education etc ..."

    How did you find out about it then? Or do you live in Texas?

    "I also remember that Clinton was able to win only because there was one time stunt candidate who managed to grab 19% of the national vote."

    And Bush-2.0 was only able to win because of critical votes that went to Nader. Nader, a very left candidate, arguably took a higher percentage of dem votes than Perot did of rep votes.

    Your problem is that when viewing symmetric situations where the only difference is the role of your particular favorite political party, you arrive at non-symmetric conclusions. Your sig is demostratably false. Was Clinton a liberal at the time of his national election? Don't hedge your bets and move the goal posts when challenged, back up your claim. Your sig doesn't say "the only way liberals can win a national election (in which a third party candidate doesn't blow my perceived validity of the election) is by pretending they're not liberal. Let's go further. Was Jimmy Carter a liberal? How about FDR? Kennedy?

    If I wanted to play your partisan games, I could quip in return that "the only way conservatives win national elections is by pretending they're not conservative". But unlike you, I know both claims are wrong. Your sig, like most partisan rhetoric, may be a nice sound bite, but anyone can see after the slightest scrutiny that it doesn't hold water.

    By all means keep using it, I just find it sad that so many people succumb to the us-versus-them mentality of modern american politics.


  • WRT "us-versus-them mentality", I rest my case.


  • Various "soundbites" from your rhetoric:
    • "... militant mentality was unfortunately forced on us mostly by Democrats ...."
    • "... emotional outcry, which has become so common among Democrats ...."
    • "... every time there is a proposal to reform SS we hear about Republicans extinction plan for our seniors ...."
    • "It is always Democrats with their cries about "racism","bigotry" and all that crap."

    And the clencher:

    "I almost never hear insults or heated rhetoric coming from that [right wing] end"

    Open your ears, the irony might be clogging them when you speak.

  • So far, I'm using "njamd" as a memory debugger and it doesn't detect any problems ou memory leaks.

    What use is the debugger if it does not detect memory leaks!? ;-)
  • Right:) I mean, I did (first thing checked when I found the memory leak ). I also tried with XtVaSetArgs, which accepts plain strings instead of XmString (I guess it converts them internally?).

    At the end I solved using textfields, with resources set si that they looked almost like labels.

  • I am aware of one leak which is real, though. Try putting up a window full of XmLabels and update them every second. You will see your memory sleep through your fingers for no apparent reason.

    I discovered this bug severals years ago, and it is still there ...

    Having done my fair share of Motif GUI programming, I am glad that now there are mature alternatives. Though Motif had some good ideas, in its time. One such idea (IMO) was the User Interface Language, which describes your GUI elements much like Glade files do. And, like libglade, it allows programmers to generate the GUI in a single stroke.
    For me, this is much better than GUI code generators, which tend to generate rather messy and unmaintenable code, especially for non-OO languages.

  • Nice reasoned article, many things I'm inclined to agree to.

    A remark, though: I was forced to used Motif under C++ for my diploma thesis in University. Of course we had no GUI builder.

    It sucked. Royally. No, wait,...

    It sucked beyond comprehension.

    I spent most of my time finding out how things, parameters, widgets etc actually behaved (as opposed to manpages or Fontaine's book), fought with incredibly shitty useless details (the things a toolkit is supposed to do right but almost guaranteedly did wrong when not speficically told to do right). I even spent considerable time to work around that f** kit.

    Example: you use binary libraries that produce output via c stdout or stderr. Now get their output into a motif text widget. Nearly impossible.

    Another: have a standard C++ streams object for output to a text widget. Should be a a basic component - instead I had to write all stuff myself

    Another: you want to see state of some inner workings of your program. Standard programmer trick - just make it say something occasionally. Really Bad Idea with motif... it waits to display anything until you give some time in the main loop. I _hate_ this way the toolkit guys break traditional control flow of software. If I say "printf x" or "y >> cout" (printf and cout beeing properly widgetized) , I want to see it _now_. With motif I see it never.

    I could rant on and on. Maybe Motif is the best thing since the inventioin of sliced bread when you have one of these fabulous UI builders, but with just gcc, vi and the OReilly Books it borders on unusable. And it's object model is so alien to C++ that it seems nearly hostile.

  • I think I have written about 70k of that!

    Maybe what I dislike most about X, Motif and OpenGL is the visual sucks to see menus/popups/drag ops crashing apps. The "Green Book" molview program explains how to get past this issue.

    The gui builders are usually expensive and weak, or generate proprietary stubs, or use proprietary libs, locking you to the vendor. I still write a lot of Motif apps by hand. The runtime is nice and fast compared to alternatives like Tcl and Java.

    The Xbae matrix (from is one of the fastest matrix displays I've ever seen.

    Motif is really not that bad's all in the resources.

    If you want to talk about some ugliness, I still cringe at the naming conventions and typing in GTK. I know why they did it, but it still makes me cringe.

    Now that Motif is free, I can't see any reason to consider Qt with it's expensive least for closed source.

    Treatment, not tyranny. End the drug war and free our American POWs.
  • With approximately 700000 lines of Motif-based legacy GUI-code already written: no.

    Motif may suck, but so does everything else. The main benefit of Motif is stability and backwards compatibility, as well as feature completeness.

    Contrary to popular opinion, this is important even in new projects. A large project that takes, say 3 years to complete requires somewhat stable components during building. Who knows what changes will happen to GTK+ and Qt during those three years? At least with Motif I would have some confidence that the API's originally documented 3 years ago still work on the latest version. This matters if you are just trying to get some work done!

    Most development on Linux uses a different model. There are no customers. There are no in-house users that must be supported at all costs. There are no deadlines. If the software is buggy, it can be fixed later. Hacking value and aestethicks matters the most (as well as licensing debates), and actual functionality matters little, because if you want to do something useful, you use the command-line. Nobody cares about end-users. And those end-users that exists don't have a job to do either, so they complain about lack of themes instead of lack of functionality.

  • Wrong!

    He didn't miss it. If you checked the date of the article before complaining, maybe you would have understood that too.

  • Well, anything will be dead in the not so near future. Including Linux, Motif, X11, Qt, C++, Java, combustion engines, communism, USA, humanity, and so on. What is interesting is what will be dead in the near future.

    Motif has been used to create mission-critical applications in large corporations all over the world. Motif simply can't go away. There are way too much invested in Motif for it to go completely away even in the next 20 years.

    That doesn't mean that Motif will ever be exciting and new again. It will be like Fortran or Cobol, with old engineers cranking out code for old legacy systems. But thrust me: It won't go away soon.

  • The same arguments couln't be used. XView was never "the standard", and was never intended to be. XView was a poor-man's replacement for OpenLook. And OpenLook was already small compared to Motif. So XView never had the enormous amount of legacy code written by large corporations that Motif has, and could therefore go away silently.

    Personally I find this a bit sad, as I happened to like XView very much, and found the OpenLook look much nicer than Motif. It was also relatively sane to program. Well, well --- those times seem to be gone now.

  • I want what Mr. Fountain is smoking. Seriously, if he can't see that Motif development will be dead in the not so near future well then that is his problem. Also, I guess he thinks all the rumors that Sun and HP are moving towards gnome in order to phase out CDE are just rumors. Oh no wait they aren't rumors []
  • Motif is no more dead than Cobol, it would seem. The most we can expect is that eventually Motif will wind up being supported as a legacy system for quite a long time, but will wind up being deprecated for new toolkits (probably Gnome).

  • Are you thinking Motif or Athena? Motif's defaults are very simple, clean, and nicely shaded. Athena (Xaw) is the beast behind the really nasty X apps (xedit, xfig, other such old, horrid beasts). It looks nice to me and *very* similar to default GTK+.
  • I dunno, MotifZone looks alive and well:

    BTW, grab the latest version of OpenMotif (or order a CD).
  • Now, don't get me wrong, this Xt stuff sounds like a Good Thing(TM), it's just a shame he feels he has to talk it up at the expense of Qt/GTK. He makes a lot of good technical points, but wraps them up in a whole bundle of M$-style FUD. Anyone would think he was trying to sell you something. Oh, wait, he is...

    A few choice quotes...

    There are things Qt in particular does better than Motif: it is nicer to program with, for example. As a language, Motif does show its age. However, that doesn't make a hoot of difference when you have an end product to produce.

    When you have an end product to produce, it does make a hoot of difference. If a tool-kit is nicer to program with, you code faster and with fewer bugs.

    It does not matter how elegant a toolkit is in terms of programmer taste if at the end of the day the product derived from the toolkit is shorn of customizability, internationalization, attribute configuration, or a standardized way of working.

    Compare this to his later statement:

    Xt/Motif provides built-in standard methods for user customizability of components, which includes built-in internationalization capability. The internationalization issue may prove to be a key killing point for Qt/GTK+.

    So, does he think internationalisation is important or not?

    The commercial world writes product for customers and users; the Linux community writes software for programmers.

    Funny, when it comes to programming toolkits, I thought the programmer WAS the customer/user? I've yet to meet the CEO or end-user who gave a toss what toolkit I used, so long as it did what they wanted.

    The nature of the software being produced with Qt and GTK+ is yet more software for programmers. KDE, GNOME, and the like aren't about products and customers at all.

    OK, so all those desk-top apps I'm using are only for programmers? KDE and Gnome are about building a better environment for developers and users to work in. Now that these environments are maturing nicely, the products will come. It's the same factors that led to CDE and Motif being developed in the first place.

    Indeed, there is no commercial GUI builder for Qt or GTK+.

    Kylix anyone? And why does it need to be commercial, like that inherently makes it better?

    There are a number of private programs available, but as far as companies go, this is a no-no because it fails to guarantee any kind of continuance, stability, or development. Compare this with the Open Group's license for maintaining Motif, guaranteed by contract. Continued development is absolutely guaranteed. The same cannot be said about Qt or GTK+. The commercial infrastructure just isn't in place.

    Not sure what license they use, but it's commercial right? So if Open Group goes under, what's the use of a support contract? Continued developement is not guarenteed, unless they just invented some new economic model that means they can't fail. At least GPL means there's a whole community behind QT/GTK who can pick the baton up and run with it.

    Now, it is true that Motif has features that QT/GTK can't compete with. Yet. Motif's been around for how long now? 15/20 years? Give QT/GTK that long and they too will have all those features. But by then they too will have been superceded by the Next Big Thing, that's the nature of the industry.

  • Many of these were actually Purify brainfarts
    having something to do with the unusual mgmt
    of memory under the hood in Motif, IIRC.

  • by Courageous ( 228506 ) on Tuesday May 22, 2001 @05:38PM (#204455)

    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.

  • by srichman ( 231122 ) on Tuesday May 22, 2001 @05:10PM (#204456)
    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.
  • Fountain is probably right. I know from experience that the military, which requires mission critical applications, is still depending on Motif and even in some cases (yuck) OpenLook. There probably are some companies out there that are capable of looking ahead of the curve, but as far as being tried and true, Motif is the best route.

    of course, probably going to start a holy war with that statement

    "sex on tv is bad, you might fall off..."
  • Acctually gtk is covered by the LGPL. That means you can use it for closed source apps as long as you share changes to the library, and you dynamically link it.

    This is very important, because it's the entire basis for the gnome/kde flamewar.

  • So it's ugly. So what? Have you sat in front of Windows lately? It don't matter that it's not the prettiest packaging. What matters is that it works, and works well. It's functional.

    Functionality Rocks. Don't lose sight of that. If you want pretty, buy a Mac.

    (Shit. I'll get modded down for the Mac comment...)

  • The biggest single group of large scale developers with Motif is not the operating system vendors producing various workbench products, but very large commercial companies who make and distribute very large Motif applications in-house for their own purposes.
    Umm, can't anyone who is developing in-house applications use, say, gtk and achieve the same results without having the cost of Motif? The GPL only covers distribution, not use within an organization.
  • I'd rather not hear the word "rather" used, well, rather overzealously.
  • I work for one of those shops that has millions of lines of Motif code. That doesn't necessarily mean Motif is that great, just that if you lined up our years of Motif experience end-to-end, it would probably predate Noah and the biblical flood. It's hard to overcome that much momentum.
  • "No user design guides in linux" How about /k de/style/basics/index.html
    or /i ndex.html

    What those don't cover (or, at least, I didn't see it) is a basic guide to size/positioning - how far apart buttons should be, how high they should be, spacing between labels/checkboxes/radio boxes/tabs/etc, icon sizes, etc. Consistency in those little anal details actually makes a bit difference in giving an application a professional crispness.
    Convictions are more dangerous enemies of truth than lies.
  • I dunno... KDE widgets seems to be sufficiently different from traditional Motif widgets to warrant a new set of design guidelines. For example, KDE buttons are usually highlighted on the inside, Windows-style, instead of around the outside like Motif. Things like that make a significant difference in spacing.

    Given all the different themes that are available, design guidelines for for app spacing/sizing and theme design would probably be a good idea. Or maybe there's really just no way to make apps look professional with someone's Wooden-button Matrix-like Pamela Anderson theme...

    Convictions are more dangerous enemies of truth than lies.
  • Tk, unfortunatly, has a very limited set of widgets. They are good enough for probably 90% of the applications people write, but what are they going to do for the rest? In part, I think these limitations are a consequence of the fact that Tcl is a pretty limited language and isn't sufficient to extend Tk (MegaWidgets and [incr Tcl] were too little too late and still aren't even part of the default distribution).

    Having said that, I think Tcl/Tk is still proof of how powerful the combination of an interpreted language and a widget set can be. And the Tk binding to Tcl is a lot easier to use (in particular, for "non-specialists") than any of the Gtk+ or Qt bindings to Python or other languages.

    I think you are going to see a system like Tcl/Tk appear again, but based on a better language and with more of the widget code written in the scripting language.

  • For plain Tk, you have to write new widgets in C. I'd say, that's a little easier than for Motif, and a little harder than for Gtk+. It's significantly harder than for Qt. And it's a lot harder than writing new widgets for FLTK, wxWindows, or Swing. Another problem, though, was distribution. The Tcl/Tk team never seemed very eager to incorporate outside code, and a lot of widgets that got created languished for a few releases on some external web site and then eventually stopped being maintained. Finally, I think Tcl/Tk was ultimately limited by the large number of people who felt that Tk was contaminated by its close association with Tcl.

    I think Tcl/Tk could have been so much more than it is if it had had a somewhat less screwy scripting language and a more open development process. Even as it is, it's still very widely used and extremely portable: you can pretty much use it on any UNIX or Windows system.

  • by janpod66 ( 323734 ) on Tuesday May 22, 2001 @09:02PM (#204474)
    Fountain has some points. First, Motif uses X11 more efficiently than Gtk+ or Qt. I think much of the reputation X11 has among new programmers for inefficiency is because Gtk+, Qt, Mozilla, and other recent toolkits take such a brute force approach to using the X11 APIs. Gtk+ and Qt's redraw logic also don't work as well with the X11 protocol. Of course with 1GHz machines and 1Mbit Internet hookups, that matters less and less. Also, neither Gtk+ nor Qt have anything that is a nice and flexible as the toolkit intrinsics when it comes to GUI configuration, options, and GUI building.

    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.

  • by janpod66 ( 323734 ) on Wednesday May 23, 2001 @01:18AM (#204475)
    I know what you mean: the text components in Swing are complex. But what's the alternative? At least, with Swing you could get there without starting from scratch. And while we both may be cursing the complex and general APIs that do so much more than we want, and all the thinking we have to do to figure them out, it's still a lot better than starting from scratch.

    The text widgets in Tcl/Tk, Gtk+, wxWindows, and Win32 are easier to use, but I think they are too limited to implement a full HTML editor (or do a lot of the other oddball things I have managed to do with Swing). OTOH, if you start with the Mozilla editor or Frontpage as a component, someone has already done all the hard work, but you probably can't customize them in the way you want without hacking their sources, and in the end, they will probably still retain functionality that's inappropriate and confusing to users (not to mention their size and potential licensing problems).

    I found what helps a lot with complex APIs like Swing's text widget is to get a "cookbook" type manual. That way, I can get whole code snippets and assemble them into what I want.

"We don't care. We don't have to. We're the Phone Company."