
McCLIM: A GUI Toolkit for Common Lisp - tosh
https://common-lisp.net/project/mcclim/
======
Athas
Blast from the past! I used to work on McCLIM and Climacs as an impressionable
youth almost ten years ago. I think the battle for coming up with new ways of
defining GUIs is lost (and the web is eating everything anyway), but CLIM was
definitely an interesting idea. While it lost a bit in the ability of
individual applications to customise their behaviour, it won a lot in the
interoperability that was transparently provided by the presentation system.
Using "presentations", any on-screen object could be associated with a Lisp
object. An application would usually "present" various objects using
"presentation types" (image, graph, filename, etc), and other applications
could then "accept" input of a given presentation type. If some object of an
acceptable type was somewhere on the screen, the user could just click it.
Text-based input entry was usually also permitted, assuming the presentation
type in question had a textual representation.

I mostly worked on Drei, which was the input editor. It finds use in Climacs
(which is probably not worth using if you have Emacs), and the McCLIM
Listener, which _is_ really cool. It shows the potential of adding bits of
graphics support to a classical REPL, and being able to work interactively
with opaque objects.

Using CLIM is a bit like operating an artifact that somehow made its way from
an alternative universe.

~~~
jstimpfle
I've long been very unimpressed by common GUI development models. And also by
resulting GUIs themselves - typically not very flexible. I've made a few
attempts to find better approaches. But the fundamental problem is that in the
end one always ends up with a separate state machine for GUI elements - so the
GUI has to be synchronized with the state of the main thread. This is hard to
get right, and unflexible in the end.

Two days ago I came across the "Immediate Mode GUI" approach. It has some
following for example in the games or realtime graphics sector. I think it's
nice and very flexible, but could imagine it falls flat for complex
interaction models where you just _need_ considerable state, and it's better
to use conventional widgets which have much of the logic encapsulated:

    
    
        https://www.youtube.com/watch?v=Z1qyvQsjK5Y
        https://github.com/ocornut/imgui

~~~
0x445442
Maybe the common approaches and models are what's wrong. Too me, if EMACS
could render HTML the way a browser could it could cover almost every desktop
user interface use case.

There have been other systems developed which have similar approaches to
simplifying desktop user interfaces; Enso comes immediately to mind. But I'm
not aware of any systems that's completely replaced the notion of sandboxed
applications running in their own windows and employing their own menu systems
and widget layouts.

With web applications things have become many times worse. I absolutely hate
all the different UI paradigms I must deal with on a daily bases.

There's empirical evidence to support the fact that I'm not in the minority
either. I don't have the reference off hand but I was reading how a very large
percentage of the Chinese population uses WeChat for many common, daily tasks
other than chat. My claim: this is because consciously or not they don't like
dealing with multiple, varying user interface paradigms.

~~~
pmoriarty
_" Too me, if EMACS could render HTML the way a browser could it could cover
almost every desktop user interface use case."_

I mostly browse the web using emacs-w3m in a terminal. It works great with the
exception of javascript, which it can't handle. For that, I reluctantly switch
to a traditional browser.

