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