Community
Participate
Working Groups
This extension point currently takes a label and command id. Instead... - label can be gotten from the command - should have validation properties that are separate from the command - the service implementation (currently none) could potentially run a transform on the item to get the format needed by the command. So...we could offer "Git Status" for an editor's parent folder, and if selected, we would first run the transform on the folder to get the git info and then use that to run the git status command. We want to make sure the transform is on demand, so that it doesn't cause loading of something like the git plugin until the user selects something.
we would have to make sure that we have a good fail message for the case where the transform does not work
Could you also stub in some doc for the service here so it doesn't get missed: http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/User_interface_services
(In reply to comment #2) > Could you also stub in some doc for the service here so it doesn't get missed: > > http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/User_interface_services will do, thanks for the reminder.
all of the pages need to be participating in this extension point. I haven't added them all yet.
*** Bug 369735 has been marked as a duplicate of this bug. ***
I added a few more items tonight: - ability to provide an "alternate item transform" function so that if a command doesn't validate against your metadata, you can run a function to try to get related metadata. Right now I just support one transform. There's an example in the editor (setup.js) which transforms the file item to its folder parent (so that you can now get "Git Status" from the editor.) YEA! mGlobalCommands.setPageTarget(metadata, serviceRegistry, commandService, function() { if (metadata.Parents && metadata.Parents.length > 0) { return fileClient.read(metadata.Parents[0].Location, true); } }); The function returns a deferred that will get alternate metadata. - I added support in the git repo and commit pages for related pages (was already doing so in git log) - I added two new commands in support of bug 370706. Now you can link to the corresponding github or eclipse.org git repo from an orion git page. See that bug for detail. Things I'd still like to do are: - in pages that use orion.core.linkscanner, I'd like to add all scanned links to "related pages" or at least see how busy that makes things. This requires some additional mGlobalCommands API to add a stateless link without going through a command first. We should be able to link to bugzilla in "related links" from the editor or the commit pages or log pages, etc. - the navigator itself should contribute some "go to navigator" related links so that you can get to the navigator easily from any git page, or search results, or other pages where the breadcrumb is repurposed. - we should be able to get to git status from more places (git repo, commit page, etc.) - git status needs to participate so you can link to the navigator, git logs, etc. A really cool thing (time permitting, late breaking feature) would be a related links menu that let you add a related link for a resource location. Then it would show up whenever any page was working with that resource. So if I wanted to add a link to a bugzilla query on files that I work with a lot, I could. I doubt I'll get to this because you need UI for removing the link, etc. But it would be cool.
(In reply to comment #6) > Things I'd still like to do are: > - in pages that use orion.core.linkscanner, I'd like to add all scanned links > to "related pages" or at least see how busy that makes things. This requires > some additional mGlobalCommands API to add a stateless link without going > through a command first. We should be able to link to bugzilla in "related > links" from the editor or the commit pages or log pages, etc. opened bug 371001 > - the navigator itself should contribute some "go to navigator" related links > so that you can get to the navigator easily from any git page, or search > results, or other pages where the breadcrumb is repurposed. done > - we should be able to get to git status from more places (git repo, commit > page, etc.) > - git status needs to participate so you can link to the navigator, git logs, > etc. done > > A really cool thing (time permitting, late breaking feature) would be a related > links menu that let you add a related link for a resource location. Then it > would show up whenever any page was working with that resource. So if I wanted > to add a link to a bugzilla query on files that I work with a lot, I could. I > doubt I'll get to this because you need UI for removing the link, etc. But it > would be cool. also in bug 371001 This is all there is time for in 0.4
