[0x445442]

The problem is applications. Applications, even within an environment of standardized widgets, still present a wildly disjointed experience to users. Now you throw in the infinite number of UI paradigms available with HTML/CSS/JS and you have a modern desktop that requires so much context switching between one use case and another that users who are trying to be more efficient with their computing are slammed in the face.

I believe that's why "power" users gravitate to the command line. With the command line and terminal you have a much more cohesive experience with your computing.

Jeff Raskin with the Canon Cat (http://www.canoncat.org/) and his son Aza with Enso (https://therichwebexperience.com/blog/aza_raskin/2007/01/ens...) and later with Ubiquity (https://venturebeat.com/2008/08/27/mozilla-labs-aza-raskin-t...) attempted to address this problem.

Actually, the first time I started to recognize this issue was back in 1996 when I read about David Galernter's Lifestreams (http://www.cs.yale.edu/homes/freeman/lifestreams.html).

The current state of affair;, Emacs goes quite a ways to solving this problem. Where Emacs falls down is the ability render html content and graphical content in general the way a browser does. If Emacs could render graphical content then I think it could be used to implement my ideal UI.

My ideal UI would be this:

1. Command input component similar to browser omni bars or Emacs M-X interface which parses command input and delegates to service.

2. Result of command entry is a list of 0-N items presented in a tree list view with the first item in the list selected by default. Think old Usenet UI.

3. Any item selected in 2 renders its own view. Again think of old Usenet UI. However instead of just text this item renderer can be anything. Text, graphics, embedded video, etc.

4. The resultant list of any command can, in turn, be used as input to a following command. Think Unix pipe.

The result is an interface that's a hybrid of the command line and Emacs M-x but is modern enough to handle more than text rendering. With this interface you don't develop applications but agents/verbs that return items and you provide renderers for each item

[fao_]

> 1. Command input component similar to browser omni bars or Emacs M-X interface which parses command input and delegates to service.

You might find what you're looking for in dmenu: https://tools.suckless.org/dmenu/

[0x445442]

Yeah, so dmenu might potentially cover the command input bit but AFAIK it's really just like Enso, QuickSilver, Launchy etc. What I'm thinking of doesn't really index executables per say but allows for the registration of commands.

What I'm thinking of is limited in scope to "commands" that are registered with the component. Maybe dmenu can be bent to this use case; thanks for the link.

[curioussavage]

I found a really cool project that makes a sublime style command menu for any gtk app https://github.com/p-e-w/plotinus. Still need to try it but it sounds awesome

[0x445442]

That's cool... It seems KDE's KRunner is pretty extendable as well. (https://techbase.kde.org/Development/Tutorials/Plasma4/Abstr...)

[fao_]

dmenu at it's core takes a list of input (dmenu_path), fuzzy matches it, and then just fork()s off or something like that, it's tiny so it'd be trivial to alter it so it does something else with that match. You could hook it up to xdotool or something and have it send a command to alter the current X app or whatever.

[zeckalpha]

What are executables on your PATH but registered commands?