Death of CDE & Motif?

I just found this feature on ZDNet which talks about what will happen with CDE and MOTIF. The author wonders whether they will be replaced by QT or GTK. What do you think? Will corporates switch to QT or GTK? (Both libraries got support for almost all platforms which Motif has). What do you think QT & GTK are missing to be a true replacement for Motif?

Comments

CDE and Motif died in 1998

[crow]

CDE and Motif were developed by The Open Group. While TOG still sells them, they ceased all development back in the summer of 1998, at the same time they shut down X development and pretty much everything else other than licensing and branding.

Disclaimer: I am a former employee of The Open Group. I worked at the Research Institute in Cambridge, Massachusetts, which is now a much smaller operation in Woburn where the few engineers who didn't quit still work.

Nooooooooo way

[Gokmop]

Not for a long time anyway.

As fast as the tech market moves, I think one thing that linux has shown me, (through the long series of such-and-such company adopting linux, and so on) is that companies are sure good at dragging ass when they want to.

And they've got a lot of motivation to. Proclaiming the end of CDE and Motif and so on is not something that Triteal wants to hear.

One of the things that I've noticed about linux and GNU software seemingly "pushing things out of the way" is that generally, it happens in a spot where a company isn't *too* afraid of giving ground.

HP/UX, Solaris, and all those other UNIXen are still extremely entrenched in corporations. Just because linux does exist in companies, and just because people do use it, doesn't mean that people can go around proclaiminig "ding dong the witch is dead" spouting out that such and such extremely popular software package for UNIX is on the way out because of some free software replacement. Even for packages that are non-free, it takes a long time to get mindshare and get people using the software, and it can take just as long to get them out of it. That QT and GTK+ are making inroads is interesting, but that's quite different from seriously threatening the EXISTANCE of an alternative.

Also, linux is moving into some of the spots where otherwise solaris or HP/UX might be used. But do HP and Sun *really* care if they don't sell copies of Solaris and HP/UX? Sure, that's revenue that they're losing but at the same time, they make their money selling HARDWARE not software. So it's really not that much of a tragedy if some of their software gets pushed a bit to the side.

But with CDE, you're going up against pure software companies that have all of their revenue to lose if they let themselves be pushed to the side, and because of that, I'm betting that they'll "fight harder"

I'm skeptical...

yes probably.. well maybe

[josepha48]

Netscape already uses gtk as its framework, plus some homegrown stuff too. KDE and Gnome neither use Motif. Because of the license of Motif vs gtk / qt I think we will see less and less companies use Motif. It also depends on weather they are going to write open source software or some proprietary stuff and if they want to use C or C++ as there is a difference. There is also the option of gtk-- for C++ as wrapper functions on gtk. It will also depend on weather they can find Motif programmers vs QT / gtk programmers.

Chances are that if they are wring for UNIX it will also depend on which UNIX they write for. Solaris still uses Motif / CDE.

Something to notice is that companies that write for Linux are going with gtk or qt and/or something that they have inhouse. Just look at Corel.... only time will really tell ....

send flames > /dev/null

One thing that Motif was getting right...

[ptomblin]

Last time I used Motif (about 2 years ago, on Irix) was that it had a working and fairly powerful drag and drop. Granted, they changed the API right in the middle of things, which sucked, but I could (and did) write an application where any user could drag "film rolls" (an object in our system) onto the desktop, and then drag them from the desktop into other programs that knew something about "film rolls" and that program could process the film roll. Programs that didn't know anything about film roll object just got the file name where the film roll was stored, but applications that knew about film rolls got all sorts of other characteristics of the film roll in the drop message without opening the file.

I haven't figured out how to do similar dragging and dropping on the desktop or between applications with KDE or Gnome. I'm pretty sure it's there, but it doesn't seem as integrated as it did on Irix.

Oh please Oh please Oh please

[Tim Behrendsen]

As someone who developed a major hospital information system using Motif/Xt, I hope that piece of garbage goes to the fiery depths of hell it deserves.

