[patch] Grab windows anywhere, not just titlebar

[Lubos Lunak]

On Thursday 08 of November 2007, Aaron J. Seigo wrote:
> that would be awesome. essentially, i would like a way to flag a window as
> being "document modal"; the parent winId relationship would be enough to
> communicate what it is modal to, just like other dialogs. this window hint,
> however, would add the extra guidance that this dialog is modal to the
> document contained within that window.
>
> here's the relevant page in Apple's HIG:
>
> http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGui
>delines/XHIGWindows/chapter_17_section_6.html#//apple_ref/doc/uid/20000961-T
>PXREF11

 I must be missing something, because I fail to see the difference:
- it's modal - we have modal dialogs
- it's attached to a specific window - dialogs are attached to their specified 
mainwindow
- "Mac OX X layering model" - if I'm getting it right that this is just a name 
for keeping the dialog together with the window in the stacking order, then 
we have that
- it doesn't have a titlebar - visual difference
- it slides in - visual difference
- "Sheets also allow users to perform other tasks before dismissing the 
dialog, with no sense of the system being “hijacked” by the application." - 
oh boy, that is from an old HIG version, right?

 Where exactly is the absolutely killer feature I don't see?

> > > that they work has been proven pretty well by other operating systems
> > > that have less trouble with such "innovative" ideas (the same one(s)
> > > that tend to have a better reputation with users, btw)
> >
> >  Macs are quite rare in these parts. But I've heard they're known for
> > having a very consistent interface.
>
> on the term "consistent", to quote one of my favourite movies, "you keep
> using that word, but i do not think it means what you think it means."

 Consistent: marked by harmony, regularity, or steady continuity, free from 
variation or contradiction (Merriam-Webster). My mistake about the Macs part, 
but as I said I have no experience with them.

> > mouse. Another reason why trying to be inconsistent just for the sake of
> > being different is bad.
>
> i'm not going to raise to the bait in your mail, and i'm sorry i did that
> in past message. in return, it would be cool if you didn't mischaracterize
> my motivations.

 Quite frankly, to me your motivation seem to be being strongly decided about 
how exactly minicli will look like and dismissing any kind of complaint as 
not understanding your vision. But now that I know a workaround, I don't feel 
like continuing this.

> > > > I can force the borders on with KWin,
> > >
> > > yep ... i can't get that to work atm, however, with kwin from trunk...
> > > maybe the window is being too agressive; but this is perhaps a decent
> > > way to get what everyone wants.
> >
> >  It currently cannot override the application, but looks like I'll have
> > to change it.
>
> i've installed some default kwin rules and got rid of the move() code.
> should be good now ....

 Almost. First of all, that's KWin's configuration -> it belongs to KWin. 
Second, I've already said that such rule is not okay for just one dialog - 
either it's none, or all of Plasma's dialogs (I suppose I can take that). 
Third, the dialog is not going to be called 'Add Widgets' here - the dialog 
needs a window role (gee, that seems to be a Qt problem, I know I'm gonna 
hate that :(  ).

 I will move and fix the file, unless you for some reason don't like some of 
this.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz