Quoth ibrahim via 9fans <9fans@9fans.net>:
> What I suggest is a lower level interface to use the framebuffer
> directly and I think devdraw (memdraw, memlayer) is too high level and
> rio oriented.
I don't think this is desirable.
Every single program uses devdraw directly. Rio is
just another
A well established example for direct rendered frame support is the SHM
extension of X11. There you can create a shared memory in your application and
render directly into this. Afterwards you switch buffers without any transfer
of image data. The image is directly rendered on the screen if the
On Friday, 28 January 2022, at 3:11 PM, Philip Silva wrote:
> I didn't deep-dive yet into the internals of it, but isn't it that when
> combining the images at the end, that transfer of the initial images with
> lots of data basically happens only once? It seems to me devdraw can be quite
>
Also of course it depends on what needs to be rendered. I didn't deep-dive yet
into the internals of it, but isn't it that when combining the images at the
end, that transfer of the initial images with lots of data basically happens
only once? It seems to me devdraw can be quite performant on
On Friday, 28 January 2022, at 10:55 AM, Frank D. Engel, Jr. wrote:
> 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.
What you are suggesting is a higher level filesystem and libdraw
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
On Friday, 28 January 2022, at 8:53 AM, vic.thacker wrote:
> Hmm. Have you considered using Inferno?
I gave it a try long ago but I don't want to use it. The reason is the
involvement of limbo. I prefer system code to be written in a language that I'm
using now for decades and where I can
On Friday, 28 January 2022, at 6:22 AM, ori wrote:
> It'd probably make sense to generalize: 'service=foo'
in plan9.ini could run /bin/^$foo^rc.
This is an excerpt for one experimental gdi from profile
...
ramfs
font = /lib/font/bit/lucida/unicode.10.font
upas/fs
fn cd { builtin cd $* && awd }
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"
On Fri, Jan 28, 2022, at 11:03, 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
Quoth ibrahim via 9fans <9fans@9fans.net>:
> 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
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,
12 matches
Mail list logo