But let me not pull punches, and tell you what I really think. The problem isn't really with Motif, it's with Xt, which is a slow, buggy, slow, hard to understand, slow, inflexible, slow piece of poop. I am totally convinced that it's Xt that has held back applications from being ported to Unix. I think Motif wanted to be a better package, but it was held back by having to work within the straight-jacket of Xt.

On the other hand, X11 (the low-level protocol) is actually pretty good. If we could get some decent font handling, it could be very good. The only problem with X11 is that you really have to understand how it works in order to be efficient over the network connection, but on balance, it's a very well-designed protocol.

One last dig at Xt: DIE DIE DIE

--

Lacking features in GTK

[ABadDog]

There are a few features missing in GTK which I find really annoying, being used to X applications which actually use the X Resource Mechanism.

1) GTK apps don't parse Xt command line arguments. so you can't do something like "gtkapp -geometry +400+20", or even worse, you can't do "gtkapp -display remotehost". How annoying!

2) GTK doesn't support the editres protocol for querying and customizing widgets.

3) GTK doesn't accept X resources from .Xdefaults like any X application should. Try setting a default geometry from .Xdefaults.


GTK suffers a bit from not-invented-here syndrome, and ignores existing standards like .Xdefaults and the X resources mechanism. I thought we liked standards around here? Yes, I know it's somehow possible through GTK's own customization files to accomplish these tasks, but why not use the existing standard mechanisms to accomplish the same task?


Finally, what's the status of i18n for GTK? Does it exist?

Jon Christopher
LessTif Releasemeister

Motif?

[ajs]

Some people have pointed out that Gtk+'s table handling is a tad shy of Motif's, but that's about it. If you compare CDE+Motif to GNOME+Gtk+, you get:

• GNOME has a component object model
  
• GNOME has an anti-aliased canvas which can handle rotation and scaling
  
• GNOME handles unified printing very nicely.
  
• Gtk+ has a much more covinient event model which can incorporate arbitrary I/O and event loops.
  
• Gtk+ has a fundamentally saner object model which actually works well in C and C++.
  
