4 ms·

X has been the bane of McCLIM for the last 20 years. It limited adoption and delivered horrible first impressions to not-hardened Lisp users / McCLIM developers

X has been the bane of McCLIM for the last 20 years. It limited adoption and delivered horrible first impressions to not-hardened Lisp users / McCLIM developers: Basic-level functionality that's supremely important for a positive experience such as font rendering, absence of graphical glitches, tearing, smoothness and overall look&feel was bottom-of-the-barrel for very long periods of time. Maybe it still is, I don't know since I no longer use X. Hopefully that is about to change. Daniel Kochmanski seems willing to push McCLIM forward with alternative rendering backends. Moreover, Luke Gorrie (of SLIME and Distel fame) is working on an Emacs McCLIM backend: https://mobile.twitter.com/lukego/status/1387747747864973312 https://mobile.twitter.com/lukego/status/1387747747864973312

p_l 5y ago
Alternative backends are old thing, Daniel mainly documented how to make them (other than various cleanups underneath). The reality is that nobody cared enough about those alternative backends to keep them alive (other than CLX, for a time beagle was usable - but only on OSX, unless someone did a lot of work to compile it for other unices using GNUstep/OPENSTEP)
- metroholografix 5y ago
  Well yeah, if there's no documentation on how to create a backend, the barrier to entry is that much higher. It is great that this is now getting addressed. And none of the old alternative backends, including Beagle, ever worked for me. I certainly tried. I think it's fair to say that all of them were in various states of disrepair and none ever reached the point of "fully working".
  - p_l 5y ago
    I'm pretty sure beagle worked for a time, but that time was probably "CCL/RMCL on PPC mac with OSX" and I don't think it would cover all versions of that.
dan-robertson 5y ago
Yeah I worry about the reliance on CLIM too. I want to like it but it seems so complicated and general despite also not seeming that useful or relevant today. Perhaps it is something that really requires everything to already be in CLIM, or perhaps it is just incomplete and insufficient at the moment due to a lack of resources. Supporting multiple backends sounds like a good idea but if CLIM is one backend among “many” then it cannot be taken advantage of. But maybe CLOS will allow CLIM to still be exploited.
- fiddlerwoaroof 5y ago
  The backend are implemented “behind” CLIM itself: McClim is designed to abstract over multiple rendering backends. For a while the X backend was the only one that was ready, but I think there’s ongoing projects for a Windows and a Gtk/Cairo backend right now.
  - dan-robertson 5y ago
    This is the kind of backend I was referring to: > Climacs depends on McCLIM for its graphic user interface. Second Climacs is independent of any particular library for making graphic user interfaces, allowing it to be configured with different such libraries. Though, at the moment, the only graphic user interface that exists uses McCLIM
lonjil 5y ago
Hm, Luke has also been working on a GTK backend for McCLIM. I wonder if he gave up on that, or just working on it in the background, or simply put it on pause for a bit?
- lukego 5y ago
  That must be someone else. The Emacs backend is the first one I'm working on.
  - lonjil 5y ago
    So it seems. It's actually lokedhs. I must have mixed up "loke" with "luke".
