Roadmap 2020

ttcoder at netcourrier.com ttcoder at netcourrier.com
Wed Jan 15 11:04:46 CET 2020


---- Message d'origine ----
> De : Stefan Kalkowski <stefan.kalkowski at genode-labs.com>
> * A more sophisticated window-manager incarnation for Sculpt
> 
> I use several virtual-machines aside, as well as noux shell,
> pdf-viewer, battery-applet, and top-view. At last, it became
> unmanageable to use all these windows overlapping each other, and
> without a feedback when switching in between.

I'm tempted to add my 'vote' for implementing features addressing this, as a mid-term goal :
In my daily use I just can't get anything done without a good implementation of "workspaces". There are more features 
used for organizing a desktop of course, like a "task bar" ..etc. But implementing multiple workspaces (virtual screens) has a 
surprisingly far reaching impact on applications, and thus might need careful planning.

E.g. here's the number of references in the API (just the header files alone) in the workspaces implementation I'm used to 
working with:
  /boot/system/develop/headers/os> grep -Ri workspace | wc -l
  38
Those span classes related to windows, of course, but also application classes, deskbar/taskbar related classes ..etc.

And even that implementation, as hi-speed-low-drag as I find it, could still be considered incomplete. There are lots of 
behavioral questions to be adressed when implementing workspaces : what if an application is activated, yet its window is 
in a workspace /other/ than the one currently facing the user : should that other workspace come into focus, or to the 
contrary, should the application window's be "warped" into the current workspace? Or should that behavior be user 
configurable, rather than hardcoded ? Lots of questions like that.

Genode's philosophy seems to be "don't deny complexity, but organize it". So it would be an interesting challenge: would 
implementing workspaces entail big changes in nitpicker? in wm? How to reconcile the need for a low number of source-
code lines, with the need for additional, complex features -- it might justify offering several w.m.'s (which I think is already 
the case), of varying degrees of complexity, so that users have a choice between high reliability (but somewhat restricted) 
wm's and more feature-rich wm's implementing workspaces, at the expense of possibly more bugs.

Cedric








More information about the users mailing list