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

Applix 5.0 uses GTK

[szo]

You can download the beta from http://www.SmartBeak.com/M1

! Szo

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.

Please God

[FascDot Killed My Pr]

Speaking as someone who is porting a Motif on Tru64/AIX app over to LessTif on Linux, I say: "I dearly hope so".
--
Java banners:
Bad for users because Java kills Netscape

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

Lacking "features"

[Jon Abbott]

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

-- Does Rain Man use the Autistic License for his software?

I've programmed in Motif and CDE...

[Anonymous Coward]

It's ghastly. CDE is the worst GUI I've used in my entire life, aside from the early versions of Winblows (2 and 3.1). It's inconsistent, unhelpful and difficult to configure.

Motif fares a little bit better, but heaven help you if an existing widget can't be goaded into doing what you want.

For example, there still isn't a way of easily doing something like a password text field in Motif. The sanctioned ways involve pathetic kludges. Still.

It's slow. Its layout engine is admittedly a really nifty idea, but make a complex form full of widgets and sit back in amazement as your sparcstation sits and meditates for five seconds before the stupid window comes up.

And it hasn't improved the slightest in the past five years. It's stagnant dead crap. You couldn't pay me (anymore) to develop for it. It's history.

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

Compatibility tool?

[ABadDog]

"LessTif is considered a compatibility tool..."

Several points to this:

1) Considered by whom? Certainly not the LessTif core team and users. I write code to Motif/LessTif all the time.

2) And what's so bad about compatibility anyway? Heaven forbid!

LessTif is alive and well. Many of the "hundreds of applications" available for GTK, are new reinvent-the-wheel applications for which Motif/LessTif applications have been available for years. GTK/KDE are considered sexy because they're new, so existing applications are ported to the new toolkits for very little gain. But hey, hackers have the right to code whatever they like, even if it seems like a foolish effort to the rest of us.

Jon Christopher
LessTif Releasemeister

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.

Re:One thing that Motif was getting right...

[Guy Harris]

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,

