
NsCDE: Not So Common Desktop Environment - bilegeek
https://github.com/nscde/nscde
======
yjftsjthsd-h
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").

~~~
satya71
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].

[1]
[http://cdesktopenv.sourceforge.net/man1/dtksh.html](http://cdesktopenv.sourceforge.net/man1/dtksh.html)

~~~
yjftsjthsd-h
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.

~~~
mhd
ksh itself was pretty powerful, and some of its programming features still
haven't found their way into bash or zsh.

But yeah, the API is a rather direct translation of the somewhat verbose
Intrinsics/Motif interface. Compare that to its contemporary Tcl/Tk.

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

~~~
j-james
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.

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

~~~
83457
Too good for someone to realize you are a non-native speaker, and not good
enough to not occasionally make obvious mistakes without realizing it.

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

------
themodelplumber
The author did a nice job preparing a playlist video presentation as well. If
you're not able to test the software, it's worth a look.

[https://www.youtube.com/playlist?list=PLpVwwj0aIJjeHbA38F1z6...](https://www.youtube.com/playlist?list=PLpVwwj0aIJjeHbA38F1z693-fKIC8IHS5)

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

~~~
iso-8859-1
I remember the EUMETSAT Meteosat Second Generation control panels also showing
some teal on my visit in '06\. I took this photo:
[https://upload.wikimedia.org/wikipedia/commons/9/91/EUMETSAT...](https://upload.wikimedia.org/wikipedia/commons/9/91/EUMETSAT_MSG_control.jpg)

I don't think they'd replace it with no good reason, so since the MSG program
is still running, these computers probably also are.

~~~
DonHopkins
I prefer bisque to teal.

[https://news.ycombinator.com/item?id=17173197](https://news.ycombinator.com/item?id=17173197)

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

~~~
passthejoe
I shouldn't have gotten rid of my Sun Sparcstation 20. It ran CDE, and you
could also run an early, super-slow GNOME.

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

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

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

~~~
yjftsjthsd-h
You can still use it:) It was open sourced a while back and I can personally
attest that I works on Arch and OpenSUSE.

------
jakear
> during nineties and first decade of the 21 century

Anyone else like “naughties”? Heard it first on Mythbusters of all places and
it stuck with me. Not sure why it’s not more popular.

~~~
zapzupnz
'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.

------
satya71
Apparently the real thing is still under development.
[https://sourceforge.net/projects/cdesktopenv/](https://sourceforge.net/projects/cdesktopenv/)

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

~~~
coleifer
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:

[https://zensites.net/fvwm/guide/](https://zensites.net/fvwm/guide/)

~~~
blablabla123
Thanks for sharing! I might give it a shot again! (I used fvwm around 15 years
ago and it took me weeks to do the final setup ;))

------
nonamenoslogan
I've been using CDE since it was open sourced and love it. This is a very cool
project, I'll give it a try!

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

~~~
bilegeek
I'm not sure what he's done about HiDPI, but apparently that can be invoked
(depending on the app) using xsettingsd[1].

[1][https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-
screen-...](https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-screen-linux)

------
Wildgoose
This is really nice.

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.

------
pantulis
I always thought the Motif WM window decorations were very elegant. The rest I
didn't care much about but this is nice, really nice.

Could have been done a decade ago, why now?

~~~
DonHopkins
[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47#4fa8)

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

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

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

[https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt](https://donhopkins.com/home/archive/NeWS/uwm.extensions.txt)

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.

The X-Windows Disaster:

[https://medium.com/@donhopkins/the-x-windows-
disaster-128d39...](https://medium.com/@donhopkins/the-x-windows-
disaster-128d398ebd47)

Recreational Bugs talk [1989] by David Rosenthal (author of the ICCCM, the
Andrew Window Manager, and NeWS):

[https://blog.dshr.org/2018/05/recreational-
bugs.html](https://blog.dshr.org/2018/05/recreational-bugs.html)

>"You will get a better Gorilla effect if you use as big a piece of paper as
possible." -Kunihiko Kasahara, Creative Origami.

[https://groups.google.com/forum/#!search/%22xpert%22$20%22do...](https://groups.google.com/forum/#!search/%22xpert%22$20%22don$20hopkins%22/comp.windows.x/qJO5IgI_7HU/JXwAVovn5x0J)

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>

>Location (for anonymous FTP):

    
    
            Host: bongo.garnet.cs.cmu.edu (128.2.205.150)
            Dir:  /pub
            File: piewm.tar.Z
            Size: 948239 bytes
    
            Host: ftp.uu.net (137.39.1.9)
            Dir:  /tmp
            File: piewm.tar.Z
            Size: 948239 bytes
    

>Could someone "in the know" please tell me how to get this into the
appropriate X contributed software collection?

> -Don

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

------
badsectoracula
> In CDE there is no really XFT font rendering

Doesn't CDE rely on Motif for font rendering? Motif itself supports Xft for a
very long time now.

------
hapless
The best parts of CDE were Motif and ToolTalk. This ... thing omits both.

This is a CDE skin for FVWM.

Nothing important from CDE is included. None of the technology ideas. Just a
cute window manager.

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

------
r1ed1
[https://youtu.be/5dlYh_eHr4Y](https://youtu.be/5dlYh_eHr4Y)

------
DonHopkins
Speaking of the plague, does it support UIL? ;)

Neils Mayer described WINTERP (XLisp + Motif) as: You might think of such
functionality as "client-side NeWS without the postscript imaging model".

[http://nielsmayer.com/winterp/](http://nielsmayer.com/winterp/)

Don Hopkins wrote to a comp.human-factors discussion about "Info on UIL (User
Interface Language)" on January 22, 1993:

[https://groups.google.com/d/msg/comp.human-
factors/R3wfh90HM...](https://groups.google.com/d/msg/comp.human-
factors/R3wfh90HMss/WR1-qmjnNJIJ)

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

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

[http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/la...](http://www-
cgi.cs.cmu.edu/afs/cs/project/ai-
repository/ai/lang/lisp/gui/garnet/garnet.faq)

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

[https://www.cliki.net/CLX](https://www.cliki.net/CLX)

Here's Omar's posting about UIL, WINTERP, and Lisp:

Date: 19 Jan 90 09:53:11 GMT From: umich!umeecs!anon@yale-zoo.arpa (Omar S.
Juma) Subject: Re: To UIL or not to UIL? To: xp...@expo.lcs.mit.edu

In article <11658.632634712@hplnpm> mayer%...@HPLABS.HPL.HP.COM (Niels P.
Mayer) writes:

[Heavily edited]

> > ...rumor... ...UIL... > ...didn't meet HP's quality... > ...poop... >
> ...UIL SUCKS... ...silly... >...buggy... ...inelegant... > ...doesn't make
> life... ...easier... >...completely nonstandard... >

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.

I could go on...

an...@eecs.umich.edu

...anon...

~~~
DonHopkins
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:

[https://guidebookgallery.org/articles/osfmotif/pics/01](https://guidebookgallery.org/articles/osfmotif/pics/01)

Date: 27 Mar 90 13:36:06 GMT

Subject: Re: UIL or NOT to UIL

From: snorkelwacker!spdcc!tauxersvilli!alphalpha!naz...@bloom-beacon.mit.edu
(Kee Hinckley)

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.

-kee

\--
+-----------------------------------------------------------------------------+
| Alphalpha Software, Inc. | Voice/Fax: 617/646-7703 | Home: 617/641-3805 | |
148 Scituate St. | Smart fax, dial number. | | | Arlington, MA 02174 | Dumb
fax, dial number, | BBS: 617/641-3722 | | naz...@alphalpha.com | wait for
ring, press 3. | 300/1200/2400 baud |
+-----------------------------------------------------------------------------+

