Roadmap 2023 - DnD, PP GUI

[ttcoder at netcourrier.com]

> https://www.genode-labs.com/publications/secure-gui-2009.pdf#subsection.4.3.5
> 

The DnD protocol exposed in secure-gui-2009.pdf reminds me of the advanced one
described in the BeBook as "negociated drag'n'drop" (by opposed to the simplified
B_SIMPLE_DATA I typically use in my apps). Heck, it even has the use of MIME types assigned
to the data payload. That convergence is a very good sign, if I say so myself 8-)

I'll run that in my head, though an aspect for me is inter-operability with my existing
code base : to keep my code working "as-is" without #ifdef-Genode's it would need continued
reliance on BMessage's, by contrast to interacting with Genode ROMs/report_rom's and other components
(well of course, whichever way I go, in either case I'll rely on the underlying Genode, but in a
different way : if I go the "cooperative" way, the "glue" code will be down in layers, down
in my h-o-g components instead of being exposed in higher layers or requiring changes in my
actual application code).

(generally speaking, even beside my own DnD design idea, if I was to implement a DnD "engine"
for Genode I would prioritize brainstorming about how that engine will be exposed as an API, how it
will interact with known applications and their APIs : GTK, Qt, etc -- I have zero knowledge about DnD on
those latter two and wonder how much they expect from the underlying operating system ; for Sculpt you
would not have to worry about interaction of course as Sculpt would adapt to the provided API).

****

Regarding community contributions, after someone mentionned LVGL on the PinePhone that got me
thinking a bit, trying to guess in what direction the PP GUI will go. (I make no guarantee
express or implied that my below ramblings will be relevant to the Genode project, caveat emptor :^)

>From one extreme (reliability) to the other (full featured),
I suppose the GUI "arsenal" could potentially look like this:

- native Genode widgets' set
- LVGL
- Higher-level widget toolkit? (possibly with expressive power similar to InterfaceKit or comparable ?)
- Full-blown Qt etc

So which of those are used, or will be used in the future ?

We've seen screenshots of native widgets being used for Sculpt/Leitzentrale and administration GUI,
and that makes sense to have a rock solid GUI -- it must be since it's part of the (user-facing) TCB.
At the other end of the spectrum, it was mentionned that Qt (?) support might get consolidated
on the PP in order to allow app ports, which makes complete sense too.

Someone mentionned LVGL ; that seems fairly solid/stable and (in my few weeks of working with it)
impressively full-featured (some would say "eye candy", in the positive meaning) for such a small code base
that is designed to run even on an Arduino with a few hundred KB of RAM (!). Seems they've put some
serious coding effort into LVGL over the years. Though IIRC it needs exclusive
access to the framebuffer (or part of it ?) so not sure whether its use can be wide spread or shared with Sculpt ; but
since I know it a little, I'll keep an eye on it if it pops up in github changes, though it's not
clear if I could make useful suggestions... Except to suggest looking for the C++ wrapper API (which allows
piloting LVGL with objects instead of the plain C API... though most people seem ok with the C API,
especially for small-scale GUIs).

Where I'll keep my eyes peeled however, is for the third item above. That possibility has not popped up,
and it's entirely possible it will not be needed, i.e. there won't be room for
a "fifth wheel" between native widgets one one hand, for implementing all
"operating system" GUI aspects, and applications on the other hand, for the "everything-else" GUI aspect.

Cedric