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=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4510 invoked from network); 28 Jan 2022 09:55:42 -0000 Received: from tb-ob1.topicbox.com (64.147.108.173) by inbox.vuxu.org with ESMTPUTF8; 28 Jan 2022 09:55:42 -0000 Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob1.topicbox.com (Postfix) with ESMTP id 5BA6E31104 for ; Fri, 28 Jan 2022 04:55:41 -0500 (EST) (envelope-from bounce.mM54ac272859201587addb6b91.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 5931613E98F0; Fri, 28 Jan 2022 04:55:41 -0500 (EST) ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=fjrhome.net; spf=none smtp.mailfrom=fde101@fjrhome.net smtp.helo=dpmailmta01.doteasy.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=content-type:message-id:date:mime-version :subject:to:references:from:in-reply-to:list-help:list-id :list-post:list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=sysmsg-1; t=1643363741; bh=NqkKPIuu+Z9p4592 B0TJosBIHPANOuMIunpTANJzkvg=; b=oD7dWRirFEcjEglk92in2ruqgJ05pyFY S4d8vWSOS/Bln9DEXVzO75qJmLKVfZCZukQvWo7mlIZ3PpBlPsv6XP21HiQp5sHV L5kul9MpPe02dWUcEMCRYW1e5m9+eY7v/vPVd9vTbZndPKeAYKh3GtxeXLMbr2vx D2+zFvUsGZE= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1643363741; b=er+uqj5J0/CZz4bMyR84uenOfkQFovWzURAZboY4YWlMIGAMbk si3GlCULmj9sKqA4tMLXYWjCzDAjqCyYehXjLRnK9rZ1aA4c1iWRU0EUeeSPskK4 DcUKlOAe+gQoehoRaBbKkwzw1TCEXyOYKeJj51PIdZJW1+sKSfNixaLpg= Authentication-Results: topicbox.com; arc=pass; dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=fjrhome.net; spf=none smtp.mailfrom=fde101@fjrhome.net smtp.helo=dpmailmta01.doteasy.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) X-Received-Authentication-Results: tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=fjrhome.net; iprev=pass smtp.remote-ip=65.61.218.6 (dpmailmta01-06.doteasy.com); spf=none smtp.mailfrom=fde101@fjrhome.net smtp.helo=dpmailmta01.doteasy.com; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=fail smtp.helo=dpmailmta01.doteasy.com policy.ptr=dpmailmta01-06.doteasy.com; x-return-mx=pass header.domain=fjrhome.net policy.is_org=yes (MX Records found: dpmail01.doteasy.com,dpmailbu.doteasy.com); x-return-mx=pass smtp.domain=fjrhome.net policy.is_org=yes (MX Records found: dpmail01.doteasy.com,dpmailbu.doteasy.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= content-type:message-id:date:mime-version:subject:to:references :from:in-reply-to:list-help:list-id:list-post:list-subscribe :reply-to:content-transfer-encoding:list-unsubscribe; s=dkim-1; bh=168WY3b6NPvT4bBKoU7nw4+vkfkHGyyDKirjGBn7r00=; b=ULypqTzAkzPD 0xpH9lZvZ66domr7Kqd0/GgBGAw4mD9rb0IdY3I3DEjIny/g1/GZsmr6kLENGVQz n2iggJYsasWVNFFvj1u+f3NzQF+APsgoQjwhTGcCpt/4oF1MOgjBDoR4iPwfASxQ ZM1kNxeKFDsbavv47D+31bhjUo4pHY8= Received: from tb-mx1.topicbox.com (localhost.local [127.0.0.1]) by tb-mx1.topicbox.com (Postfix) with ESMTP id 813D0FD246C for <9fans@9fans.net>; Fri, 28 Jan 2022 04:55:30 -0500 (EST) (envelope-from fde101@fjrhome.net) Received: from tb-mx1.topicbox.com (localhost [127.0.0.1]) by tb-mx1.topicbox.com (Authentication Milter) with ESMTP id F3A4A56AEC8; Fri, 28 Jan 2022 04:55:30 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1643363730; b=Zx1c00F7PsYg+DUZKr+9LRN6CKAVDV6q2ZaQdGb50Gl117srmY A4oBfQt0R0y1FxQVUSiuyACJG6B/u//ewWX+Laj7dapsA9G1LRp84QbdVnCixVSW E0dCkLu+Y7ebMjgtpnzE90Tjc18tlNvB2t/Q6A5cHFSIZAtUyWeKKYQO35omLeI/ HGKAMyNcf8gY37jlecpeal2DzKruVMAqWq0g/bhMVKoQ3qdx8QOM9ZEyeLelzAbv g05R2ZaNYdaOFnY53cdhgea5paD7Boc9Be9Z3qdhSuGDttRH6nsbGsB9/MqixLU7 6PUmad10zfH8JX6Pkc3PrJRIx5/04ImJuvvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=content-type:message-id:date:mime-version :subject:to:references:from:in-reply-to; s=arcseal; t= 1643363730; bh=/Xa7ZDBV13jN9ng88wBZf6ufvdIB8584T0IsdxiHKO4=; b=L 4I8fNn+xYmx2QP/DLYzj6PVrtUENRngvuKuUerDko4RZzfUTZ+DTf6rRsYMhO11v jk51M0GWmjicpQwwF/x86Trc3S0eenN6lHQRMze55u+IR389g1TwYG870BfpPS+u v0G1v6d80HVrIY1Z9sxicD+jQgcnQihn0LPHolDISxs77VHp252ceN3prxeLdDDg B7kcKgAypS2IaRoBtFpYF2yG2sebXOIJ8CROCbTeF5XSVJI5Ud7B5RttjzFu6/yt FwphgBygGPQ4FPZJC8o5sCetAJcHiRBzeIIwgVhaCr/12Bkg3Zzzwbq9Aelv1wO4 +9I8M4BujQCezCV9MyTsA== ARC-Authentication-Results: i=1; tb-mx1.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC did not pass); dkim=none (no signatures found); dmarc=none policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=fjrhome.net; iprev=pass smtp.remote-ip=65.61.218.6 (dpmailmta01-06.doteasy.com); spf=none smtp.mailfrom=fde101@fjrhome.net smtp.helo=dpmailmta01.doteasy.com; x-aligned-from=pass (Address match); x-me-sender=none; x-ptr=fail smtp.helo=dpmailmta01.doteasy.com policy.ptr=dpmailmta01-06.doteasy.com; x-return-mx=pass header.domain=fjrhome.net policy.is_org=yes (MX Records found: dpmail01.doteasy.com,dpmailbu.doteasy.com); x-return-mx=pass smtp.domain=fjrhome.net policy.is_org=yes (MX Records found: dpmail01.doteasy.com,dpmailbu.doteasy.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgedvvddrfeeggdduvdduucdltddurdegudelrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgf nhhsuhgsshgtrhhisggvpdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttd enucenucfjughrpegtkfffgggfuffvfhfhjghisegrtderredtfeejnecuhfhrohhmpedf hfhrrghnkhcuffdrucfgnhhgvghlpdculfhrrddfuceofhguvgdutddusehfjhhrhhhomh gvrdhnvghtqeenucggtffrrghtthgvrhhnpeeltdefkedvfeeuleelheegheduveehtefh uedviedvkeefkeekuddtjefhieekudenucffohhmrghinhepthhophhitggsohigrdgtoh hmnecukfhppeeihedriedurddvudekrdeipdduledvrdduieekrddutddurdekuddpudej fedrieejrddufeegrddugeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hinhgvthepieehrdeiuddrvddukedriedphhgvlhhopeguphhmrghilhhmthgrtddurdgu ohhtvggrshihrdgtohhmpdhmrghilhhfrhhomhepoehfuggvuddtudesfhhjrhhhohhmvg drnhgvtheq X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: none (fjrhome.net: No applicable sender policy available) receiver=tb-mx1.topicbox.com; identity=mailfrom; envelope-from="fde101@fjrhome.net"; helo=dpmailmta01.doteasy.com; client-ip=65.61.218.6 Received: from dpmailmta01.doteasy.com (dpmailmta01-06.doteasy.com [65.61.218.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx1.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Fri, 28 Jan 2022 04:55:29 -0500 (EST) (envelope-from fde101@fjrhome.net) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=192.168.101.81; Received: from dpmailrp01.doteasy.com (unverified [192.168.101.81]) by dpmailmta01.doteasy.com (DEO) with ESMTP id 86865221-1394429 for <9fans@9fans.net>; Fri, 28 Jan 2022 01:55:28 -0800 Received: from dpmail01.doteasy.com (dpmail01.doteasy.com [192.168.101.1]) by dpmailrp01.doteasy.com (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTP id 20S9tR5f012183 for <9fans@9fans.net>; Fri, 28 Jan 2022 01:55:27 -0800 X-SmarterMail-Authenticated-As: fde101@fjrhome.net Received: from [192.168.1.14] (pool-173-67-134-144.hrbgpa.fios.verizon.net [173.67.134.144]) by dpmail01.doteasy.com with SMTP; Fri, 28 Jan 2022 01:55:08 -0800 Content-Type: multipart/alternative; boundary=------------ZjNs1bb0c0E0Hqho5h8wwIjg Message-ID: <1942de7a-1126-7600-3b36-69ce2effd610@fjrhome.net> Date: Fri, 28 Jan 2022 04:55:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [9fans] suggestion : new service targets for plan9 Content-Language: en-US To: 9fans@9fans.net References: <16433354030.97ACA3.134633@composer.9fans.topicbox.com> From: "Frank D. Engel, Jr." In-Reply-To: <16433354030.97ACA3.134633@composer.9fans.topicbox.com> X-Exim-Id: 1942de7a-1126-7600-3b36-69ce2effd610 X-Bayes-Prob: 0.995 (Score 4, tokens from: base:default, @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.1 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 016M9Trce - 62afc54689c3 - 20220128 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.81 X-Originating-IP: 192.168.101.81 Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 702d167c-8020-11ec-ae6b-c045d7355998 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UMjUxOGY5ZTRmYzEwZWQwMy1NNTRhYzI3Mjg1OTIwMTU4N2FkZGI2?= =?UTF-8?B?YjkxPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M54ac272859201587addb6b91:1:6QZuT-2FZeFJlVOS1AMHzAE7tZlPOsNeYKmagO9umE4 --------------ZjNs1bb0c0E0Hqho5h8wwIjg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I was actually thinking of a somewhat different approach to providing a=20 more modernized user interface. Consider that rio currently exports the required files for each window,=20 which provide the same interface as the display driver underneath them. Now consider adding a new "control manager" file server which exports a=20 filesystem to manage individual controls arranged inside a window (or at=20 the root level if not running rio or other window manager).=C2=A0 Create a= =20 directory inside the exported filesystem to add a new control.=C2=A0 Inside= =20 the directory would automatically appear those same files that are=20 exported by rio or by vga, but specific to the control.=C2=A0 There would=20 also be a file for controlling the scaling and placement of child=20 controls of the control in some defined manner, allowing "layout=20 managers" to be defined (such a file would also appear at the root).=C2=A0= =20 Add a new subdirectory within the directory of a control to create a=20 child control. Individual types of controls can then be implemented as separate=20 programs or libraries which would interact with those basic elements to=20 provide the specific functionality of a control or layout manager -=20 standard controls to be provided would be the typical buttons,=20 checkboxes, text fields, etc., while layout managers would arrange their=20 children in specific patterns, such as vertically stacked, horizontally=20 stacked, grids, etc. This mechanism is an extensible way to cover the provision of "modern"=20 controls within a window, even when still using rio, and is true to the=20 "everything is a filesystem" nature of plan9. A second step would be to create an alternative to rio which would do=20 the same job, but with title bars and the like. Some kind of file management / desktop environment application could=20 then be built on top of these foundations.=C2=A0 Users could mix and match= =20 the use of applications based on the control manager within the existing=20 rio environment, and the existing command line / rio applications such=20 as acme would work unmodified with the new window manager but have=20 "modern" title bars and some sort of "minimize" and possibly "full=20 screen" functionality, maybe with a dock of some kind. As far as I can tell this would require practically zero core changes to=20 the system as it is built entirely on existing primitives already offered. On 1/27/22 9:03 PM, ibrahim via 9fans wrote: > I developed a kiosk version of plan9 (based on 9front and legacy9) and=20 > am about to develop a single user desktop system. Those can coexist=20 > with the existing plan9 system. > > I named the new service targets kiosk and desktop. Both work without rio. > > Currently I used initdraw, initmouse, initkeyboard, loadimage,=20 > flushimage from devdraw to avoid breaking of compatibility with the=20 > existing plan9 systems while the whole rendering of the windows is=20 > framebuffer based. Instead of the usual plan9 fonts I used regular=20 > truetypefonts. > > So my suggestions would be : > > 1) Define new service targets kiosk and desktop (Currently I do this=20 > in init or /user/.../lib/profile. This makes it possible for a user to=20 > start an alternative window manager or even a single applicaton (kiosk=20 > service) with a modern look and feel. > > 2) Define a layer between vga and devdraw perhaps vgafb which improves=20 > the performance for frame buffer rendered window managers. > > 3) Define events for mouse, keyboard, touchpad, windows which is based=20 > on notes managed by light threads inside the client app. > > Those three steps would protect the existing plan9 from changes and=20 > make it possible to only use the kernel, libraries, tools from=20 > alternative user interfaces. Plan9 is one of the smallest operating=20 > systems accompanied with a compiler and an abstraction which would=20 > attract much more developers and users if it had a modern user=20 > interface. We don't have to throw away anything and rio would even be=20 > able to run inside a window of a modern desktop. > > Plan9 has everything necessary to make it an attractive system not=20 > only for a handful of developers. The compilers, the portability, 9p,=20 > unicode, direct support for video hardware and its small size are=20 > fascinating. > > The only reason why it isn't recognized by more people is its GUI. I=20 > don't get the reason why we wouldn't extent it so we can use other=20 > GUI's while keeping the existing in respect of the developers who=20 > created this system. > > I will integrate this changes but I would prefer staying fully=20 > compatible to the existing projects legacy9 and 9front even more I=20 > would prefer not forking any of them but sharing my parts as=20 > contributions. > > What I need and what those changes need is a separation level between=20 > devdraw and the graphics hardware and a new event mechanism which can=20 > be based on notes or equals. > > I'm not a native English speaker so excuse the many mistakes. > > *9fans * / 9fans / see discussions=20 > + participants=20 > + delivery=C2=A0options= =20 > Permalink=20 > =20 > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M54ac2= 72859201587addb6b91 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --------------ZjNs1bb0c0E0Hqho5h8wwIjg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <= p>I was actually thinking of a somewhat different approach to providing a more modernized user interface.

Consider that rio curre= ntly exports the required files for each window, which provide the same interface as the display driver underneath them.

Now consider adding a new "control manager&qu= ot; file server which exports a filesystem to manage individual controls arranged inside a window (or at the root level if not running rio or other window manager).  Create a directory inside the exported filesystem to add a new control.  Inside the directory would automatically appear those same files that are exported by rio or by vga, but specific to the control.  There would also be a file for controlling the scaling and placement of child controls of the control in some defined manner, allowing "layout managers" = to be defined (such a file would also appear at the root).  Add a new subdirectory within the directory of a control to create a child control.

Individual types of controls can then be implemented as se= parate programs or libraries which would interact with those basic elements to provide the specific functionality of a control or layout manager - standard controls to be provided would be the typical buttons, checkboxes, text fields, etc., while layout managers would arrange their children in specific patterns, such as vertically stacked, horizontally stacked, grids, etc.

This mecha= nism is an extensible way to cover the provision of "modern" controls within a window, even when still using ri= o, and is true to the "everything is a filesystem" nature of plan9= .


A second step would be to create an alternative to rio w= hich would do the same job, but with title bars and the like.


Some kind of file management / desktop environment application could then be built on top of these foundations.  Users could mix and match the use of applications based on the control manager within the existing rio environment, and the existing command line / rio applications such as acme would work unmodified with the new window manager but have "modern" title bars and some sort of "minimize" and possibly "full screen" functionali= ty, maybe with a dock of some kind.


As far as I can tell this would require= practically zero core changes to the system as it is built entirely on existing primitives already offered.


On 1/27/22 9:03 PM, ibrahim via 9fans wrote:
I developed a kiosk version = of plan9 (based on 9front and legacy9) and am about to develop a single user desktop system. Those can coexist with the existing plan9 system.
<= br />
I named the new service targets kiosk and desktop. Both work without rio.

Currently I used init= draw, initmouse, initkeyboard, loadimage, flushimage from devdraw to avoid breaking of compatibility with the existing plan9 systems while the whole rendering of the windows is framebuffer based. Instead of the usual plan9 fonts I used regular truetypefonts.
So my suggestions would be :

1) Define new service targets kiosk and desktop (Currently I do this in init or /user/.../lib/profile. This makes it possible for a user to start an alternative window manager or even a single applicaton (kiosk service) with a modern look and feel.

2) Define a layer between vga and devdraw perh= aps vgafb which improves the performance for frame buffer rendered window managers.

3) Define events for mo= use, keyboard, touchpad, windows which is based on notes managed by light threads inside the client app.

Those three steps would prot= ect the existing plan9 from changes and make it possible to only use the kernel, libraries, tools from alternative user interfaces. Plan9 is one of the smallest operating systems accompanied with a compiler and an abstraction which would attract much more developers and users if it had a modern user interface. We don't have to throw away anything and rio would even be able to run inside a window of a modern desktop.

Plan9 has everyth= ing necessary to make it an attractive system not only for a handful of developers. The compilers, the portability, 9p, unicode, direct support for video hardware and its small size are fascinating.

T= he only reason why it isn't recognized by more people is its GUI. I don't get the reason why we wouldn't extent it so we= can use other GUI's while keeping the existing in respect of the developers who created this system.

I will integrate this changes but I would prefer staying fully compatible to the existing projects legacy9 and 9front even more I would prefer not forking any of them but sharing my parts as contributions.

What I nee= d and what those changes need is a separation level between devdraw and the graphics hardware and a new event mechanism which can be based on notes or equals.
I'm not a native English speaker so excuse the many mist= akes.

= --------------ZjNs1bb0c0E0Hqho5h8wwIjg--