Rename "Nitpicker" session to "Gui" session

[nfeske]

Naming the session interface after the nitpicker GUI server was not a good idea because the name has no intuitive meaning. When looking at init configurations, the obscure name spoils the clarity. Hence, I'd like to rename the session interface to Gui. This is a change at two levels. At the code/API level, the Nitpicker namespace will be renamed to Gui. Second, at the configuration level - in particular the session routing - the server interface will be named "Gui".

For the latter, I intend to use "Gui" as opposed to "GUI" to follow the convention that only core services are written with all-uppercase letters. "Gui" is a non-core service like "Nic" or "Uart".

[mewmew]

In relation to the work on renaming the GUI session API - as it may already include a lot of API refactoring, I would like to start a discussion about something Daniel (@7i) and I have been curious about for some time. Namely, how difficult it would be to bring Wayland API over to Genode. The benefit would be that a lot of GUI frameworks and graphical applications would work out of the box, or at least, that would be the idealistic outcome. So the Wayland API wrapper could be similar that that of what Noux was for POSIX API.

I realize this is similar in spirit to the discussion in https://github.com/genodelabs/genode/issues/2084#issuecomment-264652653. This is mostly to keep it in mind when working on renaming the Nitpicker session, as potentially there could be more than one implementation of the Gui session? Where Nitpicker could be one.

Cheers, Robin

Edit: not entirely related, but I've been using Wayland as my primary display server on Linux for the last year or so. Firefox, Chromium and several other larger projects have now added native support for Wayland, just as a data point. It would be incredible to bring these over natively to Genode. Of course, for them to take full advantage of the capability-based security in Genode, they would have to be better integrated. But having them running natively in the first place would be a wonderful start.

[nfeske]

Hi Robin,

thanks for chiming in. The suggestion comes up every now and then but since I have never looked closely at the Wayland API, I'm unable to give a well-educated answer. However, here is what I know / what I think:

• In the posting https://genodians.org/nfeske/2019-09-13-challenges, I suggested Xlib compatibility as a challenge for community members or students to work on. The topic is closely related. The underlying motivation is the same as you mentioned: the prospect of GUI-application compatibility. When looking strictly from this angle, I doubt that the Wayland API has a fundamental advantage over Xlib compatibility as long as applications preserve Xlib compatibility. Maybe it is less complex? Until now, however, no one has picked up the posted idea yet.

• My current work on the GUI stack is a very low level refinement of what we already have. The goals are (1) optimizing the pixel-data path by eliminating pixel-format conversions, (2) solving pixel-buffering problems in a holistic fashion, (3) retaining the low complexity of the nitpicker GUI server, (4) making graphics drivers restartible / swapable, (5) simplifying the future support of multi-head. It does not touch the application/API level much.

• There are already multiple GUI servers implementing the interface of nitpicker (now renamed to "Gui"), specifically the window manager I described in the following posting: https://genodians.org/nfeske/2020-03-27-window-management and the book at https://genode.org/documentation/genode-foundations/20.05/components/Component_composition.html#Interposing_individual_services.

• I see Wayland or Xlib API compatibility probably as a prerequisite but not as the magic potion for enabling complex applications like Firefox or Chromium on Genode. The current road blocks are elsewhere. There are other - more fundamental - problems to solve first. In particular the building (cross-compiling for Genode) packaging of such beasts. The latter point is our current focus with the Goa tool (https://genodians.org/nfeske/2020-03-02-goa-update). Another prerequisite is a decent emulation of certain infrastructure that application programs take for granted on Linux, e.g., the emulation of machine-local Unix-domain-socket communication, or commonly used mmap semantics. Not to speak of emulating dbus and such. There are many steps that must be taken before a rich application ecosystem magically appears on Genode. The question is which one to take first?

• There is work by @cproc in progress to bring the Chromium engine over to Genode in the form of Qt5's WebEngine. This work benefits from Genode's existing integration of Qt5.

It's very considerate that you mentioned the discussion at https://github.com/genodelabs/genode/issues/2084#issuecomment-264652653 :-) I'd be excited about someone stepping forward committing to such work.

[ttcoder]

Robin: FWIW and in case it adds wind in your sails so to speak, I've found that Genode's framebuffer+Nitpicker API was easy to work with for porting another windowing display API to it (namely, make applications that use the InterfaceKit API compile and run as-is on Genode with Nitpicker; code can be found under my nickname on chiselapp.com). Still lots to do and stubbed out code I need to finish, but it was an enjoyable experience.

[mewmew]

Robin: FWIW and in case it adds wind in your sails so to speak, I've found that Genode's framebuffer+Nitpicker API was easy to work with for porting another windowing display API to it (namely, make applications that use the InterfaceKit API compile and run as-is on Genode with Nitpicker; code can be found under my nickname on chiselapp.com). Still lots to do and stubbed out code I need to finish, but it was an enjoyable experience.

Hi @ttcoder,

That's great! It's a really cool project you have for adding a Haiku compatability layer on top of Genode! Thanks for sharing both the project and your experience on porting a window display API to run on top of Nitpicker! :) This is very similar to what I had in mind.

Cheers, Robin

[nfeske]

Fixed in master.