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

[sirjofri <sirjofri+ml-9fans@sirjofri.de>]

Hey, that was my idea! 😉

Well, to be precise, I also had the idea of having a filesystem hierarchy 
for window contents.

/mnt/window/mywindow/vbox/hbox/button/label/
and inside that: text, padding, margin, ... Whatever you like.

It would be easy to write UIs using shell scripts, and to be fair, many 
user applications can just be a shell script that hauls data between UI 
and specialized filesystems for their task.

I suggest you look at the rcgui test I did quite some time ago, I believe 
it's available at https://git.sr.ht/~sirjofri/rcgui. It's sadly not a 
filesystem, but does an app lifecycle approach and you can react to 
events like redraw and give simple text draw commands for button 
controls. I really would like to see the filesystem approach as that's 
what my goal is, but I was not so good at implementing filesystems 
(although I have many ideas) and I have very limited time due to 
ninephone project and especially work.

Btw I was planning to have some kinda filesystem wrapper so you can 
easily write simple filesystems using rc, some kinda glorified 9pcon, but 
that's another topic.

if you're interested in discussing touch UI ideas (or stuff that leads 
towards touch UI on 9) I set up a garden repository on shithub for this 
exact purpose. garden means, you only need a shithub account and have 
push access. The URL is http://shithub.us/garden/touchui/HEAD/info.html . 
I wanted to add my ideas earlier, but I sadly didn't have enough time for 
that (I have ideas though, just need to write them down).

sirjofri

28.01.2022 10:55:01 Frank D. Engel, Jr. <fde101@fjrhome.net>:

> 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-M54ac272859201587addb6b91]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T2518f9e4fc10ed03-M9e7cea6cac0af336bf4dd3ac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription