Improved window management

[Norman Feske]

Hi Ben,

On 05/10/2015 10:50 PM, Nobody III wrote:
> Thanks for getting me to reread the New GUI Architecture page. It
> answers some of my questions, but not all of them.
> For adding minimize/maximize/restore/close buttons to the window
> decorations, how do we handle the decorator not recieving input? Should
> it send rectangles to indicate where the buttons are, and be sent
> signals from the layouter when the mouse is over/clicking on one of them?

it should work like this:

1. The layouter produces a report for the window layout. Each window
   that is to be equipped with a maximize button has an attribute set,
   e.g., maximize="yes".

2. The decorator receives the layout report and renders the window
   decorations. It detects the 'maximize' attribute and draws the
   maximize widget accordingly. It is up to the decorator to decide
   where the widget is located or how big it is.

3. The window manager (the parent of both the decorator and layouter)
   virtualizes the nitpicker session of the decorator. It thereby
   intercepts the user input that is referring to the decorator's
   nitpicker session. The stream of input events is routed to the
   layouter. However, the current pointer position is presented to the
   decorator (it is updated only if the pointer moves over the
   decorator's views).

4. The decorator observes the change of the pointer position and
   determines the widget at the pointer position. It reports this
   information as a "hover" report to the window manager.

5. The window manager routes the hover reports from the decorator to
   the layouter.

6. Thanks to the hover model, the layouter knows the type of the
   pointed-at decoration widget. Since it receives the user input
   events that refer to the window decorations, it can implement the
   application logic to respond to user input events. For example,
   if it observes a mouse-button-press event and the hover model
   reports "maximize", the layouter can adjust the window position
   and size and reports the updated window layout. The story
   continues at 2.

Intuitively, this procedure sounds pretty daunting, doesn't it? The more
fascinating is the fact that it performs quite well. ;-) In return, this
design achieves the following goals:

* It sandboxes the potentially complex (and bug prone) graphics
  operations in the form of the decorator component.

* It protects the content of and user input to applications from
  the decorator and layouter.

* Since the graphical style of the window decorations is defined
  inside the decorator component, it can be simply replaced by
  another implementation. We spare us the complexity of adding
  theming support to the window manager.

* Since the window-layout policy is defined by a separate layouter
  component, different implementations could accommodate a variety
  of window layout approaches like tiled and tabbed windows,
  virtual desktos etc.

* The window manager has a very low complexity, which is important
  because it is in the TCB of its client applications.

As you noticed, the implementation is not complete yet. I plan to pick
up this line of work again in June.

> Also, what is the best way to implement focus on click? People won't
> want to have to click on the window decorations or the panel every time
> they want to switch windows.

I guess you are referring to click-to-raise, not click-to-focus. The
current version of the window manager does not propagate mouse clicks
targeting the application views to the layouter, which would be a
precondition to allow the layouter to respond to such events. I agree
that this should be added in the future to give the layouter this ability.

> It seems like the destop and panel should be at least partially
> combined. I understand that there could be security issues with this.
> I have been thinking about how to allow users to have user-specific
> applications appear on the desktop and menu. What seems the most logical
> (secure yet user-friendly) is to use different text colors for
> system-wide and user-specific applications. Do you have any ideas on
> this? I could see the panel/desktop becoming overly complex.

This is definitely a valid concern. As an experiment to see how to avoid
complexity in such security-critical graphical components, I have
designed the launcher (gems/src/app/launcher) as a multi-component
application. Similar to how the window manager separates the concerns of
the layouter and decorator, the launcher separates the concerns of
widget rendering and fading from the application logic. Thanks to this
design, the launcher's actual application has very few lines of code.

I think that there won't be _the one_ Genode way to address the
application-management issue. I foresee different implementations of
panels, decorators, layouters, and widget renderers that accommodate
different users. For example, personally, I don't need a panel and would
rather prefer to activate an application-management interface via a
keyboard shortcut.

Marking "trusted" applications with a special color is not an effective
security measure unless you prevent all other applications to use this
particular color. Otherwise a malicious application could just mimic a
trusted application. Nitpicker's X-ray mode addresses this integrity
issue by giving the user (not the software!) a mechanism is toggle the
security feature at any time. While activated, it actually revokes the
ability to use the entire color space from the applications. Bright
colors are preserved to nitpicker only. Another complementary approach
is the preservation of a certain screen region to the trusted
application-management interface and making sure that this region always
remains unobstructed from other applications. Nitpicker's layering
mechanism accommodates this idea.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth