Re: [9fans] suggestion : new service targets for plan9

["Frank D. Engel, Jr." <fde101@fjrhome.net>]

[-- Attachment #1: Type: text/plain, Size: 5627 bytes --]

I was actually thinking of a somewhat different approach to providing a 
more modernized user interface.

Consider that rio currently 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" 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 separate 
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 mechanism is an extensible way to cover the provision of "modern" 
controls within a window, even when still using rio, and is true to the 
"everything is a filesystem" nature of plan9.


A second step would be to create an alternative to rio which 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" functionality, 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.
>
> I named the new service targets kiosk and desktop. Both work without rio.
>
> Currently I used initdraw, 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 perhaps vgafb which improves 
> the performance for frame buffer rendered window managers.
>
> 3) Define events for mouse, keyboard, touchpad, windows which is based 
> on notes managed by light threads inside the client app.
>
> Those three steps would protect 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 everything 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.
>
> The 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 need 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 mistakes.
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions 
> <https://9fans.topicbox.com/groups/9fans> + participants 
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options 
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink 
> <https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-Mb4eb2005f779e611cdef4de4> 
>
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M54ac272859201587addb6b91
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6903 bytes --]