[openbox] Move events not propagated instantly

[Andreas Fink]

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