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

What it needs

[ebunga]

Corporate people like to spend money. So, the only way to make GTK and QT be a success is to charge large sums of money for them. Remember, to be an "Open Standard", one must be required to pay money to be called "standards compliant". Well, atleast this is what The Open Group believes. And all those other standards groups want you to pay a few zillion for documentation on the standard. Oh joy. I love standards.

Re:What it needs

[mindstrm]

Corporate people do not simply 'like' to spend money, they just don't *care* if they have to spend money or not.

If you come and say 'we have a tool that does the job, and we back it 100%, and we have a huge support team'... yes they expect you are charging for that support. If you aren't, how are you affording to provide the level of service they expect?
They don't use Motif because it's expensive, they use it because it's a standard.

And this will definately change as gtk and the like grow.

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

Re:Nooooooooo way

[AugstWest]

The Unix workstation market has been dwindling for quite some time, more to the NT market than the Linux market (Remember SGI going to NT?).

Given the cash to set up a server environment, Intel hardware is the last place you should look. Give me a couple of UltraSparcs over the fastest SMP Intel boxes anyday.

Maybe Merced will change that, assuming that we see it sometime in the near future, but I don't think so. Workstations are a different issue, but I don't think that workstations make up quite the bulk of their sales that servers do. I could be very wrong on that, but it's just my impression.

Cheaper and easier mean little when you're interested in raw speed, throughput and stability. Linux isn't utilizing the 64-bit Sun hardware anyway at this point, IIRC, anyway. So, if you need the speed, you need the hardware. If you've got the hardware, why cripple it with an OS that doesn't utilize it to its fullest potential?

Re:Nooooooooo way

[sjames]

Who will buy their HARDWARE if generic off the shelf components are cheaper an easier to come by, and are supported in linux?

Have a look at the price of new SparcStations now. They have fallen a good bit so that they are more in line with the PC price/performance. The newer Sparcs with PCI bus and Linux are looking very nice!

I think the change IS due to Linux making PCs into reasonable Unix boxes. The really nice thing with Linux is that it is making the choice of hardware and software independant decisions.

Back on topic: I am not really a GUI programmer, but I muddle through when necessary. Personally, I find GTK apps MUCH more understandable than Motif.

Re:Nooooooooo way

[AugstWest]

excellent, thank you, good to know. of course, I'm currently about 5 minutes from completion on installing Solaris on a Sparc box, when I could have done a 64-bit linux and saved myself about a million hours of trouble...

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?

Re:Lacking "features"

[Anonymous Coward]

Our corporation is currently switching from Motif to Qt for a large project (500K C++ lines) in order to insure seamless port to the windows platform while keeping Unix port available.

Troll support is quite efficient and helped us to
implement missing features if any.

Qt has nice "modern" widgets that are not available with Motif.

Re:Lacking "features"

[jd]

Two things worry me about your post. First, it's 100% true, and secondly there are plenty of pointy-hair bosses who genuinely see those as important features.

Re:Lacking "features"

[spinkham]

Unix is old, not archaic.
Old=old
Archaic=old, and most everyone agrees much better things have come along.
Old things can still be good (ala a Rembrant painting)
Old things can also be archaic, ala Motif or cp/m.

Re:Lacking "features"

[Jon Abbott]

I've never understood the "Motif is ugly" argument. What exactly is it that is unappealing?

Motif apps just seem to have the same drab, "don't look at me too long or your eyes will cross" appearance. I think more than anything it's the lack of themeability for checkboxes, drop-down boxes, scroll bars, and the like. Please correct if I'm wrong and there is a way to make these appear differently.

Remember, Motif is *highly* customizable (even themeable to an extent with X resources files, although you don't get background pixmaps). Calling Motif ugly is just saying "I don't like the defaults, and I don't know how to change them."

Here's a hint for your .Xdefaults file: *background: grey80

The only changable thing I've seen is colors. I'm highly interested in knowing other ones, but I've never seen them in anything I've read or come across.

"And they're not archaic." Um...like unix? or X?

When I say that they are archaic, I'm not necessarily referring just to the age of the toolkits themselves. More specifically, I'm referring to the concepts they embrace, and how they will address user and developer needs in the future. A few years ago, Motif had lots of commercial momentum driving it. Yet, a year and a half ago, The Open Group has discontinued its development. Lesstif (AFAIK) is the only actively developed form of Motif now. Are new features planning on being added in Lesstif, or will it just be a game of catch-up until it is completely feature complete?

Unix, while being archaic in the age sense, is in many ways less archaic than Windows -- the most interesting ideas and projects (at least, in my opinion) are being implemented on Unix based systems. This makes it more "lively" than other systems, namely Windows and the like. See spinkham's comment above for more insight as to what I mean.

About X being archaic -- all I have to say is bring on Berlin! :^)

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

Motif is living only on momentum

[sarchasm]

I've written a couple of good size apps that originally used Motif for the UI. But I've since ported them to GTK for the following reasons:

1. Open source

