Bug 361003

Comment 1 Susan McCourt 2011-10-14 12:16:27 EDT

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.

Comment 2 John Arthorne 2011-10-14 13:06:58 EDT

(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.

Comment 3 Susan McCourt 2011-10-14 13:11:24 EDT

(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

Comment 4 libing wang 2011-10-14 13:32:42 EDT

(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.

Comment 5 Mark Macdonald 2011-10-14 13:55:24 EDT

(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.

Comment 6 libing wang 2011-11-09 08:32:24 EST

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.

Comment 7 Susan McCourt 2012-01-27 22:58:08 EST

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.