Web lists-archives.com

Re: GTK+, WM, desktops and CSD

On Thu, 5 Mar 2015, Paul Davis wrote:

On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell <cottrell@xxxxxxx> wrote:

On Thu, 5 Mar 2015, Florian Müllner wrote:

 The worst thing that can happen when the toolkit forcefully rips CSD from
applications is that there is no more UI to save, navigate, load or
whatever essential UI the applications happens to put into its decorations.

Isn't there some dissonance here: "essential UI" embedded in
"decorations"? How did we come to this? I can sort of see why if metacity
is taken as the baseline, since metacity in its default appearance suffered
from a severe case of macroencephaly: a huge wasteland of bare forehead
holding a bloated boldface window title and little else. But why not fix
the WM (not all WMs waste anything like that amount of desktop) rather than
conflating UI with decoration?

consider a simple dialog. Should it have a close button or not? If the
application adds an explicit close button, there are now two areas of the
window as displayed by most WMs which will, upon being clicked, cause the
window to be hidden. So should the application add its own?   Or should it
tell the WM that it would like a "close" button to be added? If it does the
latter, is this "close" button "decoration" or "essential function" ?

That's a good, practical question that I'm happy to answer as an app developer. If I'm confident that the WM/OS is going to add a "close" control at the top right (a pretty good bet in most cases) then I wouldn't choose to add my own "close" widget in that vicinity. But if I have row of buttons at the foot of the window and "Close" makes sense as one of the options, I'd be inclined to add that option, to save the user from mousing a few inches to achieve his or her desired effect.

Allin Cottrell
Department of Economics
Wake Forest University
gtk-devel-list mailing list