2. Low (zero) cost (because of #1)

3. GTK is much easier to write for than Motif

4. It's also much easier to maintain on multiple platforms. GTK's design is pretty good (maybe not fantastic, but definitely easier than Motif)

And GTK isn't the only alternative nowadays. Motif has no advantages anymore for new development and because of maintenance I think it's even advantageous to port to another kit in most cases.

Ummm....

[Gokmop]

"Of all the several hundred or so apps out there that use the GTK library, they require either 1.0.x, 1.2.x, or 1.2.x-x blah blah blah."

Ever seen a lot of the KDE/Qt apps? They say, "Don't use such and such a version of Qt because it's not ready yet or the APIs are different" and so on. It's the same thing for Qt, it's just that there are probably a lot of GTK+ apps out there that haven't been updated yet. That's not the toolkits fault.

"Basically you need to install several different versions of GTK just to use the apps you want."

Bzzzt! Wrong! Just about any application worth using has been updated for the 1.2.x series, which has been out for quite a while. If it doesn't run with 1.2.x, then chances are you don't want to run it anyway.

"GTK is also one of the most bloated toolkits availible, and it is ugly"

I can't argue with your sense of aesthetics, since that's your choice, but you're wrong about it being bloated. I get the feeling that you're basing that entirely off of your theming argument - and I can tell you, you don't need anywhere near those requirements you listed, and you can stay away from 90% of the overhead if you just don't use pixmapped themes. The flexibility that pixmapped themes gives you is something you have to pay for. If you read some of the info on gtk.themes.org, you'd know this.

Re:Ummm....

[Thrakkerzog]

They can be statically linked.

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

Re:Compatibility tool?

[jd]

A few points. First, Motif is =HORRIBLE= to use, with C++. Motif++ is old and decrepid - at least, the version on src.doc.ic.ac.uk, which is the main UK archive of software.

Secondly, Motif dialogue boxes and sliders are the pits! Give me Open Look, ANY DAY! Please! When I did some porting of Motif apps to Java/Swing, people cheered when they saw the new dialogue boxes they'd be using.

Third, which version of Motif do you use? There are -dozens- of different, incompatiable Motifs in existance, largely because nobody wants to upgrade or pay for a new licence. I wonder why. But I'll wager any Motif 1.2 code you're using won't work out the box on any Motif 2.1 platform. "So what?" you say. And rightly so. Nobody expects that of Gtk. But, then, Gtk doesn't have the degree of diffusion Motif has, so the problem is much rarer. It's also much easier to fix.

Fourth, Gtk and KDE support inter-application communication, in a way Motif did not. Motif apps were a royal pain at times, for that reason.

Lastly, if Motif/Lesstif added the ROX-style drag-and-drop, I'd say it had a feature worth using. But it doesn't, so surely it's Motif that's not worth the effort, if anything is going to be so labelled.

Re:GTK + GNOME + Linux == GOD

[Cid Highwind]

>Gtk and GNOME will own all the other pansy ass
>inflexible non object based development toolkits
>and environments. Like Motif, CDE, AND Qt.

Implying that Qt isn't object-oriented? It is.
As for gtk "owning" it's a matter of opinion. I think it's butt-ugly without a pixmapped theme, and too slow with one. To each his(or her) own...

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

[ptomblin]

No, the drag and drop was part of the Motif 2.1 API. I know because I was writing programs to use it. 4DWm merely implemented the Motif built-in DnD on the desktop, unlike mwm which hadn't changed since the Motif 1.0 days.

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.

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

[Guy Harris]

Worth ignoring because Qt 2.x is, guess what - compatible with GTK+ and Motif.

And Motif? It does support the Xdnd protocol that GTK+ (and the toolkit/application framework that introduced Xdnd, JX) support, but I hadn't heard that it, like GTK+, also supported the Motif DnD protocol as well - are you certain that it does (e.g., because Troll Tech says so on their Web site)?

They are good but...

[Junta]

I've interviewed with several companies, wokring with FreeBSD Solaris and AIX lately. They noted and immediately recognized linux and that had them interested. However, when they saw GTK+, they asked if it was some specific version of Tk or something. These are relatively knowledgeable people, and among the people I work with few even know what GTK+ is, they just do Java and Motif and Win32 and a little Tcl/Tk, but never hear of Qt and GTK+. I find it a shame in any 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

[Yarn]

I think they cut these features because they wanted to abstract the toolkit as much as possible from the display. Lets face it, X isn't going to be around forever (It just seems that long :) and being able to port things to cygwin fairly simply is *nice*.

I very rarely use xresources, so I dont really miss them.

My main gripe with GTK is the options, theres so many of them! run gtkapp --help and you get loads of scroll with all sorts of options that apply to all gtk apps (--geometry, --display etc)

There is i18n for gnome, but not for GTK itself.

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

[dublin]

I've hardly used the GTK stuff, so what you say comes as a complete shock to me.

Despite all the X-bashing present here, the ability to arbitrarily redirect the display to another place on the network is an incredibly valuable capability, and one that the Windows folks haven't figured out yet.

If you can't even use -display with GTK apps, then they're next to useless in a networked environment!

Also, I'm going to be contrarian and say that I think themability is a really, really, bad idea, and may ultimately be the single largeest contributing factor inhibiting Linux from making large-scale inroads against Windows. Why not do one interface really well, instead of 500 that are ugly, confusing, sick jokes? And I won't even mention the user training issues themeability presents...

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.

Re:Lacking features in GTK

[Jamie Zawinski]

The fact that 500 people are working on ugly, confusing interfaces in no way prevents anyone from doing one interface really well. Why not do one interface really well, and allow 500 alternatives for people who prefer them?

Too often people use customizability as a crutch. They say ``if you don't like it then change it'' instead of getting it right the first time. This is, to a large extent, what has been wrong with X from day one: by refusing to dictate policy, we ended up with a zillion crappy UIs instead of focussing all those people on fixing the same one that everyone was using.

We've seen it in this very thread! People excusing shitty performance and UI criticisms by saying ``well you're using the default theme, you dummy! If you'd only used my favorite theme, which you can download from this web site over here that's down right now...''

I'd rather have Developer X working on getting one core UI right than adding features and fixing bugs in the theme engine.

Themes are a cute, useless toy for people whose hobby is tweaking their desktop Because They Can. There's nothing wrong with that hobby per se, but those people are not the people you need to win over if you want your desktop to be a success.

Re:Lacking features in GTK

[spitzak]

A lot of the responders here seem confused as to what X resources are, thinking they have something to do with Xt or that Xt is required. Xt bloated it up horribly, but the useful part is defined in Xlib. Having seen some of the ugly stuff people use for "resources" now, especially that awful "INI" format, makes me respect what was done a lot.

The X resources are a single block of text, usually copied from a file in your home directory when X starts up. This text is put on a property of the root window (XA_RESOURCE_MANAGER) and the only actual communication is to get the entire text sent over the wire to the application (thus it should not be huge, certainly not like Xt wants it to be).

Xlib provides a single call to make it easier to use this block of text as a database (and also to cache the copy of the database in local memory):

const char* XGetDefault(Display*, const char* A, const char* B)

If the two strings are "A" and "B" the above function searches the data for a line of the form A.B:{whitespace}C and returns a pointer to C. It returns null if not found.

It is common that A is a word naming your application and B is the name of a piece of your application. B may contain periods but there is no need to obey any of the Xt rules, Xlib does not care. If the entry is not found, you should change A and try again. Usually A is changed to "*". So "*.background: blue" could set all programs blue, while "Clock.background: red" will make the clock red.

Xresources are quite useful for appearance preferences. Unlike Xt (or Windows' registry, which has the same problems) they should not be used for required options.

The big missing element is that there is no standard for X resource names. However I think a good start would be to use KDE's "affect other Xlib applications" and use what it writes to the resources for it's color settings as a standard.

I have looked at this some. The main addition I would do is to allow images for widget backgrounds to be specified by X pixmap number, this requires another program to maintain the pixmaps and modify the resource database, but avoids the need to put code for reading images into all the programs and allows the pixmaps to be shared.

Re:Lacking features in GTK

[nathanh]

X as a user interface is foul

C as a user interface is foul, but then again C is a programming language not a user interface.

X, like C, is a tool for creating user interfaces, not a user interface unto itself.

Re:Lacking features in GTK

[John Allsup]

X as a tool for creating user interfaces is foul

It can't match anything much on 'user apparent' speed grounds -- X's event model takes care of that.

It isn't extensible, regardless of what everyone else says -- for examle GLX was around donkeys' years ago, but no-one's able to 'extend' XF86 with it until now (you can't extend X at run time, you've gotta hope you've got the source to extend it at compile time, and then you've gotta make it work with your X server)

Its , network transparency was done better by QNX with their MicroGUI (which based its protocol around distributed IPC). Even NeXT could just redirect object commands and postscript display commands -- X didn't have the display model to keep up.

p.s. C has good programs written for it quite often -- X doesn't have good UI's made with it.
John

Get a real toolkit

[Anonymous Coward]

--== www.fltk.org ==--

No bloat, no silly c cast checking. Portable to win32 and X11. No 1/2-assed license, uses LGPL. Cool object oriented design. Give it a try...

Re:Get a real toolkit

[duplex]

Bastard! you stole my post! Shame on you! Seriously though, I'm gonna expand your punch line a little bit here. I really don't understand why FLTK is treated with such neglect by the Open Source community. This toolkit quietly evolved into something extremely powerful and flexible. Several advantages over GTK+ QT come to mind right away:

• Coded by someone who understands OO design. The toolkit is immensely object oriented and so consistent that one can almost do away with documentation. Header files are all it takes to understand how it ticks. That's what I call good code.
• It is easy to implement additional message loops as FLTK is a toolkit not a Framework. Check the Mico Dispatcher to see an example.
• It sports a very nice and extremely flexible layout editor called FLUID. Using fluid beats any experience I had with layout editors
• Finally and most importantly using FLTK is Fun! Coding it is a pleasure. This is a quality unheard of in UI toolkits but having experience of MFC, QT and a little bit of OWL I can assure you that FLTK feels like a breath of fresh air.
• It's LGPL which means that commercial vendors and Free Software developers can use it alike. You may consider this a disadvantage only if you are an OSS zealot.
• It's fast and lean. Immensely. The built binary is around 300KB in size! FLTK redefines the meaning of Lean. With the area of mobile devices looming this could be a particular strength but even the desktop applications could do with less overhead these days.

Obviously FLTK is not without its problems. The biggest one at the moment is a lack of good keyboard handling on non-input widgets but this is about to be ironed out.

The version 2.0 will bring lots of improvements in many areas. Mainly themeability and keyboard handling will be improved.

Try it and if you can appreciate good C++ code FLTK will not disappoint.

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.

Re:Motif?

[acb]

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. Straightforward in a rather painful way. If you don't mind defining lots of functions and stringing them together with big ugly tables, all the while paging back and forth through volumes of documentation. Then again, I found Gtk less than perfect as well. IMHO, object-oriented programming in C is a masochistic exercise. Even C++ (as horribly malformed as it is) is better. For a recent project, I started looking at Gtk, but went over to Qt, and ended up writing it in C++ using STL as well. -- acb [Where Python is not an option, C++ will do...]

Re:Motif?

[ajs]

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

In Gtk+, I can tell my application to respond to an event (signal in Gtk+ terminology) that is triggered by, say a button press. So far this is the same as Xt. But let's say I'm writing a Web browser. Ok, now I want to open a socket and handle events on that too. The usual Xt/Motif way to do this is to pull out the X display socket file descriptor from Xt (Xlib really) and then add that into your select call. When select returns, you see which descriptor triggers, and then jump into Xt's event handling if X triggered the select.

In Gtk+ you simply tell it about your socket and request events from it with the same callback strucutre as the rest of your code! This makes Gtk+ code a lot easier to develop and maintain (big emphasis on maintain).

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.

No, I meant what I said. Gtk+ provides features like virtual destructors and a well defined line between class definition and implimentation. These features of Gtk+'s C-based OO do not exist in Xt.

In many ways Xt was a grand experiment, but I've spoken to one or two of the original Xt creators, and even they admit that if they had it to do over, it would be done very differently. I agree, and I think that Gtk+ makes great strides in that direction.

I can't comment on what it's like using Xt from C++, because C++ is an abomination

I used to feel this way, but it was basically because I did not understand C++. Now, I understand it better and I think it's the wrong choice for much of what it is applied to, but when used carefully and selectively, C++ has some excellent applications. I'm glad to see that the Gtk-- folks have staballized their interface to Gtk+, as C++ access to Gtk+ is quite important. However, I am pleased that most coding for GNOME and Gtk+ continues to be in C. C is more portable, more debuggable and generally a better choice for most of these projects.

Qt on the other hand suffers from being a C++ implimentation. I've seen a lot of developers simply discount it out of hand because they don't use or want to use C++.

Re:Motif?

[ajs]

Where Python is not an option, C++ will do...

But... but... Python is an option in Gtk+. It's even a well supported option! Perl, Python, C, C++, guile, Objective C and ADA appear to be the best supported languages for Gtk+.

Qt on the other hand as some poorly maintained bindings for Perl and Python (last I looked I couldn't actually find a non-broken link to them from the Qt pages) and then C++ is the default. As far as I can tell there are no interfaces to other languages. C being the notable exception. I can understand wanting a C++ binding, but no C binding? For UNIX systems?

Re:Motif?

[Jamie Zawinski]

Ok, now I want to open a socket and handle events on that too. The usual Xt/Motif way to do this is to pull out the X display socket file descriptor from Xt (Xlib really) and then add that into your select call. When select returns, you see which descriptor triggers, and then jump into Xt's event handling if X triggered the select.

In Gtk+ you simply tell it about your socket and request events from it with the same callback strucutre as the rest of your code! This makes Gtk+ code a lot easier to develop and maintain (big emphasis on maintain).

No, what you described is the wrong way to do it. In fact, I think it doesn't work (or didn't used to) on VMS systems running DECnet, because calling XConnectionNumber() is not guarenteed to return something you can pass to select().

You seem to be unaware of XtAddInput() (and possibly also XtAddTimeout() and XtAddWorkProc().)

In a portable Xt program, one doesn't call select(), one calls XtMainLoop() (or XtNextEvent() and XtProcessEvent().)

In other words, it works exactly like it does in GTK.

Re:Motif?

[acb]

I meant in terms of performance. If one is writing, say, a digital audio application, one needs to use C/C++.

As for Gtk's other language bindings, they tend to lag behind the C. You can, for example, pretend that Gtk is a C++ class library, but if you do any deep delving, or defining of widgets, you need to start doing pseudo-OO in C, which is always an ugly job.

C++ is a hideous language, but at least it can do OO and some neat abstractions without burdening the programmer with the details. In a sense, it's not so much a language as a code-generation tool. And STL rocks.

Re:Motif?

[ajs]

I seem to remember that XtAddInput does not work. I don't know why off the top of my head (Xt being something that I stopped using back in '92 or so), but every Xt or Motif program that I've seen that needs this functionality does exactly what I describe. Perhaps they're all wrong, in which case it's just that Xt is widely misunderstood.

Re:Motif?

[ajs]

Oh, on the contrary, the C++ port for Gtk+ (called Gtk--) is tracking the current development of Gtk+ quite nicely. Take a look at the most recent release.

The Python support tends to lag a little, but not much. There are some pretty serious applications that use python (including the gnumeric spreadsheet).

You definitely want to impliment the digital-audio portion of your digital-audio application in C or C++, but why can't the UI be in Python or Perl or Guile?

Re:Motif?

[acb]

You definitely want to impliment the digital-audio portion of your digital-audio
application in C or C++, but why can't the UI be in Python or Perl or Guile?


Because it's easier to implement it in C++ rather than gluing two languages together. And the application is not really an end-user product that will benefit from being scriptable.

Re:Motif?

[Jamie Zawinski]

I seem to remember that XtAddInput does not work. I don't know why off the top of my head (Xt being something that I stopped using back in '92 or so), but every Xt or Motif program that I've seen that needs this functionality does exactly what I describe. Perhaps they're all wrong, in which case it's just that Xt is widely misunderstood.

