[9front] [PATCH] programmable menus for rio

[9front] [PATCH] programmable menus for rio

[Jacob Moody]

Something I've been playing with is a way of exposing part of the rio
menu to the programs running within it. This is a bit of a simple
approach, but I would like to gauge interest that people have in
something along these lines before continuing.

This adds a /dev/menu file that can be written to
to add new entries to the button3menu. The file
can be read to get the text string of an added
menu entry when hit by the user.

Thanks,
moody


diff 8dcf65f21e079f471eef6d3b3d0360c7beac4cd6 uncommitted
--- a/sys/src/cmd/rio/dat.h
+++ b/sys/src/cmd/rio/dat.h
@@ -19,6 +19,7 @@
 	Qwsys,		/* directory of window directories */
 	Qwsysdir,		/* window directory, child of wsys */
 	Qtap,
+	Qmenu,

 	QMAX,
 };
@@ -326,6 +327,8 @@
 Channel *totap;		/* our keyboard input to tap program */
 Channel *wintap;	/* tell the tapthread which Window to send to */
 Window	*input;
+Channel *usermenu;
+Channel *userhit;
 QLock	all;			/* BUG */
 Filsys	*filsys;
 Window	*hidden[100];
--- a/sys/src/cmd/rio/fsys.c
+++ b/sys/src/cmd/rio/fsys.c
@@ -38,6 +38,7 @@
 	{ "window",	QTFILE,	Qwindow,		0400 },
 	{ "wsys",		QTDIR,	Qwsys,		0500|DMDIR },
 	{ "kbdtap",	QTFILE,	Qtap,	0660 },
+	{ "menu",	QTFILE,	Qmenu, 0660 },
 	{ nil, }
 };

--- a/sys/src/cmd/rio/rio.c
+++ b/sys/src/cmd/rio/rio.c
@@ -53,6 +53,7 @@
 	Delete,
 	Hide,
 	Exit,
+	Hidden,
 };

 enum
@@ -82,8 +83,6 @@
 	menu2str
 };

-int	Hidden = Exit+1;
-
 char		*menu3str[100] = {
  [New]		"New",
  [Reshape]	"Resize",
@@ -94,6 +93,9 @@
 			nil
 };

