Hacker News Reader

Comment by sidlls | Hacker News Reader

"Self abuse kit" is such an appropriate way to describe Motif.

A few years ago I found a book on Motif user interface programming in a used bookstore, and started leafing through it. The entire book had exactly ONE picture. ONE. And it was some architectural diagram describing X, depicting a network of terminals and servers and happy little cloud things. The rest of the book (asymptotically, all of the book) described APIs and widgets and protocols and whatnot, all without the benefit of showing what the user would be interacting with.

That someone could write a book on UI programming and someone else would publish a book on UI programming without any actual depictions of UI is pretty much all I need to know about X and its community (although I know a lot more, and my actual exposure to X goes back to early versions that came on 9-track tapes directly from MIT and supported mostly just frame buffers on DEC Vaxen).

(For years -- and this may still be true -- the software to manage the equipment in Comcast's head end datacenters was controlled by some X-based UI. Now, I ain't gonna say "Them folks surely deserve it, because they done me wrong" but that miserable train-wreck of a system goes a long way towards explaining why it's often hard for Comcast to fix their stuff. I have un-fond memories of taking down whole QAMs because I was fool enough to click some check boxes in a dialog in the wrong order...)

You can write hideous UI in just about anything, but X seems to have a special place in the ecosystem.

It's because Motif is so ugly, they were embarrassed to include a screen snapshot.

Then TCL/Tk came along and emulated Motif's look and feel, only better because its default color was bisque.

"Bisque is Beautiful"

http://www.ucolick.org/~de/Tcl/pictures/

"The procedure tk_bisque is provided for backward compatibility: it restores the application's colors to the light brown (“bisque”) color scheme used in Tk 3.6 and earlier versions."

https://www.tcl.tk/man/tcl/TkCmd/palette.htm

http://mars.cs.utu.fi/BioInfer/files/doc/public/Tkinter.Misc...

Are you referring to the Motif programming manual(there are few motif programming books so I am assuming you are). If so that was a mutli volume effort with books devoted to particular subjects(ie the API would be one of them).

Win32 is a pleasure to program for, when compared with X/Athena/Motif.

I far prefer Motif to Gnome. It's much lighter, I think it's much nicer looking (Gnome's default theme is really really ugly IMO, Motif feels well defined and simple.) and seems to have far fewer dependancies.

I've written software that uses both and I don't remember thinking that one was significantly easier than the other, I did dislike that they took control of the main loop, Plan9's method of synchronous event polling is much nicer IMO.

GNOME isn't a toolkit, it's a full desktop environment. The toolkit is GTK+.

And yeah it is heavier than Motif. It does a lot more with it, though. Whether you think those things are valuable or not presumably depends on what software you use and your own sense of aesthetics.

Also when GTK+ was created, Motif was proprietary. There was Lesstif, but if I recall correctly that wasn't all that good, so there was a good incentive to develop a Free Software GUI toolkit.

I haven't used Motif in almost 20 years, and I don't think I've seen more than a handful of Motif widgets in the last 10 years, but I still can't get over how incredibly ugly and hard to use Motif was. People actually paid money for Motif!

OTOH every time I use CSS to try to lay something out in a manner that can handle different window sizes, I think nostalgically of the Motif Form widget.

I'm running mwm on my desktop machine now and I build emacs against Motif too.

tru master. Send a screenshot please, I like motif.

I don't have a running one on me, but here is an actual screen snapshot from 1990 or so, showing what happens when you resize XCalc again and again, as the layout rounding errors build up in the bounding boxes of the X Toolkit widgets used for the buttons.

And Motif is based on that very same code.

http://www.art.net/studios/hackers/hopkins/Don/unix-haters/x...

At one point I got frustrated and hacked the window manager (probably piewm) so I could pass it a command line parameter telling it the window ID on which to run instead of the root framebuffer, and then I ran it on the XCalc window, so I got window frames around all the buttons and could pop up menus on them, move them back to where they belonged, resize them, iconify them, etc.

Yay ICCCM! How powerful! It was totally worth ICCM being that complicated and pushing all that complexity into every other toolkit and application, just in order to make that trick possible just once.

http://www.freshports.org/x11-wm/piewm/

Ha, I didn't even read your nick, how unsurprising :)

you know what, I love http://www.crynwr.com/piewm/ screens a lot. I'm deep into a retro 8bit mindset these days. Very fitting.

Alas I never had to write code for it, but I like the idea and look.

Some people like to configure it to not have any frames at all, and operate it with pie menus bound to alt/command keys (which if you mouse ahead through quickly, they will not appear on the screen), rendering the window manager practically invisible.

Here's a version of the original X10 "uwm" window manager from which "piewm" is a distant descendent (pre-ICCCM, for X10, not X11), that I hacked to implement my original version of pie menus, and then integrated with FORTH, so you could program the window manager in FORTH (foreshadowing programming NeWS in PostScript), and even fork off light weight FORTH tasks to bounce the windows around!

http://www.donhopkins.com/home/archive/piemenu/uwm1/

http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai...

Here's the bouncy window code, including some reverse polish notation 68k assembler code for 256/ and 256*:

http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f

oh of course a pre NeWS postscript capable WM .. was it the first ?

funny http://www.donhopkins.com/home/archive/piemenu/uwm1/call-ema... ;)

ps: I couldn't locate the actual exec_string that interpret Forth

Emacs qualifies as a window manager in my book! ;)

That code you linked to is from Mitch Bradley's "Forthmacs", which ran on Sun workstations including 68k i86 and SPARC, and also Atari ST, Mac and other systems. He developed it into the "Open Boot ROM" architecture, which was used in Sun workstations and Apple PowerPC Macs as well as the OLPC children's laptop.

https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs

https://en.wikipedia.org/wiki/Open_Firmware

http://wiki.laptop.org/go/Open_Firmware

On SunOS, Forthmacs had a library clink.f with the ability to dynamically relocate and link Unix libraries so that you could call them from Forthmacs, pass arguments on the stack, etc. SunOS didn't actually support shared libraries or dynamic address relocating at that time, so Forthmacs simply ran the Unix linker utility to create a file with the library relocated to the desired address space in the FORTH dictionary, and then read that file into memory, define its symbols in the FORTH dictionary, and let you access its variables and call its functions directly from FORTH!

That's how Mitch originally integrated MicroEmacs with Forth to make Forthmacs, and how I later integrated "uwm" into FORTH: I refactored uwm so instead of having an event loop in the main function, it was a library that could be called by FORTH, which would link the library in and run the main loop itself, calling into the library as needed to initialize and handle specific events (_uwm_init, _uwm_poop).

http://www.donhopkins.com/home/archive/piemenu/uwm1/fuwm-mai...

Here's the glue that links in the uwm library from fuwm.out:

http://www.donhopkins.com/home/archive/piemenu/uwm1/load-fuw...

    .( Loading...) cr
    requires tasking.f
    requires uwm.f
    requires clink.f
    .( Linking...) cr
    "" fuwm.out clink
    .( Linked!) cr

My head is spinning. Amazing history part still.

In the game Big Rigs: Over the Road Racing, there is no threshold to how fast you can go backwards. Keep accelerating backwards and you will drive straight off the map. Continue to accelerate and you will be at world coordinates where the details of your truck's model are far smaller than the distance between two adjacent floating-point numbers (which grows with increasing magnitude). This causes your truck to be rendered with bizarre geometry: the details subtly wiggle and change size slightly at first, then warp all over the place and become completely unrecognizable.

Your xcalc screen shot made me think of that and smile a bit.

oh that's what happens with early rigid body simulation, it's float unstable and can create absurd new coordinates .. leading to spikes.

Different strokes for different folks, I guess. Personally I'd rather use twm. I like the flat-looking widgets better.

Reply on news.ycombinator.com