Re: GTK+, WM, desktops and CSD

[Allin Cottrell <cottrell wfu edu>]

On Thu, 5 Mar 2015, Paul Davis wrote:

> On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell <cottrell wfu edu> 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