Slashdot Mirror


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?

6 of 432 comments (clear)

  1. CDE and Motif died in 1998 by crow · · Score: 5

    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.

  2. One thing that Motif was getting right... by ptomblin · · Score: 5

    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.

    --
    The next Cmdr Taco duplicate will be ready soon, but subscribers can beat the rush and see it early!
  3. Lacking features in GTK by ABadDog · · Score: 5

    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

  4. In our case, yes. by FreeUser · · Score: 5
    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.
    --
    The Future of Human Evolution: Autonomy
  5. Motif "ugly" while GTK "beautiful"?? by Jamie+Zawinski · · Score: 5

    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:

    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.

  6. Xt is not the problem by Jamie+Zawinski · · Score: 5
    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.