lukego 5y ago
The surprise for me, working on the Emacs backend for McCLIM, is that CLIM is actually a lot simpler than it seems. The CLIM specification is overwhelming. The Lispworks and Franz user manuals for CLIM are too. There are just too many concepts being presented at the same time and with incredibly complex class hierarchies (e.g. a Stream is a Medium is a Pane is a ... I can't keep track.) But behind all of that there are a few simple and mostly separate frameworks: describing colored geometric shapes and text; associating drawn shapes with application objects; defining commands to operate on application objects. You can actually pick and choose from these APIs and map them onto whatever "backend" you like. The Emacs backend, for example, initially just translated the geometric drawing commands into SVG elements. That was really easy. Then we added unique IDs to those elements so that we can enable/disable them as input sources - also fairly easy. The Emacs backend is becoming fairly extensive but it's still only 650 lines of code: https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/emacs.lisp https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/...
lukego 5y ago
> Luke Gorrie is working on an Emacs McCLIM backend This works quite well now. If anyone wants to try it the installation instructions are at https://gist.github.com/lukego/0b74b94492066ae2b8c2a12b18e845c7 https://gist.github.com/lukego/0b74b94492066ae2b8c2a12b18e84....

p_l 5y ago

Alternative backends are old thing, Daniel mainly documented how to make them (other than various cleanups underneath). The reality is that nobody cared enough about those alternative backends to keep them alive (other than CLX, for a time beagle was usable - but only on OSX, unless someone did a lot of work to compile it for other unices using GNUstep/OPENSTEP)

metroholografix 5y ago
Well yeah, if there's no documentation on how to create a backend, the barrier to entry is that much higher. It is great that this is now getting addressed. And none of the old alternative backends, including Beagle, ever worked for me. I certainly tried. I think it's fair to say that all of them were in various states of disrepair and none ever reached the point of "fully working".
- p_l 5y ago
  I'm pretty sure beagle worked for a time, but that time was probably "CCL/RMCL on PPC mac with OSX" and I don't think it would cover all versions of that.

dan-robertson 5y ago

Yeah I worry about the reliance on CLIM too. I want to like it but it seems so complicated and general despite also not seeming that useful or relevant today. Perhaps it is something that really requires everything to already be in CLIM, or perhaps it is just incomplete and insufficient at the moment due to a lack of resources. Supporting multiple backends sounds like a good idea but if CLIM is one backend among “many” then it cannot be taken advantage of. But maybe CLOS will allow CLIM to still be exploited.

fiddlerwoaroof 5y ago
The backend are implemented “behind” CLIM itself: McClim is designed to abstract over multiple rendering backends. For a while the X backend was the only one that was ready, but I think there’s ongoing projects for a Windows and a Gtk/Cairo backend right now.
- dan-robertson 5y ago
  This is the kind of backend I was referring to: > Climacs depends on McCLIM for its graphic user interface. Second Climacs is independent of any particular library for making graphic user interfaces, allowing it to be configured with different such libraries. Though, at the moment, the only graphic user interface that exists uses McCLIM

lonjil 5y ago

Hm, Luke has also been working on a GTK backend for McCLIM. I wonder if he gave up on that, or just working on it in the background, or simply put it on pause for a bit?

lukego 5y ago
That must be someone else. The Emacs backend is the first one I'm working on.
- lonjil 5y ago
  So it seems. It's actually lokedhs. I must have mixed up "loke" with "luke".

lukego 5y ago

The surprise for me, working on the Emacs backend for McCLIM, is that CLIM is actually a lot simpler than it seems. The CLIM specification is overwhelming. The Lispworks and Franz user manuals for CLIM are too. There are just too many concepts being presented at the same time and with incredibly complex class hierarchies (e.g. a Stream is a Medium is a Pane is a ... I can't keep track.) But behind all of that there are a few simple and mostly separate frameworks: describing colored geometric shapes and text; associating drawn shapes with application objects; defining commands to operate on application objects. You can actually pick and choose from these APIs and map them onto whatever "backend" you like. The Emacs backend, for example, initially just translated the geometric drawing commands into SVG elements. That was really easy. Then we added unique IDs to those elements so that we can enable/disable them as input sources - also fairly easy. The Emacs backend is becoming fairly extensive but it's still only 650 lines of code: https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/emacs.lisp https://github.com/nuddyco/McCLIM/blob/clime/Backends/Emacs/...

lukego 5y ago

> Luke Gorrie is working on an Emacs McCLIM backend This works quite well now. If anyone wants to try it the installation instructions are at https://gist.github.com/lukego/0b74b94492066ae2b8c2a12b18e845c7 https://gist.github.com/lukego/0b74b94492066ae2b8c2a12b18e84....