Ubuntu's window buttons to stay on the left

Posted Apr 2, 2010 17:48 UTC (Fri) by alecs1 (guest, #46699)
In reply to: Ubuntu's window buttons to stay on the left by cmsj
Parent article: Ubuntu's window buttons to stay on the left

By client side decoration you mean the thing that XMMS/Winamp and many video players do? That the decoration is managed by the client, and that client also takes care to move itself when needed and anything else.

I have my doubts about how this can be nicely implemented:
1. Getting this right seems very hard. The range of problems is huge: when the program freezes it won't move any more, most times won't resize either. My window manager has "magnetic" edges, resize at Alt+Rmb and many other shortcuts which affect the window. This could probably be solved by making a library "libkwindekorations" and have funky apps link to it. This brings me to the next point:
2. Duplication. The lazy creators of "GtkNotepad" (which consists of a text edit widget and a menu) will make linking to libkwindekorations compulsory, so in order to start my 2k LOC editor I'll bring in the complex 50k LOC window handling library.

I believe that, *at most*, the applications that want it should be able to borrow their menus, toolbars and maybe some space to the window manager. If my Konqueror here gave its status bar to the WM to manage, then the WM could show a nice grab handle at the right of the status bar, in the bottom-right corner. The same goes for the fancy menu blended in the title bar.

I actually love it on Linux desktop that all windows are low level citizens, governed by WM, they will listen to some extent even if they are frozen.

Ubuntu's window buttons to stay on the left

Posted Apr 2, 2010 18:08 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

More details about CSD is at

http://jasondclinton.livejournal.com/74222.html

Ubuntu's window buttons to stay on the left

Posted Apr 2, 2010 18:10 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

One more

http://live.gnome.org/GTK+/ClientSideDecorations

Ubuntu's window buttons to stay on the left

Posted Apr 2, 2010 21:14 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

I don't see how this could be made to work without major wm changes.

If you think that horrible stuff like in-window Google Chrome-style
decorations are a nice idea, then maybe this would work, but how do you
stop the window manager from drawing decorations as well? (And how do you
stop it looking totally out of place with respect to older apps that *do*
have the wm draw the decorations?)

Presumably you mark these things as transient windows so that the window
manager doesn't try to decorate them... but a lot of window managers
interpret transience to mean a lot of other things as well (often 'do not
hide when desktops are switched' and things like that).

(And if you're changing the wm, you don't *need* in-client decorations,
you just teach the wm how to decorate the window in the same way.)

client side decoration

Posted Apr 9, 2010 20:26 UTC (Fri) by spitzak (guest, #4593) [Link]

You mark the windows as either "override" or turn on the no-border hints in the ancient TWM window manager hints.

Worries about mouse-dragging and resize can be fixed by adding a new Window manager API where the program can convey simple commands to it, like "the user is dragging the right edge of my window, do whatever you want..."

There is no reason for the window border to somehow be special and rendered by a different asynchronous task. This was a kludge solution for systems before there were shared libraries. We have much much better solutions for making reusable widgets nowadays and this ancient system should be ditched for a modern one.

I would GREATLY love to see this. The current X design (and Windows and OSX that copied it) is crap, it is slow, always has redraw glitches, and it requires FAR MORE code to implement than just drawing the decorations yourself, if you assume the program already needs code to draw buttons and so on in it's contents. I suggest you take a look at how many thousands of lines of ICCCM and "window manager hints" crap a toolkit has to write if you don't believe me, and compare to how much code you would need using that toolkit to draw a window border with a few buttons.

This would eliminate all the "slowness" issues with X, because that "slowness" is caused by the asynchronous nature, while a synchronous delay of all window update is not objectionable at all. It would fix window raising, provided programs can have complete control over the order of the windows, allowing things like multiple base windows sharing the same transient window, and thus make GIMP work the way the designers want it to work, and maybe get us off the "make a giant window and tile everything into it" mindset of all current software. Window systems were invented to solve this decades ago but the window-raising-on-click that WM's force on them has broken this and forced all software to revert to primitive designs.