[patch] Grab windows anywhere, not just titlebar

[Lubos Lunak]

On Thursday 22 of November 2007, Aaron J. Seigo wrote:
> On Friday 09 November 2007, Lubos Lunak wrote:
> > On Thursday 08 of November 2007, Aaron J. Seigo wrote:
> >
> >  Where exactly is the absolutely killer feature I don't see?
>
> that it keeps windows properly associated visually with the window they
> affect. most people have problems keeping windows sorted out in their head:
> which window belongs to which window. this makes it painfully obvious
> because document modal dialogs appear as if they are embedded in the window
> they belong to. there's no visual separation, so the concept is more
> clearly communicated. it's simply an easier way for people to get the
> concept that "this window is working on that window".
>
> i know you don't have problems with that, but this software is used by
> millions of people ..... many of whom do. most people don't even know
> what "modal" means.

 They don't need to, just the fact that it happens is enough. It's quite hard 
to miss the fact that a modal dialog belongs to the main window when it 
covers it and won't let you interact with it. Still, this seems to make 
sense.

 But how do you want that handled technically? If the application will have to 
explicitly specify it, there will be a mess of having sheets somewhere and 
dialogs elsewhere. I can do that simply in KWin with all modal dialogs, it's 
just keeping them at the right place and removing decoration, but then, what 
if the dialog needs resizing?

 I could just make modal dialogs work more like sheets, position the titlebar 
aligned with the mainwindow's titlebar and move/minimize together with the 
mainwindow, but I suppose you woulnd't find that enough?

> >  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).
>
> all dialogs belonging to plasma? hm. that might work. i honestly haven't
> gone through every possible dialog we'll have to see if that makes sense.

 I think that's the best that can be done for 4.0. And it's still better than 
having just one random dialog do that.

> note that human beings rarely work (or play) with such all or nothing type
> rules; as the point of usability is to make software more approachable to
> humans, these "all or nothing" approaches sometimes work against making the
> software usable. this is one of the recurring themes in our conversations
> here: you're very much about keeping the rules strict in the software (and
> i understand where you're coming from as a window manager developer)
> whereas i'm trying to introduce more thinking about how people work with
> that software ... which is often not "all or nothing".

 It's not about all or nothing, it's about keeping it consistent and 
predictable, if there's not a good reason not to. Which is also about using 
it - I don't only developer KDE, I also happen to use it.

> > 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 :(  ).
>
> mm.. right, it'll get translated. i'll add a window role to it right now ..
> *thinks* "addwidgets" sounds about right =)

 Note that unpatched QWidget::setWindowRole() just plain aborts if the widget 
is not created at that time yet (so e.g. QWidget::winId() needs to be 
explicitly called first).

-- 
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