I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong.

In all of these posts, it may sound like I'm defending Xt or Athena or Motif, but I'm only defending them against things that people are saying that are just incorrect. Motif is a mess in a zillion ways, and there are lots of scathing criticisms that can be made of Xt, Xlib, and everything down the line. But it's important to bash them for things that are actually true!

In particular, while Xt's event model has some really stupid shit in it, you didn't mention those things. The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are; and that widget finalization (the Phase2Destroy thing) is a complete mess.

Re:Motif?

[ajs]

I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong.
[...]
The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are...

Uh... Jamie, how can you make both of these statements?! As I recall, this is exaclty the kind of brokenness that people were working around.

Re:Motif?

[Jamie Zawinski]

I don't recall XtAddInput ever being broken, which means that whatever code you saw was wrong.
[...]
The things that bother me most are that timer and file-descriptor events aren't first-class events the way events are...

Uh... Jamie, how can you make both of these statements?! As I recall, this is exaclty the kind of brokenness that people were working around.

Huh? You can't work around the fact that Xt doesn't treat timers firing as first-class event objects. And you sure can't work around it by calling select().

The API associated with XtAddInput() is screwy, but it's not ``broken'' in the sense of ``doesn't work as advertised'' or ``doesn't let you do the things you can do with select().''

That's what I meant about criticising the right parts: this part of Xt has a screwy design. But it is still usable, it's just goofy. And calling select() does not make it better, it just makes it less portable. So criticise it for being a dumb design, but don't say that it doesn't work, because it does work.

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.