+char *userentry[64] = { nil };
+int nusermenu = 0;
+
 Menu menu3 =
 {
 	menu3str
@@ -193,6 +195,8 @@
 	if(mousectl == nil)
 		error("can't find mouse");
 	mouse = mousectl;
+	usermenu = chancreate(sizeof(char*), 0);
+	userhit = chancreate(sizeof(char*), 0);
 	kbdchan = initkbd();
 	if(kbdchan == nil)
 		error("can't find keyboard");
@@ -528,7 +532,9 @@
 mousethread(void*)
 {
 	int sending, inside, scrolling, moving;
+	int j;
 	Window *w, *winput;
+	char *s;
 	Image *i;
 	Point xy;
 	Mouse tmp;
@@ -535,6 +541,7 @@
 	enum {
 		MReshape,
 		MMouse,
+		MUser,
 		NALT
 	};
 	static Alt alts[NALT+1];
@@ -549,10 +556,24 @@
 	alts[MMouse].c = mousectl->c;
 	alts[MMouse].v = &mousectl->Mouse;
 	alts[MMouse].op = CHANRCV;
+	alts[MUser].c = usermenu;
+	alts[MUser].v = &s;
+	alts[MUser].op = CHANRCV;
 	alts[NALT].op = CHANEND;

 	for(;;)
 	    switch(alt(alts)){
+		case MUser:
+			if(strncmp("add ", s, 4) == 0){
+				if(s+4 != '\0')
+					userentry[nusermenu++] = strdup(s+4);
+			}else if(strncmp("reset", s, 5) == 0){
+				for(j=0; j < nusermenu; j++)
+					free(userentry[j]);
+				nusermenu=0;
+			}
+			free(s);
+			break;
 		case MReshape:
 			resized();
 			break;
@@ -771,7 +792,8 @@
 void
 button3menu(void)
 {
-	int i, j, n;
+	int i, j, n, u;
+	char *s;

 	n = nhidden;
 	for(i=0; i<nwindow; i++){
@@ -785,11 +807,15 @@
 					break;
 			}
 	}
-	if(n >= nelem(menu3str)-Hidden)
+	for(u=0; u < nusermenu; u++){
+		free(menu3str[u+Hidden]);
+		menu3str[u+Hidden] = strdup(userentry[u]);
+	}
+	if(n >= nelem(menu3str)-(Hidden+u))
 		n = nelem(menu3str)-Hidden-1;
-	for(i=0; i<n; i++){
+	for(i=u; i<n+u; i++){
 		free(menu3str[i+Hidden]);
-		menu3str[i+Hidden] = shortlabel(hidden[i]->label);
+		menu3str[i+Hidden] = shortlabel(hidden[i-u]->label);
 	}
 	for(i+=Hidden; menu3str[i]; i++){
 		free(menu3str[i]);
@@ -818,7 +844,13 @@
 		confirmexit();
 		break;
 	default:
-		unhide(i);
+		i -= Hidden;
+		if(i < u){
+			s = strdup(menu3str[i+Hidden]);
+			if(nbsendp(userhit, s) != 1)
+				free(s);
+		} else
+			unhide(i-u);
 		break;
 	}
 	sweeping = FALSE;
@@ -1202,9 +1234,6 @@
 {
 	Window *w;

-	if(j < Hidden)
-		return;
-	j -= Hidden;
 	w = hidden[j];
 	if(w == nil)
 		return;
--- a/sys/src/cmd/rio/xfid.c
+++ b/sys/src/cmd/rio/xfid.c
@@ -585,6 +585,15 @@
 		}
 		break;

+	case Qmenu:
+		if(x->data[cnt-1] == '\n'){
+			if(cnt == 1)
+				break;
+			x->data[cnt-1] = '\0';
+		}
+		chanprint(usermenu, "%.*s", cnt, x->data);
+		break;
+
 	default:
 		fprint(2, "unknown qid %d in write\n", qid);
 		filsysrespond(x->fs, x, &fc, "unknown qid in write");
@@ -864,6 +873,34 @@
 		}
 		free(t);
 		return;
+
+	case Qmenu:
+		alts[Adata].c = userhit;
+		alts[Adata].v = &t;
+		alts[Adata].op = CHANRCV;
+		alts[Agone].c = w->gone;
+		alts[Agone].v = nil;
+		alts[Agone].op = CHANRCV;
+		alts[Aflush].c = x->flushc;
+		alts[Aflush].v = nil;
+		alts[Aflush].op = CHANRCV;
+		alts[Aend].op = CHANEND;
+
+		switch(alt(alts)){
+		case Adata:
+			break;
+		case Agone:
+			filsysrespond(x->fs, x, &fc, Edeleted);
+			return;
+		case Aflush:
+			filsyscancel(x);
+			return;
+		}
+		fc.data = t;
+		fc.count = strlen(t);
+		filsysrespond(x->fs, x, &fc, nil);
+		free(t);
+		break;

 	default:
 		fprint(2, "unknown qid %d in read\n", qid);

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

[ori]

Quoth Jacob Moody <moody@mail.posixcafe.org>:
> Something I've been playing with is a way of exposing part of the rio
> menu to the programs running within it. This is a bit of a simple
> approach, but I would like to gauge interest that people have in
> something along these lines before continuing.
> 
> This adds a /dev/menu file that can be written to
> to add new entries to the button3menu. The file
> can be read to get the text string of an added
> menu entry when hit by the user.
> 
> Thanks,
> moody
> 

It seems like an interesting trick -- but, the
programs that might use it would already likely
be graphical, no?

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

[Jacob Moody]

On 8/23/22 20:46, ori@eigenstate.org wrote:
> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>> Something I've been playing with is a way of exposing part of the rio
>> menu to the programs running within it. This is a bit of a simple
>> approach, but I would like to gauge interest that people have in
>> something along these lines before continuing.
>>
>> This adds a /dev/menu file that can be written to
>> to add new entries to the button3menu. The file
>> can be read to get the text string of an added
>> menu entry when hit by the user.
>>
>> Thanks,
>> moody
>>
> 
> It seems like an interesting trick -- but, the
> programs that might use it would already likely
> be graphical, no?
> 

Switching languages via special character in ktrans
doesn't feel quite right to me. I wanted a graphical
way of switching them, and it seemed like something
I wanted on the rio menu.

I considered making ktrans itself graphical, but then this
complicates combining it with other filters.

This was the next step in iterating ways of getting
something I liked. Perhaps ktrans is special in this
regard. I think it could be generalized to programs
that are aiming to kind of slot in to rio instead
of run as a graphic program like ktrans is.

Maybe the solution is that ktrans serves an interface
like kbdmap optionally with a flag or the like.

Just kind of thinking aloud here.

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

[qwx]

On Wed Aug 24 07:01:48 +0200 2022, moody@mail.posixcafe.org wrote:
> On 8/23/22 20:46, ori@eigenstate.org wrote:
> > Quoth Jacob Moody <moody@mail.posixcafe.org>:
> >> Something I've been playing with is a way of exposing part of the rio
> >> menu to the programs running within it. This is a bit of a simple
> >> approach, but I would like to gauge interest that people have in
> >> something along these lines before continuing.
> >>
> >> This adds a /dev/menu file that can be written to
> >> to add new entries to the button3menu. The file
> >> can be read to get the text string of an added
> >> menu entry when hit by the user.
> >>
> >> Thanks,
> >> moody
> >>
> > 
> > It seems like an interesting trick -- but, the
> > programs that might use it would already likely
> > be graphical, no?
> > 
> 
> Switching languages via special character in ktrans
> doesn't feel quite right to me. I wanted a graphical
> way of switching them, and it seemed like something
> I wanted on the rio menu.

This is interesting.  umbraticus and I experimented with adding menu2
entries in sam for commands we use all of the time.  Initially I tried
doing this with menu entries for adding/removing items, but it was
horrible.  umbraticus proposed defining a new sam command `M' which
adds or removes a menu entry: as an example, `M ^R mk install' would
add `^R mk install' verbatim to the menu (R being some sam script),
and sending this again would remove it.  We both have scripts which
define a bunch of rc functions to use within sam, which also works for
adding stuff at the start of a session.  Then, while using sam, one
can add or remove commands one ends up using a whole bunch during a
session instead of switching to the command menu, finding, selecting
and sending them, which happens way too often for me (for example,
things like `|fmt -l 80', `|cmd |awk ...' or `!window -m -cd ...
cmd', etc.).  This works very nicely in my case.

For rio, it's a bit different, and I don't know how it would work out
or what the best interface would be, but I think it's worth
discussing.

Cheers,
qwx

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

[Jacob Moody]

On 8/24/22 01:05, qwx@sciops.net wrote:
> On Wed Aug 24 07:01:48 +0200 2022, moody@mail.posixcafe.org wrote:
>> On 8/23/22 20:46, ori@eigenstate.org wrote:
>>> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>>>> Something I've been playing with is a way of exposing part of the rio
>>>> menu to the programs running within it. This is a bit of a simple
>>>> approach, but I would like to gauge interest that people have in
>>>> something along these lines before continuing.
>>>>
>>>> This adds a /dev/menu file that can be written to
>>>> to add new entries to the button3menu. The file
>>>> can be read to get the text string of an added
>>>> menu entry when hit by the user.
>>>>
>>>> Thanks,
>>>> moody
>>>>
>>>
>>> It seems like an interesting trick -- but, the
>>> programs that might use it would already likely
>>> be graphical, no?
>>>
>>
>> Switching languages via special character in ktrans
>> doesn't feel quite right to me. I wanted a graphical
>> way of switching them, and it seemed like something
>> I wanted on the rio menu.
> 
> This is interesting.  umbraticus and I experimented with adding menu2
> entries in sam for commands we use all of the time.  Initially I tried
> doing this with menu entries for adding/removing items, but it was
> horrible.  umbraticus proposed defining a new sam command `M' which
> adds or removes a menu entry: as an example, `M ^R mk install' would
> add `^R mk install' verbatim to the menu (R being some sam script),
> and sending this again would remove it.  We both have scripts which
> define a bunch of rc functions to use within sam, which also works for
> adding stuff at the start of a session.  Then, while using sam, one
> can add or remove commands one ends up using a whole bunch during a
> session instead of switching to the command menu, finding, selecting
> and sending them, which happens way too often for me (for example,
> things like `|fmt -l 80', `|cmd |awk ...' or `!window -m -cd ...
> cmd', etc.).  This works very nicely in my case.
> 

I would 100% be behind bringing this sam work upstream.
That is quite neat.

> For rio, it's a bit different, and I don't know how it would work out
> or what the best interface would be, but I think it's worth
> discussing.

Yeah I'm not sure what the right solution here, I'm just throwing
out code to start the conversation.

- moody

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

[Michael Misch]

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.

> On Aug 24, 2022, at 06:38, Jacob Moody <moody@mail.posixcafe.org> wrote:
> 
> On 8/24/22 01:05, qwx@sciops.net wrote:
>> On Wed Aug 24 07:01:48 +0200 2022, moody@mail.posixcafe.org wrote:
>>> On 8/23/22 20:46, ori@eigenstate.org wrote:
>>>> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>>>>> Something I've been playing with is a way of exposing part of the rio
>>>>> menu to the programs running within it. This is a bit of a simple
>>>>> approach, but I would like to gauge interest that people have in
>>>>> something along these lines before continuing.
>>>>> 
>>>>> This adds a /dev/menu file that can be written to
>>>>> to add new entries to the button3menu. The file
>>>>> can be read to get the text string of an added
>>>>> menu entry when hit by the user.
>>>>> 
>>>>> Thanks,
>>>>> moody
>>>>> 
>>>> 
>>>> It seems like an interesting trick -- but, the
>>>> programs that might use it would already likely
>>>> be graphical, no?
>>>> 
>>> 
>>> Switching languages via special character in ktrans
>>> doesn't feel quite right to me. I wanted a graphical
>>> way of switching them, and it seemed like something
>>> I wanted on the rio menu.
>> 
>> This is interesting.  umbraticus and I experimented with adding menu2
>> entries in sam for commands we use all of the time.  Initially I tried
>> doing this with menu entries for adding/removing items, but it was
>> horrible.  umbraticus proposed defining a new sam command `M' which
>> adds or removes a menu entry: as an example, `M ^R mk install' would
>> add `^R mk install' verbatim to the menu (R being some sam script),
>> and sending this again would remove it.  We both have scripts which
>> define a bunch of rc functions to use within sam, which also works for
>> adding stuff at the start of a session.  Then, while using sam, one
>> can add or remove commands one ends up using a whole bunch during a
>> session instead of switching to the command menu, finding, selecting
>> and sending them, which happens way too often for me (for example,
>> things like `|fmt -l 80', `|cmd |awk ...' or `!window -m -cd ...
>> cmd', etc.).  This works very nicely in my case.
>> 
> 
> I would 100% be behind bringing this sam work upstream.
> That is quite neat.
> 
>> For rio, it's a bit different, and I don't know how it would work out
>> or what the best interface would be, but I think it's worth
>> discussing.
> 
> Yeah I'm not sure what the right solution here, I'm just throwing
> out code to start the conversation.
> 
> - moody

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

[Stanley Lieber]

i don’t necessarily object to this particular change, but the general lack of features is a conscious design choice.

sl


> On Aug 24, 2022, at 1:26 PM, Michael Misch <michaelmisch1985@gmail.com> wrote:
> 
> 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.
> 
>> On Aug 24, 2022, at 06:38, Jacob Moody <moody@mail.posixcafe.org> wrote:
>> 
>>> On 8/24/22 01:05, qwx@sciops.net wrote:
>>> On Wed Aug 24 07:01:48 +0200 2022, moody@mail.posixcafe.org wrote:
>>>> On 8/23/22 20:46, ori@eigenstate.org wrote:
>>>>> Quoth Jacob Moody <moody@mail.posixcafe.org>:
>>>>>> Something I've been playing with is a way of exposing part of the rio
>>>>>> menu to the programs running within it. This is a bit of a simple
>>>>>> approach, but I would like to gauge interest that people have in
>>>>>> something along these lines before continuing.
>>>>>> 
>>>>>> This adds a /dev/menu file that can be written to
>>>>>> to add new entries to the button3menu. The file
>>>>>> can be read to get the text string of an added
>>>>>> menu entry when hit by the user.
>>>>>> 
>>>>>> Thanks,
>>>>>> moody
>>>>>> 
>>>>> 
>>>>> It seems like an interesting trick -- but, the
>>>>> programs that might use it would already likely
>>>>> be graphical, no?
>>>>> 
>>>> 
>>>> Switching languages via special character in ktrans
>>>> doesn't feel quite right to me. I wanted a graphical
>>>> way of switching them, and it seemed like something
>>>> I wanted on the rio menu.
>>> 
>>> This is interesting.  umbraticus and I experimented with adding menu2
>>> entries in sam for commands we use all of the time.  Initially I tried
>>> doing this with menu entries for adding/removing items, but it was
>>> horrible.  umbraticus proposed defining a new sam command `M' which
>>> adds or removes a menu entry: as an example, `M ^R mk install' would
>>> add `^R mk install' verbatim to the menu (R being some sam script),
>>> and sending this again would remove it.  We both have scripts which
>>> define a bunch of rc functions to use within sam, which also works for
>>> adding stuff at the start of a session.  Then, while using sam, one
>>> can add or remove commands one ends up using a whole bunch during a
>>> session instead of switching to the command menu, finding, selecting
>>> and sending them, which happens way too often for me (for example,
>>> things like `|fmt -l 80', `|cmd |awk ...' or `!window -m -cd ...
>>> cmd', etc.).  This works very nicely in my case.
>>> 
>> 
>> I would 100% be behind bringing this sam work upstream.
>> That is quite neat.
>> 
>>> For rio, it's a bit different, and I don't know how it would work out
>>> or what the best interface would be, but I think it's worth
>>> discussing.
>> 
>> Yeah I'm not sure what the right solution here, I'm just throwing
>> out code to start the conversation.
>> 
>> - moody
> 
> 

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

[ori]

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.

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

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

ori@eigenstate.org writes:

> 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.

I'm with Ori on this.

> 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.

Given that rio has had a couple of decades to bake, the
world has changed around it, and thinking of new stuff
is always a good idea.  But diddling with rio just seems
a path to feechur bloat.  If you really want to try new
things, it's best to start from the ground up (IMO).
But the joy of rio is you can write and experiment with
your new stuff inside of rio, without breaking your
existing environment.

But what I *am* really reluctant to embrace is thowing
new files into /dev in a willy-nilly fashion.  The
current scheme for /dev files and how they get used has
some deep thought behind it, and I think anyone should
think long and hard about how new facilities can be
merged into the existing interfaces before throwing
new files at /dev (or anywhere else).  As always,
try to solve for the general case.

--lyndon

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

[Stuart Morrow]

On 24/08/2022, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
> [ something about new /dev files ]

I don't get why kbdtap is in rio rather than kbdfs.

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

[Jacob Moody]

On 8/24/22 13:31, Stuart Morrow wrote:
> On 24/08/2022, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca> wrote:
>> [ something about new /dev files ]
> 
> I don't get why kbdtap is in rio rather than kbdfs.

I wanted information known only to rio, namely when
a user switches windows so ktrans knows when to reset the
line buffer. I originally had this communicated via
a message through kbdtap. That is no longer the case
pending me figuring a better way of communicating
this information. There isn't much of a technical reason
for why kbdtap couldn't exist within kbdfs. I do enjoy
that I can run a kbdtap program in a subrio for testing
and have it isolated there. But this has been something
I've thought about. I haven't convinced myself enough
to allot the time to do the rewrite.

On 8/24/22 12:56, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote:
> Given that rio has had a couple of decades to bake, the
> world has changed around it, and thinking of new stuff
> is always a good idea.  But diddling with rio just seems
> a path to feechur bloat.  If you really want to try new
> things, it's best to start from the ground up (IMO).
> But the joy of rio is you can write and experiment with
> your new stuff inside of rio, without breaking your
> existing environment.

I think most would agree that a rio rewrite could be
very nice. But let's not pretend that is an easy
task. I want to be cautious about blocking any
forward movement or experimentation for some
mythical rewrite. Especially since it seems no one
has expressed enough interest to actually start
working on it.

I think I am starting to learn why people
don't enjoy working on rio. Disregarding the code, it
seems like its impossible to make a change that someone
isn't disgruntled with.

-- moody

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

[Jacob Moody]

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

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

[ori]

Quoth Stuart Morrow <morrow.stuart@gmail.com>:
> 
> I don't get why kbdtap is in rio rather than kbdfs.

It needed to be somewhere, and rio is somewhere.

There are some advantages to putting it in rio, there
are some advantages to putting it in kbdfs, but in the
end, the interface seems to be exactly what is needed,
and if there's a clear advantage it can be moved with
no change in interface. And the interface being right
is the most important thing, since it admits a number
of implementations.

If you feel strongly about moving it out of rio, I
think it'd be possible to send moody a patch along
with a strong argument to move it.

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

[hiro]

i have a lot of experience with a programmable / scriptable
windowmanager that is controlled via a file based 9p interface and
including the here mentioned idea of blocking event file reads.

over decades i found endless llittle tweaks for perfecting my most
common tasks and automated away repetitive interactions that are
unique to my personal usage patterns.

all using very few lines of shell scripts.

the lack of such feature in rio is what led to the obnoxious acme
application imho.

the possibilities may not seem very apparent at first glance but in my
experience a lot of small quality of life improvements add up to very
near perfect subjective user experience.

i would welcome this possibility on 9front.

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

[Mark van Atten]

On Sat, 27 Aug 2022 at 15:32, hiro <23hiro@gmail.com> wrote:
>
> i have a lot of experience with a programmable / scriptable
> windowmanager that is controlled via a file based 9p interface and
> including the here mentioned idea of blocking event file reads.

Is this wmii? Either way, are there some example scripts you could share?

Mark.

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

[hiro]

yes wmii.
my scripts are highly personal. i have highly modified wmiirc.
switching windows can trigger third scripts depending on window
content (inferred through window title or tag name).
it makes no sense to share my script, but please read wmiirc :)

On 8/27/22, Mark van Atten <vanattenmark@gmail.com> wrote:
> On Sat, 27 Aug 2022 at 15:32, hiro <23hiro@gmail.com> wrote:
>>
>> i have a lot of experience with a programmable / scriptable
>> windowmanager that is controlled via a file based 9p interface and
>> including the here mentioned idea of blocking event file reads.
>
> Is this wmii? Either way, are there some example scripts you could share?
>
> Mark.
>

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

[ori]

Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>:
> Given that rio has had a couple of decades to bake, the
> world has changed around it, and thinking of new stuff
> is always a good idea. 

My point goes beyond that -- rio can be thought of as an
implementation of a more general file system interface
that can be implemented by other windowing systems.

The parsimony and focus in that interface makes it easier
to swap rio for a window system that behaves differently
but provides the same mouse and keyboard multiplexing
to the programs running under it.

Rio can -- and I think, should -- change. The interface,
though, needs to be considered with care if we want to
maintain its general nature.

Arguably, rio *also* wasn't a sufficiently good steward
of this to date.

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

[Stanley Lieber]

just call it brio.

sl



> On Aug 24, 2022, at 4:05 PM, ori@eigenstate.org wrote:
> 
> Quoth Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon@orthanc.ca>:
>> Given that rio has had a couple of decades to bake, the
>> world has changed around it, and thinking of new stuff
>> is always a good idea. 
> 
> My point goes beyond that -- rio can be thought of as an
> implementation of a more general file system interface
> that can be implemented by other windowing systems.
> 
> The parsimony and focus in that interface makes it easier
> to swap rio for a window system that behaves differently
> but provides the same mouse and keyboard multiplexing
> to the programs running under it.
> 
> Rio can -- and I think, should -- change. The interface,
> though, needs to be considered with care if we want to
> maintain its general nature.
> 
> Arguably, rio *also* wasn't a sufficiently good steward
> of this to date.
> 
>