Huh. I was tempted to dismiss this as a thin skin/theme, but if they've recreated the panel and control panel, maybe it is a thorough clone. The real™ CDE is still alive and works (and open source), but I'll admit something a little less dated is probably easier to work with. Part of the appeal of CDE to me is that it actually had a unified design; in particular, every window had a help menu on the right side with good, contextual, help available. Unfortunately, in the modern world most applications aren't written like that, so just having CDE or a clone doesn't get you that same experience. And yes, you could use a modern DE and associated apps, but they all seem so shallow to me in comparison to CDE's level of thoughtful design and accessibility (it was beginner friendly in an era where that could mean "this is the first computer the user has ever touched").
That's a good point. There used to be built-in help for almost every thing in CDE. That's how I learnt all about using it. It even had some ability to create GUIs using the Bourne Shell[1].
That's sweet:) A little like the premise of zenity, but skimming that manpage it looks far more powerful. Albeit, harder to use, since it's pretty much directly exposing raw(-ish?) X & motif APIs in ksh.
Then I failed to properly express myself, and I apologize. Having watched the YouTube playlist, NsCDE is indeed an extremely thorough clone that mostly matches the original and in many places exceeds it. In particular, it does appear to have globally-available help, which lacks the "click anything and get a description" mode but otherwise is a match for the original. They've even somewhat addressed a problem with running the original in 2020 by making it support even non-native applications (through QT+GTK theme support).
So yes, this is very impressive, and not at all the shallow skin that I initially expected.
I just want to point out that while the author apologizes for his poor English, the entire github README actually explains the motivation, history and high-level architecture very clearly. I wish more projects covered all those points on their landing pages.
I find it interesting how often I observe someone give a disclaimer about being bad at English, followed up with the clearest explanation / documentation / answer I've seen in a good month or so.
Possibly you have to be really good at a language to realise how "bad" you are. If you're poor at using a language you can't see your mistakes. As you become significantly better you can appreciate nuance, and such, and again feel inferior.
One of the things that impressed me greatly when I used CDE years after using more modern desktop environments was how easy it was to use everything without a mouse. Modern desktop environments do let you do everything without a mouse, but not use everything: many components are mouse-only, but equivalent functionality is available elsewhere for keyboard users. In CDE, the components themselves were keyboard accessible. Hope this follows the same design, may give it a try to find out.
I remember being a bit of a Unix fanboy in the early 2000s and I had seen some program on EuroNews showing NASA computers running CDE or some sort of Motif based DE.
So of course I wanted to try it. And I actually used OpenMotif for a few weeks until I switched back to Blackbox or Openbox, whatever I was using at the time.
Fun times, switching distros every month and trying new things in the Linux ecosystem.
But in practice, today, I wouldn't part with my vanilla Gnome setup on Fedora for anything.
Admittelly I'm much younger than you, but I also tried few distros, desktop environments (even tried BSD) when I started out, only to settle on Arch/i3 combo. And now it would require a lot of energy for me to make a move.
Same here. A year ago I got myself a X230 as a second laptop, and installed OpenBSD to it, testing NsCDE and the original CDE only to settle down to another installation of i3. It's a great laptop and OpenBSD is perfect for my use. I cannot live without i3 or sway though...
I distinctly remember using CDE back in 2005 on a Sun Ray 2 Thin Terminals. It was serviceable however I must confess I had a hard time getting used to it, especially after using Gnome 2 and KDE 3.
The one great thing about them was that you could use a chip and pin style card. If you used this card when logging in it would associate your session with the chip and pin card and when you logged into another client (by using the card) your exisiting session was moved across. Which I thought was pretty novel at the time.
When I have time I might give this a try out (for nothing other than nostalgia reasons).
I did the same with a Sun Blade 150 (gave it to a friend). They are pretty expensive to pick up now. Solaris 8 (maybe 9) was on there and I think I ended up running on of the BSDs on there. The machine wasn't fast (not compared to an Athlon XP 2500+) but it was a nice unique unix workstation that ran solidly.
Earlier versions of xfce (3.x?) had a distinctive CDE inspired look and feel. Having become used to CDE from using it on HP-UX at a summer job, I used xfce on my Linux machine at home for several years. It was a decent UI for the time, though the bar at the bottom used quite a lot of screen real estate on the 15" (?) CRT I had at the time.
I have a lot of nostalgia for CDE. In 1994, my first job as a teenager was to install Sun Sparc 5 workstations at a pager technology company. The more expensive workstations had color displays. As a humble DOS kid, the idea that employees got to play with CDE on a high resolution color display was almost too much to bear.
'Noughties', rather, from the word 'nought'. I don't think it caught on because 'nought' is a bit old-fashioned; more common to hear 'zero' these days.
Fvwm is so nice, it's possible to customize everything from Color scheme to Mouse/Window behaviour. In Fvwm terms this is still mostly a theme, but given the flexibility themes can be very complex...
fvwm is like the pinnacle for obsessive configuration. I spent a couple hours over a weekend setting it up and thought it was really neat. The man pages and official website are very thorough, but I found this guide the most helpful getting started:
I think the real question is how well it handles highDPI displays.
Personally I just buy cheap refurbished thinkpads so it’s not a problem I have but that’s been one of the main reasons other people I know don’t run FVWM.
I used fvwm-crystal for years but am using the Unity Desktop Environment at the moment. Now I'm getting all nostalgic and thinking it's time to change to this.
>X will not run in these 4 bit overlay planes. This is because I’m using Motif, which is so sophisticated it forces you to put a 1" thick border around each window in case your mouse is so worthless you can’t hit anything you aim at, so you need widgets designed from the same style manual as the runway at Moscow International Airport. My program has a browser that actually uses different colors to distinguish different kinds of nodes. Unlike a PC Jr, however, this workstation with $150,000 worth of 28 bits-per-pixel supercharged display hardware cannot display more than 16 colors at a time. If you’re using the Motif self-abuse kit, asking for the 17th color causes your program to crash horribly.
>So, thinks I to myself cleverly, I shall run X windows on the graphics plane. This means X will not use the overlay planes, which have special hardware for cursors. This also means I cannot use the super cool 3D graphics hardware either, because in order to draw a cube, I would have to “steal” the frame buffer from X, which is surly and uncooperative about that sort of thing.
>What it does give me, however, is a unique pleasure. The overlay plane is used for /dev/console, which means all console messages get printed in 10 Point Troglodyte Bold, superimposed in white over whatever else is on my screen, like for example, a demo that I may be happen to be giving at the time. Every time anyone in the lab prints to the printer attached to my machine, or NFS wets its pants with a timeout, or some file server threatens to go down in only 3 hours for scheduled maintenance, another message goes onto my screen like a court reporter with Turett’s syndrome.
>The usual X commands for refreshing the screen are helpless to remove this incontinence, because X has no access to the overlay planes. I had to write a program in C to be invoked from some xterm window that does nothing but wipes up after the mess on the overlay planes.
>My super 3D graphics, then, runs only on /dev/crt1, and X windows runs only on /dev/crt0. Of course, this means I cannot move my mouse over to the 3d graphics display, but as the HP technical support person said “Why would you ever need to point to something that you’ve drawn in 3D?”
>Of course, HP claims X has a mode which allows you to run X in the overlay planes and “see through” to the graphics planes underneath. But of course, after 3 months of calls to HP technical support, we agreed that that doesn’t actually work with my particular hardware configuration. You see, I have the top-of-the-line Turbo SRX model (not one, but two on a single workstation!), and they’ve only tested it on the simpler, less advanced configurations. When you’ve got a hip, forward-thinking software innovator like Hewlett-Packard, they think running X windows release 2 is pretty advanced.
The UI is globally configurable via .Xdefaults. This lets you do things like add scroll wheel support to 30 year old Athena apps that never envisioned such magic. Motif respects it too.
What do you type into .Xdefaults to enable pie menus in Motif? Surely after 30 years that would be easy, no?
It could and should have been done more than three decades ago. The criticisms I made of the X Toolkit in 1987 (33 years ago) after attending the first X-Windows conference at MIT still apply. But as it turned out, we ended up with web browsers and web servers using exactly the same extensible architecture I was advocating (now called "AJAX"), leaving X-Windows and Motif in the dustbin of history.
On February 23, 1987, Don Hopkins wrote on xpert@athena:
>I see just the same problem with XToolKit. I would like to see the
ToolKit as a client that you would normally run on the same machine as
the server, for speed. Interactive widgets would be much more
interactive, you wouldn't have to have a copy of the whole library in
every client, and there would be just one client to configure. The big
question is how do your clients communicate with it? Are the
facilities in X11 sufficient? Or would it be a good idea to adopt some
other standard for communication between clients? At the X
conference, it was said that the X11 server should be used by clients
to rendezvous with each other, but not as a primary means of
communication. Why is that?
>Setting a standard on any kind of key or mouse bindings would be evil.
The window manager should be as transparent as possible. It solves
lots of problems for it to be able to send any event to the clients.
For example, how about function to quote an event that the window
manager would normally intercept, and send it on?
>Perhaps the window manager is the place to put the ToolKit?
> -Don
The people who wrote Xt, Athena, and Motif widgets and apps were not blind-sided by these issues, which are not "magic" or "rocket science". They just purposefully chose to dismiss and ignore them.
On September 19, 1989, Don Hopkins wrote on xpert@athena:
>I think it's a pretty good idea to have the window manager, or some
other process running close to the server, handle all the menus.
Window managment and menu managment are separate functions, but it
would be a real performance win for the window and the menu manager to
reside in the same process. There should be options to deactivate
either type of managment, so you could run, say, a motif window
manager, and an open look menu manager at the same time. But I think
that in most cases you'd want the uniform user interface, and the
better performance, that you'd get by having both in one process.
I think it would be possible to implement something like this with the
NDE window manager in X11/NeWS. It's written in object oriented
PostScript, based on the tNt toolkit, and runs as a light weight
processes inside the NeWS server. This way, selecting from a menu
that invokes a window managment function only involves one process
(the xnews server), instead of three (the x server and the two
"outboard" managers), with all the associated overhead of paging, ipc,
and context switching.
>Here's a message on a related subject that I sent to xpert a couple
years back (before I'd heard of the ICCCM). I never did get much
response, except that one person pointed out that that was precisely
the problem that NeWS was designed to solve. ;-)
>c(-; Once were done forging the menu manager standard, how about we
do text editors, huh?)
> -Don
On November 28, 1992, Don Hopkins wrote on xpert@athena:
>piewm - Pie Window Manager
>PieWM is a window manager for the X window system that supports pie
menus, and is based on the "tvtwm" virtual window manger. The labels
of a pie menu are arranged in a circle around the cursor, and the pie
menu selection is based on the direction of cursor motion between
button clicks.
>Pie menus are fast and reliable because of Fitt's Law: each of the
items corresponds to a large slice shaped target area adjacent to the
cursor, but in a different direction. They are fast because you
don't have to move the cursor far, and the target areas are large.
They are reliable because the further away from the menu center you
move the cursor, the finer control you have over the selection.
Because the selection is based on angle, you can "mouse ahead" quickly
and reliably without looking at the screen, and the pie menus don't
even pop up if you're fast enough.
>For many tasks, pie menus are significantly faster and have lower
error rates than linear menus. PieWM integrates pie and linear
menus so you can use them interchangeably, with top level and submenus
of either type, as appropriate.
>In addition to user definable pie menus, "piewm" supports all the
features of "tvtwm" including the virtual scrolling desktop, title
bars, shaped windows, linear menus, several forms of icon management,
user defined macro functions, click-to-type and pointer-driven
keyboard focus, and user specified key and pointer button bindings.
It also features graphical pie menu labels, and comes with a default
set of window management pie menus, designed to support an efficient
gestural style of interaction. However, the pie menu windows aren't
circular, just rectangular.
>For more information about pie menus, read "The Design and
Implementation of Pie Menus," by Don Hopkins, Dr. Dobb's Journal,
Dec. 1991 user interface issue, and "A Comparative Analysis of Pie
Menu Performance," by Jack Callahan, Don Hopkins, Mark Weiser, and Ben
Shneiderman, Proc. CHI'88 conference, Washington D.C.
>PieWM is available for anonymous ftp on
</ftp.uu.net:tmp/piewm.tar.Z> and
</bongo.garnet.cs.cmu.edu:pub/piewm.tar.Z>
The first computer I got to use on a regular basis was an HP-UX 9 running CDE. No one cared about security back then. You could create a setuid copy of /bin/sh (don't remember if bash and ksh were around), chown to root, and get yourself root in a few seconds. Those were fun days. I don't think I would call it "modern" by sense of the term.
One thing CDE did well was remind you of your multiple desktops. Gnome tends to hide this fact. The downside of CDE was that the dock took up real estate. I was a CDE user for several years, and an Xt/Motif programmer in various jobs.
> Nothing important from CDE is included. None of the technology ideas.
When I used it, the most important thing about CDE was that it was a consistent unified desktop environment with very clear and consistent human interface guidelines and extremely good built-in help. Under the hood things that you refer to may well have been great in their own ways, but from the user's perspective they're just implementation details. NsCDE uses different technology but successfully implements the same design principles.
Here are some classic messages about UIL. Avoid it like the plague.
-Don
To: xpert@expo.lcs.mit.edu
Cc: Erik Hardy <e...@sei.cmu.edu>
Subject: Re: To UIL or not to UIL?
From: Niels P. Mayer <mayer%...@hplabs.hpl.hp.com>
In article <?@?> mi...@portia.Stanford.EDU (Michael Yang) writes:
> In article <5...@tci.bell-atl.com> ke...@tci.bell-atl.com (Cory Kempf) writes:
> >I need to build an application that uses X/motif. What I need to
> >decide is if we should use UIL or not. Or maybe WINTERP? Are there
> >any strong oppinions out there one way or another?
> One advantage of using UIL, is that it's portable and is part of Motif
> from OSF (though for some reason, HP's "Motif" release doesn't include
> it).
I don't work for the product division responsible for HP's X products, and
I don't claim to speak for them. However, the rumor I heard is that UIL
wasn't included in HP's product because "it didn't meet HP's quality
standards for a supported software product." This is only a rumor, talk to
someone in charge for the official poop.
The unofficial poop, which is my personal opinion (and reflects the
opinions of others older, more experienced, and more learned than I) is
that UIL SUCKS. The idea itself is somewhat silly, the implementation is
buggy; and it is an inelegant solution to application customization.
Finally, UIL doesn't make life as an application programmer any easier --
It requires that you learn yet another programming language that is
completely nonstandard, UIL, alongside a number of Motif resource manager
calls. You have to master all that while trying to understand the
interactions of the large number of features in the Motif toolkit. The
recent questions we've seen on this group about getting back the widgetID
for a widget created in UIL is a good example of the kinds of cruft that
you can expect when doing any sort of serious programming with UIL. And I
wouldn't expect to see any example-laden books like Doug Young's excellent
Xt/Motif text for UIL application programming in the near future.
In sum, if I didn't have WINTERP around, I would prefer to program in
straight C rather than use UIL.
It still escapes me why UIL was ever built the way it is. The Motif widgets
are essentially "interpretive" in that you can give programmatic commands
to the Motif library to create new widgets, and the Xt intrinsics will
create the new widget on-the-fly. You can also send messages to created
widget objects via the "methods" in the Xt intrinsics, and especially via
XtSetValues() -- these changes are also interpreted by the intrinsics and
result in an eventual updating of the visuals associated with the widget.
The only thing that is "compiled" about widgets is the order that they
appear inside their "manager" and that ultimately depends on the
implementation of the manager widget.
UIL is thus a compiler for an interpreter. UIL compiles a widget layout
(specified in a UIL text file) into a UID (user interface definition) file.
A UIL-based application then uses the built in Motif resource manager to
read in the compiled description of the layout in order to produce a user
interface. UIL then makes the claim that this can be used to drastically
alter the look of an application independent of the program's semantics
(e.g. what the CHI community would call a "UIMS"). I seriously wonder how
drastic an alteration is possible without providing deeper hooks into the
semantics of the application itself. Alas, UIL is not a programming
language, so that is impossible.
Imagine, for example, what would be required to turn a "pushbutton-based"
application, such as the X11r3 xmh into a Mac-style "pulldown-menu based"
application? How are you going to describe the semantics of the way the
current-selected message in the browser interacts with the current-selected
folder (selected via pulldown menu or dialog box) and the actions
move/copy/delete (also selected via menu)? Are you really going to be able
to describe both styles of interface with UIL?? Or are you going to have to
provide two different styles of hooks in the application itself -- one UI
hook for the pushbutton-based UIL interface, and another for a menu-based
UIL interface. If you have to enumerate and hard-code every conceivable
dialogue style in the application, is UIL really a useful UIMS??
No, really all that UIL gives you is an extension of the old "Xdefaults"
scheme of customizing an application. Yes, UIL's syntax makes it clearer
which Xdefault resources will affect which widgets. Yes, UIL does allow you
to specify the widget hierarchy and callbacks in an interface. However,
customizing a UIL application will continue to be as tedious, if not more
tedious than it is to currently customize an application via resource
settings. The current state of X applications is that you set X resources
(via editing .Xdefaults or twiddling with xrdb) and then run an appliction
to "interpret" the resource settings. If things don't turn out right, you
quit the application, edit your resourcre file again, and rerun the
application. Anybody that has tried this knows it is tedious, especially if
the application does alot of startup processing. UIL gives you the same
tedium, with an additional compilation step thrown in. Sounds like a great
idea, no?
And to make things worse, it is quite difficult to extend UIL to handle new
widgets. While the Motif toolkit does provide a broad coverage of UI needs,
serious applications may end up using at least one new widget not contained
in the existing Motif widget set....
--------
WINTERP attempts to solve some of the problems that UIL claims to solve,
but it takes a completely different tack. WINTERP gives you access to the
"interpretive" nature of the Motif widgets through its built in mini-lisp
interpreter (XLISP). The lisp interpreter and the interactive interface to
widgets are useful both in prototyping an application, as well as allowing
an end-user to customize a delivered application.
For prototyping, WINTERP allows you to incremetally build up a user
interface, piece by piece. It also means that you can "play" with the
interface, modifying both the look and feel of the application
interactively. WINTERP even includes a "direct manipulation" primitive that
allows you to change widget resources, callbacks and eventhandlers by
designating a widget with the mouse. With WINTERP, one need not suffer the
tedium required in rerunning or recompiling the application in order to
make a change to a UIL or X resource -- incremental changes to an
application can be tested interactively.
Unkike UIL, WINTERP's widget-description language is based on a REAL
PROGRAMMING LANGUAGE, which enables you to use the language to represent
and manipulate the state of the application and the UI. UIL is not a
programming language, so you can only describe a widget layout, only mock
up prototype a static interface; you have to go through alot of trouble in
order to link up the functionality of your application with the dynamic
dialog-style of display that makes up a real application. WINTERP, on the
other hand, will allow you to prototype the dynamics of the interface. In
fact, WINTERP makes an excellent applications prototyping environment
because you can use an interactive, high-level programing language to build
the user interface AND also prototype the "dialogue" aspects of the working
application.
For customizing a delivered application, WINTERP's language interpreter
allows users to interactively modify the interface and customize
application functionality. WINTERP-based applications that are designed
for customizability will contain C-implemented lisp primitives to
accomplish core functionality which the customizer can "tie together" via
interpreted lisp. Applications might come with a set of predefined
interface libraries that enable different interface styles, such as the
pulldown- versus button-based style mentioned above. Users may use
"programming by example" to mix and match features and functionality
available in example interface profiles in order to come up with an
application better tailored to their needs. Often repeated commands can be
included in new menu or pushbutton entries, and commands themselves can be
modified to suit the user's needs.
WINTERP helps promote an "open", tailorable architecture for applications
because designers recognize that they cannot foresee all the possible needs
of the end-user. Applications like gnuemacs and autocad have shown that
such architectures are very poweful indeed. In addition to being "open" to
the application customizer, WINTERP is also "open" to other applications
because WINTERP's lisp interpreter is a SERVER (using TCP sockets). Other
applications, possibly running non-locally, can send lisp commands to a
WINTERP-based application in order to execute functionality internal to the
application. Such an architecture allows applications to talk to each
other, share data, etc. You might think of such functionality as
"client-side NeWS without the postscript imaging model"....
The choice of Lisp as the widget layout and prototyping language in WINTERP
provides numerous advantages. Lisp programs are in the same form as lisp
data. That means that lisp programs can easily perform computations to
create/alter data structures representing lisp programs. This sort of
meta-programming is especially useful in WINTERP because a user interface
description in winterp-lisp can be treated both as data as well as a
programmatic description of a user interface. That means you can use
winterp-lisp to create all sorts of dynamic widget layouts through lisp
computations that create and mutate data strucures representing
user-interfaces. We are using this feature in our groupware toolkit to
allow active user interfaces (akin to "forms") to be created, filled out,
program-transformed, shipped around via e-mail, and then interpreted on the
receiver's workstation to pop up an active form.
--------------------
UIL could be useful however -- rather than being a "compiler for an
interpreter", UIL could become a real compiler that took a structured
description of an interface's widget hierarchy, the resources used, the
callbacks, eventhandlers, etc. All that information could then be compiled
into straight Xlib + C code that would be much more efficient in size and
server resource usage than the equivalent Motif/Xtoolkit calls. Kludges
such as "flattened widgets" and "gadgets" wouldn't be needed because the
compiler would be able to figure out which server resources, gc's, and
windows could be shared by widgets based on "type declarations" and
"constant declarations" gleaned from the UIL file.... (and then I woke up
from my dream).... this would obviously be one heck of a compiler
project...
--------------------
For more information on WINTERP, see the X11r4 contrib distribution --
contrib/clients/winterp/doc/winterp.doc and
contrib/clients/winterp/doc/winterp.doc. If you are planning on building
WINTERP from the X11r4 contrib tape distribution, you must apply the
patches posted to comp.windows.x/xpert on 1/8/90 (titled
"Patches to X11r4 contrib/clients/winterp (Motif application prototyper)".
Better yet, retrieve WINTERP via anonymous ftp from expo.lcs.mit.edu. In
directory oldcontrib, you will find the following:
-rw-rw-rw- 1 ftp 6252 Dec 19 08:57 winterp.README
-rw-rw-rw- 1 ftp 605837 Dec 19 08:57 winterp.tar.Z
In directory oldcontrib/winterp.binary, you'll find:
-rw-rw-rw- 1 ftp 808483 Dec 19 06:46 hpux-s800.tar.Z
-rw-rw-rw- 1 ftp 605899 Dec 19 06:43 hpux-s300.tar.Z
----------
Niels Mayer -- hplabs!mayer -- ma...@hplabs.hp.com
Human-Computer Interaction Department
Hewlett-Packard Laboratories
Palo Alto, CA.
*
At the end of his posting about UIL, WINTERP, and Lisp, Omar suggests an even Lispier alternative to WINTERP, that you:
"Use LISP entirely. Don't even bother with C, C++, Pascal, FORTRAN, or anything similar. Start with LISP. Develop everything in LISP. This seems to be the most intuitive alternative, but it requires a lot of work. And it's not entirely portable, at least not yet."
Yeah, a LOT of work. There is a big problem with rewriting X-Windows in Lisp, which I learned from working on Garnet with CMU Common Lisp and CLX.
The problem is that CLX (the Common Lisp X11 client library) doesn't support ANY of the standard XLib based libraries, or the client side libraries for X11 server extensions like Display PostScript.
And that problem has only gotten much worse over time as the X client libraries have gotten more and more bloated as they replicate and extend everything the X-Windows server does and much more.
So with CLX, which is the X-Windows protocol client side implemented in pure Lisp, you are stuck with the generic X wire protocol, no XLib based C libraries like Display PostScript (which seemed like a good idea at the time in 1992), not even the MIT-SHM the shared memory extension, no Xt, no Motif, no OLIT, no GTK, no KDE, no NOTHING! You're on your own, buddy.
You might as well just use Lisp's foreign function interface to wrap the entire MOTIF library and translate all the #defines in the .h files into Lisp code so you can refer to symbols and ids by name instead of hex numbers. And that's essentially what WINTERP did with XLisp, so you're back where you started ("client-side NeWS without the postscript imaging model", as Neils puts it).
I absolutely agree. I've only had 4 years of serious software
experience, and UIL is the worst language/compiler combination I
have ever seen. Nothing, not even working with punch cards, has left me
with a more bitter taste in my mouth. If UIL were a car, not even the
Russians would want to manufacture it. If UIL were a--but, wait a
minute, let's be objective for a minute:
* The UIL compiler does not invoke cpp before it starts its
journey. Yo, DEC!!! Even xrdb uses cpp. There are several
advantages to using cpp. Hey, guys, ever heard of macros? Huh?
What's that you say? You wanted to create your own macro
facility? Oh, I see, in the next version. When's that? Huh?
Next year? Oh. But what do we do in the meantime? Huh? Did
you say "copy and paste"? Isn't that kind of inelegant? I tried
that. It bloated the simplest UIL files to thousands of lines.
What? Yeah, thousands, not hundreds. Made them difficult to
edit. Huh? Split the files, you said? I dunno, that's kind of
old-fashioned, rather stupid. Say what? I can run the file
through cpp first? Yeah, I tried that, in fact, since I had no
intention of wading through huge UIL files; it gave me vertigo.
Huh? You want to know how that worked, you say? Well, I ran
into this problem, see. After I did a few nice macros and got
ready and all, I ran the UIL compiler. I got this strange error
message. It told me that maximum line length was 132 characters.
Huh? Well, see, some of my macros were rather long, like 140
characters, see, and I couldn't make them less than 132 short of
compressing all the whitespace out of the macro and turning it
into one huge token. Huh? You never thought anyone would ever
write macros bigger than 132 characters? Oh, well, I did.
[Quiz of the decade: Where did DEC come up with 132? What, is
it 128 and a bit?]
* Defective error reporting. What do I mean by defective? Like,
it's almost impossible to figure out what the UIL compiler means
when it complains about something. Like, if you forget a
semicolon someplace, the compiler pukes into its own food, eats
it back again, and pukes it out again, and just gets totally ill,
dude.
* Documentation. Huh? Did someone say documentation?
* Language design. Whoever designed UIL must have been heavily
involved in BASIC and FORTRAN, because that's as sophisticated as
it ever gets. The language is extremely simple-minded. No
conditional processing. No interface actions. No anything. All
UIL offers is a substitute to writing out almost the exact same
stuff in a C program. Yes, I know that writing it in C would be
even more time-consuming, but there I have access to powerful
macros and procedural mechanisms, not to mention conditional
processing, that can make life easier. Any intelligence in the
interface must be performed in the program anyway; you can't
delegate any actions to the UIL portion, as Niels says. Which
brings me to wonder why OSF never gave Open Dialogue any serious
consideration (please, don't tell me about "demonstration
technology"). If not the entire Open Dialogue system, then at
least the language, which was several generations ahead of UIL.
My personal impression is that DEC shoved UIL down OSF's throat
as its "contribution", though in effect all it's done is cause
people to waste inordinate amounts of time and effort creating
workarounds.
* Scale. You really cannot write a serious application using UIL
and its compiler. The mechanism simply cannot handle the sheer
volume of text required to describe the interface. You need an
intermediate agent, and OSF just didn't think it was necessary to
supply one. I would have settled for preinvoking cpp, but even
that is not enough.
* Elegance. If you try to develop an application using creation
callbacks and the other standard mechanisms supplied by OSF, you
will end up with a horrendous piece of noodle code on your hands.
UIL lends itself very well to kludgy solutions; I tried hard to
extricate myself from all this mess, but it was not possible
unless I adopted several coding and pre-compilation standards.
In essence, I've spent the better part of two months fighting the
UIL mechanism, trying to create a logical framework around which
I can develop several large applications, and I'm getting close
to completely throwing in the towel and starting from scratch
with WINTERP. I've looked everywhere, and all I see is square
pegs that have been shoved and squeezed into round holes. You
can't go very far with such a setup.
* Extensibility. Are you kidding me? Extend UIL? I'd rather go
gene splicing than try to tack on more crud to UIL. DEC has
supplied what can be generously called as an embryonic extension
mechanism. It's badly documented, and from what I've seen by
wading through the code, they never really thought anyone would
want to extend it. Like, dude, there's everything you'll ever
need there anyway, so why bother?
I'm really sorry to be saying all of this, but UIL is not a solution.
Unfortunately, unless OSF is willing to break with tradition and supply a
completely different mechanism for the next release of Motif, we are
stuck with UIL for quite a while. Which means we will all waste more
time and energy coming up with solutions. Here's some alternatives:
* Create a wrapper around UIL. Bury it under a ton of macros,
processing languages, prepackaged C code. Then it may be
possible to develop an interactive interface editor that uses
these mechanisms. This is what I'm currently trying to do, but
as I said, I'm thinking of giving it up.
* Get the format for UID files and develop your own UIL language
and compiler. This is fairly time-intensive, but offers the
chance to start from zero and build the system correctly.
* Use WINTERP. I'm just not sure about this now, but it's starting
to make more and more sense.
* Use LISP entirely. Don't even bother with C, C++, Pascal,
FORTRAN, or anything similar. Start with LISP. Develop
everything in LISP. This seems to be the most intuitive
alternative, but it requires a lot of work. And it's not
entirely portable, at least not yet.
Here's some great behind-the-scenes insight into how Motif and UIL came about, and the palace intrigue between DEC and other OSF member companies, from Kee Hinkley, a member of the team that created Motif, who worked for Apollo Computer before working for HP:
I tried to reply directly to this, but auto-trol.com doesn't seem to
be around, so...
In article <792@auto-trol.UUCP> marbru@auto-trol.COM (Martin Brunecky) writes:
> For your case I'd need a more generic one, specifying widget ID to
> to set. Easy to do. I did not think of one, since to accomplish your
> task we have WsMatrixBox, which does all you need with 2-3 resources,
> without all that ugly code.
I don't suppose WsMatrixBox is available anywhere?
> With the X resource database, there is no problem, since the
> "hidden" widget always has a name (somehow constructed by the
> confusion routine). And since there is a name, and a known place
> in widget hierarchy, you can define any resources you wish.
Ugh. Not your fault, but ugh nonetheless.
>>Incidentally. OSF did at one point consider using an extended
>>Xresources form as an alternative to UIL, but was convinced (I forget
>>the exact reasons) that it wasn't appropriate (too hacky?).
> Wasn't the real reason some OSF member was already using UIL
> and wanted to make it a "standard" ?
Keep in mind these are my opinions and mine alone, based on my view as
part of the team that "created" Motif.
There is no question in my mind that had OSF not chosen UIL, an "OSF
Member" would have been upset. The results of that, I don't know - it
didn't come to that. My feeling, and what I believe the consensus to
have been, was that UIL, while by no means perfect or even correct,
was a step in the right direction. I also felt (and I regret not
examining the code more throughly in the hour or so I had it) that it
could be fixed, and that no better, timely (e.g. Open Dialogue was
potentially not timely (in retrospect I know that is wrong, it could
have been there, but...)), solution existed. Given that something
like it seemed necessary, both as a transfer language for IDTs
(something the membership wanted), and as a means for supporting
internationalization, it was decided that it should be included but
not placed in the AES (Application Environment Specification) - in
other words, the specification of UIL is open for change in the
future. I, at least, was under the impression that work would begin to
correct these problems as soon as Motif was released. In fact, there
were several possible approaches bandied about for what the new UIL
would look like and who would do the work.
In my opinion OSF dropped the ball here, and frankly I feel somewhat
betrayed, since what we worked out was a compromise and I feel it was
tossed as soon as the transition team left. I should point out
however, that I don't think, given my knowledge of the people who are
at OSF, that this was done for political reasons. I suspect it has
been more a matter of manpower and priorities. I do think that it's
extremely regretable however, since the number of programs using UIL
is (as I was afraid) increasing rapidly, and any viable UIL
replacement now must support seamless translation to and from UIL
files.
