Bugzilla – Full Text Bug Listing
| Summary: | [client] "open favorites" popup | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Andrew Eisenberg <andrew.eisenberg> |
| Status: | RESOLVED FIXED | QA Contact: | John Arthorne <john.arthorne> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | aclement, andrew.eisenberg, john.arthorne, kdevolder, ken_walker, libingw, simon_kaegi |
| Version: | 0.2 | Flags: | john.arthorne:
review+
|
| Target Milestone: | 0.4 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 359875 | ||
|
Description
Susan McCourt
I'm finding myself wanting to open favorites from places like the editor and the git pages. It would be nice to have a popup dialog similar to "open resource" which just let you quickly get a list of favorites links and navigate to them. I think I'm wanting this more lately because I used to rely a lot more on my browser history. I would just open a new tab and type what I was looking for, and select the url. But now that I'm running inner and outer orions, and sometimes local orions, it's harder to ensure that I'm picking the right link, so I'm wanting to use a "real" link suggested by Orion that I know will go to the same domain. +1. I am always focusing on a group of files to fix a bug . I would like to switch to another file right after I've done one file. I would always make a favorite list before I start to work on the bug. So if there is a short cut I can navigate to my favorite from the editor in place , it would be nice. I'm finding now that my workflow is: - go to navigator, just so I can get favorites list - then select a favorite The favorites could show up in a menu that hangs off "Navigator". Pushing navigator takes you to the root as today, but pushing the menu button gives you the favorites in a list, including a link to "manage favorites" which would be a page that lets you rename, edit, organize favorites. Then we could take the favorites pane out of the navigator and search results. (In reply to comment #3) > I'm finding now that my workflow is: > - go to navigator, just so I can get favorites list > - then select a favorite > > The favorites could show up in a menu that hangs off "Navigator". Pushing > navigator takes you to the root as today, but pushing the menu button gives you > the favorites in a list, including a link to "manage favorites" which would be > a page that lets you rename, edit, organize favorites. Then we could take the > favorites pane out of the navigator and search results. In bug 361856 we are talking about expanding the left hand nav pane to be more than favorites. It could be groupings of different kinds of folders/file systems, etc. If we go this route, then a menu would be too small to show all these different grouped links. At that point, the question is..do we really need/want a popup, or do we just always make sure this left hand nav can be easily opened from any orion page (even the editor). The idea would be you could be working, pop it open, choose your link, close it. That could be a dialog, or just toggling the pane, etc... While using the editor I wouldn't want space wasted on a permanent favorites list. If it was a slide-out, I think I would tend to use it as a modal dialog - slide it out, Ctrl-click something to open a tab on it, close it. Since I'm a big keyboard user I'd be happier with a popup that has a keybinding. I use the existing "Open Resource" popup all the time... maybe the favorites could just be listed in there? It could even filter down the favorites list as I type to save a lot of tabbing to get to the match I want. +1 I agree with John in that, the favorites would be most useful in the open resources pop-up. A little bit of care will need to be taken for favorites that link to external sites, as well as saved searches. If the suggestions on comment 5 and comment 6 sound reasonable, I can work on this and submit a patch. (In reply to comment #7) > If the suggestions on comment 5 and comment 6 sound reasonable, I can work on > this and submit a patch. That sounds great, Andrew! Go for it! When I wrote the bug, I was originally imagining a separate popup but I think the merged one is a better idea. I'm thinking that in its initial state (no filtering) you'd just see the favorites, and as you type, the favorites filter and you also get the filtered results as before. This would be similar to the move/copy target choices we present in the nav, where the favorites are presented along with a way to choose from any resource. So I think the pattern of showing favorites along side a more generic picker is a good thing. Would the favorite folders (not just files) be shown here? That would be a "new feature" of open resource to redirect to a navigator. Also, the presence of the "random links added by user" is extending the definition a bit, but I think it would be very helpful. I know we were staying away from a total reorganization, but if we put favorites in in "open resource" I think that saved searches don't belong in this dialog. One idea is that the saved searches could appear in a combo box associated with the search box. We could retain the window/favorites/searches preference, but perhaps move the code that managed it out of the favorites service and into the search service. It's always bugged me that we had this weird, special category in favorites. Libing, what do you think? Assigning to Andrew since he is looking at this (In reply to comment #8) > (In reply to comment #7) > > If the suggestions on comment 5 and comment 6 sound reasonable, I can work on > > this and submit a patch. > > That sounds great, Andrew! > Go for it! > When I wrote the bug, I was originally imagining a separate popup but I think > the merged one is a better idea. I'm thinking that in its initial state (no > filtering) you'd just see the favorites, and as you type, the favorites filter > and you also get the filtered results as before. > > This would be similar to the move/copy target choices we present in the nav, > where the favorites are presented along with a way to choose from any resource. > So I think the pattern of showing favorites along side a more generic picker > is a good thing. > > Would the favorite folders (not just files) be shown here? That would be a > "new feature" of open resource to redirect to a navigator. Also, the presence > of the "random links added by user" is extending the definition a bit, but I > think it would be very helpful. > > I know we were staying away from a total reorganization, but if we put > favorites in in "open resource" I think that saved searches don't belong in > this dialog. One idea is that the saved searches could appear in a combo box > associated with the search box. We could retain the window/favorites/searches > preference, but perhaps move the code that managed it out of the favorites > service and into the search service. It's always bugged me that we had this > weird, special category in favorites. Libing, what do you think? I don't have strong objection on putting the saved search in the favorites area as it is convenient and you can see that right after you save it and you can rename it. We can add a combo box beside search box but to me I would think it is a collection of used keywords, where I can quickly do search without bothering typing. Here are links to a few commits for this issue: Most of the work for this issue: https://github.com/kdvolder/orion.client/commit/efeb7842dc757aa55463a9109705d22766b9b52c More changes to OpenResourceDialog.js to behave nicely with Andy's changes (Bug 344614) for up/down keyboard navigation. This commit requires Andy's changes to be applied, but the first one will work either way: https://github.com/kdvolder/orion.client/commit/1e6d1bf38e13b194953e26bd083d5b81d67726b9 A little explanation of what I have done. It is mostly as described already: 1. After initially opening the open resource dialog, all favorites are shown. 2. After typing, favorites are filtered in the same way the resource search is done (i.e, respecting ? and *) 3. Resource matches appear below a horizontal rule. Favorites are always above. 4. Keyboard navigation up/down will navigate first through the favorites (if they exist) and then through the searches (if they exist). 5. External links and folder favorites do appear in the dialog. They work as expected navigating to the external link or the folder. Some things not done: 1. resource matches can appear multiple times: once in favorites and once in the search results. I think they should be filtered from search results if they appear in favorites. 2. Kris's changes to show the full path of the resource if there are name clashes do not work for favorites. When we work on the refactoring of resource changes, we can take care of this (no open bug for the refactoring yet). Please let me know if this is sufficient or you would like any changes. I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use. thanks, Andy. I should be able to look at this after today's status call. per status call, John is going to take a look at this.... As I was playing with Andrew's changes I find that, as user who doesn't like to use favourites. I don't like that this adds extra clutter to the dialof just to say that there are no favourites. I made some small changes to make the favourites section disappear completely when it is empty: The commit is here: https://github.com/kdvolder/orion.client/commit/a5a1882530307050f707e740291c95d9c1299233 (In reply to comment #11) > Most of the work for this issue: > https://github.com/kdvolder/orion.client/commit/efeb7842dc757aa55463a9109705d22766b9b52c I have applied this change to master. > More changes to OpenResourceDialog.js to behave nicely with Andy's changes (Bug > 344614) for up/down keyboard navigation. This commit requires Andy's changes > to be applied, but the first one will work either way: > https://github.com/kdvolder/orion.client/commit/1e6d1bf38e13b194953e26bd083d5b81d67726b9 I battled to merge this into master but failed. Apparently Andy's change was released but for some reason the conflict when cherry-picking this change was horrendous. Would it be possible to rebase your change on master to make it easier to apply? It looks like you've been merging master into your branch rather than rebasing your branch on top of master. I suspect this makes the change difficult to apply because there is little in common between the two branches, but I'm not sure if this is the reason for the conflicts in this case. So the current state is that favorites appear in the open resource dialog, but there is no keyboard navigation. Maybe keyboard navigation was in another bug that I'm not finding? Bug 344614 just seems to be about closing the dialog on enter. I always used tab to iterate through matches here so I don't know if there is some other keyboard navigation that ever worked. I'll leave this bug open to sort that out. Also, I thought it would be nice to show the "star" icon next to favorites so the user could understand where these are coming from. We do this in the "Move to" menu for example. I played around with this but couldn't get the image to display nicely. I have left it in OpenResourceDialog.js commented out if someone wants to take a crack at that (line 121). John - the keyboard (arrow) navigation through open resource results commit is in bug 360977. That contains the commit on which Andrews change here is based. I think it is currently assigned to you but I haven't seen it get committed. Sorry for the mixup. Andy's right that bug 360977 points to the commit that needs to be applied for up/down arrow navigation to work, not the one I originally linked to. If after applying Andy's commit, you are still having trouble applying my second commit, then I will do a rebase. And good point about merge vs rebase, I'll be more careful about that in the future. (In reply to comment #17) > Sorry for the mixup. Andy's right that bug 360977 points to the commit that > needs to be applied for up/down arrow navigation to work, not the one I > originally linked to. > > If after applying Andy's commit, you are still having trouble applying my > second commit, then I will do a rebase. > > And good point about merge vs rebase, I'll be more careful about that in the > future. Aha! I missed that one, thanks for pointing it out. I have released the fix in bug 360977 and now your other patch does indeed apply cleanly. Pushed to master: http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=21ade2f5c4b65faa522678c2b30d0321fe2701b5 Great news. I got nervous for a minute. :) Thanks for applying the patch. this is nice. I agree a star might help show where the initial list is coming from. I'll open a bug. While trying it out I found some other oddities in the way open resource behaves, but I verified it's the same oddities from before this change, I'm just paying more attention. |