Re:O'Reilly books

[coyote-san]

Please don't let your biases lead to you making stupid statements. *Any* system with the complexity of Motif, Qt, KDE, or MS Windows will require extensive documentation. The only real question is if you'll have thick documents describing what each widget/object/fuzzball allows, or if you'll have thick documents describing what each widget/object/fuzzball does when you give it a canonical "one-size-fits-all" instruction.

The former is a little harder to code the first time, but the latter is far harder to maintain. IMHO, of course, but I have tried both. Motif has a track record, and while it's not pretty it's also clearly not a dead end.

But Qt and GTK? Many people report it's easier to get the first version out the door with these toolkits instead of Motif, but how easy are they to maintain? Where's the persistent documentation that I can put on the shelf and hand off to a maintenance programmer in five year? I don't want web pages which could go away or be changed to show only the documentation for a version major revs away from my legacy program. The O'Reilly X books set very high standard for documentation, and (I believe) are a large reason why O'Reilly is held in such high esteem. After all, many of us were introduced to O'Reilly by those books.

Re:Fill me in

[Tim Behrendsen]

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.

I wish that they had had the good sense to just punt Xt and either rewrite it, or come up with something new. Unfortunately, they didn't.

--

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

Re:LessTif status report

[Jeffrey Baker]

Yes, but where can I find the dynmotif releases of Netscape? I have been wanting them but I can't find them on ftp?.netscape.com

Cheers
-jwb

Re:LessTif status report

[FonkiE]

look into the directory where you installed netscape to ...

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.

Re:In our case, yes.

[dublin]

Sure, your life as a developer is just dreamy now.

But recognize that what you have done is to shift at least part of that burden onto the shoulders of your customers, who now must ensure they've got the correct versions of all the non-standard (in the sense they're not part of the Sun distro) libraries required to run your product.

As a customer, I'd think very hard before accepting your app in a Sun environment, since your actions just significantly increased *my* TCO! Whether you like it or not, you have to admit that the uniformity of the Sun (or other commercial Unix) environment(s) has its advantages to customers.

Java PLAF

[Hard_Code]

Quick...somebody make a QT or GTK Java PLAF.

Jazilla.org - the Java Mozilla

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.

Re:Motif "ugly" while GTK "beautiful"??

[Alan Shutko]

Turn off the theme and GTK will be a lot faster.

Re:Motif "ugly" while GTK "beautiful"??

[Temporal]

Can someone explain to me why one of these is ugly and the other is beautiful.

Exhibit A is ugly because it is flat, solid-colored, and boring.

Exhibit B is beautiful because it is 3D, smooth-shaded and interesting, and generally an eye-pleaser.

But then that's my opinion...

------
-Everything has a cause
-Nothing can cause itself
-You cannot have an infinite string of causes

Re:Motif "ugly" while GTK "beautiful"??

[redled]

"Seriously! Can someone explain to me why one of these is ugly and the other is beautiful"

Why no, I can't say that in regards to those *particular* screenshots, but you must keep in mind that while motif always looks like motif, gtk has a theme engine that allows it to look like, if you want, motif...or perhaps you would like it to look like windows -OK, no problem. Want it to look like a mac, or want it to match your enlightenment theme? That can be done easily too:

Exhibit C
Exhibit D

--

Re:Motif "ugly" while GTK "beautiful"??

[PhiRatE]

Well, I think its mostly about personal taste, which is one reason why GTK wins out, themes make it possible to adjust stuff to how you like it.

But as far as your two exhibits, well I looked at the first one and winced. The buttons are chunky for a start, and the huge arrow buttons look butt ugly (to me).

The title bar as well, big chunky square thing with far too much indentation (Those of you who have used old RiscOS applications know what I mean there..)

The GTK one however just makes me sigh happily. Arrow buttons are still slightly too large, and I dislike that odd orange thing around one of them, but the text buttons are niiiccee, small indentation, smooth gradient, mmm. And the titlebar too, much nicer look.

I could definitely improve on that theme, but overall, in my eyes it beats the motif look by leaps and bounds.

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.

Re:Sund. Explns.

[Greyfox]

Unfortunately no one's come up with anything better that I've seen. Given that X gives you a standard method of transmitting windows over a network to or from assorted other systems, that puts it well ahead of the other single user GUI's in my opinion. X may not make the gamers very happy but it seems to work pretty well for everyone else.

Re:Sund. Explns.

[Guy Harris]

Given that X gives you a standard method of transmitting windows over a network to or from assorted other systems, that puts it well ahead of the other single user GUI's in my opinion.

NeWS, as per the second point made to the person to whom you responded, also supported displays over the network - you sent PostScript code to the display server, and it runs that code to draw stuff and send information back to the application for input events that the PostScript code didn't handle itself.

For better or worse, NeWS didn't survive, though.

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)

[rcw-work]

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?

I agree that X resources are great, I use them for customizing everything from xterm to netscape (Netscape*blinkingEnabled:False :) but I've never seen anyone else ever make use of them, and I've never seen anything to set them automatically for people.

I don't know why, but it seems about 1% of the population is able to grasp the concept of a file format and edit a text file to a specific end. I guess the gtk/GNOME people decided they wanted to appeal to more of the general populace than this :)

Re:X resources (just ranting against GTK)

[Greg Merchan]

Amen!

If you'd like to have some fun with the X resources, download UDE from either CVS, or the most recent release. (I'll snapshot CVS if anyone is interested. Contact me and I'll point you to the URI.)

The CVS version has integrated (in the C sources) the feature I'm about to describe. (UNIX philosophy lovers may prefer the following method.)

