From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4b8f2a947c17af3c8fe8ca001601c4ea@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Thu,  3 Mar 2005 03:47:19 +0000
From: rog@vitanuova.com
In-Reply-To: <Pine.LNX.4.58.0502171034450.19065@enigma.lanl.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 5989605e-eace-11e9-9e20-41e7f4b1d025

> So, yes, rio is a fine and wonderful thing, but I don't buy it as the
> be-all and end-all of window managers.

winwatch helps, but i have to say, i do find available screen space
restrictive (and i'm running at 1400x1050). i run with acme
taking up all the horizontal space and 95% of the vertical
space, leaving a strip along the top for access to windows.
winwatch is useful.

> With multiple desktops, as much as I like rio, I find it easier to use
> flwm and swap around with CTRL-F[1234] etc.

so, like a fool, i thought "this'll be totally easy to do with rio; i'll just
place a filter onto its keyboard input that switches windows when it
sees a function key".

there sure are some sticky bits lurking under the surface in plan 9 if
you swim where others haven't swum before...

i kinda got it working, but it's not really usable.  here are some
gotchas i encountered along the way:

1) you can't make a full screen window in rio (1 pixel less in each dimension)
2) you can't make a borderless window in rio.
3) creation of a badly sized window fails silently.
4) there's no way of finding out the current available screen (*not* display)
	size when running rio in rio.
5) screenids run out quickly when you've got multiple clients creating screens
	(see /sys/src/libdraw/window.c:/25). most people don't notice
	because most windows are created by the same draw client.
	try:
		cpu
		for(i in `{seq 1 25}){window -m lens}
	perhaps screenid should probably be seeded somewhere random-ish
	(e.g. milliseconds^pid) and increase by prime multiples.

	at the least, the loop should at least detect that it's gone over the end
	and return an appropriate error message.
7) if you give rio an init command, it puts it in a new note group, so
	if you kill off the window within which rio is running, the
	command hangs around, thus:
8) managing recalcitrant groups of processes where the process names
	are all very similar is hard, particularly if you're running rio.
	very very easy to kill off your main window manager.
	there's no easy way to find out what processes are
	grouped together (perhaps ps could be able to print noteids, which
	helps a bit).

[if others consider any/all of the above to be bugs, i could
do patches, depending on what's considered the right way to fix
them.]

it's not worth posting my code.
conclusion: if you want to do this, modify rio itself!

'course there are other issues to solve too here, like:
if the plumber creates a new window, where should it appear?

i think rio can definitely be improved. that "sticky" menu has caused
me to unintentionally delete windows sooo many times, for one.