[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbox
Subject:    [openbox] Move events not propagated instantly
From:       andreas.fink85 () googlemail ! com (Andreas Fink)
Date:       2011-02-10 21:27:27
Message-ID: 20110210222727.36f67a2c () jocker-laptop
[Download RAW message or body]

On Thu, 10 Feb 2011 22:22:26 +0100
Mikael Magnusson <mikachu at gmail.com> wrote:

> On 10 February 2011 22:17, Andreas Fink <andreas.fink85 at googlemail.com> wrote:
> > On Thu, 10 Feb 2011 22:12:32 +0100
> > Mikael Magnusson <mikachu at gmail.com> wrote:
> > 
> > > On 10 February 2011 22:05, Andreas Fink <andreas.fink85 at googlemail.com> \
> > > wrote:
> > > > On Thu, 10 Feb 2011 22:04:12 +0100
> > > > Mikael Magnusson <mikachu at gmail.com> wrote:
> > > > 
> > > > > On 10 February 2011 21:56, Andreas Fink <andreas.fink85 at googlemail.com> \
> > > > > wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I wanted to write some code with Qt and have a question if qt or openbox \
> > > > > > has a problem. Here my problem: I want to react on toplevel window \
> > > > > > movement (I want to move two toplevel windows synchroniously). When I \
> > > > > > move the window around (clicking on the window title and drag it around) \
> > > > > > I get only one single move event, when I release the mouse. Executing the \
> > > > > > very same program in KDE (without recompiling) gives me instant move \
> > > > > > events, i.e. my application gets informed all the time during the \
> > > > > > dragging. 
> > > > > > Is this by design in openbox, or a bug, or is it even a problem with qt?
> > > > > 
> > > > > It is by design, we consider the window to only be actually moved when
> > > > > you release the button. Before that it's none of the app's business
> > > > > what the user is doing, the window seemingly moving is just feedback
> > > > > to the user where it would be if you let go of the mouse. If you press
> > > > > Escape, the whole operation is aborted and the window is not moved.
> > > > > 
> > > > 
> > > > So there is no way, keeping two windows in sync when moving?
> > > 
> > > Ugh no, don't pretend your app is a window manager.
> > > 
> > 
> > Sure it's not a window manager. But two top-level windows belonging to my single \
> > application, may have a very special layout (not in my case though, but it's \
> > possible). I guess, I don't care enough to tackle it further, but still I don't \
> > think it's a good idea to limit behaviour this way. A move event is a move event, \
> > even if in the end the result is dropped (and this is by the way inconsistent \
> > with sending resize events all the time, even if the result is being dropped in \
> > the end)
> 
> There is an option for the resize events. And arguably it is more
> useful to see what the app would do as a result of the resize than a
> move. (I have the option off though). I don't know if we would be that
> opposed to an option to send move events, it just seems very niche,
> there are pretty much no apps that care and it just sends extra
> events.
> 

Actually, I don't really mind, since it is a very special case in my application, \
that the second window is actually visible. I was just wondering why it did not send \
move events. It's for my company anyway, and I think I'm the only one there with \
openbox, so noone will ever see, that it does not "work" ;) I can live with the fact, \
that my 2nd window moves on move-finished, so I think there is no need for such an \
option.

Thanks for clarifying that it's by design.
Regards
Andreas


[prev in list] [next in list] [prev in thread] [next in thread]