Community
Participate
Working Groups
0.3RC2. Besides opening it, currently the only actions on a favorite file are delete and rename. But sometimes I need more actions on a favorite. For example: When I tried to do js unit test from "run as unit test" menu, I have to explore i n the navigator every time. It blocks me from doing it in a regular basis. I would like to do that from the favorite.
opened bug 361003 for the general idea. I really like your thinking here. Note also we have a bug for making a page for the favorites list, and I can imagine then that favorites, search results, and navigator would be very similar, with similar actions available on all.
I think we need a little helper that adds "orion.navigate.command" extensions to any menu. So for favorites, we could have Rename Delete ------- Open with Git Status or whatever... The trick here is that the top two menu items refer to the favorites object, and this generic bit would refer to the resource itself. We could do it today by having two menus, one containing the favorites specific, and then rendering another menu called "resource" or whatever that contained only the orion.navigate.command commands. This is easily done, but I'm out of time for RC1. A longer term way to think about it is being able to register item transforms for your items so that when the command service is validating all available object contributions, you could potentially run a transform (say, from faovirte object to the favorite object's resource metadata). We do this today with the "related pages" menu and setPageTarget... So maybe there is something generic to do here.
besides orion.navigate.command, we probably want openwith
What I think we need to do is: 1) have common code that can create/add the open with commands. This means breaking up fileCommands so that nav-specific stuff (move/copy) is separate from all the generically interesting file-based commands. 2) provide a utility method that can generate an href given some metadata. Basically take the code from explorer-table (line 140-160) that is reading the open with commands. 3) another utility could register all the command contributions needed given a contribution id from the caller. Seems like there are cases for just wanting the openwith commands (bug 368984) and then other cases (this bug) where you see a list of file and you want everything. The "common renderer" code that Andrew was looking at would be involved in all of this. See also bug 373189. Mark, were you thinking about anything in particular for open with? It seems reasonable to implement it as a command so that everyone can easily get to it...
(In reply to comment #4) > See also bug 373189. Mark, were you thinking about anything in particular for > open with? It seems reasonable to implement it as a command so that everyone > can easily get to it... Yeah, this makes perfect sense. As long as 'open with' is one supported usecase of commands, that fixes what I was trying to get at in bug 373189.
We've gone a different direction with favorites. See discussion here: http://wiki.eclipse.org/Orion/UX_Issues/R0.5#Navigator_look_and_feel Favorites now only shows up on the navigator, so the "I want to have nav actions on the favorites list when it's in other pages" (like search) is no longer an issue. I do think that we'll revisit the idea of "which commands appear in a file list" when we make the navigator consumable but we can work on that in bug 378124 and its offspring.
