client side decorations

[Mike Paquette]

On May 5, 2011, at 6:10 PM, Kristian Høgsberg wrote:

> Also, the concern about not being able to close and moving hung apps
> just seems blown out of proportion.  Yes, it's a neat feature that X
> WMs can deal with this, but it's just about the only good thing in
> that approach and it comes at the cost of all the complexity of trying
> to sync the look and feel of two apps living in the same window.  And
> realistically, how often is this really a problem?  I can't remember
> when I last had to deal with an unresponsive application, and I think
> I might have killed it form the panel or command line instead.  And
> it's possible to work around this to some extent, by letting the app
> specify a rect where the compositor should grab button 1 and start a
> move, for example.  Perhaps a rectangle (ie, the close button) where
> the application has to acknowledge buttons clicks within a second or
> so, or it will be assumed unresponsive and the compositor can pop up
> the "This guy is not responding, force quit?" dialog.

We addressed this in a couple of interesting ways for a commercial OS using a Wayland-style window system.   There, we had to support a traditional X server as a client, along with Carbon apps, which do client side decorations along with window close, drag/move, and resize, and also Cocoa apps, which came from a Display PostScript environment where server side code (written in PostScript!) handled event processing and window close, drag/move, and resize operations independent of the apps.

We were dropping server-side drawing operations with the move away from Display PostScript, but there was still a desire to be able to move app windows, and at least order them off-screen, even if an app wasn't responsive.   To provide this we allowed apps to describe a drag shape (Graphics Gems II, p. 31-45 as a starting point) within which a server-side drag loop would be invoked when the designated mouse drag button was down.   Any app toolkit that set this shape could have it's windows dragged asynchronously with respect to the app.  A 'WindowDidMove' event is posted on the mouse-up ending the drag loop that the client app toolkit could subscribe to.

We also allowed for the idea of a 'universal window owner,' a specially designated client that would be permitted to do limited manipulation of the windows of other apps.  This 'universal owner' property is used by desktop manager processes to order windows off-screen if needed, as well as to handle some specialized operations such as  multiple workspace management.

There is also a mechanism that can detect when an app isn't picking up pending events, which was introduced a couple decades back to trigger the dreaded wait cursor (Spinning Pizza of Death).  This mechanism can also be used to spot unresponsive applications.   A special event can be sent to a desktop manager process to let it know when an app is hung, allowing it to alter the appearance of the UI.  Unity might, for example, be extended to turn the running app indicator red, or a menu item 'Quit' could change to 'Force Quit.'

Mike Paquette