#2460 closed bug (fixed)
Mouse doesn't follow split window divider when dragging it sideways in Vision
Reported by: | koki | Owned by: | anevilyak |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Kits/Interface Kit | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
hrev25990 in VMWare.
How to reproduce:
1) Run Vision.
2) Click on the window divider that separates the chat window and the user list window and drag sideways.
3) The mouse pointer does not follow the window divider; the further sideways you drag the divider, the more the mouse pointer lags behind.
Expected behabiour: the mouse pointer should always follow (and remain over) the window divider.
Note: not sure what component to assign this to; please change as needed.
Change History (4)
comment:1 by , 16 years ago
Component: | User Interface → Kits/Interface Kit |
---|---|
Owner: | changed from | to
comment:2 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:3 by , 16 years ago
I've also changed Haiku in hrev26491 to have BeOS compatible B_MOUSE_MOVED messages, as was intended by BWindow::_SanitizeMessage().
comment:4 by , 16 years ago
Good catch! Here's hoping that fixes some other apps with odd mouse behavior. Reverted my Vision workarounds in hrev26493.
Fixed in hrev24690.
The cause was in fact a difference in behavior between R5 and Haiku, but this behavior isn't actually documented anywhere in the BeBook and was more something found by random curiosity at the time, so I'm not sure any other app relies on it. For the time being I've fixed it in Vision itself. To clarify:
When Vision's ResizeView got a MouseMoved notification, it would ask its BWindow for the current message in the queue, so as to pass that on to whichever view was in fact the target of the resize, since different resize behavior is needed for the nick lists vs the window list. In BeOS hrev5 and 5.1, this would contain the BPoint for the MouseMoved in window-relative coordinates. In Haiku, it already appears to be pre-converted to the coordinate in the view's space, which needless to say was confusing Vision quite a bit. hrev24690 should pull an updated package that contains this fix.