GTK+ 1.2[.x] (the toolkit for Gnome - as well as for many non-GNOME applications) has support for drag-and-drop, using both the Xdnd protocol and the Motif DnD protocol. Qt 2.0 (the toolkit for the under-development KDE 2.0) also supports drag-and-drop using Xdnd (but not, as far as I know, the Motif DnD protocol); I think Qt 1.x supported DnD on UNIX/X11, but not using Xdnd (unless one of the later 1.x's added support for it, which it might have).

Here's Troll Tech's documentation on DnD with Qt (probably for 2.0). There may be additional KDE APIs atop that; try plowing through the KDE developer's site.

Here's the GTK+ reference documentation section on DnD APIs; again, there may be additional GNOME APIs atop it - if you plow through the GNOME developer's site, you may find something.

I'm pretty sure it's there, but it doesn't seem as integrated as it did on Irix.

"Doesn't seem as integrated" in what sense? Presumably not in the API sense, as you haven't yet looked at the API; maybe fewer KDE and/or GNOME applications support DnD, but I'm not going to assume that's the case.

Sadly, your wrong

[grrussel]

GTK is more Open Source? Both are certified as Open Source, both are DFSG compliant. You may call GTK more free, but thats because RMS wants you to call Open Source Free Software and GTK uses the GNU Library GPL.

Both Qt and GTK have bindings - Qt is C++, C (if anyone cares - noone used it with C), Python, Perl, and Qt based apps can be scripted from any DCOP supporting language, even I hear, bash.

Qt Free Edition is X11 only - simply since no one has ported it. It is allowed.

Apps using Qt need not use Qt - GPL is fine, as is BSD, Artistic, MIT, etc - any Open Source license. Shareware / Proprietary is possible by purchasing Qt. If any one bothers about GPL + Qt, just ask about all the Motif based GPL applications, and then call them hypocrites when they defend them.

To get Windows portable software, pay or port, unlike GTK where you can only port it.

I think that covers the major errors.

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

Re:Lacking features in GTK

[Chalst]

Does it do any *good* to specify things in Xresources for standard X
applications? You finally find a font that you can tolerate --not
actually like, but just about livable with unlike the fonts that X
tries to pawn off on you-- then you export your X setup to a different
environment and you can't find anything remotely resembling the font
you had before. I cannot make head nor tail of the X font naming
scheme, it's just insane.

The chapter in the Unix Haters Handbook on X was just too close to
the bone for me to find funny. X as a user interface is foul, and the
more abstraction layers there are between me and it the better IMO.
Not recognising Xresources is a plus for Gtk in my book.

Re:Lacking features in GTK

[ajs]

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!

The Gtk+ libraries obey the POSIX command-line specification. Namely, they do not use multi-character arguments following a single dash. X was the longest holdout against POSIX compliance in this respect. As an alternative, Gtk+ uses the GNU coding conventions, which allow for a "--" to precede multi-character arguments. Thus you wanted "--display", which works just fine in all Gtk+ apps (that's built into the libraries just like it is with Xt). "--help" is also supported if you can't remember the dozen or so standard Gtk+ flags.

What's more, GNOME provides additional standard command-line parameters for things like session management.

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

Thank all the little gods! What a terrible way to do it. On the other hand, it does support dynamic theming and run-time loadable UIs. This gives you all of the advantages of editres and a whole lot more.

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

This was a hard decision, as I understand it (I wasn't involved at that time). The basic problem was that X provided a very restrictive way of communitcating such defaults. Gtk+ and GNOME instead provide a much more sophisticated mechanism which allows for dynamic information (e.g. application preferences); global and semi-global values in a well-defined namespace and a number of other useful features. It's also a lot more flexible in terms of replacing the underlying mechanism with more complex systems. As I understand it, there is work to replace the text-only database now used with something that can handle arbitrary binary data.

Yes the loss of X resources (of which .Xdefaults was just an instance) was a loss. No arguing that point, but what was gained was worth it, IMHO.

GTK suffers a bit from not-invented-here syndrome, and ignores existing standards

I disagree. The descisions were all either to stay with and/or extend existing standards (e.g. the X session management protocol) or to ignore them because they were fundamentally crippling or themselves non-standards compliant (e.g. Xt argument parsing).

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

Oh BOY. Yes, I guess is the best answer.

Your application is not GNOME compliant unless it allows for internationalization (see the GNOME coding standard for more info). There are currently something like 9 dedicated language teams for GNOME. That means there are 9 projects that do nothing but translate GNOME into their own languages. There are a lot more volunteer translations for individual applications and libraries (I think the gnome-core package ships in 26 languages), but you can basically count on those 9 being under constant development across the GNOME and Gtk+ code base.

Gtk+ and glib support the i18n features (of which I know little enough to be dangerous). There is also an effort for the next generation of Gtk+ and GNOME to start supporting fonts and character sets that require right-to-left rendering (I think that the only thing left there is some of the data-entry handling, but I don't know for sure) and cases where certain 3-character combinations are represented with a single glyph. There's acutally a lot that i18n does not cover, but GNOME is working on filling the gaps.



Basically, all of your points are good ideas for things to look out for in developing an X-based toolkit and desktop, but these are already things that the Gtk+ and GNOME folks have thought of.

Missed the point

[Xamot]

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.

The article doesn't say it is replacing exisiting Motif applications at the moment, but that there is no NEW applications being written. This isn't to say if a company is already entrenched in Motif or CDE they won't add another program that fits into their world. But probably that program either isn't a commercial product or is only a piece of a larger system that already exists.

Just like FORTRAN programs and mainframes still exist so will Motif and CDE for quite some time. But are any new commercial products being developed using FORTRAN or on a mainframe? I can't think of any. C and workstations have replaced them respectively.

--

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.

Re:Motif?

[Jamie Zawinski]

• Gtk+ has a much more covinient event model which can incorporate arbitrary I/O and event loops.

Please explain what the GTK event model can do that the Xt event model cannot. I think they are the same.

• Gtk+ has a fundamentally saner object model which actually works well in C and C++.

I do not believe that GTK's object model is fundamentally saner than Xt's.

GTK's objects are fundamentally saner than Motif's objects, but that's the implementation of the widgets, not the object model itself.

I can't comment on what it's like using Xt from C++, because C++ is an abomination that I would never use. But Xt makes it pretty straightforward to code C in an object-oriented style.

O'Reilly books

[coyote-san]

Motif may be a pain to work with, but it has one outstanding quality which Qt and GTK both lack: exhaustive O'Reilly references. Give me something comparable to volumes 6A and 6B, and libraries that don't have major changes every time I upgrade my system, and I'll consider switching.

But in the meanwhile I'll stay with Motif. It has a steep learning curve, and it forces me to do a lot of stuff myself (or use third-party widgets), but at least I have good documentation targeted at me as a developer. I also have the QT book, but it's probably less than 1/4 the material of the Motif books - *and* it wastes a lot of time telling me why I want a widget, not how to use it.

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.

Sund. Explns.

[Greyfox]

There's been talk about actually open sourcing Motif. I'd be just as happy to see it die a much deserved death as a 1980's relic much on the same level as Windows 3.1 (Which, like the walking dead, STILL refuses to go quietly into the night.)

I've specified that GTK be used in my department for UNIX GUI work since it's completely open (No nasty QPL's to worry about) and I like several of its design points. We are trying to avoid gnome dependencies (I don't really want to lock my users into a single desktop environment) despite the fact that I think it'd be fun to toss CORBA objects out there for the stuff we're doing.

Re:Sund. Explns.

[[Xorian]]

There's been talk about actually open sourcing Motif. I'd be just as happy to see it die a much deserved death as a 1980's relic

As much as I agree with you that Motif's death is overdue, X itself is just as much a "1980's relic", if not more so. Why people revile one and not the other, I don't understand. Just a few of the major things that bug me on a daily basis:

• Totally braindead multi-monitor support. Go ahead, yell "Xinerama!" so I can tell you that it's a pathetic band-aid. The Mac has had a sensible system that actually works (even with monitors with different sizes and bit depths) for more than a decade.
• The division of work between the client and server is totally wrong. Come on, a network packet for every key press and mouse move? Talk about your overly chatty protocols. The bulk of the interface code should execute on the machine that the keyboard, mouse, and monitor are attached to. Anybody remember NeWS?
• A configuration system that's nearly impossible to use. The X resource system, while powerful, makes about as much sense as the Windows registry. Figuring out what resource to set ranges from difficult to impossible. The management of resource settings ("throw 'em all in .Xdefaults") makes keeping track of them require way too much effort.

X resources (just ranting against GTK)

[David A. Madore]

I have no sympathy for Motif, but I do like the X Toolkit Intrinsics very much. The Xt Intrinsics are, IMHO, a very elegant, flexible and extensible meta-widget system. Unfortunately, apart from the (small is beautiful) Athena Widget set, the Xt Intrinsics have no satisfactory widget set. Already Motif does not follow many Xt conventions.

Now why did GTK have to go around and reinvent the wheel? Couldn't they have used Xt? All right, Xt doesn't exist for Windows, but wouldn't it have been possible to use it when it does, or implement some kind of Xt replacement for Windows, or some such thing? All right, maybe they had their reasons, but is there some end to this idea that the wheel must be reinvented every damn time you want to build a cart?

The practical consequence of GTK not using Xt is that you can't configure your GTK apps with X resources. What the fsck? X resources are a nice, standard, elegant and pleasant way of configuring programs that use the X Window System. Is there any valid reason why GTK should choose to break this? Why is it that adding gimp*font: fixed to my X resource database doens't work as I expect it? Oh yeah, there's supposed to be a .gtkrc file or some such thing. Where's the doc for this thing, again? Uh...

All right, I don't know very much about the configurability of this GTK thingy (partly because I couldn't find the doc for it). Maybe it has the same nice features and the same power as X resources. And probably I'm bitter because I spent so long learning about the difference between XTerm.VT100.translations and xterm.?*Translations, or that sort of hair-splitting. And because I paid a fortune for those now worthless ``Definititive Guides to the X Window System'' by O'Reilly. So, maybe I am bitter. But breaking everything and making me relearn what I had thought learned for good, is unfair too.

Naturally, in an Ideal World, a given program would not depend on a particular toolkit. Rather, it would simply provide a set of first-class methods that you would attach to whatever you wanted. But then, in an Ideal World, there would be no difference between a ``program'' and a ``function'', either... Oh, never mind, I'm just ranting.

Last time I tried GTK (that was, admittedly, quite some time ago), it wasn't fully thread-safe, so I dropped it (Xt and Athena Widgets, at the time, were completely reentrant). Has this changed since?

Re:X resources (just ranting against GTK)

[ajs]

As I've pointed out elsewhere, Gtk+/GNOME had to dump X resources because they simply could not do what what needed. For one there's no reasonable way to shoe-horn in a WRITABLE X resource mechanism. For another, the heirechical nature of Gtk+/GNOME's resources are just a little bit more flexible than anything that X resources can muster.

This all, not to mention the ability to replace the plain-text nature of the Gtk+ configuration file mechansim and replace it with a real, binary-capable database without a change to the API.

As an example, here's a piece of code that stores a user preference to a resource file for later use:

gnome_config_set_string("features","lots");

There's a line to open the config database / associate the program with a root path, and there's one to close it, and that's it.

Re:X resources (just ranting against GTK)

[Jamie Zawinski]

As I've pointed out elsewhere, Gtk+/GNOME had to dump X resources because they simply could not do what what needed.

Nonsense.

For one there's no reasonable way to shoe-horn in a WRITABLE X resource mechanism.

GNOME could have dictated, as a matter of policy:

• System-wide Gnome resources shall live in /usr/lib/X11/app-defaults/app-name;
• User-specific Gnome resources shall live in $HOME/.gnome/resources/app-name.

Blammo, now you know where the file is, and now you can write a preferences editor that can overwrite that file. But you're still using the traditional programatic API for applications to consult their resources; and you've still left open the option for sophisticated users to use the more advanced features of the resource database, like using wildcards or screen- or display-specific settings.

Don't believe it can work? Well I've got something better than words, I've got working code that does exactly this. Download xscreensaver and run xscreensaver-demo. Note that you can edit all the parameters of the application. Note that it saves them to disk, specifically to a file called $HOME/.xscreensaver. This file contains resources! The xscreensaver daemon examines its resources with XrmGetResource() just like X programs have always done.

Using the X resource manager does not preclude having sophisticated, user-friendly customization UIs. And doing so leaves many options open for more sophisticated users.

For another, the heirechical nature of Gtk+/GNOME's resources are just a little bit more flexible than anything that X resources can muster.

I don't believe this. Please give an example. I especially don't believe this since using the X resource manager doesn't even mean that you have to use Xrm's file format. (I'll bet Gtk could just use that file format, but that's not a requirement.) I don't use Xrm's format in the .xscreensaver file, but I still merge it in to the in-memory resource database in the proper way anyhow.

This all, not to mention the ability to replace the plain-text nature of the Gtk+ configuration file mechansim and replace it with a real, binary-capable database without a change to the API.

Last time I looked, Gnome used the DOS/Windows INI-file format, but split into one file per app. That doesn't look particularly binary-capable to me. But anyway, what large binary data do you expect to store in these resource files by value rather than reference? (I.e., you want to store pathnames, not bitmaps.) For small binary data, just base64 it or something, like you'd have to do today anyway.

As an example, here's a piece of code that stores a user preference to a resource file for later use:

• gnome_config_set_string("features","lots");

There's a line to open the config database / associate the program with a root path, and there's one to close it, and that's it.

That very API could be easily implemented on top of the traditional X resource manager.

Re:X resources (just ranting against GTK)

[ajs]

Jamie, look. Clearly you and I disagree fundamentally on how flexible and dynamic the Xt libraries can be. Fine. Bottom line is that the current contenders for X GUI toolkit are Gtk and Qt. Motif is an unsupported (as in development stopped two years ago) product of a company that's slowly drifting down the tubes.

I just don't see how one can continue to live in the past on this point. Gtk+ might have made some descisions that you don't like, but overall, these descisions have been accepted by enough programmers that these toolkits are taking over the development space that Motif used to occupy.

As for your points:

1. X resources make it very hard to store information reasonably when one application class needs to remember the same state for several different instances at the same time. You can naming-convention your way around this, but it gets very hairy.
   
2. The binary data that you might want to store accross invocations could include encrypted passwords; complex data strcutures or even small images (you say you'd want to store these by reference, but what if they're downloaded? Why have each application creating it's own directories for downloaded image files?)
   

One point that I did not bring up earlier was that the emphasis in X resources is in configuring widgets. In Gtk+ and GNOME it's on configuring user interfaces and applications. As an example, look at theming. You can use theming to change the foreground color of buttons, but that's not what it's all about. It's about changing the look of ui elements for all of your applications at once.

Commercial Engineering Apps

[cradle]

Motif isn't as dead as the article would have you believe.

Motif is still the standard for commerical desktop Unix apps.

I can hear the response: "But all the commercial desktop apps that people actually use run on Windows." When it comes to Office Productivity apps, that's more or less true.

But when you're talking about commerical engineering apps, things like EDA and FEA, Unix workstations are still a pretty popular platform. Most of those apps use Motif.

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.

--

Re:Xt is not the problem

[Tet]

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

Perhaps so, but by far the biggest problem with Motif is that it's not abstracted enough. It's not possible to write a pure Motif program -- you need to resort to using Xt and Xlib as well. A quick check of my O'Reilly X11 books reveals that's over 2500 pages of documentation to get through.

Both Gtk+ and Qt are suitably abstracted, and you don't need to learn anything else in order to use them. That's why they're going to take over from Motif. Even if neither is yet as complete as Motif, both provide the functionality needed by 99.9% of developers, which at the end of the day is more than enough!

Disclaimer: thankfully, I haven't had to write anything in Motif for many, many years now, and my memory's flaky as hell, so what I've said could be completely wrong :-)

Re:Um, now which exhibit was which?

[Guy Harris]

have no problem agreeing that the "default" GTK look is pretty klunky.

Note that the default GTK+ look is very much like that of, err, umm, Motif....

If Jamie hadn't used a GTK+ theme in Exhibit B, the "why is Motif ugly and GTK+ beautiful?" question would have been even more pointed.

Of course, what this points out is that GTK+, given that it's themable, cannot, in and of itself, be described as "ugly" or "beautiful", even by the criterion of one particular person's taste, unless you refer to its default appearance, as the way it looks depends on the theme being used.

CDE going away? (sigh)

[waldeaux]

Back in 1985, I worked on my first Sun machine. It had a gui called SunWin. It was OK because it was the first GUI system I was exposed to (before that it was VT100's and IBM mainframes).

Then they had color --- wheeee. (1987 ish).

Then around 1991, we were all moving to OpenWindows because that was the REALLY great thing to use and Sunwin was no longer supported by Sun, really. So, re-port all the code we wrote for Sunwin to Openwin. Sigh - OK but it's just this one time.

1993-or-so. Oops. OpenWindows is passe. Other groups jump to X11, but my IS department doesn't want to support that because Sun has a *vision* but still keeps everyone in the dark that Motif is where Sun is headed (supposedly).

1994/1995 - Did I say Motif? I meant NeXT, or something else. The X11 people are putting their fingers in their ears to drown out the complaints of all the people who heard through the grapevine to dump OpenWindows and embrace Motif (so they started porting things to Motif), but at least they've been able to use the same GUI for a few years. All the people in the dark are still using OpenWindows, and have no idea that everyone else is using something different.

1997 - Some people have CDE now. The X11 people are still using X11 and everyone else who still hasn't figured out how to configure OpenWindows are still using OpenWindows with the same blue screen. It's an easy discrminator to tell the populations who are aware of the non-Sun UNIX world and those for whom e-mail is still "a nifty new thing that might catch on".

1999 - I'm using CDE at work which is almost impossible to configure (I still haven't been able to get a Netscape button on the tool bar, but I'm the ONLY person around who has an Xterm button where everyone else has a "TextEditor" button a Sun application that is used by zero people except for my officemate).

2000 - Oops CDE is now passe as is Motif. What will Sun support next? (Well, not NeXT! :-) So in 15 years I've changed GUIs for my Sun workstations what 3 almost 4 (I avoided Motif) times.

Meanwhile all the X11 people are using things like Gnome (like I am at home) and we're back to where we started again, except all the clueless people are still on OpenWindows and almost no one uses the facilities that come with it, prefering to do all of that on M$ machines at home or next to their Sun workstation. The IS dept. hasn't said "boo" about where they're headed although most of them are using CDE... Meanwhile, I've just given up doing a lot of things with my Sun workstation and work from home on my Linux box with Gnome+Sawmill, hoping that eventually Gnumeric is less bug-riddled and the next stable version of Gnome won't make StarOffice crash (has anyone else seen this???)

So, as I said at the top. Sigh. What goes around.................

Why are we arguing about this anyway?

[kcarnold]

One of the things that I actually liked about Windows was its consistant (crappy or not; let's not argue about that here) interface, its "look and feel". All (err, most) Windows applications, no matter how bad they worked, looked vaguely the same. Everyone (okay, discounting LiteStep stuff) who programs for Windows gets the same API. You get a window that looks standard (okay, maybe kinda dull), a standard menu bar, toolbar, status bar, etc. There are little nice things about it, too, such as a uniform behavior of taskbar buttons (on GNOME you must do show-hide twice to raise an invisible window with the mouse (yes, you can do Alt-Tab, but even that is not as good as Windows's Alt-Tab)) (KDE thankfully does raise by taskbar click). Configuration for how all windows look is done in one place (the Display control panel). Maybe it isn't the individual elements that make the Windows UI nice; it is how it is all integrated. Even with KDE (which I think is nicest as far as "Windows emulation"), plain-old X apps don't, and can't, have the smae look and feel as straight KDE apps. And then there are the different desktop environments (someone suggested that this phrase should be in quotes; maybe that's a good idea) available for Unix (Linux), i.e., CDE(Motif), KDE(Qt), and GNOME(GTK). "So what if it's crap; it's all the same crap." -- Me

Don't go ranting and saying that I support Windows and must be burned :-). I'm just saying that Microsoft actually did get some things right. I could write a very long post on the many ways I hate Windows, but I like its consistent UI. This is one thing Linux (err, Unix) badly needs to have to really catch up and overtake Windows. Now MacOS is a different story, especially with Aqua. Man, why can't they release the source for that thing? I'd port it to Linux! (Shouldn't be that hard considering that the kernel is BSDish and Darwin is supposedly open-source.)

"Whatever,"

Ken