An entire GUI toolkit was written from scratch simply to replace Motif (Gtk).
This should tell you what you need to know.
An entire GUI toolkit was written from scratch simply to replace Motif (Gtk).
This should tell you what you need to know.
>MoOLIT (Motif OPEN LOOK Intrinsics Toolkit) is a graphical user interface library and application programming interface (API) created by Unix System Laboratories in an attempt to create a bridge between the two competing look-and-feels for Unix workstations at the time: OPEN LOOK and OSF Motif.
>The library provided common GUI features such as boxes, menus, lists, and buttons, but allowed users to choose which look and feel they wanted at runtime. It was a short-lived project, as the industry was moving towards Motif as the de facto GUI standard, a trend culminating in the COSE initiative in 1993.
Of course if you just wanted a laugh at the name, you could also use the X Anathema Widgets (Xaw) toolkit, but I think MoOLIT was funnier. I cracked up every time I saw some Sun marketing droid in a tie seriously talking about it.
https://en.wikipedia.org/wiki/MoOLIT
https://en.wikipedia.org/wiki/OLIT
https://en.wikipedia.org/wiki/OPEN_LOOK
https://en.wikipedia.org/wiki/Motif_(software)
https://en.wikipedia.org/wiki/X_Toolkit_Intrinsics
https://en.wikipedia.org/wiki/X_Athena_Widgets
>In a talk for USENIX, X pioneer Jim Gettys remarked that although Athena widgets were "ugly", they were often used in the period of X history that he describes as the "GUI wars", as a safe alternative to the competing Motif and Open Look toolkits.
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
>"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." -Philip Greenspun's Tenth Rule
The X Toolkit ends up needing to do all of these dynamic-scripting-language-like things, like resolving names and paths, binding events to handlers, calculating expressions, and instantiating objects based on resource data. So if it doesn't already start out with a standardized scripting language to use for that, it has to duplicate all that dynamic almost-but-not-quite-entirely-unlike-half-of-Common-Lisp stuff itself.
Case in point: Motif's infamous UIL (because X resource files weren't half-assed enough).
https://www.donhopkins.com/home/catalog/unix-haters/hpox/uil...
And then when you do get around to plugging that toolkit into some other scripting language (the way WINTERP plugged Motif/Xt into XLisp, or GTK/GObject plugs into Python for that matter), now you have two or more fat bloated complex buggy poorly documented incompatible impedance-mismatched half-assed competing layers of middleware and object models tripping over each other's feet and spraying each other with seltzer bottles like the Three Stooges.
https://www.youtube.com/watch?v=VO9RP4QEZKU
https://news.ycombinator.com/item?id=22610342
>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.
[...]