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.0 required=5.0 tests=T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22305 invoked from network); 24 Aug 2022 17:38:25 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Aug 2022 17:38:25 -0000 Received: from mimir.eigenstate.org ([206.124.132.107]) by 9front; Wed Aug 24 13:37:16 -0400 2022 Received: from abbatoir.myfiosgateway.com (pool-74-108-56-137.nycmny.fios.verizon.net [74.108.56.137]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 3b32e3cd (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO) for <9front@9front.org>; Wed, 24 Aug 2022 10:37:04 -0700 (PDT) Message-ID: To: 9front@9front.org Date: Wed, 24 Aug 2022 13:37:03 -0400 From: ori@eigenstate.org In-Reply-To: <21D5362C-4E8B-4EBE-A9F6-A698796FD637@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: abstract non-blocking out-scaling CMS generator Subject: Re: [9front] [PATCH] programmable menus for rio Reply-To: 9front@9front.org Precedence: bulk Quoth 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. 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.