[patch] Grab windows anywhere, not just titlebar

[Aaron J. Seigo]

On Thursday 22 November 2007, Lubos Lunak wrote:
> On Thursday 22 of November 2007, Aaron J. Seigo wrote:
> > On Friday 09 November 2007, Lubos Lunak wrote:
>  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?

yeah, that's (one reason) why this can't really be done to all dialogs. it's 
only document modal dialogs, as well. simple window or application modal 
isn't enough information, since those dialogs may not properly associate with 
any one window ... 

e.g. if we look at something like an image editor, a modal dialog warning 
about disk or memoery scratch space being exhausted / too small is 
application modal and should not be shown as a sheet. however, a dialog 
asking if they user really wants to delete a given image's contents would be.

so i don't see how we can really get around not having an explicitly set flag. 
the good news is that we can set this flag in many of our dialog classes 
(e.g. file dialogs, for the obvious example =)

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

if we could do it without the title bar on the dialog (though i suppose we 
want the draggable edges, right? is it even possible to do that with kwin's 
current clients? probably not, right?) that'd be great ... but even this 
would be an improvement ...

as a point of reference: on Mac the sheet appears to be "coming out of" the 
title bar (of course they have a cute little animation too; we could probably 
do this as well with a composite plugin someday). so really it's just a 
non-decorated window centered under the window's title bar with a drag handle 
in the lower right corner iirc.

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

fair enough...

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

agreed; it's the "good reason" part we sometimes have a hard time 
communicating about ;)

note that we "broke consistency" between the file dialog and konqueror's 
toolbar button order purposefuly (and then again after someone 
accidently "fixed" it ;) ... so .. it does happen. as you note, there needs 
to be a good reason.

so we're on the same page there =)

> Which is also about using 
> it - I don't only developer KDE, I also happen to use it.

yes, i know =))

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

so i've noticed =/ uck.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071122/79daa094/attachment.sig>