UDE workspaces have an option called ScreenCommmand. Create X resource files with the configuration you'd like for a particular workspace. Create a shell script that executes (at least) the following:
xrdb -merge myresourcefile
Any app started in that workspace which uses xrm will 'fit' with the workspace. (There are ways to update at runtime, but it's complicated unless the app is specially coded. See editres for more for example.)

I discovered the X resources will learning Xlib. (I'm on to CLX, heh, heh.) I'd have to say that Netscape 4.7 and GNU Emacs 20.5 are presently the best looking apps I've got; at least they are the ones I look at the most. (M-x world-domination ;-)

And if you think X resources are great, learn LISP and the LISP interfaces to X ( CLX ~ libX11 ). Once you do that start mucking around with .emacs and feel the AI GUI GNU goodness flow. Mmm.
Ever notice . . .
Microsoft and its allies assume everyone is stupid.

Re:X resources (just ranting against GTK)

[dublin]

This is sthe thing I hate most about everything that comes out of the FSF: they just have to throw out any prior art as unworthy because it wasn't developed by the free software community - witness the gnastiness of the perverted "--" options in GNU apps, and the bizarre insistence on using those stupid info pages in place of the well understood and accepted man page standard.

I'm not opposed to the FSF's ideas so much as I'm opposed to it's implementaiton philosophies, and I find that the more I can avoid GNU code, the better life is. Unfortunately, there aren't enough alternatives for some of this stuff, so stupidity wins by default...

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.

Re:X resources (just ranting against GTK)

[David A. Madore]

Is there some valid reason, though, why GTK couldn't read both a GTK-specific configuration file and X resources, with the former having precedence? That seems like the obvious compromise.

Re:X resources (just ranting against GTK)

[Jamie Zawinski]

Jamie, look. Clearly you and I disagree fundamentally on how flexible and dynamic the Xt libraries can be. Fine.

Uh, ok, except that what we're disagreeing over are not matters of opinion, but matters of fact.

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.

Nothing I have said here has been advocating using Motif over using GTK. (I've hardly even mentioned Qt because I haven't used it, because it's C++.)

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.

And GTK is set in stone now?

GTK is under active development, which means it can be fixed. GTK could easily be made to use the X Resource Manager as its basis for reading and storing preferences information. This could be done without breaking any existing apps: it could be a binary-compatible change.

But even if I'm wrong, and doing so would require incompatible changes, so what? They've done it before (there was a year when everyone had to have two versions of GTK installed because Gimp didn't work with the version of GTK that almost all other apps were written for.) They've had flag days before and they will have flag days again.

Changing GTK to be built on top of Xt widgets is probably impossible at this point. It would certainly be a colossal amount of work. But using Xrm resources wouldn't be hard.

Dismissing my criticisms of GTK's design because ``the decision has been made'' or ``that's living in the past'' is ridiculous. If a design mistake was made, even if that mistake is fully entrenched (like most of Unix), that mistake should be acknowleged so that people don't make similar mistakes in the future.

Or do you believe that no after-the-fact criticism ever has merit?

Re:X resources (just ranting against GTK)

[ajs]

GTK is under active development, which means it can be fixed. GTK could easily be made to use the X Resource Manager as its basis for reading and storing preferences information. This could be done without breaking any existing apps: it could be a binary-compatible change.

First, Gtk+ is well on it's way toward it's third stable release cycle (1.4, I think would be the version number). This certainly is not the time to be re-working major gobs of the internals without a darn good reason.

Second, I still disagree that the X resource manager is a good solution. Gtk+/GNOME's model works well. I guess you liked the X resource manager. Ok, cool. I didn't, and what's more, I thought that it held X back in a lot of ways. But, maybe I'm wrong. Time will tell.

But even if I'm wrong, and doing so would require incompatible changes, so what? They've done it before (there was a year when everyone had to have two versions of GTK installed because Gimp didn't work with the version of GTK that almost all other apps were written for.) They've had flag days before and they will have flag days again.

If I'm remembering correctly that was when 1.2 was on it's way or had just arrived, and significant functionality was being added that modern widget sets required. Specifically, these were features that projects like GNOME, gnumeric and even the Gimp itself could not be written without.

Now that there are several dozens of popular proof-of-concept programs that work quite well with Gtk+ as it stands, it would be much harder to convince anyone that incompatible changes in Gtk+ were required.

Dismissing my criticisms of GTK's design because ``the decision has been made'' or ``that's living in the past'' is ridiculous. If a design mistake was made, even if that mistake is fully entrenched (like most of Unix), that mistake should be acknowleged so that people don't make similar mistakes in the future.

Here's the fundamental disagreement between you and I. I don't think a mistake was made. Gtk+ used standard X conventions where they made sense and dumped them like a hot rock where they hobbled development. Clearly, given the way the market is going, they made the right choices. Their model for configuration has spawned efforts like themes.org. Please note that there is no xdefaults.org (I tried). Also note the number of high-quality end-user applications being written in the last year for Gtk+, and the number that are currently under development (find that sort of info and more at gnome.org).

What I'm saying is not that you should nto be living in the past because that's bad. Instead you should not be living in the past if the present can suit your needs. You don't "need" .Xdefaults. You "need" a configurable desktop and applications.

Dead Stuff & OpenWindows

[chandler]

Well, as it turns out, there's yet another dead desktop - OpenWindows. I know that OpenLook is open source, along with the shell and the window manager, but nothing beats the coolness of the OpenWindows file manager. Yes, there's a clone, but it's just not the same. Well, as you would know it, Sun killed OpenWindows in Solaris 8. Are we going to let this cool piece of technology die? No! We're going to petition sun and ask them to open up the rest of OpenWindows to go with OpenLook. After all, it _is_ dead.

Anybody want to help set up the petition?

QT has good docs too

[Eric Green]

I agree about the lack of good GTK documentation. But the QT documentation is first-class. I suggest you go to http://www.troll.no and browse it for yourself. Yeah, it's not paper, but it's still thorough and understandable (a combo that doesn't happen too often!).

As for "the QT book" that you refer to, it was intended for tutorial purposes, not as a comprehensive reference work. See the Troll Tech documentation for the comprehensive documentation.

There hasn't really been a big problem with QT changing every time you update your system either. Unlike GTK+.

-E

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

[Tim Behrendsen]

Actually, I'm somewhat surprised at his position considering how slow and unreliable Netscape is under X. Of course, that may not be Xt's fault, but I'm assuming he has Xt/Motif experience beyond just Netscape.

--

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:Xt is not the problem

[Jamie Zawinski]

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.

Um. So?

You'd rather they provided XmDrawLine which did nothing but call XDrawLine? That would give you more things you needed to learn rather than less.

GTK is built on GDK. libm.a is built on libc.a. So what? That's what abstraction is.

Both Gtk+ and Qt are suitably abstracted, and you don't need to learn anything else in order to use them.

That's a nice sound bite, but it's so vague that it doesn't actually tell me anything. Please be specific.

Re:Xt is not the problem

[Tim Behrendsen]

I will defend Jaime a bit on this point... it's not that hard to figure out where a function lies if you understand how the heirarchy works:

• X11: Any sort of low-level drawing primitives
• Xt: General operations on Widgets (creation, destruction, etc)
• Motif: Particular operations on the Motif Widget set

I think the design and goals of this were pretty good, but as I said in another thread, I have big problems with the implementation. Unfortunately, Motif had to break a lot of this abstraction to implement some of its features.

--

Re:Xt is not the problem

[Jamie Zawinski]

I will defend Jaime a bit on this point... it's not that hard to figure out where a function lies if you understand how the heirarchy works:

• X11: Any sort of low-level drawing primitives
• Xt: General operations on Widgets (creation, destruction, etc)
• Motif: Particular operations on the Motif Widget set

I think the design and goals of this were pretty good, but as I said in another thread, I have big problems with the implementation. Unfortunately, Motif had to break a lot of this abstraction to implement some of its features.

I don't believe that Motif had to break abstraction to implement any of the things it implemented, Motif's implementation is just bad.

As I understand it, there's never been any real overall ownership of the Motif code base; it was written by six-month-contractor after six-month-contractor, with no small group of winners looking over it and keeping the worker bees honest.

Who's ``the Motif guy''? There isn't one. Even if you read the source code comments. The spec is one thing, but the implementation is another, and the implementation seems to have had no effective architectural guidance. That's my impression from having spent way too many hours digging around in the source, anyway.

Re:Xt is not the problem

[Tim Behrendsen]

Well, I won't argue that there is a lot in Motif that is brain damaged (just how long it took to plug all the memory leaks is evidence enough). I guess my sympathy switched over to the Motif maintainers when I spent too many hours trying to get some particular Xt function to work.

I mean, I've been there, where I've had to write stuff in the main event loop to intercept certain events, in order to implement my own function to fix something in Xt that simply didn't work reliably.

It just seems to me that it ought to be possible to have an Xt-like system that encapsulates the Widget concept, but is not so hugely complex and is much more reliable.

--

qt...

[Thrakkerzog]

Commercial QT does have a price tag. ;-)

Um, now which exhibit was which?

[Christopher B. Brown]

One merit of GTK (and QT) over Motif is that they actually abstract away from X, and are getting deployed on multiple platforms...

As for the "appearance" issue, you've picked one of the appearances that I like least. I have no problem agreeing that the "default" GTK look is pretty klunky. (And I'm not hot on the WM theme that you're using either.)

But redo that with the GTKstep theme and get something looking more like this fileselector or this scrolled window.

Other looks may be found at gtk.themes.org.

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.

Speed

[QuMa]

Though I've never run motif on my own comp, so I can't really judge, motif felt a lot faster to me than gtk and qt.

Re:Commercial GTK?

[J Story]

Let's look at this one more time: It *sounds* good to say that with commercial, closed source software you have someone to sue. But seriously, has anyone ever heard of Joe Mid-sized Corporation suing Microsoft when one of its products goes off the rails? (Let's exclude Sun and J++.)

If I'm not mistaken, most software comes with the company's disclaimer that their liability is limited to the price of the software. Given that, it seems that all else being equal, Open Source comes out the clear winner.

Re:CDE is a solid std

[Cy Burdock]

As an early promoter of fvwm, we came across many obstacles in the corporate world
to it - the reason was, usually, that CDE was the standard to which the corporation
had to adhere. However, the inception of KDE (and GNOME) has huge advantages
of the archaic systems that were Motif/CDE. For example, something as simple as
adding an application as a menu item into CDE used to have you looking up the
reference manual (which was not clear on the matter).

KDE and GNOME are a breath of fresh air - they will undoubtedly become the new
"standards" on the desktop for Unix platforms. Developers ignoring these
desktop systems are going to find they've missed the boat - big style.


Having seen some of the developments going on with KDE2 such as the
Neural network window placement policy I'd also stick my neck out and say that
they have a good chance in the next 3 years of making inroads into the NT-on-the-desktop market.

I want more

[sambamateur]

X and Motif came out in the late 80s (commercially). The question is not whether Qt or GTk will replace Motif. These three toolkits do the same job: they offer buttons, scrollbars, text widgets and a "drawing area" for everything else.

The question is: do you want to stick to these interaction techniques? Do you want another "desktop" (CDE, MS-Windows or KDE)?

I want more than buttons. More than one mouse. More than "windows" and "desktops".

I think something like Quartz is more interesting, although underused in MacOS X, at least from what I saw in the videos available. This could lead to new interfaces, new interactions (far beyond the "themes" everybody wants and nobody uses...).

Netscape vs. Mozilla, and Mozilla gripes

[acroyear]

Netscape already uses gtk as its framework, plus some homegrown stuff too.

Wrong

Mozilla is currently using GTK. Netscape has used Motif for every unix version around. Whether or not Netscape finally re-builds a Motif front end for their Solaris port (if they do one) remains to be seen.

I personally find the "buttons" (in the current Mozilla milestons) to be attrocious. If you're going to use a GTK app in a GTK environment, then likely you want the theme stuff to work as well. Its a pain in the butt as it is to keep changing xmms skins everytime i change my GTK and WindowMaker themes (which i have to do separately); to have Mozilla butt ugly no matter what i use is just too much, and if it goes "skins" instead of GTK themes for its main controls might lead me to just not bother...

GUI Builders

[neonstz]

I'm doing quite a lot of MMI stuff at work with Motif and some in-house stuff. To build the interface, we use X-Designer. I would really like to use QT, but a lot of our stuff is tied up to Motif and X-designer. We have custom widgets based on Motif widgets and stuff like that. Some of the stuff is a part of a realtime system (weapon control). Changing to abother, possible more unstable, system, would be very expensive. (I'm not sure how stable QT/GTK are compared to Motif). However, a X-Designer->QT converter or X-Designer with QT-capability would have been nice.

Hiding CDE launch bar?

[SEWilco]

Okay, having a launch bar/dock/wharf is nice. Is there a way to ask CDE to hide the launch bar until I want it? My screen real estate is valuable.

What both GTK+ and Qt are missing

[Gleef]

HeUnique asks:

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

When you phrase the question that way, the answer is simple, inclusion in an updated OpenGroup Unix Workstation Standard. In order for either to be a replacement for Motif, they'd have to be included standard as part of all the commercial Unixes workstations, which will only happen if they're part of the standard for the Unix Workstation trademark. Motif may be comatose, but it's not dead as long as it's specified.

In other words, the decision will not be made on code quality, license terms, or feature set; both GTK+ and Qt have beat Motif soundly on all three counts. As long as there are commercial Unixes seeking the Unix trademark, the decision will be made on politics within the Open Group, nothing more, nothing less.

----

Sun, browsers and toolkits

[Chuck Chunder]

Sun need to ship a decent browser, and if they have to ship GTK/QT to accomplish that (even if it's statically linked) then they'll do so.

Themes

[redhog]

One thing that is different is that Gtk is themeable. Back then, I liked to use Open Look. The reason is that
a) I like the functionality (left mouse selects default menu alternative when clicking on a menu, right mouse really opens it), and
b) I like the rounded bevels around selected menu items. I think Motif (And Qt) looks pretty bad, while being such "edged", and
c) The borders of Motif are by default set to 2pixels. I personally think that is an over usage of graphical space. I want 1pixel lines everywhere.

