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