Bugzilla – Full Text Bug Listing
| Summary: | Need selection commands in sections | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Szymon Brandys <Szymon.Brandys> |
| Component: | Git | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | libingw, malgorzata.tomczyk, simon_kaegi |
| Version: | 0.5 | ||
| Target Milestone: | 0.5 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 378027 | ||
| Bug Blocks: | 349328, 376093 | ||
|
Description
Szymon Brandys
yes, we definitely need something here. We don't have anything automatically but it should be something like this: - I imagine the section object gosia is working on should have a selection service. In the same way it has progress. - When we build selection based commands we want to tie it to the selection service. - Currently the command service is passed a selection service (one to one mapping) but it seems like instead we would want to tie a selection service to particular contributions. So I think the missing pieces are: 1) we need to be able to get a selection service from a "section" (Gosia/Szymon) 2) I need to rework commands to accept a selection service at the contribution level. 3) Then I can provide sample code for rendering selection based commands I pushed changes to sections. Each section has its own selection service that can be passed to commands now. I need to tidy up the implementation, but Susan you can work on the command framework changes. Susan, if you want to play with section selection service, only staged changes sections on the new git status page was changed so far. (In reply to comment #3) > Susan, if you want to play with section selection service, only staged changes > sections on the new git status page was changed so far. great, thanks. I'll work on this after our call today. (In reply to comment #3) > Susan, if you want to play with section selection service, only staged changes > sections on the new git status page was changed so far. Szymon, I added support for a local selection service to be specified for different command scopes. I also double checked that the explorers store their own selection service rather than assume a global one. So the basic piping that would allow it all to work is there. But I got confused when I tried to use it in gitStatusExplorer. The main thing that has to happen to glue all this together is that both the staged list and the unstaged lists need to implement their content using the explorer model. You would instantiate a selection service and assign it to the explorer, and that same selection service would be given to the command service using the API I just provided. Something like GitStatusExplorer.prototype.displayStagedList ... mySelectionService = new mSelection.Selection(); mySection = .... myStagedModel = .... // the thing that provides the list of staged changes myStagedRenderer = ... // the thing that renders each item in the staged list myContentExplorer = new mExplorer.Explorer(registry, mySelectionService, myStagedRenderer); // then when you register the section area commands, you first say: commandService.registerSelectionService("stagedSectionActionsArea", mySelectionService) As a side note, it's a bit misleading that the new git sectional pages use the word explorer for their main code that renders the various sections. This is what caused some of my confusion. We elsewhere use "explorer" to refer to the list or tree explorers which use the various selection models, selection service, and renderers. Staged and unstaged sections updated. They both use explorer, model and renderer now. I can probably refactor the code to avoid duplications, but I'll do that on Monday along with changing Explorer in gitStatusExplorer to something else. Each selection service instance (global and section one) should be registered in the service registry. The name was hardcoded in selection.js. I added a way to change the name, i.e. the constructor accepts the name attribute now, so selection service for each section would have its own unique name in the registry. However we could think about adding filters to our registry, similar to filters in OSGi declarative services. I will raise a bug for that. However Susan can we live now with the simple solution and just refactor the code when filters in the registry are added? Simon, do you think you could add filters in the timely manner? (In reply to comment #7) > Simon, do you think you could add filters in the timely manner? See bug 378027. (In reply to comment #7) > However Susan can we > live now with the simple solution and just refactor the code when filters in > the registry are added? Yes, it looks fine to me with specifying the id. Existing users get what they expected... I just wanted Simon to be aware that we were doing this in case he wanted to suggest a different solution. Susan, staged and unstaged sections use selection commands now. Each section uses its own selection service, but there seems to be a problem with selection for many explorers on one page. Steps: 1) Open the new status page (git-status2.html) 2) Have some unstaged and some staged changes 3) Select something in the unstaged section, you should see "Stage", "Checkout" and "Show Patch" actions 4) Unselect changes 5) Select something in the staged section, you should see "Unstage" 6) Now leave the selection in the staged section and select something extra in unstaged section You would expect to see "Stage", "Checkout" and "Show Patch" actions again, but that does not happen. I noticed that Selection#setSelections method (in selection.js) always gets all selected items from staged and unstaged sections. (In reply to comment #10) > Susan, staged and unstaged sections use selection commands now. Each section > uses its own selection service, but there seems to be a problem with selection > for many explorers on one page. I raised Bug 378683 for that. I think we may close this bug and raise new ones like Bug 378683 for remaining problems. (In reply to comment #12) > I think we may close this bug and raise new ones like Bug 378683 for remaining > problems. ok, I am in the process of converting favorites to an explorer and I will be a client of this as well.... |