[haiku-commits] Re: r42221 - haiku/trunk/src/kits/tracker
- From: Rene Gollent <anevilyak@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 18 Jun 2011 07:45:16 -0400
On Sat, Jun 18, 2011 at 6:02 AM, Alexandre Deckner <alex@xxxxxxxxxxxx> wrote:
> Thanks for looking into this, but following our talk on IRC, something still
> doesn't sound right in your fix.
> It looks like the DragStart() method is wrongly named and the call is now in
> the wrong place (and was making non obvious assumptions).
> This DragStart() method was only called before showing the nav menu (and
> nowhere else AFAICS) and i ported it as-is (overlooking things obviously!)
> to this new spot as it's now where this event happens. With your change it's
> now called on every MouseMoved without a clear reason. For logical and
> semantical reasons, if something needs to be done for the drop menu when
> initiating a drag, i'd expect it to be called in the new MouseDragged
> callback and make it find the necessary data by other means, i.e port the
> previous mechanism to the new async mouse tracking.
>
There are a few problems. The reason for the DragStart() mechanism is
fairly simple: when one drops the dragged message onto the x-ray menu,
the latter is the recipient and it has no idea what to do with it ; it
will simply invoke the targetted menu item, which in turn sends the
window a message containing the destination ref. Upon receipt,
ContainerWindow checks if it was in a dragging state (which is set via
DragStart(), which clones the drag message so the window has a cached
copy of it). If that's the case, ContainerWindow then uses that in
order to be able to determine what was actually dragged. The problem
is, this can't really be done anywhere other than MouseMoved(),
because BView provides no API for retrieving the current drag message,
only setting it, and consequently once you've set it, the only way you
can see it is via the parameter on the MouseMoved() hook.
This is further complicated by the case when one drags the message
into a different container window from the source, and then hits the
xray menu from there. I actually moved the code after our discussion
last night to where the drag message is generated rather than in
MouseMoved() itself, but that will actually break the case I just
described, so that one needs to be reverted. I really don't see any
other way to handle it unfortunately, given current API restrictions.
In any case, it's only actually called if there isn't already a drag
operation in progress, not on every move, and that mechanism isn't
used by anything else other than the above described op.
Regards,
Rene
Other related posts:
