Re: [9front] [PATCH] programmable menus for rio

[ori@eigenstate.org]

Quoth Michael Misch <michaelmisch1985@gmail.com>:
> I really like the concept for this type of menu. Being able to extend behaviours, without it being clunky is a hallmark feature of Acme, for example. This same mindset being extended outwards into Rio where it has been considerably more rigid in adhering to the designed usage from the outset, enables things that may not have been conceived or considered in the 90s and early 2000s when these designs were laid.

I like the concept; I wonder how it'd be used.

It may make more sense to just run a command on the menu entry -- and,
at that point, if you want to have the menu entry name sent, you could
echo into a pipe:

	echo 'menu 3 Foo echo foo >/srv/event'

where menu 3 would say to add it to the button3 menu,
'Foo' would be the name of the entry, and 'echo ...'
would be run in an rc shell when the button is clicked.

At the same time, I've got some hesitation because this
is part of the rio interface -- and the more we add to
the rio interface, the less it becomes a general interface
it becomes.

In the past, there's been talk of a notebook style rio
replacement, and every knob and feature we add to rio
would become something that we'd need to fit into (or
shoehorn into) this hypothetical rio alternative.

This isn't a statement that it's a bad idea to add this,
just an observation that general, reimplementable, widely
usable interfaces are hard, and need some careful
consideration.

I like that rio is mostly forwarding the console and
devdraw interfaces, without too much addition, and the
way that it's *mostly* just a multiplexer.

Bug, given how much talk there's been of rio alternatives,
and how little code has been written, maybe this isn't
something that needs consideration.

I don't know the right balance here.