'Follow the leader' dialogs
l.lunak at sh.cvut.cz
Sun Aug 4 21:04:08 BST 2002
On Sunday 04 August 2002 21:18, Thomas Zander wrote:
> On Sunday 04 August 2002 21:13, Lubos Lunak wrote:
> > On Sunday 04 August 2002 21:01, Zack Rusin wrote:
> > > On Sunday 04 August 2002 12:57, Lubos Lunak wrote:
> > > >" The question is - do we want this? Do we want our
> > > > dialogs to follow the parent? "
> > No no no, I didn't ask that. I asked why and _when_ should this feature
> > be useful.
> > > This was the only question asked. Patch wasn't for testing/commit or
> > > anything else involving review - it was there to give people who had no
> > > clue what I was talking about an idea of how it would work (not the
> > > code, but behavior). I take you answer was 'I don't like that behavior
> > > and am against it' right?
> > Kind of. I simply don't see 'why' and especially 'when'.
> In my opinion the idea is usefull when a window 'belongs' to an application
> and the application is moved, then the windows should also be moved.
> The child windows can be anything from toolbars seperated from the main app
> to dialogs like 'find'.
Ah, I see (there's a difference between 'dialog' and 'child window').
> This is mostly usefull for anything several KOffice components and MDI
> applications like kate and konq now do in splitted windows but some
> users/applications prefer to do in seperate windows.
> I don't see how this can be done relyable for something like GIMP, but
> there moving the picture window would move the brushes and the layers (etc)
> But when there is not exactly one 'main' window the idea becomes highly
> questionable on behavioral details ;)
Following either WM_CLIENT_LEADER or WM_TRANSIENT_FOR hints should probably
solve this. A couple of lines in KWin could handle that.
> To reiterrate the 'when';
> When the main window which the extra-window belongs to moves the child
> window moves the same offset.
> If the child window moves there is extra action.
There are definitely going to be people or cases where it won't fit, so it
shouldn't be hardcoded (e.g. if I put a toolbar at the screen edge, I guess
I'd yell if it moved together with the window - not that _I_ actually move
windows much when I maximize them all anyway ... maybe I should implement a
new KWin placement policy called 'maximize' ;) ).
l.lunak at email.cz ; l.lunak at kde.org
More information about the kde-core-devel