McCLIM: A GUI Toolkit for Common Lisp(common-lisp.net)
common-lisp.net
McCLIM: A GUI Toolkit for Common Lisp
https://common-lisp.net/project/mcclim/
52 comments
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:
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/imguiMaybe 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.
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.
"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.
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.
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.
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.
Immediate mode GUI was a common pattern in MS-DOS GUIs.
Do you mean immediate mode rendering by any chance? This is a bit different (but not that much) from what e.g. imgui does.
No, exactly like it is on imgui landing page.
On MS-DOS your application owned the machine when it was running, so most graphical applications controlled the rendering loop and explicitly checked the state of each widget, keyboard and mouse buttons.
A bit like the SDL event loop works, but extended to widgets as well.
On MS-DOS your application owned the machine when it was running, so most graphical applications controlled the rendering loop and explicitly checked the state of each widget, keyboard and mouse buttons.
A bit like the SDL event loop works, but extended to widgets as well.
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
We are moving steadily forward, if you have any questions I'll try to answer - I'm one of the current maintainers.
We are moving steadily forward, if you have any questions I'll try to answer - I'm one of the current maintainers.
State of non-X11 frontends?
WinAPI frontend pending (alpha quality) - 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)
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)
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...
The Glamorous Toolkit: http://gtoolkit.org/
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...
The Glamorous Toolkit: http://gtoolkit.org/
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...
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
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
Small world indeed :) that's really old code, I don't remember much about it :)
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.)
Ha, great, another name to google :p
ps: always skip the parsing.
ps: always skip the parsing.
I had some fun Haskelling Thompson's algorithm too: https://github.com/darius/sketchbook/blob/master/regex/nfave... -- though I think Haskell's at a disadvantage for this one.
Be sure to click "Get excited" link to take a look at screenshots.
Recently I'm seeing many Lisp contents in HN and always seeing tosh's name. Thanks for the posts tosh!
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/screensh...
Calling C++ programs "cancerous abstractions" is simply funny. I'm sure even C++ programmers agree :) It's NOT "why Lisp environments don't take off".
That guy's face on the screen is creeeepy af though...
That guy's face on the screen is creeeepy af though...
I've been a C++ developer for a couple of decades. It's funny and nicer than a lot of things we say about the language ourselves. And waaaaay nicer than what the C guys say. :-)
That's Gabriel Laddel's screenshot, he is quite an abrasive fellow but he doesn't represent the entire community.
Parent is downvoted but look at the screenshot. That is indeed a bad attitude and it's on the official project site. This does _not_ help.
You are right, sorry about that. I've used screenshots provided by someone and didn't take a close look at each of them (I already had one report like that and taken action immedietely).
If you find anything else, please let me know, I'm one of the maintainers. Picture removed.
If you find anything else, please let me know, I'm one of the maintainers. Picture removed.
Great, I really wish this project all the best.
There is still some snark in the screenshots on the site but nothing I found too off putting.
There is still some snark in the screenshots on the site but nothing I found too off putting.
That was fast! Thanks for taking the concern seriously.
It may seem like a small thing, but content that literally says "we expect you to already know Emacs and Symbolics, if you used something else, piss off" is a major turn-off.
It may seem like a small thing, but content that literally says "we expect you to already know Emacs and Symbolics, if you used something else, piss off" is a major turn-off.
if you're talking about https://web.archive.org/web/20170820092504im_/https://common..., then it literally did not say that. let me quote literally:
Given that you lisp, you're probably familiar with Emacs or the symbolics lisp machine. This environment shares some of its modality with these systems and is modeled (rather imperfectly), in their image.
that's too optimistic for sure, but how is it a turn-off without you putting different words into author's mouth?
Given that you lisp, you're probably familiar with Emacs or the symbolics lisp machine. This environment shares some of its modality with these systems and is modeled (rather imperfectly), in their image.
that's too optimistic for sure, but how is it a turn-off without you putting different words into author's mouth?
You conveniently left out the preceding sentence which is of the format "X, Y and Z can stop reading now" -- and whoever is left is assumed to already know Emacs or Symbolics.
no, i very narrowly responded to the content of your comment, because no matter how much of dick the guy may be (i have no idea but the screenshot certainly gave away a very imature impression), you, instead of attacking that preceding sentence, instead twisted the next one unfavorably.
your claim literally says "we expect you to already know Emacs and Symbolics, if you used something else, piss off" is bullshit, figuratively speaking. i just wanted to point out that your high horse of niceness is not so high or nice if you need to lean on slandering people. that's all. i don't know the guy or the software.
your claim literally says "we expect you to already know Emacs and Symbolics, if you used something else, piss off" is bullshit, figuratively speaking. i just wanted to point out that your high horse of niceness is not so high or nice if you need to lean on slandering people. that's all. i don't know the guy or the software.
Symbolics is long dead, and Emacs lost the edtor wars. A modern developer coming to Lisp would much rather use Sublime, Visual Studio Code, or even vim with appropriate plugins. This set of assumptions is increasingly invalid.
"Emacs lost the edtor wars."
The editor wars are not over yet. Emacs is still winning over new users, as is vim, and both are growing and improving all the time.
"A modern developer coming to Lisp would much rather use Sublime, Visual Studio Code, or even vim with appropriate plugins."
They might until they see the power of emacs tools like slime and paredit.
The editor wars are not over yet. Emacs is still winning over new users, as is vim, and both are growing and improving all the time.
"A modern developer coming to Lisp would much rather use Sublime, Visual Studio Code, or even vim with appropriate plugins."
They might until they see the power of emacs tools like slime and paredit.
Who are you to speak for everyone? Did vim users and emacs users meet on ye old battlefield and now the emacs users have to slink off in defeat and delete their emacs configs because more people use vim?
In reality there is plenty of support for both to continue.
In reality there is plenty of support for both to continue.
Gabriel is a buffoon of the highest order, and tries to sneak his bad attitude into nearly everything he ever contributes to.
Please don't defend him, especially via these kind of tactical omissions.
Please don't defend him, especially via these kind of tactical omissions.
Oh yeah Lisp is the only community with hostile individuals. Every sizeable community has such people and one must know to avoid them. It's hostile in itself to derive ideas about communities themselves from indiviudals' behaviour.
Lisp's hostile reputation dates back to when most language discussions happened on comp.lang.lisp on Usenet and the toxic environment created by Erik Naggum and his acolytes. It's a hard reputation to shake, apparently, seeing that it's a subject that still comes up decades later.
If it's in the project's official screenshots (under the heading "Get excited"), it's not unreasonable to assume that it's representative of the project community.
What was it?
It was this: https://web.archive.org/web/20170820092504im_/https://common...
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.
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.
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.
Mezzano is a open source Lisp OS: https://github.com/froggey/Mezzano
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.
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.
Please enter #clnoobs and #lisp at freenode IRC for meeting the community.
Welcome to the wonderful world of Common Lisp, and beware: CL is addictive like a hard drug!
Welcome to the wonderful world of Common Lisp, and beware: CL is addictive like a hard drug!
[deleted]
[deleted]
Why not react-like interface like reagent-project.github.io
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.