All of these, except for the first are solvable using Gtk themes. And the first one should be solvable using the loadable module feature of Gtk.

You might have selected a more diff erent theme (Not to say you where wrong selecting that theme, it proved your point).

I have never programmed Motif, so I have nothing to say about it. But I have programmed under Gtk (And even on Gtk, that is patched the libs to add some functionality (Altough, my patches never made it into the CVS)).

The Gtk API is not that flawed. From my point of view, it really have only one drawback - one that results from it being implemented in a non-oo-language - it does not have multiple inheritance, which have resulted in some partly hackish solutions (It is even mentioned in the code comments).

--The knowledge that you are an idiot, is what distinguishes you from one.

Re:Themes

[Yarn]

From a users standpoint I would far rather have OpenLook, it was quick and looked nice. I remember using a Sun with openwindows back in '93(or thereabouts, long time ago :) and once I got around the 'right click' bit of the menu usage I loved it.

I used OLVWM a lot in slackware 2, then slowly became disenchanted with it due to lack of apps that fitted in. I slid into an anarchic desktop running bowman and some athena based file manager, with XV for images. Now, with gnome and sawmill, my desktop is approaching the consistancy I loved on that old sunstation...

Re:Themes

[redhog]

Someone really should write a Gtk Open Look theme! And perheaps a hack for the right-click thingy. Unfourtunately, I don't have the time to doe neither of them...
--The knowledge that you are an idiot, is what distinguishes you from one.

