Bugzilla – Full Text Bug Listing
| Summary: | [launch][menu] Make launch favorites be buttons on the toolbar | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ed Burnette <ed.burnette> | ||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | ben_hutchison, filipe, mkomor, mooreb, n.a.edgar, nicholls, pawel.1.piech, remy.suen, timmak | ||||
| Version: | 3.0 | Keywords: | helpwanted | ||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Ed Burnette
This is a Debug feature request that will require new Workbench support. Moving to Debug for comment. Perhaps Chris could consider this as part of his investigations into dynamic menus;. Notes: * the favorites support is modelled after IE's favorites - i.e. you can decide what appears in the menu, and in what order * we have anohter feature request to add key bindings to launch configs, which will also enhance the use of favorites I've used a system that just had the key bindings (TextPad external tools) and it is somewhat useful but not terribly. The ability to easily add a button on the toolbar (whether you continue to call it favorites or whatever) would be much better. Currently deferred. We've had customers who have requested for this feature as well. *** Bug 98238 has been marked as a duplicate of this bug. *** *** Bug 80447 has been marked as a duplicate of this bug. *** *** Bug 127803 has been marked as a duplicate of this bug. *** See bug 127803 for contributed patch/implementation. I have created a patch which implements the feature described by this bug. It allows a user to define their own icon for a launch configuration, and to add these launch configurations to the Toolbar area. This patch was created against the CVS repository on March 10th, 2006. THe patch affects 4 plug-ins: org.eclipse.debug.core org.eclipse.debug.ui org.eclipse.ui.externaltools org.eclipse.ant.ui The latter two plug-ins are only affected due to a refactoring of 2 classes, to avoid circular dependencies. The bulk of the changes occur in debug.ui, with a few small changes to debug.core. While implementing this feature I ran into a separate bug regarding launch configurations and putting them on the favourites list. I have opened a separate bug for this. Please see Bug 131346. This patch provides the following: - Alters the tab group viewer to allow the specification of a user defined icon for each launch configuration (with dynamic variable support) - Leverages the existing framework used to manage the launch configuration Favourites list, and adds the ability to show these configurations on the toolbar - Toolbar buttons can be repositioned by re-ordering the favourites list - When a launch action is invoked from the toolbar, the launch mode is retrieved by querying for the launchGroup from the launch history (again, using the existing framework that the Favourites list uses) - An action was added to the external tools drop down menu to switch the toolbar on and off - The delegatingModelPresentation (label provider) now gives precedence to user specified icons, before attempting to retrieve the default images. I am submitting this patch in hopes that this implementation will make it in to the next Eclipse release. Created attachment 36064 [details]
Custom Toolbar implementation
Patch for what I described above.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. Deaf to your users. A bureaucratic, corporate parody of the "open" source you claimed to be. Please don't go that way, Eclipse. Heres a much requested feature. 6 years old. 3 duplicate reports. 2 contributed patches. Simple and useful. To what end? "Status: RESOLVED WONTFIX" Sadly, this is no isolated incident, the Eclipse bug database has several of these sorry stories, each with queues of frustrated users piling up behind blocked tickets. Eg, some of the infamous ones: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939 https://bugs.eclipse.org/bugs/show_bug.cgi?id=35779 ..although unlike those other two, this one is not particularly difficult or controversial to fix. (In reply to comment #13) > Heres a much requested feature. 6 years old. 3 duplicate reports. 2 contributed > patches. Simple and useful. > > To what end? "Status: RESOLVED WONTFIX" In the Debug team's defense, the bug was originally set to RESOLVED/LATER (which I admit is not exactly "ideal"). https://bugs.eclipse.org/bugs/show_activity.cgi?id=51003 Those resolution states no longer became valid so the webmaster performed a mass conversion of all bugs previously in either of those two states (see comment 12 above yours and the history that was previously linked which shows Denis changed it from LATER to WONTFIX). I am going to reopen this bug on the grounds that there are still people that consider this important based on comment 13. The attached patch does a lot more than the title of this bug. Any interest in implementing this feature using the command framework? Comment on attachment 36064 [details]
Custom Toolbar implementation
Marking the patch as obsolete as it has many conflicts with the current debug code and includes changes that are unrelated to this bug.
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. If the bug is still relevant, please remove the stalebug whiteboard tag. |