Community
Participate
Working Groups
It would be useful if the Bookmark view had "Show Next" and "Show Previous" buttons just like the Search view has. Also on the subject of inconsistency...the "Delete" button is a red X on the Bookmark view and the Task view, but is a horizontal blue bar on the Search view and the Breakpoints view.)
Created attachment 2599 [details] showing the different changes shows the changes in menus and views
Created attachment 2600 [details] the icons have to be placed in org.eclipse.ui
Created attachment 2601 [details] adds next/previous button, rearranges menus, different remove icon @@ Implementation notes BookmarkNavigator @@ viewer - changed its type from StructuredViewer to TreeViewer - createPartControl() already assigned a TreeViewer - saves casting to get its Tree removeAction - new icons goToNextBookmark() goToPreviousBookmark() - package visible so that the Action classes can call them - wrap-around behavior - if no bookmark is selected and one clicks on next/previous the first bookmark will be opened - opens the bookmark's editor w/ a BusyIndicator handleBookmarkCountChanged() - package visible so that BookmarkContentProvider can call it handleSelectionChanged() - multi-select not allowed -> disable icons addContributions() - removed toolbar button for "Go to"; Search View does not show a similar button; next/previous fill it's function - "Copy to Clipboard" now has the normal icon instead of the colored one; also a "disabled" version - "Go to" still on context menu; disabled icon for "Go to File"; hover version not needed for context menu - added disabled icon version for "Copy to Clipboard" - hook w/ next/previous on Navigate menu fillContextMenu() - reordered menu items to be consistent w/ Search View @@ Notes on icons @@ Copied icons from org.eclipse.search and renamed them (remitem_tsk.gif, prev_nav.gif, next_nav.gif). prev_nav.gif and next_nav.gif previously existed in their enabled version only. I did not overwrite the existing ones (remtsk_tsk.gif, rembkmrk_tsk.gif) because other clients might already use them. @@ Other notes @@ GoToNextBookmarkAction - new class GoToPreviousBookmarkAction - new class IBookmarkHelpContextIds - added the two new actions BookmarkContentProvider - now informs its bookmarksView if a bookmark has been added/removed OpenBookmarkAction - implements Runnable so one can use a BusyIndicator ... opening an outside editor might take a "long" time MarkerUtil - new icons for "remtsk", "remtsk_grey", "remtsk_disabled" in imageDescriptors HashMap
I changed the tooltips to "Show Next Bookmark"/"Show Previous Bookmark" between making the screenshots and creating the patch.
Icons are in a ZIP-File.
Colored versions of the <- and -> icons are already in ctool16 named next_nav.gif and prev_nav.gif -- no corresponding enabled and diabled versions exist. forward_nav.gif and backward_nav.gif are in clcl16/dlcl16/elcl16. Users of ctool/next_nav.gif ctool/next_nav.gif might want to update to the "new" ones.
Chris to review. Please ensure the patch hooks the global actions for Navigate / Next and Previous (IWorkbenchActionConstants.NEXT and PREVIOUS).
Context-menu: Changed "Delete" to "Remove" to comply with Eclipes UI Guideline 2.3 Changed order to comply with 6.13
Should leave as Delete since this hooks the global Edit / Delete action. Also, the Tasks view uses Delete.
2.3 " The term 'Delete' should be used when deleting an existing resource. The term 'Remove' should be used to remove an object from a resource. " The label of the Tasks view "delete" could be changed to "remove" also; tasks and bookmarks are markers not resources. Or, should the guidelines be updated? -- It makes no sense if the basic views do not "[a]dopt the labeling terminology of the workbench". What's the point of differentiating in the guidelines when we'll hook all "delete"/"remove" actions with global delete (and thereby forced to use "delete")?
I think guideline 2.3 needs to be clarified. The example there refers to content within the file, not markers. But even then, it's not clear to me that "Remove" should be used instead of "Delete".
There are currently no plans to work on this
Should I update the patch?
Please do Sebastian - thanks
Assigning to KM to consider in the more general context of quickly moving focus between views and editors (i.e. you could use the arrow keys to move through the list if, when you select something and focus is given to the editor, there was an easy way to get focus back on the list)
See bug #193608 which I've just entered on the more general problem. I'm marking this one as dependent on the general one, assuming the general one addresses this problem sufficiently,
*** Bug 80894 has been marked as a duplicate of this bug. ***
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
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.