Re:Bizarre Motif!

[Teferi]

Enh...
I'd have to say that GNUstep-gui does, seeing as that WINGS was essentially created as a simplified version of that library. I do, however, agree that it is a _very_ nice look.

"If ignorance is bliss, may I never be happy.

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

Re:QT and GTK lack ...

[Guy Harris]

QT and GTK both lack good software for GUI building and prototyping. When you're trying out different looks for an application, it's REALLY annoying to have write code to have to specify the look'n'feel of an app when it makes much more sense to use your visual intuition to 'draw' the interface.

Qt and GTK+ may lack them, but the environments built atop them may have them; does Glade, for GNOME (and, it indicates, raw GTK+), or Kdevelop, for KDE, provide enough of that sort of functionality for you? (Kdevelop has a dialog editor, at least, and Glade also appears to have a way of visually constructing the GUI.)

A comprehensive webpage on GUI toolkits

[Andy Tai]

This may be of use to people interested in GUI toolkits, a web page showing virtually all alternatives to Motif, including gtk+ and Qt:

The GUI Toolkit, Framework Page at http://www.atai.org/guitool/

Re:CDE is a solid std

[SoftwareJanitor]

Maybe Linux users don't use it because (Gasp!) it's commercial?

Not only that but it is fairly expensive. CDE costs more than the boxed commercial version of Red Hat, and the cheapest Motif development distribution costs almost twice what the boxed version of RedHat does.

Commercial software can make some penetration in the Linux world, but if it wants to compete, it needs to be better than the free alternatives and priced reasonably relative to what it is. Currently none of the CDE or Motif packages do that, so the only Linux users who buy them are people who absolutely need them (either as a checklist item or for compatibility with commercial *nixes).

BeOS...

[adamsc]

As for head-bashing, I agree that Motif & gtk are both wacky to program for, but what graphical API isn't? Have you ever heard anybody say that they *love* this toolkit or that one?

I've heard people say this about the BeOS API, which is actually pretty nice. Generally things just work the way you'd expect. I'm not entirely sure why, but it also feels like a more "comfortable" GUI than any of the X stuff.

It's like comparing Apples to Oranges...

[tepp]

I think the author of that column missed the point. Motif on top of commercial un*x implementations never intended to compete with Microsoft's Windows NT/9x. It was instead a robust high-computing server, designed to handle applications which require the heavy artillery (number crunching, file processing, memory usage) which your average PC cannot provide, while still being cheaper and more adaptable than your average mainframe.

This is why commercial Un*x was invented. This is why commercial Un*x OS's, whether they be Ultrix or Irix or Solaris, are still sold at incredibly high rates. There never was a "plan" to replace your average secretary's cpu with a Un*x box running Motif - it's similar to replacing a child's machine with a CRAY.

So there isn't much "new" and "modern" work done on Motif. So what? Motif is a stable platform. It will continue to be used over KDE in it's intended environment - the heavy-duty commercial applications world.

Folks, I'm talking engineering here. I'm talking about the machines which generate special effects for the entertainment biz. I'm talking about the machines run millions of calculations and checks on DNA while trying to crack the genetic code. I'm talking about the machines which monitor the safety conditions in a factory, making sure the bio-hazards remain safe. Do you *really* want these applications to run on top of KDE - a still in development, still unstable, still buggy environment? Would you trust your life on KDE? Or somebody else's?

Most of us love Linux and some of us love KDE. We're willing to forgive it's "growing pains" for the greater good, overlook the occasional crashed kernel and the odd core dump. But what if that machine was mission critical? Would you really suggest Linux and KDE for the job?

I'm all for KDE and I'm all for Linux, but let's call a spade a spade and stop bashing Motif for not being Windows 98. Because frankly, I wouldn't trust my life on Windows 98. And I would trust my life on Motif.

Qt vs. Motif and GPL.

[Svartalf]

One should note the following before making comments about the Motif/GPL/LGPL situations...