emacs-w3m is definitely not up to handling "every desktop user interface use
case", but it's very nice for browsing the web in "plain text mode", as it
were, viewing the occasional image (or more, if you're using gui emacs), and
having full integration with emacs.

~~~
0x445442
Yeah, I'm aware of w3m but it would be nice to be able to just render HTML
payloads in an Emacs buffer. About a year ago I saw a demo on Youtube of an
embedded Webkit in Emacs but I'm not sure what the progress is there.

What I envision is something very close to Gmail's interface. But instead of
just email the interface presents a list of items. Each item is of a
particular type and each type has an associated renderer. A command box
facilitates command entry and the result of each command is a list of these
items. When an item is selected a view of the item is rendered. Items can also
have tags associated with them such that we can filter item sets by tags. A
resulting set of items can be piped to an ensuing command to produce another
set of items.

Item renderers don't need to be read only either. For example I could issue a
file search command that returned a set of files. By selecting one, if an
editor renderer existed I could edit the result in place and issue a save
command on the item.

I could take the paradigm even further. I could issue something like a project
command that returned a set of projects where a project was really just a tag
for an item which had metadata pointing to a directory path. After selecting
one of these project items I might be presented with a rendered view of the
directory's contents. From there I might be able to execute a build command on
this item and the command would use the metadata associated with the item to
build the project. The output would be a list of one item with the build
results.

I've been thinking about this for a long time and the only apps I can think of
that don't fit with this paradigm are apps that actually require a mouse or
pen pad for input like photo shop or auto cad.

There are varying technologies which nibble around the edges of such a system
but nothing that really implements it fully. Emacs comes close, the command
line in a terminal comes close, Gmail exhibits aspects, Enso exhibited aspects
but nothing exists which puts all the pieces together.

------
jackdaniel
Cool that we got into the Hacker News. If someone is interested in getting
involved in development, I want to hint that we have some bounties set here:
[https://www.bountysource.com/teams/mcclim/bounties](https://www.bountysource.com/teams/mcclim/bounties)

We are moving steadily forward, if you have any questions I'll try to answer -
I'm one of the current maintainers.

~~~
aidenn0
State of non-X11 frontends?

~~~
jackdaniel
WinAPI frontend pending (alpha quality) - [https://github.com/ailisp/mcclim-
graphic-forms](https://github.com/ailisp/mcclim-graphic-forms) (bounty $500)

Framebuffer backend working (although it uses X11, porting it to something
else should be considerably easier)

OSX backend beagle is broken (bounty $400)

I suppose that's all we have atm (plus CLX backend of course, which is X11)

------
lukego
I am really happy to see McCLIM moving forwards, great hacking!

I recently started a project called Studio that is a suite of interactive
development tools (profilers, etc.) The two frameworks that I shortlisted were
McCLIM and The Glamorous Toolkit. Everything else seemed too low-level to me.
(I ended up going with the latter because it was more actively developed.)

Studio: [https://hydra.snabb.co/job/lukego/studio-manual/studio-
manua...](https://hydra.snabb.co/job/lukego/studio-manual/studio-manual-
html/latest/download-by-type/file/Manual#view-hot-traces)

The Glamorous Toolkit: [http://gtoolkit.org/](http://gtoolkit.org/)

~~~
agumonkey
Funny, after the thread about J. Rees T, I dug the web and ended up there
[https://web.archive.org/web/20061013002258/http://fresh.home...](https://web.archive.org/web/20061013002258/http://fresh.homeunix.net:80/~luke/misc/haskell/NineNines.hs)

small world

ps: I just peeked at the regexp function, did someone told you or did you come
up with it on your own ? it's so damn short

~~~
lukego
Small world indeed :) that's really old code, I don't remember much about it
:)

~~~
lukego
Regex code was probably based on the standard Erlang regex module that Robert
Virding wrote. Simplified by skipping the regex syntax and writing the AST
directly (like in scsh.)

~~~
agumonkey
Ha, great, another name to google :p

ps: always skip the parsing.

~~~
abecedarius
I had some fun Haskelling Thompson's algorithm too:
[https://github.com/darius/sketchbook/blob/master/regex/nfave...](https://github.com/darius/sketchbook/blob/master/regex/nfavector2.hs)
\-- though I think Haskell's at a disadvantage for this one.

------
sanxiyn
Be sure to click "Get excited" link to take a look at screenshots.

------
doall
Recently I'm seeing many Lisp contents in HN and always seeing tosh's name.
Thanks for the posts tosh!

------
pavlov
The attitude in this screenshot may explain why Lisp environments don't take
off:

[https://common-
lisp.net/project/mcclim/static/media/screensh...](https://common-
lisp.net/project/mcclim/static/media/screenshots/k1vOauV.png)

~~~
gugagore
What was it?

~~~
Athas
It was this:
[https://web.archive.org/web/20170820092504im_/https://common...](https://web.archive.org/web/20170820092504im_/https://common-
lisp.net/project/mcclim/static/media/screenshots/k1vOauV.png)

Not really offensive unless you identify as Smalltalk (called a "toy"), or C++
(called a "cancerous abstraction"), but kind of shrill and not a good way to
present the project.

~~~
linguae
I just started learning Common Lisp a few days ago, actually, and I agree that
this isn't a good way to present this project. I've never used Emacs (I'm been
using vi for 13 years now), and regarding Lisp machines, I'm very curious
about them but in 2017 I have the slightest idea where I could try one out;
unlike Smalltalk where there are open-source Smalltalk VMs such as Squeak,
there are no open-source Lisp OSes; plus, Lisp machines themselves are
expensive collectors items. (I wish there were some type of computer lab
available where one could try out old machines that had a tremendous impact on
computing history such as the Xerox Alto and Symbolics Lisp machines running
Genera, but I digress.) It would be nice if the IP issues regarding Symbolics
Genera were resolved and if the IP owners open-sourced the OS; there are
enough interesting and unique ideas in Genera for it to still have an impact
on the computing landscape despite its age.

~~~
pmoriarty
It would be nice if there was a docker image or a VM new developers could
download, and which had a batteries-included Lisp/Scheme development
environment with emacs/vim prettied up and having all the bells and whistles,
so they could just start hacking away instead of spending days or weeks
learning, setting up, and tweaking their editors and downloading and
installing tons of libraries and plugins.

~~~
aidenn0
[https://shinmera.github.io/portacle/](https://shinmera.github.io/portacle/)
<\-- it needs a bit more testing so the scary warning message at the top of
the page will go away, but it's impressive already IMO.

------
souenzzo
Why not react-like interface like reagent-project.github.io

