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 28357 invoked from network); 11 May 2022 08:46:25 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 11 May 2022 08:46:25 -0000 Received: from sirjofri.de ([5.45.105.127]) by 9front; Wed May 11 04:44:27 -0400 2022 Received: from sirjofri.de ([95.90.218.92]) by sirjofri.de; Wed May 11 10:44:19 +0200 2022 Date: Wed, 11 May 2022 08:44:17 +0000 (UTC) From: sirjofri To: 9front@9front.org Message-ID: <94b96400-a26e-4fda-9c38-942c2ec0cf62@sirjofri.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <94b96400-a26e-4fda-9c38-942c2ec0cf62@sirjofri.de> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: non-blocking structured shader ActivityPub core extension event-based control Subject: [9front] wloc - rc doesn't work because of pid Reply-To: 9front@9front.org Precedence: bulk Good morning, > contains several window commands generated by wloc. - rio(1) However, wloc uses the window labels to construct the commands, and rc=20 labels contain the pid by default. Thus it's impossible to restore=20 existing rc windows without relabelling them manually before running=20 wloc. Imo using labels to reconstruct windows isn't a good design. The only way= =20 to accurately restore windows is by labelling the windows when running=20 applications, therefore using the windows label as some kinda 'dump'=20 place (like acme Dump/Load). This can conflict with user intentions for=20 custom labels. Restoring rc windows can currently only work by running a command=20 beforehand, e. g. the label command or a shell script/program controlling= =20 the label. However, the label is also used for display in winwatch, which= =20 can cause issues with workflows (e. g. I use labels in winwatch to=20 describe the namespace of that window, which breaks the workflow for=20 wloc). The only out-of-the-box-solution I can currently think of is, removing=20 the pid from a default rc session label. (If you don't want to read a different design idea, you can skip to the=20 end at this point.) If I were to design a better way around that, I'd probably give rio=20 windows another file (dump) which can be controlled by an application and= =20 is used instead of the label. The dump line would be a complete command=20 to partially restore the full session, including namespace, label, and=20 potentially state. A gridchat rc session could for example put the string =C2=A0=C2=A0 rc -c 'label gridchat; 9fs net!chat.9p.zone!9999 /n/chat' inside the dump file, which is then used by wloc to construct the line =C2=A0=C2=A0 window -r x y a b rc -c 'label gridchat; 9fs ...' ... you get the idea. The design would work, but would probably also break compatibility with=20 other 9 systems. However, it would also work as an addition (don't use=20 wloc, but name it differently, original 9 tools can just ignore the dump=20 file). sirjofri