Death of CDE & Motif? 432
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?
Applix 5.0 uses GTK (Score:3)
! Szo
CDE and Motif died in 1998 (Score:5)
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 (Score:3)
--
Java banners:
Bad for users because Java kills Netscape
What it needs (Score:2)
Nooooooooo way (Score:4)
As fast as the tech market moves, I think one thing that linux has shown me, (through the long series of such-and-such company adopting linux, and so on) is that companies are sure good at dragging ass when they want to.
And they've got a lot of motivation to. Proclaiming the end of CDE and Motif and so on is not something that Triteal wants to hear.
One of the things that I've noticed about linux and GNU software seemingly "pushing things out of the way" is that generally, it happens in a spot where a company isn't *too* afraid of giving ground.
HP/UX, Solaris, and all those other UNIXen are still extremely entrenched in corporations. Just because linux does exist in companies, and just because people do use it, doesn't mean that people can go around proclaiminig "ding dong the witch is dead" spouting out that such and such extremely popular software package for UNIX is on the way out because of some free software replacement. Even for packages that are non-free, it takes a long time to get mindshare and get people using the software, and it can take just as long to get them out of it. That QT and GTK+ are making inroads is interesting, but that's quite different from seriously threatening the EXISTANCE of an alternative.
Also, linux is moving into some of the spots where otherwise solaris or HP/UX might be used. But do HP and Sun *really* care if they don't sell copies of Solaris and HP/UX? Sure, that's revenue that they're losing but at the same time, they make their money selling HARDWARE not software. So it's really not that much of a tragedy if some of their software gets pushed a bit to the side.
But with CDE, you're going up against pure software companies that have all of their revenue to lose if they let themselves be pushed to the side, and because of that, I'm betting that they'll "fight harder"
I'm skeptical...
Lacking "features" (Score:3)
Well, for one, both QT and GTK lack the butt-ugliness of Motif. Secondly, they lack the quality that they're not as akin to bashing your head against the wall when programming with them. Thirdly, they're not archaic. That's about all I can think of..
-- Does Rain Man use the Autistic License for his software?
I've programmed in Motif and CDE... (Score:3)
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 (Score:2)
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.... (Score:2)
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.
yes probably.. well maybe (Score:4)
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? (Score:3)
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:GTK + GNOME + Linux == GOD (Score:2)
>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... (Score:5)
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:Lacking "features" (Score:2)
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.
They are good but... (Score:2)
Sadly, your wrong (Score:3)
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 (Score:4)
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 (Score:5)
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
GTK suffers a bit from not-invented-here syndrome, and ignores existing standards like
Finally, what's the status of i18n for GTK? Does it exist?
Jon Christopher
LessTif Releasemeister
Get a real toolkit (Score:2)
--== www.fltk.org [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...
Missed the point (Score:3)
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? (Score:4)
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.
O'Reilly books (Score:3)
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:Fill me in (Score:2)
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.
--
Re:Lacking "features" (Score:2)
LessTif status report (Score:4)
Also, even though binary compatibility isn't a main goal of the LessTif project, some apps (including Netscape 4.5+) which are dynamically linked with OSF/Motif will also run when linked against LessTif. Getting this far is a tremendous accomplishment of the LessTif programming team (I'm on the core team, but I don't do much of the programming, as I mostly coordinate the releases.)
Jon Christopher
LessTif Releasemeister
In our case, yes. (Score:5)
Our reasons for switching away from Motif and other closed-source, proprietary libraries and development tools include:
The list goes on and on, but you get the idea.
Java PLAF (Score:2)
Jazilla.org - the Java Mozilla [sourceforge.net]
Motif "ugly" while GTK "beautiful"?? (Score:5)
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 B [jwz.org]
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:Compatibility tool? (Score:2)
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.
Sund. Explns. (Score:3)
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.
X resources (just ranting against GTK) (Score:3)
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?
Dead Stuff & OpenWindows (Score:2)
Anybody want to help set up the petition?
QT has good docs too (Score:2)
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
Re:Lacking "features" (Score:2)
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:Motif "ugly" while GTK "beautiful"?? (Score:2)
Commercial Engineering Apps (Score:3)
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 (Score:5)
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:What it needs (Score:2)
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.
qt... (Score:2)
Re:Motif? (Score:3)
Please explain what the GTK event model can do that the Xt event model cannot. I think they are the same.
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.
Um, now which exhibit was which? (Score:2)
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 [linuxbox.com] theme and get something looking more like this fileselector [linuxbox.com] or this scrolled window. [linuxbox.com]
Other looks may be found at gtk.themes.org. [themes.org]
Speed (Score:2)
Re:Ummm.... (Score:2)
Re:Commercial GTK? (Score:2)
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:Lacking "features" (Score:2)
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.
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.
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?
Re:CDE is a solid std (Score:2)
to it - the reason was, usually, that CDE was the standard to which the corporation
had to adhere. However, the inception of KDE [kde.org] (and GNOME [gnome.org]) 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 [mosfet.org] going on with KDE2 such as the
Neural network window placement policy [iie.cnam.fr] 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 (Score:2)
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...).
Re:Um, now which exhibit was which? (Score:3)
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.
Re:One thing that Motif was getting right... (Score:2)
Netscape vs. Mozilla, and Mozilla gripes (Score:2)
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 (Score:2)
Hiding CDE launch bar? (Score:2)
Re:One thing that Motif was getting right... (Score:3)
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 [troll.no] (probably for 2.0). There may be additional KDE APIs atop that; try plowing through the KDE developer's site [kde.org].
Here's the GTK+ reference documentation section on DnD APIs [gnome.org]; again, there may be additional GNOME APIs atop it - if you plow through the GNOME developer's site [gnome.org], you may find something.
"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:Sund. Explns. (Score:3)
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:
Re:Xt is not the problem (Score:4)
Some of the things that are broken under Xt:
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:Lacking features in GTK (Score:2)
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.
What both GTK+ and Qt are missing (Score:2)
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 (Score:2)
Re:Motif "ugly" while GTK "beautiful"?? (Score:2)
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:O'Reilly books (Score:2)
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:Nooooooooo way (Score:2)
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?
Themes (Score:2)
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:Sund. Explns. (Score:2)
Re:Bizarre Motif! (Score:2)
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) (Score:3)
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 ... (Score:2)
Qt and GTK+ may lack them, but the environments built atop them may have them; does Glade [pn.org], for GNOME (and, it indicates, raw GTK+), or Kdevelop [kdevelop.org], 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 (Score:2)
The GUI Toolkit, Framework Page [atai.org] at http://www.atai.org/guitool/
Re:Xt is not the problem (Score:2)
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:LessTif status report (Score:2)
Cheers
-jwb
Re:Themes (Score:2)
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:CDE is a solid std (Score:2)
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).
Re:Get a real toolkit (Score:2)
- 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.
BeOS... (Score:2)
Re:Sund. Explns. (Score:2)
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.
Re:X resources (just ranting against GTK) (Score:2)
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 :)
It's like comparing Apples to Oranges... (Score:2)
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.
Re:One thing that Motif was getting right... (Score:2)
And Motif? It does support the Xdnd protocol that GTK+ (and the toolkit/application framework that introduced Xdnd, JX [newplanetsoftware.com]) 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)?
Qt vs. Motif and GPL. (Score:2)
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:Motif "ugly" while GTK "beautiful"?? (Score:2)
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 [themes.org]
Exhibit D [themes.org]
--
Re:Themes (Score:2)
--The knowledge that you are an idiot, is what distinguishes you from one.
OT: themes.org format (Score:2)
--
Re:Motif "ugly" while GTK "beautiful"?? (Score:2)
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.
Re:X resources (just ranting against GTK) (Score:2)
If you'd like to have some fun with the X resources, download UDE [ude.org] 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
Ever notice . .
Microsoft and its allies assume everyone is stupid.
Why are we arguing about this anyway? (Score:3)
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:Lacking features in GTK (Score:3)
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:Nooooooooo way (Score:2)
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:GTK: A School project gone terribly wrong (Score:2)
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 [jwz.org] distribution.
Re:Xt is not the problem (Score:3)
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 (Score:2)
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.
That's a nice sound bite, but it's so vague that it doesn't actually tell me anything. Please be specific.
Re:Nooooooooo way (Score:2)
Re:Lacking features in GTK (Score:2)
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:In our case, yes. (Score:2)
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.
Re:X resources (just ranting against GTK) (Score:2)
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:Why are we arguing about this anyway? (Score:2)
Re:Xt is not the problem (Score:2)
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:
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 (Score:2)
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:Lacking features in GTK (Score:3)
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.
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.
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
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).
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:X resources (just ranting against GTK) (Score:3)
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:
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) (Score:3)
Nonsense.
GNOME could have dictated, as a matter of policy:
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 [jwz.org] 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.
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.
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.
That very API could be easily implemented on top of the traditional X resource manager.
Re:X resources (just ranting against GTK) (Score:3)
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:
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.