Re: Command interfaces like the Lisp Machine

On 03/11/2014 04:22 PM, Bruce Mitchener wrote:
> Lately, prom has been developing a library called "command-interface"
> which is now available here:
>
>     https://github.com/dylan-lang/command-interface/
>
> How might we use this?
>
>   * When running a build, we might show a progress bar as it goes
>     through the files in a project when we can, and keep the warnings
>     scrolling above that.
>   * When showing a class hierarchy, in a rich application, we'd be
>     able to have mouse actions attached to classes to further interact
>     with them. We'd also be able to show hierarchies graphically and
>     be able to interact with the graph.
>

My original background with regards to this is using the CLI
for "system control" in a manner similar in style to network equipment.

A web service would offer a separate control program that you can start
to interact with the service in various ways such as dynamic reconfiguration
as well as monitoring and debugging. Next to command output the
system would display a continuous log stream from the logging library.

My intention is to offer a command system that feels snappy like a hackers
tool but is as approachable as a command-driven system can be.

>
> I think a starting approach might be to have data models that commands
> can interact with and views or presentations of that data model that
> can be displayed. This makes it a pretty classic MVC model.
>
> A command needs to be able to start the presentation prior to the
> command completing because many commands are long-running (builds,
> tests, etc).  I think we can define abstract classes for the
> presentations and then let the display / terminal create the right
> per-display class that is needed.
>
> We'd also have gadgets or widgets which represent the basic things
> that a UI is built with (much like DUIM). This would hopefully make it
> fairly easy to go about creating a presentation on top of a basic set
> of widgets. Perhaps we could even use parts of DUIM here? I'm not sure.

I would like to have this implemented as two separate layers, where the
"basic" layer
supports only a certain set of abstractions, namely those that can
actually work
well on character cell terminals. I think these are:

- "basic" markup
   (tables, text attributes, enhanced pretty printing)
- text editor views with basic output-only markup
   (fully textual command entry, including basic multiline editing if
desired)

Above that there should be a layer that supports full fancy graphical
systems, where
I am in favor of offering comprehensive compatibility between "web" and
"native UI":

- "advanced" markup with interactive elements
   (supercharged pprint that can build GUI hierarchies or HTML with
possible AJAX updates)
- interaction on views including issue of new commands by clicking (like
genera)

My reason for wanting to separate these is that I want a "clean"
terminal-friendly subset
for my own purposes as well as for "system control".

I am not sure how to approach native toolkits for the "advanced" version.
Many things that feel natural in markup systems map badly to classical GUIs.
Maybe the default, even for DUIM, should be displaying small web views,
but I'm not sure how large the cost of these is in modern Qt.

> The goal is that it should be easy to create better text UI than just
> spewing output to a stream and eventually, it should be easy to have
> this UI upgrade to richer capabilities (HTML, native widgets, etc).
>
> Thoughts?
>
>  - Bruce
>
>
>
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers