Community
Participate
Working Groups
It would be cool to allow the user to specify hot keys for the first, second .. history item for the debug, run, and external tool history menus. Could be something like create the action definitions / acceleratorSets for a set number of history elements. Then when the history items are generated, the setActionDefinitionId could be set and the keyBindingService for the active part updated.
Better yet, it would be nice to be able to specify the key binding in the Launch History page. However, I'm going mark this one as "later". Unless we can modity the action "description/label" it would be unfriendly. I.e. we'd have to action descriptions like "First Favortite"...
What we really want is to be able to associate a key binding with a launch config.
Deferred on workbench support.
Re-open for 3.1 investigation.
If I understand this, I could define keystroke for a particular launch config, and pressing it would Run that launch, right? Definately a needed feature.
Currently, commands have to be defined in plug-in XML (i.e. can't be programatically created). Deferred, pending status of above 'depends on' features.
I could use this feature too (also bug 80447).
I tried this as described in bug 53433. On the bright side, it does work - but you get a potentially huge drop down box in the "Modify" tab of the "Keys" preference page (one for each configuration, in each launch mode).
Re-opening for 3.2 consideration.
Deferring. I don't think we have the right solution yet. I will attach a patch to show how to use the existing infrastructure. I don't think the user want to go to the "keys" pref page to set a key-binding for a launch config. It would make more sense to do this on the launch config itself (perhaps on the common tab). As well, the keys page does not scale well for (number of configs * lauch modes). This solution creates a possible "launch config" command for each configuration in each launch mode. Unfortunately, not all launch modes are applicable to all configurations, but they still show up.
Created attachment 33861 [details] Sample patch
*** Bug 222589 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 290252 has been marked as a duplicate of this bug. ***
Re-opening based on re-newed interest (this bug was auto-closed when "LATER" was removed).
Pinging for status, now that all "depends-on" bugs seem to be fixed. I think the most important case to address is this: As an Eclipse user, I have 3 or 4 Launches which I use most frequently. I'd like to associate those most favorite Launches with keyboard shortcuts such that I can access them quickly. Today, I can already use menu accelerators to do this: Alt+R, H, 1 ## debug 1st favorite Alt+R, H, 2 ## debug 2nd favorite Alt+R, T, 2 ## run 2nd favorite The number to use can be configured with the mouse: Use the dropdown beside the debug button and "Organize Favorites..." to sort the order. The first 9 ones will be available via number accelerator, #10 and later will not be directly available by keyboard. So in general, the request seems to be satisfied except for following few issues which could be further improved: - I did not find a way to "Organize Favorites..." with the keyboard only, in order to change the order of Launch configurations. Is this an accessibility problem to be tracked separately? - Using just accelerators and numbers is not team-shareable and hard to remember. When importing shared launch configs which are associated with favorites, the ordering would be random. It would be better if "Organize Favorites" would allow explicitly specifying a key to associate with each item (and storing that key in the launch config, or workspace prefs). - Instead of a 3-part key sequence it would be better to have a 2-part sequence or user defineable 1-part sequence. --> For 2-part sequences, there could be a SINGLE key command to "open debug history" or "open debug favorites". --> For 1-part sequences, in order to properly deal with key binding conflicts (which may be quite common), so I think this would need to be set via Keys Preferences. For me personally, the patch attached from comment 11 does not look that bad.
(In reply to comment #10) > I don't think the user want to go to the "keys" pref page to set a key-binding > for a launch config. It would be better than nothing (but IMO good enough for power users who really care). If you create the commands without a category ID, then they are filtered on the Keys page (reveal them view Filters... > Filter uncategorized). > It would make more sense to do this on the launch config > itself (perhaps on the common tab). That could also be added later.
An alternative could be commands to open the "Run History >" etc. menus as quick menus, like "File > New >", which opens with Alt+Shift+N. Advantages: - only 3 new commands (Run Debug, External Tools), no conflicts - good discoverability (shortcut shown in the Run menu) - nothing to configure except for launch favorites - simple implementation using QuickMenuCreator Disadvantage: - shortcuts are always two strokes (<base binding>, <number>)
(In reply to comment #18) I had mentioned something similar in comment 11 already, but there are a couple of issues: 1.) My main concern is, that this approach is not team-shareable. I would like to see a solution where one admin (or OEM) can configure the Eclipse based system such that the most important launches are available immediately. 2.) In my experience, the "history" doesn't help much since the numbers of recent launches are not deterministic. If I have to carefully look at the menu to pick the correct number, the shortcut doesn't help me much. This leaves the favorites ... which are not exactly intuitive to configure since I need to first edit the Launch Config itself to make something a Favorite, then "Organize Favorites) to choose a number. Another reason why I'd really like to see a team-shareable solution. 3.) There's potentially more than just 3 commands (consider "Profile" for example). 4.) Do we really win much with a 2-stroke approach compared to the 3-stroke approach we already have today? I still think that the patch from comment 11 is not that bad, since it allows to assign deterministic single-stroke commands and allows to team-share the setup via export/import preferences or keys. Though using the Launch Configuration itself for assigning a key would IMO be superior in terms of ease-of-use and flexibility (just share the assigned key just with the Launch that it refers to).
Without realising this bug existed, I've implemented something similar (keybindings for recent launches). It's in its own plug-in at the moment, and is available at: https://github.com/Sinjo/eclipse-run-helper It's got a maven build script around it, so you can run "mvn clean package" to get a jar which will work fine in the dropins folder. There are a few things about it which I'm not keen on, and would like to find cleaner implementations for: * To work around the inability to change a command's name (which is what appears when using two-stroke commands), I implemented a single command which launches a dialog that lists all the recent launches, and listens for key presses to decide what to launch. * The above workaround also got me past https://bugs.eclipse.org/bugs/show_bug.cgi?id=369860 which I didn't want to wait for a fix for at the time of writing my plug-in. * To detect the last JUnit launch, the plug-in depends on the JDT JUnit plug-in. This should really be made into an optional dependency. I'd certainly be interested in trying to get this functionality (or some modified form of it) integrated into Eclipse Platform Debug. To that end, I'd welcome any comments on what I've done, and on what would need doing to integrate it back into Eclipse. I've attached a screenshot of the plug-in in action.
Created attachment 224934 [details] Screenshot of Eclipse Run Helper plug-in UI
(In reply to comment #21) > Created attachment 224934 [details] > Screenshot of Eclipse Run Helper plug-in UI I grabbed your project and tried to run it, although immediately after trying to open the popup I get the following: java.lang.NullPointerException at uk.co.sinjakli.eclipserunhelper.ui.RunHelperDialog$1.getImage(RunHelperDialog.java:113) at org.eclipse.jface.viewers.ColumnLabelProvider.update(ColumnLabelProvider.java:37) at org.eclipse.jface.viewers.ViewerColumn.refresh(ViewerColumn.java:152) at org.eclipse.jface.viewers.AbstractTableViewer.doUpdateItem(AbstractTableViewer.java:400) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:485) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:2167) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefreshAll(AbstractTableViewer.java:712) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:650) at org.eclipse.jface.viewers.AbstractTableViewer.internalRefresh(AbstractTableViewer.java:637) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1508) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1443) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1404) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1506) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:537) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1465) at uk.co.sinjakli.eclipserunhelper.ui.RunHelperDialog.createDialogArea(RunHelperDialog.java:166) at org.eclipse.jface.dialogs.PopupDialog.createContents(PopupDialog.java:700) at org.eclipse.jface.window.Window.create(Window.java:431) at org.eclipse.jface.dialogs.PopupDialog.open(PopupDialog.java:1140) at uk.co.sinjakli.eclipserunhelper.handlers.DisplayRunHelperHandler$1.run(DisplayRunHelperHandler.java:94) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3965) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3642) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1048) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:939) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:79) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:587) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:542) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1443) at org.eclipse.equinox.launcher.Main.main(Main.java:1419) Also the binding Shift+F11 is reserved on Mac OSX for showing the desktop.
(In reply to comment #22) > (In reply to comment #21) > > Created attachment 224934 [details] > > Screenshot of Eclipse Run Helper plug-in UI > > I grabbed your project and tried to run it, although immediately after > trying to open the popup I get the following: > > java.lang.NullPointerException I made a quick fix to get the dialog up and running and have a couple of thoughts: 1. it would be cool if the popup looked just like the history menu does: the favorites are always on top, with a separator, then the rest of the launch history 2. which brings me to thought 2, the history size preference should be honoured here as well - if I say I want to see 20 launches in my history I should see 20 of them in the popup 3. it seems like I can only get the configurations for the run launch mode Other than that I did not do an in-depth review of the code, just fixed the NPE - which is in the RunHelperDialog ~line 117, DebugUITools.getDefaultImageDescriptor(type) can return null for types that do not define an image. This solution is sort of like what Markus mentioned in comment #18, except it shows them in a popup.
I have a few concerns about the solution from comment 20. In contrast to comment 18, this solution is not discoverable and adds a new UI for something that is already available (quick menus). And it also doesn't address the concerns from comment 19. The special command for "Run last JUnit test" would have to be implemented in the org.eeclipse.jdt.junit plug-in -- but it still looks a bit off: Why is JUnit a special case? What about JUnit Plug-in Tests? Or External Tools launch configurations? If we add a special "Run/Debug/Profile last *" command, then it should also be generic and work for all kinds of launch configurations.
(In reply to comment #23) I'll take a look at making it behave more like the current history menu. > 3. it seems like I can only get the configurations for the run launch mode On my local machine (Windows x86_64) changing this line of code http://git.io/M5yOkg between the RUN and DEBUG options seemed to make no difference to the list of Launch Configurations returned. I'll give it another try and see what happens. (In reply to comment #24) > I have a few concerns about the solution from comment 20. In contrast to > comment 18, this solution is not discoverable and adds a new UI for > something that is already available (quick menus). And it also doesn't > address the concerns from comment 19. Just to clarify on quick menus, is that what the functionality for "normal" two stroke keybindings is called (eg what appears when you press alt+shift+d)? The reason I steered away from those were the static names they get from the commands, which would leave you with labels like "Run 2nd from launch history". Is it possibly to make those dynamic? > The special command for "Run last JUnit test" would have to be implemented > in the org.eeclipse.jdt.junit plug-in -- but it still looks a bit off: Why > is JUnit a special case? What about JUnit Plug-in Tests? Or External Tools > launch configurations? If we add a special "Run/Debug/Profile last *" > command, then it should also be generic and work for all kinds of launch > configurations. I agree that in the context of the Platform Debug, it is weird to special case that plug-in. When I started on the Run Helper plug-in, I hadn't seen this bug and so wasn't really thinking about how it would fit into the core Eclipse Platform.
> Just to clarify on quick menus, is that what the functionality for "normal" > two stroke keybindings is called (eg what appears when you press > alt+shift+d)? No. Quick menus are submenus that can also be opened directly via a shortcut, e.g. File > New (Alt+Shift+N) or Navigate > Show In (Alt+Shift+W). org.eclipse.ui.actions.QuickMenuCreator creates and opens such menus.
*** Bug 45396 has been marked as a duplicate of this bug. ***
Hi, Is there any plan to merge this enhancement? Thank you.
(In reply to Alejandro Torras from comment #28) > Hi, > > Is there any plan to merge this enhancement? There's currently nothing to merge. Someone would have to provide a high quality patch.
*** Bug 530013 has been marked as a duplicate of this bug. ***
Created attachment 275195 [details] Shortcut tab external tools I was wandering if something similar will be implemented as DVT (see attachments). This kind of option i am really missing in the current environment
(In reply to Hans van der from comment #31) > Created attachment 275195 [details] > Shortcut tab external tools > > I was wandering if something similar will be implemented as DVT (see > attachments). This kind of option i am really missing in the current > environment If someone can work on this and provide a quality patch, we can look at it.
