Bounties

Bounties

[Jens Staal]

Dear all,

Below are some bounties for stuff that I would like to see:

[1] A dwm/i3/sway-like rio replacement = 50 €

10 work spaces, tiling, start terminal with $mod+enter, switch work space with
$mod+number. You can choose what you name it :)

[2] A bar for the i3-like rio replacement with useful info = 30 €

Some info that should be possible to display: workspaces, system info (cpu load,
memory load, network load, ...), digital 24h clock. If not configurable, the bar
should be at the top of the screen on all work spaces.

[3] configuration-file based customization of the i3-like rio replacement and
bar = 20 €

A configuration file where key bindings and colours can be adjusted.

Re: [9front] Bounties

[Ethan Gardener]

On Sun, Jan 5, 2020, at 7:06 AM, Jens Staal wrote:
> [2] A bar for the i3-like rio replacement with useful info = 30 €
> 
> Some info that should be possible to display: workspaces, system info (cpu load,
> memory load, network load, ...), digital 24h clock. If not configurable, the bar
> should be at the top of the screen on all work spaces.

I wouldn't make this as described, it's making extra code with a different interface for no reason; very un-9ish. ;) Instead, I'd make a text field or a window. The text field would be linked to a writeable file, similar to writeable /dev/text. A script could write to it, as I once did in Rio to display time and battery while 9vx was full-screen. (If /dev/text had been writeable, it would have been perfect.)

The window would be a superset of this. A command to the window manager would start a program with the bar as its window. A script could write text to /dev/text or a graphical program could run in it. It's very easy to make a graphical program for that sort of task, or Rio could be patched to run multiple programs in the bar.

Re: [9front] Bounties

[sl]

> From: "Ethan Gardener" <eekee57@fastmail.fm>
> To: 9front@9front.org
> Subject: Re: [9front] Bounties
> Reply-To: 9front@9front.org
> 
> On Sun, Jan 5, 2020, at 7:06 AM, Jens Staal wrote:
>> [2] A bar for the i3-like rio replacement with useful info = 30 €
>> 
>> Some info that should be possible to display: workspaces, system info (cpu load,
>> memory load, network load, ...), digital 24h clock. If not configurable, the bar
>> should be at the top of the screen on all work spaces.
> 
> I wouldn't make this as described, it's making extra code with a different
> interface for no reason; very un-9ish. ;)

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]

sl

[0] http://plan9.stanleylieber.com/rc/hstats

Re: [9front] Bounties

[Calvin Morrison]

On Sun, Jan 5, 2020, at 2:06 AM, Jens Staal wrote:
> Dear all,
> 
> Below are some bounties for stuff that I would like to see:
> 
> [1] A dwm/i3/sway-like rio replacement = 50 €

Jens,

If you look around there's a patch set for Tiling windows from a right click action. Could be a good place to start. Take a look at /n/griddisk/turkey/trio/ (http://www.9gridchan.org/ describes the grid service)

Calvin.

Re: [9front] Bounties

[Calvin Morrison]

On Sun, Jan 5, 2020, at 2:06 AM, Jens Staal wrote:
> Dear all,
> 
> Below are some bounties for stuff that I would like to see:
> 
> [1] A dwm/i3/sway-like rio replacement = 50 €
> 
> 10 work spaces, tiling, start terminal with $mod+enter, switch work space with
> $mod+number. You can choose what you name it :)

A second follow up. I think that ACME as the WM is a very laudable and  realistic goal. It implements sub windows  (but not /dev/draw for each window) and handles columns rows, minimization, and you can implement programs (like wiki) to work with ACME with some good benefits.

Re: [9front] Bounties

[Ethan Gardener]

On Thu, Jan 16, 2020, at 7:35 PM, Calvin Morrison wrote:
> 
> A second follow up. I think that ACME as the WM is a very laudable and  
> realistic goal. It implements sub windows  (but not /dev/draw for each 
> window) and handles columns rows, minimization, and you can implement 
> programs (like wiki) to work with ACME with some good benefits.

I found Acme's dynamic window placement gets in the way if I'm doing anything other than editing C code. It's not the worst possible issue, but it did get in the way rather a lot when I used Acme to organize my notes and projects like a sort of personal wiki. Increasing the number of columns helps a lot, but 3 columns is the minimum for comfort and my weakening eyesight requires ever-larger fonts, so it's now untenable.

For perspective, I should probably say I also found dwm's dynamic window placement a bit confusing too, but I didn't give it much of a chance.

Re: [9front] Bounties

[umbraticus]

indeed, and /dev/text is writeable.

while(){date >/dev/text; sleep 60}

replace date with whatever and run in a rio window with your favourite dimensions

umbraticus

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

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