Re: [9front] Bounties

Re: [9front] Bounties

[Ethan Gardener]

On Fri, Jan 17, 2020, at 12:47 AM, sl@stanleylieber.com wrote:
> This is trivial to implement with existing tools:
> 
> 	; font=/lib/font/bit/lucidasans/boldunicode.7.font \
> 		@{while(){ hstats; sleep 60 }} | \
> 		aux/statusmsg -w 1082,5,1400,59 &	# [0]

I always forget about statusmsg. So we've got this, and rio is scriptable, which leaves 2 things: preventing clients resizing their own window, and keyboard control. I don't suppose it's hard to write a filter for /dev/kbd in C. It would have to run before rio. I think it could wait for rio's files to appear, or wait for rio's /srv file & mount it. This keygrabber could be quite generally useful.

Preventing resizing is a stranger problem. Window clients need to be prevented, but the keygrabber allowed. Or, one could simply not worry about it. Only games resize their window, right?

I'm not sure whether I want to take on the job. It might go all right, but I almost always end up frustrated with Plan 9. Actually, I don't; I've got tons of other things to do.

Re: [9front] Bounties

[kvik]

> I don't suppose it's hard to write a filter for /dev/kbd in C.

Indeed.

> It would have to run before rio.

There is your problem.

The proverbial shortcut machine needs to have a target rio -- actually a
current window -- bound in its namespace if it is to boss one around.

I can imagine some elaborate scheme to work around this, taking into
consideration the possibility of having lots of (sub)+rios, but...  this
is about as elegant as adding shortcuts you want to rio.c and calling it
a day.

-- 
kvik

Re: [9front] Bounties

[Silas McCroskey]

> The proverbial shortcut machine needs to have a target rio -- actually a
> current window -- bound in its namespace if it is to boss one around.

The quick-and-dirty way to do workspaces is sub-rios anyways, with the
"status bar" outside them, so that doesn't seem like a problem to me
for this case.

> rio is scriptable

http://sam-d.org/win/

contains a couple scripts I use for ad-hoc window management;
conspicuously missing is win/fill to tell a window to expand to fill
any empty space left by a recently-closed window, but that should
be doable as well by iterating through all the windows in the current
rio to determine what's empty space (though relative coordinates
in sub-rios -- the bane of rio scripting -- may trip you up here).

- sam-d

rio wishlists

[Lyndon Nerenberg]

Since we're bashing the rio wishlist, the one thing I would love to have
is p9p's virtual rio desktops.

But as a variation, with the ability to selectively configure individual
desktops in their own namespace, allowing for isolated plumber and
factotum instances as you switch between desktops.

You can do this now with recursive rio instances, but tracking the
sub-rios is a pain in the ass.  There's a real benefit to being
able to rip between virtual desktops using the scroll wheel on the
mouse.  I've been using this under p9p for years.  Having that
capability, with distinct namespaces, under native plan9 would be a
godsend.

--lyndon

Re: [9front] rio wishlists

[Stanley Lieber]

but 9front rio already uses the scrollwheel.

sl

Re: [9front] rio wishlists

[hiro]

 i like the idea of having only one layer of namespace separation in rio, i.e.
windows inside a subrio could all just share the same parent ns. would be
useful for me not to have to post every window's ns ressources in a
/srv. and the top-level rio would still allow separation (and by
default).
not sure i need a window manager for that :)

