8 ms·

NsCDE: Not So Common Desktop Environment

214 points by bilegeek 7y ago

ttul 7y ago
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 7y ago
  You can still use it:) It was open sourced a while back and I can personally attest that I works on Arch and OpenSUSE.
yjftsjthsd-h 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
- coleifer 7y ago
  >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.
  - yjftsjthsd-h 7y ago
    >>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.
satya71 7y ago
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.
satya71 7y ago
Apparently the real thing is still under development. https://sourceforge.net/projects/cdesktopenv/ https://sourceforge.net/projects/cdesktopenv/
themodelplumber 7y ago
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=PLpVwwj0aIJjeHbA38F1z693-fKIC8IHS5 https://www.youtube.com/playlist?list=PLpVwwj0aIJjeHbA38F1z6...
ghostpepper 7y ago
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.
- RMPR 7y ago
  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-macro-recording-and-playback-tool-03-16 https://telegra.ph/Announcing-atbswp-a-minimalist-keyboard-m... Disclaimer: I wrote that.
  - arka2147483647 7y ago
    > 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.
    - RMPR 7y ago
      I get your point but I'm arguing that a blog is more expressive when talking about things like project history and whatnot.
- j-james 7y ago
  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.
  - read_if_gay_ 7y ago
    Probably because they put in more effort.
  - pbhjpbhj 7y ago
    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.
nonamenoslogan 7y ago
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!
jabl 7y ago
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.
badsectoracula 7y ago
> 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 7y ago
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.
- pjmlp 7y ago
  Although Motif was only bearable with help of Roguewave's Motif++.
- russfink 7y ago
  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.
- yjftsjthsd-h 7y ago
  > 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.
- DonHopkins 7y ago
  If you liked ToolTalk, you'll LOVE ChatRoulette.
blablabla123 7y ago
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 7y ago
  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 7y ago
    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 ;))
jakear 7y ago
> 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 7y ago
  '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.
swiley 7y ago
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 7y ago
  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-linux https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-screen-...
INTPenis 7y ago
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.
- urxvtcd 7y ago
  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!
  - pimeys 7y ago
    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...
- iso-8859-1 7y ago
  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_MSG_control.jpg 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.
  - DonHopkins 7y ago
    I prefer bisque to teal. https://news.ycombinator.com/item?id=17173197 https://news.ycombinator.com/item?id=17173197
  - 7y ago
pantulis 7y ago
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 7y ago
  https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#4fa8 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.
hvdijk 7y ago
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.
r1ed1 7y ago
https://youtu.be/5dlYh_eHr4Y https://youtu.be/5dlYh_eHr4Y
uk_programmer 7y ago
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 7y ago
  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 7y ago
    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.
deleted 7y ago
[deleted]
Wildgoose 7y ago
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.
DonHopkins 7y ago
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/R3wfh90HMss/WR1-qmjnNJIJ https://groups.google.com/d/msg/comp.human-factors/R3wfh90HM... 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. *

214 points by bilegeek 7y ago

ttul 7y ago

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 7y ago
You can still use it:) It was open sourced a while back and I can personally attest that I works on Arch and OpenSUSE.

yjftsjthsd-h 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.
coleifer 7y ago
>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.
- yjftsjthsd-h 7y ago
  >>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.

satya71 7y ago

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.

satya71 7y ago

Apparently the real thing is still under development. https://sourceforge.net/projects/cdesktopenv/ https://sourceforge.net/projects/cdesktopenv/

themodelplumber 7y ago

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=PLpVwwj0aIJjeHbA38F1z693-fKIC8IHS5 https://www.youtube.com/playlist?list=PLpVwwj0aIJjeHbA38F1z6...

ghostpepper 7y ago

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.

RMPR 7y ago
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-macro-recording-and-playback-tool-03-16 https://telegra.ph/Announcing-atbswp-a-minimalist-keyboard-m... Disclaimer: I wrote that.
- arka2147483647 7y ago
  > 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.
  - RMPR 7y ago
    I get your point but I'm arguing that a blog is more expressive when talking about things like project history and whatnot.
j-james 7y ago
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.
- read_if_gay_ 7y ago
  Probably because they put in more effort.
- pbhjpbhj 7y ago
  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.

nonamenoslogan 7y ago

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!

jabl 7y ago

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.

badsectoracula 7y ago

> 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 7y ago

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.

pjmlp 7y ago
Although Motif was only bearable with help of Roguewave's Motif++.
russfink 7y ago
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.
yjftsjthsd-h 7y ago
> 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.
DonHopkins 7y ago
If you liked ToolTalk, you'll LOVE ChatRoulette.

blablabla123 7y ago

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 7y ago
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 7y ago
  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 ;))

jakear 7y ago

> 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 7y ago
'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.

swiley 7y ago

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 7y ago
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-linux https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dual-screen-...

INTPenis 7y ago

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.

urxvtcd 7y ago
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!
- pimeys 7y ago
  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...
iso-8859-1 7y ago
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_MSG_control.jpg 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.
- DonHopkins 7y ago
  I prefer bisque to teal. https://news.ycombinator.com/item?id=17173197 https://news.ycombinator.com/item?id=17173197
- 7y ago

pantulis 7y ago

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 7y ago
https://medium.com/@donhopkins/the-x-windows-disaster-128d398ebd47#4fa8 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.

hvdijk 7y ago

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.

r1ed1 7y ago

https://youtu.be/5dlYh_eHr4Y https://youtu.be/5dlYh_eHr4Y

uk_programmer 7y ago

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

deleted 7y ago

[deleted]

Wildgoose 7y ago

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.

DonHopkins 7y ago

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/R3wfh90HMss/WR1-qmjnNJIJ https://groups.google.com/d/msg/comp.human-factors/R3wfh90HM... 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. *