Community
Participate
Working Groups
We are starting to ask UI questions that hint at "show view" support. Examples: - if I have a git history page, could I decide to place it on my navigator so that I could select files in the navigator and look at history? I've got all that white space in the nav... - if I have a git repositories view, can I look at branches from there? (see bug 339564) - could I embed a navigator somewhere in the editor page? I think we all agree that building these pages separately is a better first start so that we are not unintentionally coupling pieces of UI. But I think that we are starting to have a enough tasks that we are running into user prefs as to which tasks belong together. With the following, we could support "show view": * extension point for views, including a way of expressing input requirements (similar to file validation requirements on fileCommands?) * a way for user to select a view and say where it goes * a way for user to get rid of a view * we need to understand per page, which view(s) are the main task on a page and thus cannot be removed. It's easy to get caught up in the details of placing the view and configuring the page. (layout mode, etc.). As a brute force start, I think we could just allocate the BorderContainer chunks and let the user choose "left", "center" "right"
> Examples: > > - if I have a git history page, could I decide to place it on my navigator so > that I could select files in the navigator and look at history? I've got all > that white space in the nav... > - if I have a git repositories view, can I look at branches from there? (see > bug 339564) > - could I embed a navigator somewhere in the editor page? more examples: - list my site configurations and edit the selected one on the same page - I want side by side compare in my git-status instead of inline - I want file history in my editor
The question is also if we shouldn't just use OpenSocial gadgets for this as opposed to inventing our own mechanism.
for what it's worth, I think the eclipse fastview metaphor will play out nicer in the long run (rather than "show view") and I think that imagining the fastview container as something that can hold one or more opensocial gadgets has some potential here.
+1 on OpenSocial. At least investigation if you haven't already adopted them for other reasons. Not clear if the constraints they bring will be worth it, but it would be fantastic to leverage the existing work (and widgets) here. I saw two examples that I was curious about: > - could I embed a navigator somewhere in the editor page? >- list my site configurations and edit the selected one on the same page The first sounds like an overview situation. I'm sitting in an editor, I'd like to know about the file's environment. The second sounds like a master-details story. There's a "nav" (master) for the site configurations, and you can select a configuration which brings up an editor (details) in page. Of course, they're kind of the same thing, but the "container" in both cases has different roles. In particular, what can I do in the first case, with the navigator? I'm sitting in an editor, there's a list of files in the same directory floating somewhere on the page - what happens when I select/activate one of those files? The editor seems to be the main driver here, it would be weird to have it switch the page out completely to edit the new resource - and does that navigator magically show up in the new page? Seems jarring. Compared to the second case where I would think of the "site configurations" to be the main resource for the page, and selecting/activating a configuration would leave you the page, but switch the editor contents to the new configuration. I will admit I'm a fan of master-details; and in particular a navigator list sitting beside my editor; like Eclipse, TextMate, BBEdit, (ie, any modern text editor). Seems very natural. But not sure if it should be lumped into "show view" or treated as a first-class thing itself.
(In reply to comment #4) > I will admit I'm a fan of master-details; and in particular a navigator list > sitting beside my editor; like Eclipse, TextMate, BBEdit, (ie, any modern > text editor). Seems very natural. But not sure if it should be lumped into > "show view" or treated as a first-class thing itself. I've opened bug 389643 to treat it as a first-class thing because I've been doing some experiments...
(In reply to comment #5) > (In reply to comment #4) > > I will admit I'm a fan of master-details; and in particular a navigator list > > sitting beside my editor; like Eclipse, TextMate, BBEdit, (ie, any modern > > text editor). Seems very natural. But not sure if it should be lumped into > > "show view" or treated as a first-class thing itself. > > I've opened bug 389643 to treat it as a first-class thing because I've been > doing some experiments... I thought that we could extend the concept of Related pages to add Navigator or any other page to other Orion pages. So far Related are just links (you click an open a new page), but we could show a preview or small version of the page in a popup and maybe pin it to the page. Editor already has Navigator in Related. So my change would allow to preview the page and pin the minimal version of it to Editor page.
There's been momentum building for having a generic "left side/right side" page. Even if it's not full on "let the user put any view anywhere," we could allow different kinds of left hand (or right hand?) views to be mixed and matched. As Szymon mentioned in comment 6 ...the related page mechanism already lets us find related metadata and determine what other kinds of views a user might be interested in...so having some kind of view instead be drawn in the LHS makes sense to me.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