the main problem is that right now rio terminals have their own ns so
that they can have their own /dev/* files per window, bound there for
them by rio.
but there should be a way to allow partial sharing of namespaces, i.e.
all other files.

Re: [9front] rio wishlists

[Steve Simon]

sorry if i am stating the obvious but i use Local, a script that submits a command to the plumber, and as the plumber runs before rio everything run in Local effects all rio windows’s namespaces.

maybe you want finer grained control but this does enough for me.

-Steve


> On 18 Jan 2020, at 8:21 am, hiro <23hiro@gmail.com> wrote:
> 
>  i like the idea of having only one layer of namespace separation in rio, i.e.
> windows inside a subrio could all just share the same parent ns. would be
> useful for me not to have to post every window's ns ressources in a
> /srv. and the top-level rio would still allow separation (and by
> default).
> not sure i need a window manager for that :)
> 
> the main problem is that right now rio terminals have their own ns so
> that they can have their own /dev/* files per window, bound there for
> them by rio.
> but there should be a way to allow partial sharing of namespaces, i.e.
> all other files.

Re: [9front] rio wishlists

[hiro]

i suppose i could automate rc to prefix Local in front of everything.

still not sure.

Re: [9front] rio wishlists

[Ethan Gardener]

On Sat, Jan 18, 2020, at 8:19 AM, hiro wrote:
>  i like the idea of having only one layer of namespace separation in rio, i.e.
> windows inside a subrio could all just share the same parent ns. would be
> useful for me not to have to post every window's ns ressources in a
> /srv. and the top-level rio would still allow separation (and by
> default).
> not sure i need a window manager for that :)
> 
> the main problem is that right now rio terminals have their own ns so
> that they can have their own /dev/* files per window, bound there for
> them by rio.
> but there should be a way to allow partial sharing of namespaces, i.e.
> all other files.

If all programs prefixed an environment variable to their /dev files, rio wouldn't need to namespace at all, just fork the environment for each window (rfork e). Most of the prefixing cases could be handled by small changes to existing libraries.

Re: [9front] rio wishlists

[Ethan Gardener]

On Sat, Jan 18, 2020, at 12:23 AM, Lyndon Nerenberg wrote:
> There's a real benefit to being
> able to rip between virtual desktops using the scroll wheel on the
> mouse.

Alternative: Implement Exposé for Rio. *flees* :D

Re: [9front] rio wishlists

[hiro]

env variables aren't super flexible either.
i would prefer the higher granularity for namespaces which will have
many other benefits in unrelated scenarios, too.

Re: [9front] rio wishlists

[Ethan Gardener]

On Tue, Jan 21, 2020, at 9:49 AM, hiro wrote:
> env variables aren't super flexible either.
> i would prefer the higher granularity for namespaces which will have
> many other benefits in unrelated scenarios, too.

I don't see the problem. You'd still be able to use namespaces, but you wouldn't be forced to use them. Just rfork n if you want a window to have its own private namespace.

Re: [9front] rio wishlists

[hiro]

i just don't like having two slightly different systems for the same
thing. environment files and normal files.

Re: [9front] rio wishlists

[Ethan Gardener]

On Wed, Jan 22, 2020, at 4:47 PM, hiro wrote:
> i just don't like having two slightly different systems for the same
> thing. environment files and normal files.

I see what you mean, but already we have mount and /shr offering two slightly different systems for another single task, that of mounting removable storage. This situation exists primarily due to rio's private namespaces. This is actually the reason I thought about how to make rio work without private namespaces. ;) On the other hand, I'm not really sure my way would be more elegant overall. I don't hate /srv, it's simple and I admit it may be useful with other private-namespace situations.

Re: [9front] rio wishlists

[Marshall Conover]

> Alternative: Implement Exposé for Rio. *flees* :D

If this is the feature where you do some mouse gesture/button click
and all the windows shrink and appear on the screen at once, so that
you can select one, which is then foregrounded, I unironically would
support this behaviour. I've come to heavily rely upon it over the
last few months at work, and it scratches the same itch as tiling
window managers without feeling oppressive. If others don't protest
too loudly/ want to support the idea, I may consider putting a bounty
on it.

Thanks!

Marshall

On Thu, Jan 23, 2020 at 1:06 PM Marshall Conover <marzhall.o@gmail.com> wrote:
>
> > Alternative: Implement Expos=C3=A9 for Rio. *flees* :D
>
> If this is the feature where you do some mouse gesture/button click and all
> the windows shrink and appear on the screen at once, so that you can select
> one, which is then foregrounded, I unironically would support this
> behaviour. I've come to heavily rely upon it over the last few months at
> work, and it scratches the same itch as tiling window managers without
> feeling oppressive. If others don't protest too loudly/ want to support the
> idea, I may consider putting a bounty on it.
>
> Thanks!
>
> Marshall



-- 
Have a good day,

Marshall Conover

Re: [9front] rio wishlists

[hiro]

eekee: /srv and /shr never felt right to me either. they are not
orthogonal at all.

does everybody understand what i mean with higher granularity
namespace sharing? it might be non-obvious if you don't know the linux
mount namespaces and their features.

i might be all wrong about this, but then i still would like to see a
more generalized mechanism that is self-similar and orthogonal to
everything else.

Re: [9front] rio wishlists

[Julius Schmidt]

One mechanism would be turn the namespace into a tree of commands, which 
can then be shared only partially.
For instance, /dev could be a node in the tree which is shared among 
most/all programs.

Another approach would be to give mount/bind commands a number indicating 
priority, but I don't have a clear picture how that would work.

On Thu, 23 Jan 2020, hiro wrote:

> eekee: /srv and /shr never felt right to me either. they are not
> orthogonal at all.
>
> does everybody understand what i mean with higher granularity
> namespace sharing? it might be non-obvious if you don't know the linux
> mount namespaces and their features.
>
> i might be all wrong about this, but then i still would like to see a
> more generalized mechanism that is self-similar and orthogonal to
> everything else.
>

Re: [9front] rio wishlists

[Ethan Gardener]

On Thu, Jan 23, 2020, at 9:23 PM, hiro wrote:
> does everybody understand what i mean with higher granularity
> namespace sharing? it might be non-obvious if you don't know the linux
> mount namespaces and their features.

I think so. With my idea, the sections of the namespace you could change with env vars are fixed at compile time. I mean there might be just one var for cons kbd mouse and draw, or there might be two, but that's about it. File namespacing allows all sorts of detail changes which the program/library authors may not have considered.

> i might be all wrong about this, but then i still would like to see a
> more generalized mechanism that is self-similar and orthogonal to
> everything else.
>

On Thu, Jan 23, 2020, at 10:42 PM, Julius Schmidt wrote:
> One mechanism would be turn the namespace into a tree of commands, which 
> can then be shared only partially.
> For instance, /dev could be a node in the tree which is shared among 
> most/all programs.

Sounds like what I intend for my Forth, but that's an entirely different concept. :)

> Another approach would be to give mount/bind commands a number indicating 
> priority, but I don't have a clear picture how that would work.

I don't think I quite understand either of these, but they inspired this "namespace priorities" idea: A process may have multiple namespaces, each with a different priority. Files are searched for in the highest-priority namespace first, then if they're not found, the next highest, etc. Rio would then pass two namespaces to each of its children, the global namespace it itself inherited as a low priority, and a high-priority private namespace with only its window-specific files. (This also seems to provide a better means of union mounting.

What happens if Rio inherits multiple namespaces in this scheme? Some options:
A: They could all look like one single namespace with rio unable to distinguish between them.
B: Priorities are numbers, the priorities of inherited namespaces are reduced.
C: Namespaces occupy a linked list. A namespace's priority is simply determined by its position in the list.

C is by far my favourite, linked lists are so powerful in this context. One of the biggest reasons I like Forth so much is the power given by the dictionary being a linked list.

B has the same problem as BASIC and APL with their line numbers and goto. :)

Both B and C have a little problem: What *exactly* is inherited by child processes? Are the numbers/is the list copied to each child, or can the child mess with the priorities of its parent? Grandparent? I suspect it would be enough to always copy the priorities, but I'm tired and need to stop thinking now.

Re: [9front] rio wishlists

[Ethan Gardener]

On Fri, Jan 24, 2020, at 12:39 AM, Ethan Gardener wrote:
> On Thu, Jan 23, 2020, at 9:23 PM, hiro wrote:
> > does everybody understand what i mean with higher granularity
> > namespace sharing? it might be non-obvious if you don't know the linux
> > mount namespaces and their features.
> 
> I think so. With my idea, the sections of the namespace you could 
> change with env vars are fixed at compile time. I mean there might be 
> just one var for cons kbd mouse and draw, or there might be two, but 
> that's about it. File namespacing allows all sorts of detail changes 
> which the program/library authors may not have considered.

Errata: Even a single env var could point to a tree constructed in a fine-grained way. mount bind and srv(4) as you like, then point the environment variable at the mess you just constructed.

Re: [9front] rio wishlists

[Ethan Gardener]

On Thu, Jan 23, 2020, at 6:12 PM, Marshall Conover wrote:
> > Alternative: Implement Exposé for Rio. *flees* :D
> 
> If this is the feature where you do some mouse gesture/button click
> and all the windows shrink and appear on the screen at once, so that
> you can select one, which is then foregrounded, I unironically would
> support this behaviour. I've come to heavily rely upon it over the
> last few months at work, and it scratches the same itch as tiling
> window managers without feeling oppressive.

Yes, that's what I meant. I sometimes find it useful, although it requires I stop and refocus. (I've yet to find the perfect window selection mechanism.) 

> If others don't protest
> too loudly/ want to support the idea, I may consider putting a bounty
> on it.

The catch is mostly technical: it requires fast good-enough image scaling, and I think it probably requires it in the kernel. Ah... I just had a thought: cropping rather than scaling the windows might be better. Text windows would probably be easier to identify by part of their text. Acme and Sam would be identifiable by their colors and maybe text. Perhaps crop text windows around the text cursor or prompt, and others to the top left? Not sure how well that would work for mothra or page.

Re: [9front] rio wishlists

[Jeremy Jackins]

> The catch is mostly technical: it requires fast good-enough image scaling, and I think it probably requires it in the kernel.

What about pre-rendering the down-scaled images? For example, whenever
the number of windows (or their sizes) change, rio recalculates the
appropriate miniature image sizes so that all windows can
simultaneously fit on the screen, then pre-renders each of them in a
background thread. Once this is complete there isn't any work to do
except display them when the "exposé" function is called.

On Thu, 23 Jan 2020 at 15:51, Ethan Gardener <eekee57@fastmail.fm> wrote:
>
> On Thu, Jan 23, 2020, at 6:12 PM, Marshall Conover wrote:
> > > Alternative: Implement Exposé for Rio. *flees* :D
> >
> > If this is the feature where you do some mouse gesture/button click
> > and all the windows shrink and appear on the screen at once, so that
> > you can select one, which is then foregrounded, I unironically would
> > support this behaviour. I've come to heavily rely upon it over the
> > last few months at work, and it scratches the same itch as tiling
> > window managers without feeling oppressive.
>
> Yes, that's what I meant. I sometimes find it useful, although it requires I stop and refocus. (I've yet to find the perfect window selection mechanism.)
>
> > If others don't protest
> > too loudly/ want to support the idea, I may consider putting a bounty
> > on it.
>
> The catch is mostly technical: it requires fast good-enough image scaling, and I think it probably requires it in the kernel. Ah... I just had a thought: cropping rather than scaling the windows might be better. Text windows would probably be easier to identify by part of their text. Acme and Sam would be identifiable by their colors and maybe text. Perhaps crop text windows around the text cursor or prompt, and others to the top left? Not sure how well that would work for mothra or page.

Re: [9front] rio wishlists

[hiro]

yeah, aiju got what i meant. thanks for the nicer detailed description.

Re: [9front] Bounties

[Ethan Gardener]

On Fri, Jan 17, 2020, at 4:05 PM, kvik@a-b.xyz wrote:
> > I don't suppose it's hard to write a filter for /dev/kbd in C.
> 
> Indeed.
> 
> > It would have to run before rio.
> 
> There is your problem.

And I gave a suitable workaround.

> The proverbial shortcut machine needs to have a target rio -- actually a
> current window -- bound in its namespace if it is to boss one around.
> 
> I can imagine some elaborate scheme to work around this, taking into
> consideration the possibility of having lots of (sub)+rios, but...  this
> is about as elegant as adding shortcuts you want to rio.c and calling it
> a day.

I'm not sure why you're saying what you're saying in this post, kvik; subrios wouldn't help at all and a current window makes no sense for something grabbing the keys before rio can see them. Regardless, I more than agree with your final conclusion anyway. It would be more elegant to modify rio itself.

Re: [9front] Bounties

[Ori Bernstein]

On Fri, 17 Jan 2020 17:05:05 +0100, kvik@a-b.xyz wrote:

> > I don't suppose it's hard to write a filter for /dev/kbd in C.
> 
> Indeed.
> 
> > It would have to run before rio.
> 
> There is your problem.
> 
> The proverbial shortcut machine needs to have a target rio -- actually a
> current window -- bound in its namespace if it is to boss one around.
> 
> I can imagine some elaborate scheme to work around this, taking into
> consideration the possibility of having lots of (sub)+rios, but...  this
> is about as elegant as adding shortcuts you want to rio.c and calling it
> a day.
> 
> -- 
> kvik
> 

Another option is to just make things more programmable.

For example, if you had a writable /dev/$winid/kbd, and a /dev/prekbd which
let you insert a keyboard, when opened, would feed keyboard events into
your keyboard shortcut program instead of into the focused window, you
could do whatever you want.

-- 
    Ori Bernstein