A computer is a tool, most tools are not sleek, they have buttons and dohickies, sharp edges that do work, etc. There is nothing wrong with polishing something up, sure, but it has to be strictly secondary to usability.

The high contrast 3d look in motif wasn't because its creators had bad taste. They may well have also had bad taste, but the appearance served a utilitarian purpose. :)

I use this: https://github.com/grassmunk/Chicago95

https://github.com/NsCDE/NsCDE

Things they got right: contrast. Shapes. I don’t need my glasses to use this stuff.

Things they got wrong: over the top 3D look. Fonts are shit. Italics in menus? Ragged bitmap italics? Gotta be fucking kidding me.

>The X-Windows Disaster

[...]

>The Motif Self-Abuse Kit

>X gave Unix vendors something they had professed to want for years: a standard that allowed programs built for different computers to interoperate. But it didn’t give them enough. X gave programmers a way to display windows and pixels, but it didn’t speak to buttons, menus, scroll bars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the Unix community had six or so different interface standards. A bunch of people who hadn’t written 10 lines of code in as many years set up shop in a brick building in Cambridge, Massachusetts, that was the former home of a failed computer company and came up with a “solution:” the Open Software Foundation’s Motif.

>What Motif does is make Unix slow. Real slow. A stated design goal of Motif was to give the X Window System the window management capabilities of HP’s circa-1988 window manager and the visual elegance of Microsoft Windows. We kid you not.

>Recipe for disaster: start with the Microsoft Windows metaphor, which was designed and hand coded in assembler. Build something on top of three or four layers of X to look like Windows. Call it “Motif.” Now put two 486 boxes side by side, one running Windows and one running Unix/Motif. Watch one crawl. Watch it wither. Watch it drop faster than the putsch in Russia. Motif can’t compete with the Macintosh OS or with DOS/Windows as a delivery platform.

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

http://www.art.net/~hopkins/Don/unix-haters/x-windows/motif....

>MOTIF ANGST PAGE

>If you have any ANGSTFUL Motif code, comments, documentation, or resources, please share them with me! Here is some of the stronger stuff I've found. Note: this is only for official Open Software Foundation Motif inspired Angst. If you're experiencing TCL/Tk That Only Looks Like Motif But Doesn't Suck Angst, then you should stop whining and fix the problem yourself, if somebody else hasn't already.

/* Note that the text callbacks are "weird" in that they expect values in the callback structure to be set inside the callback proc to determine what actions need to be taken after the callbackproc returns. In particular, the XmTextVerifyCallbackStruct's 'doit' slot is always set to True, and must be set to False if the callbackproc doesn't want the action to be taken. To do this, Set_Call_Data_For_XmTextVerifyCallbackStruct() is called by Wcb_Meta_Callbackproc() after the callback lisp code is evaluated, and the values bound to these settable variables are set inside call_data....

Another inconsistency with the Text widget is that some callbacks on this widget return XmAnyCallbackStruct's (XmNactivateCallback, XmNfocusCallback, XmNvalueChangedCallback), whereas XmNlosingFocusCallback, XmNmodifyVerifyCallback, and XmNmotionVerifyCallback return XmTextVerifyCallbackStruct. In the code below, we look at the 'reason' slot of the call data, (which is present in both XmAnyCallbackStruct and in XmTextVerifyCallbackStruct) to determine the kind of callback that occured and we only bind the values that are appropriate for that kind of callback. Information about which slots are valid for particular callback was taken from the documentation on the XmText(3X) widget, and verified against the Motif 1.1 source -- this is valid for both XmText and XmTextField widgets... */

    static LVAL s_CALLBACK_CUR_INSERT, s_CALLBACK_NEW_INSERT, s_CALLBACK_START_POS, s_CALLBACK_END_POS, s_CALLBACK_TEXT;
    static void Lexical_Bindings_For_XmTextVerifyCallbackStruct(bindings_list,
                                    lexical_env,
                                    call_data,
                                    client_data)
         LVAL bindings_list; /* a list of symbols to which values from XmTextVerifyCallbackStruct are bound */
         LVAL lexical_env;  
         XtPointer call_data;
         LVAL client_data;  /* XLTYPE_CALLBACKOBJ */
    {
      extern LVAL true;
      register LVAL s_bindname;
      XmTextVerifyCallbackStruct* cd;

      /* How long can this go on???? */
    }