Community
Participate
Working Groups
Hi! Please add the feature to switch tabs by mousewheel scrolling on the tab-bar. GTK 2 supports that, and it's more convenient than moving mouse to target tab and click.
Created attachment 94944 [details] Patch to add a MouseWheelListener to the presentation's CTabFolder. I think this would be a nice add-on and certainly 'noteworthy'. It is, however, questionable as to whether this should be something offered by the CTabFolder class out-of-the-box or not.
Kevin, does this patch look OK? PW
I loaded the patch and the event never comes in on WinXP. Is this GTK specific behaviour at the SWT level? (ie. the mouse event would come in?) I'm not sure how you get platform behaviour out of CTabFolder since its not a native widget. Plus the desired behaviour as described confuses me: on XP if I have a tab selected and I mouse wheel, the contents of the editor gets the event. That's because the editor area itself has input focus. There's no (easy) way to get focus to the tabs themselves. Is it true that on GTK you don't need input focus to catch mouse wheel? (Clearly I never use GTK) If this patch does actually work on GTK, then I have only one comment: The line fireEvent(TabFolderEvent.EVENT_TAB_SELECTED, getSelection(), getPaneMenuLocation()); doesn't need the last argument (and I don't think the data provides value). If you look at the selectionListener just above it, you'll see we call: fireEvent(TabFolderEvent.EVENT_TAB_SELECTED, item); Otherwise the patch seems to be right but I'd like to see it running in GTK to sign off on it. Feedback to Remy: from a code simplicity point of view, I would've been tempted to have each case assign to a local holding the resulting index, then have one paneFolder.setSelection() at the end. That way its clear that in each case we're not doing different work, we're simply computing the new selection. For further compaction you can then use the pattern ? : (although some people don't like using that) like: int resultIndex = index; if (e.count > 0) { index++; resultIndex = (index == paneFolder.getItems().length) ? 0 // since we're on the last tab, rotate forward to the first tab : index; } else { resultIndex = (index == 0) ? paneFolder.getItems().length - 1 // on the first tab, rotate backwards to the last tab : index - 1; } paneFolder.setSelection(resultIndex);
(In reply to comment #3) > I loaded the patch and the event never comes in on WinXP. Is this GTK specific > behaviour at the SWT level? (ie. the mouse event would come in?) I'm not sure > how you get platform behaviour out of CTabFolder since its not a native widget. I am not sure. I will try my hand at this on Vista maybe later tonight or tomorrow. > Plus the desired behaviour as described confuses me: on XP if I have a tab > selected and I mouse wheel, the contents of the editor gets the event. That's > because the editor area itself has input focus. There's no (easy) way to get > focus to the tabs themselves. Is it true that on GTK you don't need input > focus to catch mouse wheel? (Clearly I never use GTK) I am not sure if I understand what you are saying completely. In any case, if I have an IM window up on top of Firefox but my cursor is over Firefox and I roll my mouse's scroll wheel, it will scroll webpage and not my IM conversation. For your code/patch comments, I will be sure to respin a new one later once I have done some testing on Vista. One thing I want to note is that on gtk+ it actually doesn't rotate back to the beginning if the user reaches the end of the tab folder. I noticed this after I submitted the patch. Do you think it should rotate back or should it just stay at the end/beginning?
Created attachment 95572 [details] DefaultTabFolder patch v2 This patch incorporates the comments that Kevin brought up in comment 3. I tried using the scroll wheel this morning on Vista and it certainly wasn't receiving any events. Perhaps a bug should be filed to SWT?
Created attachment 95573 [details] DefaultTabFolder patch v2 alternate This is an alternate patch that stops the rotation if the user is at the end. Thus, scrolling up when the user has the last tab selected and scrolling down when the user is on the first tab will do nothing (whereas the first patch will rotate around from the other end as appropriate).
I tested the scrolling on Vista (I20080401-0851) with the snippet below: import org.eclipse.swt.SWT; import org.eclipse.swt.custom.CTabFolder; import org.eclipse.swt.custom.CTabItem; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Event; import org.eclipse.swt.widgets.Listener; import org.eclipse.swt.widgets.Shell; public class Main { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); CTabFolder folder = new CTabFolder(shell, SWT.BORDER); folder.addListener(SWT.MouseWheel, new Listener() { public void handleEvent(Event e) { System.out.println("Hello world!"); } }); CTabItem item = new CTabItem(folder, SWT.CLOSE); item.setText("Item"); //$NON-NLS-1$ folder.setSelection(item); shell.setSize(400, 300); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } Oddly enough, the message does get printed to the console. So why doesn't my patch work? :(
Curious. Yes I just tried your test and the handler is triggered but not in the real patch. The only difference I can think of is that someone else is eating the mouse wheel event. So for example in the real workbench there's always some content within the tab. Maybe its getting the event? We can't release this patch until we understand why it doesn't work on XP/Vista.
I had a chat with (the other) Kevin on IRC. <krbarnes> rcjsuen: I think the answer is that the MouseWheel events are coming from the StyledText and not the CTabFolder. <rcjsuen> krbarnes: StyledText..........? <krbarnes> the TextEditor. <rcjsuen> krbarnes: Why does it work with the snippet? <rcjsuen> I didn't add a StyledText there. <rcjsuen> Is there a StyledText embedded in the string text of a CTabFolder's tab? o.O <krbarnes> because your tab has no scrollable control. <rcjsuen> hm <krbarnes> no, that text is just drawn on there. <rcjsuen> so if there was it would be caught by that? <krbarnes> yes, as long as the styled text had the V_SCROLL bit <krbarnes> rcjsuen: it works until you give focus to the StyledText, then you can't give focus back to the tab item <rcjsuen> Interesting. <rcjsuen> Which I guess essentially renders it as a failure in any editorpart or viewpart since they generally all have scrollable controls. <krbarnes> you might be able to use display.addFilter, but you'd have to determine when the editor should be scrolling and when the tab should be changing somehow <rcjsuen> indeed, i had not considered this <rcjsuen> scrolling with my mouse over the tabs does send it down to the editor/treeview <rcjsuen> I guess gtk+ does things differently. <rcjsuen> or maybe not, since I don't think I tested this on editors <rcjsuen> How despicable, I must investigate this when I reboot then. <rcjsuen> krbarnes: Thanks for the help. <krbarnes> I didn't try gtk... I suspect it doesn't work there either.. I tried scrolling in the 'Outline' view on Vista and the tree did scroll. On gtk+, scrolling in the 'Navigator' does not scroll the tree.
This matches somewhat my model of what was going on, which is that a scrolled widget in the tab will get the scroll event. We haven't quite explained why your demo works but I suspect as soon as you drop a scrolled widget in there it'll stop working. The thing is that the tabs in the CTabFolder aren't "real widgets". As I recall, its one composite will all the tabs being drawn by SWT graphics calls. Therefore you have the problem of scrolled event handling within a composite. This may very well work differently in Win32 vs. GTK and I'm not sure is well defined for composites. I don't know if this is technically possible on all platforms, or at least not without a lot of work. My concern is that the fact it works on GTK may be more an accident than an SWT architectural decision to be relied on. All that said, Remy if you want to continue to hack on this I'm happy to keep discussing it and looking at patches. I think you'll need more answers from SWT on scroll event processing differences.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
