Community
Participate
Working Groups
Seen on Eclipse Cocoa. When scrolling in a form page, the form can get stuck in text fields that are created with the SWT.WRAP flag. This can be seen in the Mylyn task editor. Open an Eclipse.org bug with Mylyn and expand the Attributes section. The Keywords attribute is not a CCombo, but is a text field with an arrow button next to it. Hover over the text field portion so that you see the caret cursor and attempt to scroll wheel down. The form page will not respond, but if you hover over the URL text field above it and scroll wheel down, the form page scrolls with you. The URL text field is created without the SWT.WRAP flag. On Windows and Linux we've seen that the Mylyn editor does not get stuck on text fields with SWT.WRAP. Forms also seem to get stuck in tables and lists. Again in the Mylyn editor, if you use the scroll wheel on the table in the Attachments section or on the CC list at the bottom of the page, the form page does not scroll with you (although the CC list will scroll itself if it needs to). From our testing of the Mylyn editor on Windows and Linux, the form page will scroll even if hovering over tables or lists.
On windows scroll wheel is sent to the focused control, on mac it is sent to the control under the mouse. This is a platform behavior.
How is that handled on Gtk? It doesn't seem like the focus control is getting the events. Scrolling works even when hovering over tables or StyledText.
OK didn't realize I was seeing platform behaviour, but what about the issue of Text fields when given the SWT.WRAP flag? Is that not a bug?
On mac, anything capable of scrolling will eat mouse wheel events when the pointer is over that control. Multi line Text (regardless of WRAP), Table, Tree, etc will all behave this way.
OK thanks for clarifying.
An old bug report, but in case anyone finds it today I just wanted to add that Kevin's reply is not entirely conclusive. While it is true that a multi-line SWT Text will eat mouse wheel events, this is not mandated platform behavior (today, at least, with OS X 10.9). The reason multi-line Text, Table, Tree etc. eats mouse wheel events is because SWT embeds the core Cocoa views (NSTextView, NSTableView, NSOutlineView) in a NSScrollView, regardless of whether they have scrollbars or not. Although this may be similar to what you get by default when designing a Cocoa GUI in Interface Builder, it is indeed possible to get rid of the surrounding NSScrollView. It is the NSScrollView that by default consumes the mouse wheel events. But in Cocoa, you can easily override that behavior so that when the scrolling has reached the bounds, the event is propagated to the next responder, typically the parent view. An example of this behavior can easily be seen in the Safari web browser, when scrolling through an HTML textarea. This behavior, which seems what the bug reporter wants, cannot easily be reproduced using SWT today. So this is indeed a bug. The simplest solution seems to be to omit the NSScrollView when no scroll bars are requested through the style bits. That would solve the issue for many cases. (As a matter of fact, at least for read-only text on OS X 10.9, you can actually achieve this today by using a SWT.SINGLE style instead of SWT.MULTI. Text will then create a bare NSTextField, which surprisingly enough happily expands to show multiple lines. But relying on that bug isn't advisable, and of course platform dependent.) But the simple solution wouldn't solve that vertical (mouse wheel) scrolling gets consumed although the Scrollable only has horizontal scroll bars. But this, at least, can be said to be consistent with default platform behavior. Recreating the Safari behavior is often desirable and it can be done in principally two different ways: A) The SWT user adds mouse wheel and/or gesture listeners to the inner Scrollable:s which scroll the outer Scrollable using setOrigin() when bounds are reached. B) Add a mechanism to Scrollable to propagate scrolling to parents when bounds are reached, with per-axis enablement. Solution A currently fails on OS X with multi touch scrolling due to Bug 220175. But even though I have a proposed fix for that bug, platform fidelity will be lost. This is because setOrigin() won't allow you to scroll beyond the bounds, but native multi touch elastic scrolling will. Also, supporting more than two levels of Scrollable:s becomes more complicated and might require subclassing or wrapping of the Scrollable:s. Solution B is trivial to implement in SWT for Cocoa and would give full platform fidelity for any level of Scrollable nesting. This mechanism could also be combined with a hint for enabling elastic scrolling, mutually exclusive of course. Not sure about other platforms, though.
Abhishek, should we take a re-look at this?
Can this issue be re-opened? I have a view with multiple tables inside and gesture scrolling there is really annoying due to the table widgets consuming all the scroll events from those gestures on OSX. Or is it possible to configure this somehow in the latest versions (Eclipse Mars)?
