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. <fde...@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