Community
Participate
Working Groups
I am connected to 4 different github repositories for various contributors. It is very hard to find a branch from this list. It would be helpful to have a better way of visually making out the repo. Some things that could help: - there is a lot of vertical space between each branch in the list. maybe a more compact representation will help my eye to scan the list so I don't have to scroll - maybe the repo name could be in a separate column so I can quickly parse which repo it's from rather than deal with a long list
Created attachment 210018 [details] screenshot I think vertical compaction would help immensely. With 4 remotes of the org.eclipse.orion.client repo, I have to scroll through 25 pages to see all the branches.
(In reply to comment #0) > - maybe the repo name could be in a separate column You mean the remote name, right? I pushed a fix today that makes both repo and commit pages more compact. Moreover it adds alternate background for longer lists. What would make sense is a section filtering field where you could put a name and the list would show just matching items.
I was thinking about a search/filter field in each section. Then you could type in the name of your branch or/and remote and it would narrow the section to just matching items. But this will be .5.
(In reply to comment #3) > I was thinking about a search/filter field in each section. Then you could > type in the name of your branch or/and remote and it would narrow the > section to just matching items. But this will be .5. Proposal fix: https://github.com/maciej-bendkowski/orion.client/commit/8e7e32edd4db67e21e4d015d03cda73b40cd07ac At this point only remote branches in the 'view all' might be filtered. If this solution will meet our expectations I'd like to extend the filtering to commits and tags.
Also I'd like to point out an idea we've came up with Szymon lately. As for now, the new filter feature should facilitate working with remotes, but of course there arises a natural question why don't we expand this idea into the main repository page. In my opinion the main repository page usage should be rethought (at least updated). The main repository page should consist only of most commonly used items and associated commands. Usually, working on a task I'm interested only in a small portion of all possible branches, tags, etc. Loading large parts of unneeded data is not only unhelpful, but also slows my workflow. Quick access to items we're working on should be considered crucial at this point. In order to accomplish this goal we'd like to extend the idea of 'favorites' onto branches, commits, and so on. Branches could be marked as favorites and would be always visible on the main repository page at the top position in the branch list. Next, we would find some of our recent 'touched' branches. To determine the 'recent' part, Orion would track our activity and store in on the server side. At the main repository page we would load only the 'most possible' items we expect the user to work on. In addition, we would provide a filter search for these items. If the user is interested in a particular branch and it's not on the main page, we would provide a quick link to the branch on the 'view all' page. This way we load only crucial items, the repository page loads quickly and is considered a nice navigation point for working with repositories. Of course this solution would require to rethink the favorites feature in Orion and especially their visual representation.
(In reply to comment #5) > Branches could be marked as favorites and would be always visible on the > main repository page at the top position in the branch list. <snip> > > Of course this solution would require to rethink the favorites feature in > Orion and especially their visual representation. I like this approach, just wanted to comment that I don't think we would have to rethink the handling of other favorites. For example, we have file favorites that show in the navigator, but they also appear contextually in other places where we prompt for files. (find file dialog, move/copy menu items). So I think it would be fine to introduce "branch" or "tag" favorites, etc. and these would appear in the "short lists" on the repo page. I don't think these should show up in the navigator favorites list. We'd be introducing the notion of marking favorites that appear contextually. The main thing would be how to get rid of them. (The file favorites can be deleted in the favorites list). Maybe we just have a command for "remove favorite" that would appear if something were already marked a favorite? Or alternatively a favorites tray but I'm not sure it makes sense, since you wouldn't necessarily navigate to the favorite the way you would in the navigator. The long run answer might be bug 371007.
(In reply to comment #6) > We'd be introducing the notion of marking favorites that appear > contextually. The main thing would be how to get rid of them. (The file > favorites can be deleted in the favorites list). Maybe we just have a > command for "remove favorite" that would appear if something were already > marked a favorite? Since the only place where the favorite branches appear is the main repository page, the "remove favorite" command (possible a star icon, or something) seems to be the most appropriate solution. Also as I think about it, the user-defined favorites are a nice and elegant way of tracking our work items, but maybe not the easiest one. This feature should coexist with the "Orion tracking" feature I've mentioned before. It would be nice to have Orion by default do the branch tracking so I don't have to (if I don't want to). Combined, those two features may facilitate the workflow dramatically. Or at least I hope so.
(In reply to comment #7) > Also as I think about it, the user-defined favorites are a nice and elegant > way of tracking our work items, but maybe not the easiest one. This feature > should coexist with the "Orion tracking" feature I've mentioned before. It > would be nice to have Orion by default do the branch tracking so I don't > have to (if I don't want to). Combined, those two features may facilitate > the workflow dramatically. Or at least I hope so. If by "tracking" you mean "most recent, or most used" tracking I agree. We used to do this in the navigator, but the problem there was that we were doing server round trips to record client-side only navigations. In the case of making branches active, etc., it's already a heavyweight operation so remembering the branch is a small part of that. The main thing is to make sure that if a branch is deleted, it's also deleted from the recent/most used list.
(In reply to comment #8) > If by "tracking" you mean "most recent, or most used" tracking I agree. We > used to do this in the navigator, but the problem there was that we were > doing server round trips to record client-side only navigations. In the > case of making branches active, etc., it's already a heavyweight operation > so remembering the branch is a small part of that. The main thing is to > make sure that if a branch is deleted, it's also deleted from the > recent/most used list. Yes, I meant most recent and/or most used branches. Recording the "recent" part could be done with one timestamp per item. The "use" part would take an integer which would hold the information how many times the item was requested. The total cost seems to be minimal. Also it would be nice to come up with a way to balance situations where an old and very popular item is shown in the "Orion favorites" list, but for obvious reasons shouldn't be.
(In reply to comment #4) > Proposal fix: > https://github.com/maciej-bendkowski/orion.client/commit/8e7e32edd4db67e21e4d015d03cda73b40cd07ac > > At this point only remote branches in the 'view all' might be filtered. > If this solution will meet our expectations I'd like to extend the filtering > to commits and tags. Generally this proposition looks and works nice. I propose to change one thing before commiting: the filterSearchBox should be more generic, so that you'll be able to use it in other filtered sections, to do this I propose: 1. remove "hardcoded search box id", and replace it with an option in constructor 2. placeHolder message should have default text like "Filter" that can be overwritten in constructor 3. the node to clean should be passed, not hardcoded ("remoteBranchNode") 4. change the terminology "branches" -> "items" apart from this I think the code may be merged. For the extended favorites functionality we can open a new bug, if it's not opened yet.
Suggestions included: https://github.com/maciej-bendkowski/orion.client/commit/af43b25c50ff13a1598b48ba4aac701db7c35f0e I'd like to comment, that this approach is not the most elegant one I could think of. Unfortunately I have to render all matching items in the main event thread, which causes the browser to freeze for a brief moment (noticeable if you filter more then 100 branches). I intentionally did not used any WebWorkers at this point. We could think of using them in future for efficiency reasons.
> Unfortunately I have to render all matching items in the main event thread, > which causes the browser to freeze for a brief moment 1. Use setTimeout(function(){...}, 1); to force the asynchronous call. 2. Please update jsdoc for FilterSearchBox
(In reply to comment #12) > 1. Use setTimeout(function(){...}, 1); to force the asynchronous call. > 2. Please update jsdoc for FilterSearchBox Fix: https://github.com/maciej-bendkowski/orion.client/commit/dde0b1d797d93b61ccb349796af5df588f9c4679 Done as requested.
*** Bug 371739 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > Fix: > https://github.com/maciej-bendkowski/orion.client/commit/ > dde0b1d797d93b61ccb349796af5df588f9c4679 > > Done as requested. I'm fine with this commit and I think we can merge it. Szymon, waiting only for your opinion.
As Szymon requested: https://orion.eclipse.org/git/reviewRequest.html#git@github.com:maciej-bendkowski/orion.client.git_dde0b1d797d93b61ccb349796af5df588f9c4679
I found an issue. Steps: 1) Go to View All Branches page 2) Enter e.g. 'origin' to the filter field and see how the list is filtered nicely 3) Now leave the filter box, enter it again and exapnd 4) See that the list is not filtered
(In reply to comment #17) > I found an issue. Steps: > 1) Go to View All Branches page > 2) Enter e.g. 'origin' to the filter field and see how the list is filtered > nicely > 3) Now leave the filter box, enter it again and exapnd > 4) See that the list is not filtered Well, this is actually a dijit.form.Combobox issue. The list is filtered only after we type a character in the filter box. I looked up for a programmatic solution to force a filter on focus - unfortunately without any success. I don't see any way to solve this issue. A quick workaround would be to delete the last character and type it again. If you wish, we could post a bug to dijit.
(In reply to comment #18) > Well, this is actually a dijit.form.Combobox issue. The list is filtered > only after we type a character in the filter box. I looked up for a > programmatic solution to force a filter on focus - unfortunately without any > success. I don't see any way to solve this issue. A quick workaround would > be to delete the last character and type it again. If you wish, we could > post a bug to dijit. I opened a bug on dojo's side for this: http://bugs.dojotoolkit.org/ticket/15908
Fix merged to master. Thanks Maciek.
(In reply to comment #19) > I opened a bug on dojo's side for this: > http://bugs.dojotoolkit.org/ticket/15908 I raised a follow-up bug, see Bug 388454.
