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

[Jacob Moody <moody@mail.posixcafe.org>]

On 8/24/22 14:10, Jacob Moody wrote:
> There isn't much of a technical reason
> for why kbdtap couldn't exist within kbdfs.

I've been giving this quite a bit of thought.
I also recalled some discussion I had with cinap
on this topic.

This issue is what happens with misbehaving taps.
If you are making use of kbdtap outside of a rio
environment. A

cat /dev/kbdtap >/dev/null &

will lock you out completely with no hopes of escape.
This is an interface with some pointy edges, programs
that use it gain a lot of power over the overall
stability of your session. In some ways I think you
want to enforce that these run under rio so you
can keep an eye on them. You need the escape
hatch of deleting the window to regain normal
operation. A bug in a kbdtap program shouldn't nuke
my session.

Ori mentioned it earlier, the primary focus
of rio is multiplexing. The children windows of rio
(ideally) think they are just running in tiny screen. Some of
the devdraw bits under the hood break this abstraction
but that's besides the point. What I seem to be searching
for here is not an interface to rio the multiplexer, but rio the
window manager. I want to interact with its menus, its stream
of characters, get events about things like focus changes. In a way
that Mail is built on top of acme, I would (like to) view something like
ktrans as being built on top of rio.

I can understand an argument for keeping rio as more of a multiplexer,
but I don't think I share the sentiment. When I first started this
work, I was quite surprised to see how widely used riow was. There is
evidently a desire for people to plug programs in to rio. I dont think
this is a new sentiment either, a lot of /mnt/wsys is built for this
and programs like winwatch have been doing this for a long time.
In that way, the general problem I want to solve is that the interface
to rio the window manager is a bit lackluster.

Just some more thought, I didn't like my first response.

-- moody