From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 18583 invoked from network); 25 Aug 2022 06:44:04 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 25 Aug 2022 06:44:04 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Thu Aug 25 02:40:53 -0400 2022 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1661409649; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4blYIsqIOKVM5ViQFV71NgMXtaFeDzs4CV5CZO5JULM=; b=e4T/rO/o8EUjPIT5GVrirQ6ot9lqDidyjcq6uB8wEPlu06UQIDC0RcCHvJ01uRzHR1ERQC aGikfvTQxMD5UkgU60qJ6YILjvdOi88Z2Lr4OJrq0jvqhH7v1z1Czrr3haxSJRvltyb9zB TL4xi/OM4tIaHkhu8YdIHwtFBQ18pSE= Received: from [192.168.168.200] (161-97-228-135.mynextlight.net [161.97.228.135]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 239b7415 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Thu, 25 Aug 2022 01:40:49 -0500 (CDT) Message-ID: Date: Thu, 25 Aug 2022 00:40:45 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Content-Language: en-US To: 9front@9front.org References: <6381c6d9cb1ff9f2@orthanc.ca> From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: stable agile injection CMS manager Subject: Re: [9front] [PATCH] programmable menus for rio Reply-To: 9front@9front.org Precedence: bulk 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