3 ms·

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 d

by Athas 9y ago

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 9y ago
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 9y ago
  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 9y ago
    "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 9y ago
      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.

by Athas 9y ago

jstimpfle 9y ago

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 9y ago
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 9y ago
  "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 9y ago
    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.