• glib (the non-graphics portability layer that's part of the Gtk+ distribution) reduces the number of pointer-related bugs in your code by providing higher level abstractions of many simple data types (from strings to hashes), includes portable threading and has many ease-of-debugging features.
  

These are just some examples, and only for Gtk+/GNOME. Qt/KDE has it's own set of features, and obsoletes Motif in several unique ways.

What I'd really like to see is a GNOME/KDE abstraction library that makes it easy for apps like Word Perfect or EMACS to be re-written to use either at compile-time.

LessTif status report

[ABadDog]

For those who don't know, LessTif is a LGPL'd replacement for Motif. It provides a nearly complete clean-room reimplementation of the Motif 1.2 API, and is source code-compatible with it. Most apps written for Motif run out-of-the box on when compiled with LessTif, and we want to know about those which don't.

Also, even though binary compatibility isn't a main goal of the LessTif project, some apps (including Netscape 4.5+) which are dynamically linked with OSF/Motif will also run when linked against LessTif. Getting this far is a tremendous accomplishment of the LessTif programming team (I'm on the core team, but I don't do much of the programming, as I mostly coordinate the releases.)

Jon Christopher
LessTif Releasemeister

In our case, yes.

[FreeUser]

We are writing our in-house (read: proprietary) software using Open Source libraries and NOT Motif. This was not true four years ago.

Our reasons for switching away from Motif and other closed-source, proprietary libraries and development tools include:

• Being burned in the past with orphaned products (OI, anyone?)
  
• Outrageously expensive development licenses (offending products shall remain anonymous to protect the guilty)
  
• Even more outrageously priced source licenses
  
• License Management headaches and associated downtimes (Sun C++ is one example - by no means unique - in that it is completely useless if flexlm hiccups or goes down, costing the company lots of money in idle developers until it can be brought back on-line)
  
• Slow development cycle
  
• Lack of support on desired platform (e.g. Linux)
  
• Synchronization of upgrades (or rather, the severe lack thereof). I.e. Being forced by one product to upgrade (e.g. to Solaris 2.x) while forced by another, equally critical product, to wait until they finish their port to the same platform, perhaps months or even a year later.
  
• The Open Source alternatives are, almost without exception, superior in quality, performance, and ease of use than their commercial counterparts. This is not universally true, but has been the case more often than not, and was most certainly true with respect to Motif vs. what we chose to replace it with. In the few cases this hasn't been true, the savings in other areas (such as those noted above) was more than sufficient to make up for any additional headaches (and they have been remarkably few).
  

The list goes on and on, but you get the idea.

Motif "ugly" while GTK "beautiful"??

[Jamie Zawinski]

What do you think that QT & GTK are missing to be a true replacement of Motif?

Well, for one, both QT and GTK lack the butt-ugliness of Motif. Secondly, they lack the quality that they're not as akin to bashing your head against the wall when programming with them. Thirdly, they're not archaic. That's about all I can think of.. :^)

There are many fair criticisms that can be made of Motif (and I've made all of them,) I programmed Motif for years, and I've got more reason to hate it than most people.

But I've never, ever understood the ``Motif is ugly and GTK is beautiful'' argument, because they look the same to me. Seriously! Can someone explain to me why one of these is ugly and the other is beautiful:

• Exhibit A
  Exhibit B

Because I just don't see it. Except for the default font sizes, those look damned near identical to me.

I'd also be interested to hear in what way Motif is ``archaic'' while GTK is not.

And thirdly, I've found writing in GTK to be almost as much as a head-bashing experience as programming in Motif. The APIs are just as crazy, they're just different. One thing that GTK has going for it is that it's slightly less buggy. But it's also a hell of a lot slower.

Xt is not the problem

[Jamie Zawinski]

The problem is really with Xt, which is the low-level "Widget" interface to X11. It is a slow, buggy, complete pile of garbage. I honestly feel sorry for the Motif guys, because they really wanted to use the "standard" Xt interface. As it stands, they had to write a lot of Xt-incompatible stuff for Motif to work right (keyboard shortcuts come to mind), but there's just no getting around the fact that Xt sucks huge.

This is completely wrong! I'm sorry, but you don't know what you're talking about.

Xt is rock solid, and highly consistent internally. Xt is basically just an object system and an event loop, all the policy and mechanism (implementation of dialogs and menubars, etc) is in the libraries built on Xt (Motif and Athena.)

Motif is bug-ridden, poorly architected, and breaks the object abstraction model left and right.

Athena is consistent and doesn't break the object model, but it also doesn't do much, and looks terrible (Athena doesn't even have proper menubars.)

The biggest mistake GTK made was not using Xt. Xt is just fine, and if they had built on Xt, then it would be possible to mix-and-match GTK, Athena, and Motif widgets in the same program, instead of having to rewrite the whole world.

Also Xrm (the X Resource Manager) would have worked.

The GTK folks were crazy to not build on Xt.

Re:Xt is not the problem

[Tim Behrendsen]

Some of the things that are broken under Xt:

• Writing widgets is insanely overcomplicated, and the execution is slow.
• Resource files were buggy and inconsistent
• Motif broke the object model because it had to break it in order get things to work (otherwise why would they bother to break it?)
• Keyboard shortcut processing was broken (which was why Motif had to do its own thing)
• Focus handling was unreliable and broken (Quick... how do I set the focus to a particular Window? How do I raise a Window? Sorry -- XtSetKeyboardFocus doesn't work!)

That's all I can remember right now; it's been a few years. I lived with Xt/Motif for about 7 years in developing a major hospital application (A Labor and Delivery monitoring and information system called WatchChild). I don't have an exact count of how many bugs and limitations I've coded around in Xt, but it's a lot.

I'll accept that you truthfully didn't have a problem with it with your particular apps. And I should say that it's not all bad; it does have some good concepts and a lot of the design is correct. The problem is that they either a) didn't go far enough to make a feature useful, or b) screwed up the implementation of the feature.

But all I can tell you is that in my experience, it is just a bad piece of software than needs to be replaced by cleaner APIs.

--