NsCDE: Not So Common Desktop Environment(github.com)
github.com
NsCDE: Not So Common Desktop Environment
https://github.com/nscde/nscde
56 comments
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].
[1] http://cdesktopenv.sourceforge.net/man1/dtksh.html
[1] http://cdesktopenv.sourceforge.net/man1/dtksh.html
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.
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.
But yeah, the API is a rather direct translation of the somewhat verbose Intrinsics/Motif interface. Compare that to its contemporary Tcl/Tk.
>I was tempted to dismiss it....
Goes on to completely dismiss it.
This is an amazing project and much more than a theme/skin, and obviously a labor of love. Glad to see it on HN getting some well-earned kudos.
Goes on to completely dismiss it.
This is an amazing project and much more than a theme/skin, and obviously a labor of love. Glad to see it on HN getting some well-earned kudos.
>>I was tempted to dismiss it....
>Goes on to completely dismiss it.
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.
>Goes on to completely dismiss it.
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.
Probably because they put in more effort.
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.
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.
His documentation in general is top-notch, especially the included PDF.
I wonder if as people get sufficiently good at a second language, particularly on the internet, people become more willing to nitpick.
Is the README a landing page? I prefer a separate blog post with all that, to keep the README as concise as possible.
Like this: https://telegra.ph/Announcing-atbswp-a-minimalist-keyboard-m...
Disclaimer: I wrote that.
> Is the README a landing page?
Well, yes? Isnt that whats it for?
Also, blogs will be lost to the sands of time, while readme will survive as long as someone has the sources.
Well, yes? Isnt that whats it for?
Also, blogs will be lost to the sands of time, while readme will survive as long as someone has the sources.
I get your point but I'm arguing that a blog is more expressive when talking about things like project history and whatnot.
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.
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=PLpVwwj0aIJjeHbA38F1z6...
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.
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.
Almost like simulated annealing!
Almost like simulated annealing!
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 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...
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.
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.
I prefer bisque to teal.
https://news.ycombinator.com/item?id=17173197
https://news.ycombinator.com/item?id=17173197
️️️
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).
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 shouldn't have gotten rid of my Sun Sparcstation 20. It ran CDE, and you could also run an early, super-slow GNOME.
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.
You can still use it:) It was open sourced a while back and I can personally attest that I works on Arch and OpenSUSE.
> 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.
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.
'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.
Apparently the real thing is still under development. https://sourceforge.net/projects/cdesktopenv/
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:
https://zensites.net/fvwm/guide/
https://zensites.net/fvwm/guide/
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 ;))
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!
[deleted]
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.
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'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-...
[1]https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-screen-...
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.
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.
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?
Could have been done a decade ago, why now?
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
>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.
>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.
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...
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
>"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...
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):
> -Don
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
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...
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
>"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...
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
> -Don
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.
> 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.
Doesn't CDE rely on Motif for font rendering? Motif itself supports Xft for a very long time now.
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.
This is a CDE skin for FVWM.
Nothing important from CDE is included. None of the technology ideas. Just a cute window manager.
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.
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.
Although Motif was only bearable with help of Roguewave's Motif++.
If you liked ToolTalk, you'll LOVE ChatRoulette.
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/
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...
Here are some classic messages about UIL. Avoid it like the plague.
-Don
To: [email protected] Cc: Erik Hardy <[email protected]> Subject: Re: To UIL or not to UIL?
From: Niels P. Mayer <mayer%[email protected]>
In article <?@?> [email protected] (Michael Yang) writes:
> In article <[email protected]> [email protected] (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....
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.
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
----------
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/
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...
Here are some classic messages about UIL. Avoid it like the plague.
-Don
To: [email protected] Cc: Erik Hardy <[email protected]> Subject: Re: To UIL or not to UIL?
From: Niels P. Mayer <mayer%[email protected]>
In article <?@?> [email protected] (Michael Yang) writes:
> In article <[email protected]> [email protected] (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....
--------
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.
--------------------
--------------------
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 -- [email protected]
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.
http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/la...
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
Here's Omar's posting about UIL, WINTERP, and Lisp:
Date: 19 Jan 90 09:53:11 GMT From: [email protected] (Omar S. Juma) Subject: Re: To UIL or not to UIL? To: [email protected]
In article <11658.632634712@hplnpm> mayer%[email protected] (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...
[email protected]
...anon...
"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...
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
Here's Omar's posting about UIL, WINTERP, and Lisp:
Date: 19 Jan 90 09:53:11 GMT From: [email protected] (Omar S. Juma) Subject: Re: To UIL or not to UIL? To: [email protected]
In article <11658.632634712@hplnpm> mayer%[email protected] (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...
[email protected]
...anon...
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
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 <[email protected]> [email protected] (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 | | [email protected] | wait for ring, press 3. | 300/1200/2400 baud | +-----------------------------------------------------------------------------+
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 <[email protected]> [email protected] (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 | | [email protected] | wait for ring, press 3. | 300/1200/2400 baud | +-----------------------------------------------------------------------------+