Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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!


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: