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."
Re:Taking lessons from Microsoft (Score:1)
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.
Dev experience (Score:4)
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.]
DanBuggy user interface, (Score:5)
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.
Re:Buggy user interface, (Score:1)
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.
Re:Dev experience (Score:2)
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).
Re:Motif wouldn't survive without FUD (Score:2)
Go talk to the guys at lesstif.org 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!
If Motif is so great... (Score:1)
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?
"Key killing point" (Score:2)
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...
Re:why do you even need X any more let alone motif (Score:2)
What about Tcl/Tk? (Score:2)
Re:What about Tcl/Tk? (Score:2)
I mean, at some point GTK had less widgets than Tk did. So there must be some reason GTK got ahead.
1000000 lines of motif ? (Score:2)
Sun and GNOME (was Re: Motif *is* dead.) (Score:1)
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.
Much of this is lame FUD (Score:2)
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.
--
repeat (Score:4)
Re:Motif wouldn't survive without FUD (Score:2)
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.
Re:Save some cash... (Score:2)
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.
Re:Save some cash... (Score:2)
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. [gnu.org] And here is a pertintent quote (emphasis added).
Re:Save some cash... (Score:3)
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.
Waste? Not really. (Score:1)
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.
Re:Motif wouldn't survive without FUD (Score:2)
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.
API's aren't all good... (Score:3)
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.
Re:Buggy user interface, (Score:2)
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.
Re: X resources (Score:2)
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.
Re:Qt/GTK looks like Windows (Score:2)
It is possible to be crappier than Windows. "different" and "better" are not synonyms. Analog computers are different too, maybe you should use them.
Re:One important thing ... (Score:3)
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.
Re:Article is OLD, Focus on eliminating the fork! (Score:3)
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).
Re:Is Motif Dead? No but it is gasping for air (Score:2)
Re:Is Motif Dead? No but it is gasping for air (Score:2)
Re:I like Motif better (Score:1)
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.
--
Re:Mature like my grandma (Score:1)
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...)
Re:Motif Power Tools (Score:2)
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.
Re:Motif wouldn't survive without FUD (Score:1)
Motif wouldn't survive without FUD (Score:5)
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.
Re:Save some cash... (Score:1)
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.
Re:CDE (Score:1)
domc
Not that I like CDE though.
Re:Much of this is lame FUD (Score:1)
Re:Much of this is lame FUD (Score:2)
if.. then .. (Score:2)
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!
trolling through the forest all day long... (Score:3)
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.
Problem with Motif (Score:2)
--
Re:I like Motif better (Score:1)
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.
Re:If Motif is so great... (Score:1)
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.
Re:Motif's advantage... (Score:1)
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.
I like Motif better (Score:2)
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?
Try actually using Motif and Qt... (Score:4)
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.
Re:If Motif is so great... (Score:2)
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Re:why do you even need X any more let alone motif (Score:1)
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.
Fountain is spraying FUD about GTK / QT i18n (Score:3)
motif was too little quality ..too late (Score:1)
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
Various toolkits (Score:1)
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. [fltk.org]
Re:I like Motif better (Score:1)
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.
Re:Mr. Fountain is ignorant of the facts. (Score:1)
Mr. Fountain is ignorant of the facts. (Score:3)
Indeed, there is no commercial GUI builder for Qt or GTK+.
WRONG!
How did Mr. Fountain miss the press release announcing Kylix [borland.com] from Borland [borland.com]? This is a commercial GUI builder and RAD development environment which relies on Qt.
Re:I like Motif better (Score:2)
Now, explain to me how you would go about building a cross-platform toolkit "on top of X".
Re:repeat (Score:3)
You can read two pages [oreilly.com] of responses [oreilly.com] to the interview, too!
bunch of pussies (Score:1)
Re:my experience (Score:1)
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
my experience (Score:4)
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.
Re:Qt is much better (Score:1)
So, um, I take it Qt core dumps a lot, then, but it sort of feels good when it happens?
Are you serious: no resource editing for GTK or Qt (Score:3)
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.
why do you even need X any more let alone motiff! (Score:4)
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 [agendacomputing.com] 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.
apparently... (Score:2)
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?
Out of touch (Score:2)
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.
Having Done Both... (Score:3)
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.
should this happen more often? (Score:1)
doesn't everyone know products that they wish word never got out about?
Re:Qt/GTK looks like Windows - none more Unix (Score:1)
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.
Re:I like Motif better (Score:1)
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?
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?
Re:I like Motif better (Score:1)
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
How did you find out about it then? Or do you live in Texas?
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.
HAND
Re:I like Motif better (Score:1)
HAND
Re:I like Motif better (Score:1)
And the clencher:
Open your ears, the irony might be clogging them when you speak.
What a dumb memory debugger! (Score:1)
What use is the debugger if it does not detect memory leaks!?
Re:Buggy user interface, (Score:1)
At the end I solved using textfields, with resources set si that they looked almost like labels.
Re:Buggy user interface, (Score:2)
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.
Re:Article is OLD, Focus on eliminating the fork! (Score:1)
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.
f.
millions of lines of code. (Score:2)
Maybe what I dislike most about X, Motif and OpenGL is the visual inheritance...it 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 lesstif.org) is one of the fastest matrix displays I've ever seen.
Motif is really not that bad looking...it'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 licensing...at least for closed source.
Treatment, not tyranny. End the drug war and free our American POWs.
Re:Save some cash... (Score:2)
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.
Re:Mr. Fountain is ignorant of the facts. (Score:2)
He didn't miss it. If you checked the date of the article before complaining, maybe you would have understood that too.
Re:Is Motif Dead? No but it is gasping for air (Score:2)
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.
Re:Is Motif Dead? No but it is gasping for air (Score:2)
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.
Is Motif Dead? No but it is gasping for air (Score:2)
Re:Dev experience (Score:2)
/Brian
Re:Problem with Motif (Score:2)
MotifZone (Score:2)
http://www.motifzone.net/
BTW, grab the latest version of OpenMotif (or order a CD).
Taking lessons from Microsoft (Score:2)
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.
Re:Buggy user interface, (Score:2)
Many of these were actually Purify brainfarts
having something to do with the unusual mgmt
of memory under the hood in Motif, IIRC.
C//
Motif Power Tools (Score:3)
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//
Mature like my grandma (Score:4)
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.
it's all a matter of perception... (Score:2)
of course, probably going to start a holy war with that statement
"sex on tv is bad, you might fall off..."
Re:Save some cash... (Score:2)
This is very important, because it's the entire basis for the gnome/kde flamewar.
Ugly? So what? (Score:2)
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...)
Save some cash... (Score:2)
Where's the Grammar Nazi? (Score:2)
MegaLOCS of Motif (Score:2)
Re:trolling through the forest all day long... (Score:2)
http://developer.kde.org/documentation/standard
or
http://developer.kde.org/documentation/design/u
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.
Re:trolling through the forest all day long... (Score:2)
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.
Re:What about Tcl/Tk? (Score:2)
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.
Re:What about Tcl/Tk? (Score:2)
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.
he has some points... (Score:3)
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.
Re:he has some points... (Score:3)
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.