Community
Participate
Working Groups
Many interesting bugs lately regarding moving around between pages more easily, and many of these could be implemented by allowing the "orion.navigate.command" contributions to appear in more than just the navigator. Or else at least extend what we mean by "navigator". You could think of the favorites list, global search results, find file by name results...as all being specially filtered views of files/folders, similar to the navigator. When the user is just trying to look at a list of files/folders filtered somewhere, he probably wants to do the same kinds of commands he does in the navigator. Note that we wouldn't necessarily generalize this concept to put the same commands in places like git log. So we need to generalize the idea of a page that "navigates" and show the command contributions there. We are moving toward this for favorites in bug 347058.
related to this is whether any orion.navigate.command contributions should appear in the editor toolbar. (can you make a favorite from within the editor?) Perhaps this is specified in the extension, whether the command also shows in the editor.
(In reply to comment #0) > You could think of the favorites list, global search results, find file by name > results...as all being specially filtered views of files/folders, similar to > the navigator. When the user is just trying to look at a list of files/folders > filtered somewhere, he probably wants to do the same kinds of commands he does > in the navigator. I sense an "objectContribution" coming to Orion soon ;) That concept is very powerful, but I think it would need to be purely declarative so we don't bog down page load times with plugin loading.
(In reply to comment #2) > (In reply to comment #0) > > You could think of the favorites list, global search results, find file by name > > results...as all being specially filtered views of files/folders, similar to > > the navigator. When the user is just trying to look at a list of files/folders > > filtered somewhere, he probably wants to do the same kinds of commands he does > > in the navigator. > > I sense an "objectContribution" coming to Orion soon ;) That concept is very > powerful, but I think it would need to be purely declarative so we don't bog > down page load times with plugin loading. yes, the "item level commands" are really our version of that. It is declarative today, this bug is about allowing them to appear in more than just the navigator
(In reply to comment #3) > yes, the "item level commands" are really our version of that. It is > declarative today, this bug is about allowing them to appear in more than just > the navigator "item level", I like this term. Does that mean where ever we render it, we get the actions associated with it by free? Of course we should also be able to trim/extend them. E.g. something like : default actions/commands will be registered to a type of model but when you render it you can still control them.
(In reply to comment #1) > related to this is whether any orion.navigate.command contributions should > appear in the editor toolbar. (can you make a favorite from within the > editor?) I'd say "yes" to both of these. Having access to the Git-log command while editing a file would be especially useful for me.
Adding John Barton's comments and my replies here, regarding "access git status from editor". >Very often I am looking at coding.html and wanting to commit changes. >For example, I just complete my test on another window/screen, then >returned to Orion to commit. >Often I leave a git status tab up, so I select it, reload it, and commit. >If not then my workflow is sluggish: I have to think, then click >repositories, project, git status. >In general it seems to me the links on the upper RHS ought to be >project buttons rather than top level, just based on frequency. >For example, the RHS on coding could have > git status | site | home >and home could be like navigator now but with links for repository and sites. I had exactly the same work flow as yours and I always kept a separate tab there for git status. More specifically, if I am coding on one of a dozen files sometimes I want to see what I've changed on this file not the whole status page. In this case, in addition to "git status", maybe "compare to head" in the tool bar is more useful.
this is fixed. We don't put all navigate.command extensions everywhere, but we currently let a plugin define "orion.page.links.related" and specify a command id for something that is related. It is up to any orion page to set their page target to something that the command will understand, and then the command will validate against that page's target. One oddity is that we go out of our way not to load a plugin in order to look at the possible command matches. But this can mean that a resource is not decorated in a way that a preexisting command understands. This is unfortunately keeping us from doing things like editor->git status But I think that can be covered in other bugs. This bug is fixed by virtue of the "related links" code traversing orion.navigate.command and adding commands that are valid to the page target.
