Community
Participate
Working Groups
This came to my mind while working on git-commit.html page. I think that our compare widget should have a toggle that switch between modes: one view, side by side view, show just a diff. At the moment I have to handle it on my side and it would be handy to have it built-in.
One of the foundation changes that will affect the switcher will be the diff navigation model.
Fix of bug 376130 will be soon. Most of the diff feature will be shared between inline and side by side. The only exceptions in the inline widget will be the "merged" text and the "pair of annotation" in the same editor. In order to consolidate the commands and the parent DIV shared by both modes, we need a rule where to put the "toolbar". Currently all the commands (next, previous , change mode(coming) , etc) are rendered in the file name area. We may want to render them in a toolbar. By "toolbar", I was wondering whether to allow the caller to pass a span ID or just self-contain that in the widget. I prefer to self-contained toolbar. The whole nested container UI parts are generated by TwoWayCompareUIFactory or InlineCompareUIFactory(on the way), so if we want the self contained toobar, I need another layer to render both toolbar and compare DIV (vertically) , where the switcher decides which compare UI fills up that DIV
(In reply to comment #2) > I prefer to self-contained toolbar. The whole nested container UI parts are > generated by TwoWayCompareUIFactory or InlineCompareUIFactory(on the way), so > if we want the self contained toobar, I need another layer to render both > toolbar and compare DIV (vertically) , where the switcher decides which compare > UI fills up that DIV I think the caller should decide how to place commands and pass the id's for the regular actions and navigation actions. That way, in a page where the compare widget is the only thing, we can use the existing toolbar "pageActions" and "pageNavigationActions". In a page where the widget is not owning the whole page, the person designing the page can decide where those should go. Our existing patterns are that commands appear either in the toolbar, in a section header, or inline. This seems like a toolbar and/or section header thing to me, and that is something the page designer can decide.
(In reply to comment #3) > (In reply to comment #2) > > > I prefer to self-contained toolbar. The whole nested container UI parts are > > generated by TwoWayCompareUIFactory or InlineCompareUIFactory(on the way), so > > if we want the self contained toobar, I need another layer to render both > > toolbar and compare DIV (vertically) , where the switcher decides which compare > > UI fills up that DIV > > I think the caller should decide how to place commands and pass the id's for > the regular actions and navigation actions. That way, in a page where the > compare widget is the only thing, we can use the existing toolbar "pageActions" > and "pageNavigationActions". In a page where the widget is not owning the > whole page, the person designing the page can decide where those should go. > Our existing patterns are that commands appear either in the toolbar, in a > section header, or inline. This seems like a toolbar and/or section header > thing to me, and that is something the page designer can decide. Thanks, Susan. Just in case of allowing page designer to render their own commands before or after, the diff commands order range will be 100 to 200.
fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=279c541b7cd2361eabe43623bfc2c2a52557f9f1. Talked to Susan about the command name of the switcher. "Unified" <--> "Side by side" The "show just a diff" mode is not implemented. My guess is that it should be just a "shorter" version of the inline view. If we think we really need it we can make it later.
