Between lawsuits from Apple, and Microsoft being Microsoft, Digital Research’s GEM desktop for DOS never really had a chance. It did have another life on Atari home computers, but it’s the DOS version that provided the code for [Tomaz Stih]’s Linux port of the GEM graphical desktop — which isn’t a WM or DE for X or Wayland, for the record. It is entirely it’s own graphical display that will live in the framebuffer of a minimal Linux installation.
[Thomaz] is leveraging DR’s original code — or at least what started as DR’s code before a series of acquisitions and open sourcing — via OpenGEM and FreeGEM. Sample applications include the clock and calendar, but [Thomaz] says the APIs are compatible with Atari ST applications; presumably given the codebase the it will match the DOS version as well.
Much like when it was originally crushed betwixt Macintosh System and Microsoft Windows, we doubt many will be rushing out to use GEM instead of Wayland or XServer on Linux, but there may well be some use cases. If nothing else, it’s got to be lightweight.
If you missed the Digital Research GEM saga, this might get you up to date. If the idea of it running on Linux tickles your funny bone, you might enjoy seeing GEM on an AlphaSmart word processor.
It´s actually perfectly appropriate for using a matrix LCD display (B&W)
Doesn’t have to be latest hardware. GEM code is ~190KB.
On my Linux install? Never. But on an ESP32-XX with a touch screen? Well that is starting to sound interesting. The next time I need a UI on an ESP device. I may give this a second glance.
But GEM is 100% mouse-centric, so it would still be a bunch of work to make it useful for a touch screen. GEM is also single-touch (well, single-button), if it would become multi-touch compatible, I’d say that now we’re talking… :)
The key being that it should still stay lightweight. Not go the way that iOS and Android went.
I deliberately made it highly portable.
To implement HID devices (mouse and keyboard) you only need to implement one function:
int gem_hid_poll(gem_hid_event_t *evt)
And to draw framebuffer you implement:
int gem_raster_resync(void);
void gem_raster_shutdown(void);
gem_raster_surface_t *gem_raster_surface(void);
void gem_raster_present(void);
void gem_raster_present_rect(int x, int y, int width, int height);
void gem_raster_set_palette(uint8_t index, uint8_t r, uint8_t g, uint8_t b);
You write these functions and GEM should run anywhere.
You can use directly libvdi and libaes and have single process GEM or use libgem via gemd daemon which serializes GEM calls to libvdi and libaes and have multi process GEM.
The newest Open Computer 2, a Minecraft mod that inserts Linux computers into the game, has support for framebuffer graphics but the emulated RV64 is a bit lacking for a full blown X, not speaking of Wayland, DE. This could be a nice solution for that.
The touch panel on the Cheap Yellow Display is resistive, so you wouldn’t be getting multitouch on that anyway, and that’s a huge ESP32 touch UI market.
Well this is HackADay, that’s not a problem, that’s a challenge.
Word-a-day!
Betwixt is a perfectly cromulent word, we should use it more often.
As a non-native speaker I couldn’t agree more.
You’ll poke your eye out!
It would be nice to have something like this for Qt-Embedded, because QT-Embedded is much to fat to have hany usecase. Or even more better PalmOS!
I am developing “something like that”. It is not ready yet but here is the preview link – https://github.com/wischner/native
The Native library targets: Windows, Mac, Linux X11, SDL2, CDE/Motif, Window Maker, Open Look, Haiku, GEM, and I’m working on the Amiga 3.2 port.
The goal is WinForms simplicity in modern C++, using native controls or native look’n’feel, same code that runs everywhere.
Version for GEM targets GEMix (GEM on Linux) and adds a few controls such as splitters, toolbars, tree controls, tables…in style of GEM and using underlying GEM APIs.
i briefly used “MGR”, which has a similar look to it. i considered it because my PC back then was way too limited to practically run X (only 4MB of RAM). the neat part is, clients connected to it via pty just like a terminal, but it had escape sequences for vector graphics, bitmaps, etc. so it was effortlessly network-transparent. i never got any use out of it, and it is super limited. but i still admire its simplicity.
Do you have a link to more information on this?
https://en.wikipedia.org/wiki/ManaGeR
http://en.wikipedia.org/wiki/ManaGeR
https://ninakalinina.com/notes/mgr/
https://www.youtube.com/watch?v=QlQ7jv07Uco
Thanks, everyone!
Monospaced font only? (Looking at the top pic)
The GEM code does have (partially implemented) vst_load_fonts / vst_font additions for proportional fonts, but Atari ST GEM font is monospaced.
I think this is cool just because. But I’m a bit unsure of all this talk of X being so heavy. And isn’t Wayland supposed to be lighter than X?
I say this freely admitting, I have never attempted to port X or Wayland to anything small. But.. my Sharp Zaurus Collie with OpenZaurus/GPE installed ran a whole UI on X just fine back in the early 2000s. How heavy could it be?
Maybe there is a lot of extra eyecandy cruft piled on top of it these days. But can’t that all be de-selected at compile time? Worst case, if the bloat is not optional, does someone need to fork a 20 year old X server for embedded use?
It just seems like it would be easier to port applications when they already run on X.
yeah…back in 1995, X was way too heavy for me. but by 2002 i had a palmtop with 32MB of RAM that could run X satisfactorily, with the matchbox window manager, probably not far off from your zaurus. what’s heavy today is “desktop user environments” like gnome / kde, and browsers. in X11, i mostly use fvwm, xterm, vncviewer, and a custom pdf vewer, and pretty much anything sold in the last 15 years that can boot linux at all makes that feel very light indeed.
Ventura Publisher was so amazing in the day and it was built on GEM. Word processing and the spreadsheets really kicked off the PC revolution but Ventura Publisher let you do layouts and really added the pah-zaz.
Wow, what a flash back. We used Gem and Ventura Publisher on a AST 286 for parts and service manuals. Data was on a DBase II database.