Motif is a system library (as in, it comes with it and you can't not have it!) and is covered under the "native system library" clause of the GPL and LGPL. It's completely legit to have a GPLed application or library and use Motif in those environs.

LessTif works for almost every one of the apps that fall under this situation under Linux.

I'm afraid that there is no equivalent for Qt for any GPL software (it has neither system lib status or clones...) at this point in time.

Re:Qt vs. Motif and GPL.

[grrussel]

Motif is never a system library on Linux - yet I
see static linked binaries aka GPL violations

These apps have also predated LessTif, and what of
those which code to Motif 2.1 not 1.0 or 1.2?

Qt is a system library on Corel, Caldera and SuSE
linux. Its even used in the Graphical installers
i.e. in YaST 2 and Lizard, and in the default, nay
only GUI environment supplied (in Caldera \ Corel)

The linking of Qt + GPL'ed code does not break GPL
as Qt cannot be considered a derived work merely
by linking to it - its a flawed GPL interpretation
brought on by the GPLs vagueness on linking
In short, hypocrite's, with political views about
software freedom to peddle.

Lynx isn't rendering /. too well, this'll be an ugly poorly formatted comment.

OT: themes.org format

[Quinn]

Has anyone else stopped going to themes.org since they switched to that new format a few months back? The preferences don't appear to work, and it's hell to browse themes. Before, I'd download new themes from wm.themes.org every other day; now I can't stand wading through the glitz.

--

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

Re:Why are we arguing about this anyway?

[Graymalkin]

The kernel is Mach-ish as in based on the 2.5 Mach kernel with some modifications. The BSD comes in where they added BSD API calls to the kernel so you could write and run BSD apps on the Darwin kernel.

Re:GTK: A School project gone terribly wrong

[Jamie Zawinski]

No X gui which shuns Xt is an acceptable X gui.

Period. I want my X resources, my command line parsing, and a standard framework of gui mechanisms.

I totally agree with this.

For what it's worth, I have a kludge for making use of Xrm with GTK, but it's pretty fragile. Had GTK been built on top of Xt, then all the usual resource mechanisms would have worked automatically, and one would have been able to reuse the enormous body of Xt-aware code that is out there already. Among other things it would have been a lot easier to port Motif apps to GTK than it is today, because most of the implementation of any Motif or Athena application really consists of Xt calls.

If you want to see my evil kludge for using Xrm resources and command-line processing (but not Xt Widgets) from inside a GTK program, have a look at main() in driver/demo-Gtk.c in the xscreensaver distribution.

Re:GTK: A School project gone terribly wrong

[Guy Harris]

I want my X resources, my command line parsing, and a standard framework of gui mechanisms.

And I've managed to live without those being available in every application, so the failure to use Xt in no way makes a GUI unacceptable to me. Period.

(The bulk of the stuff in my .Xdefaults file is cruft to batter various applications into giving me the colors, key bindings, fonts, etc. that I want, rather than, say, the key bindings that the developers of Netscape Navigator wanted. The GTK+ and Qt-based applications I've used somehow seem, by and large, to give me what I want, without having to fill up a configuration file with stuff.)

Re:CDE and Motif are still the best.

[Guy Harris]

Newer versions, by the way, are improved, so if you only have experience with, say, 1.2, don't judge newer versions based on this.

To which newer versions are you referring? Later 1.2[.x] releases, or 2.x? If 2.x, which commercial UNIXes ship with 2.x?

I'll sign

[acb]

Aye to that... For a long time, XView was my favourite GUI toolkit. It's the only one which can be programmed in C without line upon line of function calls and huge structs with pointers to functions. Not to mention that the UI looked much better than anything else on UNIX/X; it looked as if they actually had some professional designers do it.

Btw, has anyone appropriated the OPEN LOOK look and feel for Gtk or Qt?

The magic number 7+/-2

[acb]

In the late 1950s, psychologies found that the human brain can only keep about 7 "things" in mind at any one time. This varies depending on various factors, but not by much. It was because of this that telephone numbers, for example, were designed to have seven digits.

The definition of "things", of course, depends on which level you're looking at. If you've got a highly complex system, with dozens of elements, it will be impossible to understand it all at once, unless the elements are subsumed into some sort of hierarchical structure.

Xt and Motif's fatal flaw is that it violates this, failing to provide enough abstraction to allow the programmer to easily get their head around it. As such, Xt/Motif programmers are forced to flip through reference books. (Think of the Xt/Motif API/model as the cognitive equivalent of a horribly bloated program, far too large to fit in memory, and not designed well enough to minimise swapping.)

LGPL is important for the GUI toolkit

[jetson123]

Let's assume that the QPL is actually like the GPL with an option to pay to get out of it for commercial applications (I think that interpretation is incorrect, but that's a different discussion). I still think that's a bad license for a major Linux GUI toolkit.

For some libraries, GPL is fine. But a GUI toolkit is a core piece of functionality for an operating system. I believe it is good to get as many commercial vendors to use a single standard GUI toolkit. And this is really no different from the Linux kernel itself: I can write commercial software running under the Linux kernel without going open source. LGPL best encourages that kind of use.

I think Qt isn't a good choice as a major Linux toolkit: as a GPL'ed system, I think its license is too restrictive to allow universal use, and as a for-pay commercial toolkit, I think it's too expensive compared to commercial alternatives. And the QPL and Troll Tech's statements about it always leave a lingering doubt about licensing issues for both free and commercial software development. Qt is technically not bad, but to me, it isn't so much better than the alternatives to warrant living with that kind of hassle.

Netscape == Mozilla

[josepha48]

Sorry, but when I refered to netscape I was referring to Mozilla as Mozilla is the OS version of Netscape. Yes it is true that Netscape use Motif, but Mozilla does use gtk, and Mozilla is slotted to be Netscape 5.0 so Netscape == Mozilla...

send flames > /dev/null

Re:CDE and Motif are still the best.

[Guy Harris]

It is important to remember that CDE/Motif 2.1 is a large improvement over 1.2

E.g., it finally has widgets from which you can construct a tree view or a multi-column list (as one of the developers of Ethereal, my interest in toolkits that don't come with tree-view or multi-column list support is somewhat limited - yeah, there are probably alternative tree-view or multi-column list widgets out there, but having to supply it and have people have to compile it is a bit of a pain).

and that's why it was developed

Yeah, most new versions of products aren't specifically intended to be worse than their predecessors (although some products have been known to be improvements on their successors...)

--so if you're going to judge CDE/Motif, judge it by 2.1.

Except that if a lot of UNIX systems still ship with 1.2[.x], 2.1 isn't necessarily usable for many applications (unless you want to force people to upgrade in order to run your application, which you might be able to get away with for a commercial app, but I suspect you couldn't get people to do in order to run a free-software app).

By the way, do I risk an invasion from Hot Grits Man if I note that my copy of the OSF/Motif(TM) 2.0 Programmer's Guide has, right after the RESTRICTED RIGHTS NOTICE on the trademark and license page, a RESTRICTED TIGHTS[sic] LEGEND?

Yup!

[FreeUser]

Well said.

There's also this remarkable thing about open source libraries -- I can distribute them with my product! Add to that this remarkable technology called "shell scripting" and I can have a software bundle that will install and run coherently with no real dependencies on Sun (especially if I staticly link in the clib calls, as Sun does like to introduce irritating incompatabilities between hardware updates of the same version of Solaris).

But we have gone a step further ...

There's also this remarkable platform called Linux, which works wonderfully well and costs a minute fraction of what a Sun box does, for the same or even better performance, depending on the application and hardware platform.

Another remarkable product called FreeBSD works wonders as well. I'd be hard pressed to pick one over the other, and would pick both, hands down, over the proprietary alternatives.

It is cheaper to provide a complete hardware solution than to jump through Sun's hoops. And since it is in-house trading software, our only customers are the traders, who make us all millions trading on this system. Our developers are happy, our "customers" are happy, and I as a system/network administrator am happy.

Yeah, I guess my life is "dreamy" now. It's also extremely productive and well paid, allowing me to indulge in hobbies (like flying airplanes) I never would have dreamed of a few years ago, and providing the robustness and stability to give me the time to do so.

This is the kind of rewards one gets when one goes out on a limb a little and empowers oneself (and one's employer) by taking control of one's infrastructure and technology back from one's vendors.

Microsoft is an atrocity (technically and ethically) and we no longer jump through their hoops, let alone run their software

Sun is a Microsoft wannabe, and we no longer jump through their hoops either. We use their hardware platform only in as far as it pleases us, and routinely dump it for more cost effective alternatives (Dec Alpha running Linux, Power PC, Intel, depending on the application and its requirements). And no Sun box, not even their 64 processor monster, holds a candle to a well contstructed Linux Beowolf cluster. Sun's habit of keeping open source software (Linux in particular) at arms length has caused us to dump many of their software products, such as StarOffice (Applix is better and not being allowed to rot over time) and Java, which would have otherwise remained useful and continued to be used by us. Unfortunately for Sun, they have persued an idiotic strategy with respect to Open Source software, a strategy designed to benefit Sun at their customers' (i.e. our) expense. Of course we did someting about that, by dumping the aforementioned products, with prejudice.

The same goes for the so-called Open Software Foundation (which is hardly open) and MOTIF, which we had dumped long before dumping most of Sun itself.

The net result? More productivity, vastly more uptime and reliability, more wealth, and more time to spend it doing fun stuff.

Re:CDE and Motif are still the best.

[Guy Harris]

Yeah, right. You can't get people to do that for free software? One of the major problems with the free software out there is that it mainly uses a huge variety of these crap toolkits. Every time I download a piece of software it seems I have to install three new libraries... Qt... Gtk... Glib... Allegro... So many damned toolkits! You're telling me people won't upgrade/install for free software?

I'm telling you people won't necessarily buy CDE 2.1 for their pre-2.1 system in order to build a piece of free software.

It is safe to write software for 2.1.

Even if I want it to work on, say, Solaris 2.5.1, Solaris 2.6, and Solaris 7, none of which come bundled with CDE 2.1?