Community
Participate
Working Groups
Mylar 1.4.1 / Eclipse 3.2M3 - Linux GTK / gnome 2.10 When I Alt-Click on an element in package explorer (or any other mylar'd view), nothng happens. This should pop open the element and show all sub-elements regardless of mylar "interest level". This functionality works fine in Windows installs.
I have experienced the same problem. Pressing the right-arrow button works, but this also scrolls the view horizontally (which is quite distracting).
I just changed from filtering on SWT.ALT to SWT.MOD3, which I hope resolves the issue. Ian, are you able to verify by synching and trying this in a runtime workspace? (I'll try to get a Linux test environment set up soon).
Still not working, but I don't think there is much we can do. I forgot, under X, ALT-Click grabs the current window. Should be able to see this in any application (if you hover over a button, and then alt-click). A work around (for me at least) is to press the windows key and alt, (there are beside each other on my keyboard). This seems to get sent as alt-click. I am going to write a small SWT application and see exactly what we get. cheers, ian
Thanks for figuring that out! The code that accepts the click is one line in: BrowseFilteredListener.mouseInteractionAccepted(..) So it may be just as easy to play with that rather than writing a seperate app. I assume that most, but not all people will have the Windows key (e.g. ThinkPad users won't). I wonder if we should accept both Alt and another combination?
I used the following small app, and it seems that when the alt-key is pressed, mouse events are not sent to the shell. I think we need another option. package swt_test; import org.eclipse.swt.events.MouseEvent; import org.eclipse.swt.events.MouseListener; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class SWT_Test { /** * @param args */ public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell( display ); shell.addMouseListener( new MouseListener() { public void mouseDoubleClick(MouseEvent e) { } public void mouseDown(MouseEvent e) { System.out.println("Mouse Down Event"); } public void mouseUp(MouseEvent e) { System.out.println("Mouse Up Event"); } }); shell.open(); while ( !shell.isDisposed() ) { if ( !display.readAndDispatch()) display.sleep(); } display.dispose(); } }
What about Ctrl+Alt or Ctrl+Shift+Alt? Perhaps that prevents the window manager from grabbing the Alt mouse event?
Yep, those work (so does Windows Key + alt). The problem is, ctrl and Shift are used for multiple selection, so they behaviour is really strange. If you already have an item selected, and you press Shift+alt, you get multiple selection and the expand. I guess we could change that
But Ctrl+Shift+Alt works fine, right?
We get the mouse click when we hold shift+alt+ctrl, but like other cases, it just results in multiple selection (in Mylar). It expands if it is the first shift+alt+ctrl click done.
What if we made the UI for Linux be middle button click, no modifiers? How do people simulate middle click on a laptop with only two buttons?
I know X-windows uses this for paste (it is not very common, but it still works), but I don't think anyone will be pasting in a view that supports this. I think 3 buttons are emulated by pressing both buttons. This currently selects a node and brings up the context menu.
Duh, of course, I forgot about paste (wow, it's been a while since I used Linux for my desktop, but I still have hope of of going back someday). So we can't use that because resources and Java elements can be pasted.
I think it just pastes text, but I could be wrong (eclipse also support ctrl-c, ctrl-v, so I use those). I will check this today. If it just pastes text, then we may be ok. What about a context menu option to show all descendents? (maybe you have one).
We used to have this, but it was just too slow to use. I think that this needs to be one click (and one keyboard shortcut) and not two.
Hmmm, I don't see the "scroll to the right" behavior with the arrow key. If my view has a horizontal scrollbar this still works as it would with Alt-click and doesn't cause wierd scrolling. Could you describe it in more detail?
Btw, I just checked it and it turns out that ESC doesn't work as a mouse modifier so that's out.
So there seems to be no good solution for this since all the modifiers are taen, just two work-arounds: - click, then right arrow, repeat (instead of alt-click repeat) - use the Windows modifier key to alt-click I'm marking this for LATER in case any ideas for improving on this come up.
*** Bug 150773 has been marked as a duplicate of this bug. ***
*** Bug 206503 has been marked as a duplicate of this bug. ***
Reopening to mark as resolved as per message from webmaster: http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00778.html.
Marking resolved.
I'm just wondering why this issue has been resolved as fixed, as I'm pretty sure this is still a problem on linux. I agree there is not much we can do, but is it really "fixed"? Having said that, using xfce I managed to map Window Grab Key to the Super (windows) key. This appears to be a good workaround for window managers (and keyboards) that support this.
Good point Ian. I have changed the resolution to NOT_ECLIPSE since there is nothing we can do in Eclipse to address this at the moment.
not sure if i miss something, but the OBVIOUS solution would have been to make it user-configurable. why didn't that happen?
Arne, when you ask to make it configurable, what configurations are you thinking should be supported? The other meta keys aren't any better for the reasons discussed above. Allowing users to make a choice of equally unsuitable alternatives does not seem like an improvement.
*** Bug 445314 has been marked as a duplicate of this bug. ***
doesn't matter. the first rule is: user decides. and for a complex system like eclipse, the target audience are people who are supposed to know what they are doing. users are able to think for themselves, don't you think? and since even the workaround mentioned somewhere requires users to re-configure their desk environments shortcuts, what makes you think they wouldn't be able to figure out something sensible on their own? you guys have no chance to know what makes sense for the individual user, nor for the individual desktop environment. given the fact that you know that this shortcut fails on Linux (but apparently did not grasp the concepts of a) user's freedom of choice and b) freedom to configurable) it is shocking that after almost ten years this issue is still unsolved ("NOT_ECLIPSE" is just a poor excuse).
*** Bug 478765 has been marked as a duplicate of this bug. ***
