Pros: - Theming/integrating behaviour across window contents and window frame becomes dead easy. Move windows by dragging in empty areas of the window - this is what osx does, and it's really useful. Sidebars that slide out from the side of the window, file selector preview pane. Extra buttons in title bar, progress bar in title bar. Window background texture that extends into the title bar (osx metal type of thing). Pull a tab out of a notebook and make the new toplevel window actually look like the tab. - All the window managers hints and hacks (protocol for communicating wether a window is resizeable, number of buttons, window title) are workarounds to try to make two apps (wm and client) appears as one. The more integration we want to make between the app and its frame the more protocol we need to define. Also, the idea that if we start doing more advanced integration, all other wms will implement it if we just spec it is delusional. Don't write specs for the specs' sake. With client side decorations, a new feature (file selector preview fold-out or whatever) is just another widget, instead of a new spec. - We already have examples of client-managed top level windows - tear of menus and toolbars, the resize grippies in the nautilus lower right window. No wonder, this type of tighter integration between application content and windows manager type-of actions is infeasible to split between the windows manager and client - specifying and implementing this would be a nightmare. At the same time this demonstrates that letting the client handle these actions is useful and doable. - It's not "just like xmms" - "xmms is on crack and draws its own custom decorations". This idea is implemented as a gtk stock widget so most windows get consistent frame look and feel anyway. - Technical benefit - if the decorations need argb visuals, the frame widget will just ask for that visual. Today we have a clash when a toplevel gtk+ window (typically using rgb visuals) is reparented into a argb decoration window. The x server automatic compositor kicks in making everything slow. With client side decorations, we have a centralized view of the applications visual requirements. - No reparenting madness - well, still for legacy apps. - Longer term, if we move to a model where clients post redraws by sending pixmaps to the cm using client msgs, resizing can be made much more efficient, fewer round trips. When the app gets the drag event that resizes the window, it just allocates a pixmap of the new size and redraws into that as normal, then post it to the cm as normal (see new-world-order.txt). Cons: - When clients hang, the window is stuck - need to work around this, but it's not a show stopper. This is usually the one big drawback mentioned, but it can be worked around with fewer hacks that we have now to make the frame and app seem as a whole. Client side decorations is not about getting rid of the window manager process, it will still be necessary for force-moving, force-closing apps, global key-bindings, workspaces, Alt-tabbing. - Tradition/community intertia. Considering the outrage over metacitys lack of features, going to a model where window frame decoration and behaviour is fixed in the toolkit is sure to provoke death threats. This is basically screwing over the e17, fluxbox, crackwm etc communities. But visual and behaviorial theming should still be possible, it's just gtk+ theming now, instead of wm theming. - Window decorations will look different across applications. Well, no, the windows manager will need to work as a full-blown windows manager for legacy clients, and the windows manager will use the same widget for client windows as the apps use for their toplevel windows. If later on other toolkits, say, Qt, implements their own top-level decoration widget, then yes, those applications will have different decorations. But realize, that in this case the Qt applications already look and feel different from the gtk+ applications for all of their content widgets, and the inconsistency between the Qt client side window decorations and the gtk+ client side window decorations is less of an issue than the inconsistency between the gtk+ style window decorations (provided by the windows manager) and the Qt widgets in the content area. Misc ideas: - Metacity can use the gtk+ toplevel frame widget for decorations for legacy clients. - Need use cases/examples to drive this idea. - If it's important that the window decorations can be themed independently of the window contents, it is still possible to just specify a theme engine for just the frame widget. Yes, this does go against the main motivation of this proposal - theming and integration across window frame and contents, but this may be one way to keep the flames in check. Behaviour could be configured using .gtkrc, but that's probably not flexible enough - or rather, changing keybindings shouldn't trigger a theme reload. How does gtk handle other global settings like double click speed? Much of the toplevel frame widgets look and behaviour should probably be overridable from a loadable module.