From: Jacob Moody <firstname.lastname@example.org>
Subject: Re: [9front] [PATCH] programmable menus for rio
Date: Thu, 25 Aug 2022 00:40:45 -0600 [thread overview]
Message-ID: <email@example.com> (raw)
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
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
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.
next prev parent reply other threads:[~2022-08-25 6:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-24 1:40 Jacob Moody
2022-08-24 2:46 ` ori
2022-08-24 5:02 ` Jacob Moody
2022-08-24 7:05 ` qwx
2022-08-24 13:38 ` Jacob Moody
2022-08-24 17:26 ` Michael Misch
2022-08-24 17:30 ` Stanley Lieber
2022-08-24 17:37 ` ori
2022-08-24 18:56 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2022-08-24 19:31 ` Stuart Morrow
2022-08-24 20:10 ` Jacob Moody
2022-08-25 6:40 ` Jacob Moody [this message]
2022-08-27 3:40 ` ori
2022-08-27 13:30 ` hiro
2022-08-27 14:23 ` Mark van Atten
2022-08-27 17:22 ` hiro
2022-08-24 20:04 ` ori
2022-08-24 20:17 ` Stanley Lieber
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).