Community
Participate
Working Groups
Since the Luna release, the information about which diagrams and tables are open in the editor and how they are laid out has been stored in the private workspace metadata area instead of the *.di resource (which is often shared with teams in some kind of repository). This has led to problems in the experience of the first time opening a model, when no pages are yet open in the editor. This enhancement is an umbrella for a new Welcome Page feature and related enhancements to improve the experience of working with the editor and model export/import scenarios, as documented in the wiki page referenced by the URL field.
I have added initial requirements gleaned from existing bug reports and other sources of feed-back, with some UI wireframe sketches of what I imagine a welcome page might look like.
(In reply to Christian W. Damus from comment #1) > I have added ... ... to the linked wiki page, oops.
The first step in development of this feature is demonstrated in a brief video: http://youtu.be/cfd8wW14JxA and pushed to a new development branch: committers/cdamus/469188-editor-welcome with builds coming soon on Hudson: https://hudson.eclipse.org/papyrus/job/Papyrus-Feature-Editor-Welcome/ So far, the Welcome Page is presented by the editor whenever it has no other pages to show, in which case it cannot be closed (as that would leave an empty editor). At this stage, it is just a blank placeholder. The next step is an API for providers to plug in useful content.
Chris, I have look to the visual design sketch on the wiki. here a few comments but I don't know where to put them. Your initial proposition is great but in order to improve it, I am critizing it a little to contribute. For me the actual proposed version "looks like" the model explorer. We need more to take a look into web "dashboard" rather than "welcome page" I know it is different concepts. At least, we could have the Model name and description at the top? For instance, a user should be able to add its owns widgets/plugins. We could have a widget that shwo the latest modifcationmade on the model, author, git commit / cdo server link ? You have already propose a "widget" to validate the model. We couold also imagine to propose "widgets" to analyse your model The dashboard could have a welcome page but also a preference page where we could migrate the General (top right corner in your sketch) We could propose also a widget in charge to filter/search quickly a diagram, an object? We could propose also a widget in charge to filter/search quickly the list of objects linked to a first one? It will be a pleasure if you could associaate me on specific task/widget/framework/review in order I learn the different Eclipse framework with your expertise. Francois
I guess their is a risk that the (single) welcome page may become rather crowded if we want to start adding more information to it. If I compare with another modeling tool (which Papyrus have the possibility of importing models from), it has a corresponding model editor with multiple tabs showing similar kind of information and actions as proposed here. I think it really should be considered to be able to have multiple tabs on the welcome page, either tabs to the left (as in the properties view) or tabs on the top (since tabs at the bottom probably can be confused with the tabs of the diagram pages itself). In that other modeling tool there are the following tabs and content on each tab: * Overview Here you can find information about errors/warnings on the model (with possiblity of navigating to the problems view), general information about the model (name, physical location in file system, size, last modified, editable) and also the documentation on the root element of the model * Details List of applied profiles and buttons to add, remove, migrate and repair profiles, list of model libraries being imported and buttons to add and remove libraries. Finally there are some buttons for general model operations, e.g. to upgrade models, e.g. upgrading to never versions of UML or other updates of the model file format. * Diagrams List of diagrams in the model and possibility to navigate to them. * References One list of referenced models, profiles, libraries that the current model references, i.e. outgoing references. One list of models that have references to the current model, i.e. incoming references. * Fragments The list of fragments, i.e. corresponding to sub-models, that this model is "decomposed" into. I have a feeling that if we want to add similar kind of information to the Welcome page in the Papyrus model editor, it must be able to scale it using multiple tabs.
(In reply to Francois Le Fevre from comment #4) Thanks, Francois. > Chris, > > For me the actual proposed version "looks like" the model explorer. > We need more to take a look into web "dashboard" rather than "welcome page" > I know it is different concepts. So far, I'm aiming for something more like a cross between the Eclipse Welcome experience and the standard forms UI Properties view (not so much our XWT-based implementation). Not looking for any tree-like explorer capability. My intent is for a dashboard, but perhaps the wiki doesn't communicate that well. What do you mean precisely by "web"? Do you mean a web/HTML look-and-feel, or just the concept of dashboard known from popular web services like GitHub, Facebook, etc.? > At least, we could have the Model name and description at the top? Indeed, I didn't think of that. :-) > For instance, a user should be able to add its owns widgets/plugins. User customization is an interesting consideration, which it would be nice to see for Neon+1 perhaps once we have a solid foundation on which to build it. Perhaps leveraging something like EASE for lightweight user widgets? I'll try to capture this in the wiki for further comment. > We could have a widget that shwo the latest modifcationmade on the model, > author, git commit / cdo server link ? That's an interesting idea. I'll start collecting a list of widgets on the wiki page. > You have already propose a "widget" to validate the model. > We couold also imagine to propose "widgets" to analyse your model Yes, but we need integration of an analysis framework, first. ;-) > The dashboard could have a welcome page but also a preference page where we > could migrate the General (top right corner in your sketch) Yes, I do need a preference page at least to let users turn off widgets that they don't care about. I'm also thinking about some kind of drag-and-drop to rearrange sections, but that is a lower priority ... > We could propose also a widget in charge to filter/search quickly a diagram, > an object? I'll add that to the list. > We could propose also a widget in charge to filter/search quickly the list > of objects linked to a first one? I'm not sure that I understand this proposal. I don't want anything in this dashboard to be sensitive to or act on the current selection. It's meant to be a 10000-foot overview of the model. > It will be a pleasure if you could associaate me on specific > task/widget/framework/review in order I learn the different Eclipse > framework with your expertise. Just follow this bug and its dependencies.
(In reply to Peter Cigehn from comment #5) Thanks, Peter. > I guess their is a risk that the (single) welcome page may become rather > crowded if we want to start adding more information to it. If I compare with > another modeling tool (which Papyrus have the possibility of importing > models from), it has a corresponding model editor with multiple tabs showing > similar kind of information and actions as proposed here. Indeed, there is a risk of overwhelming the user with content in this page. For the Neon release, at least, I want to try hard to keep it small: only a few "widgets" (I like Francois's terminology) at first to let us get comfortable with the overall approach and see where to take it. The primary motivation, for me at least, is to eliminate the problem of the blank editor appearing to be dysfunctional by putting something useful in its place to get the user started. > I think it really should be considered to be able to have multiple tabs on > the welcome page, either tabs to the left (as in the properties view) or > tabs on the top (since tabs at the bottom probably can be confused with the > tabs of the diagram pages itself). I understand your concern about managing scale, but I must disagree with the proposed solution. We already have tabs at the top of the editor are for the different editors and tabs at the bottom of the many multi-page editors in Eclipse (Papyrus, PDE editors, XML, POM, and more). Adding another dimension of tabs is, I think, too much. I want to try first to manage the scale by, in the first place, only actually contributing a few widgets to the welcome page and then, secondly, by letting the user turn off uninteresting widgets in the preferences. > In that other modeling tool there are the following tabs and content on each > tab: Much of what you listed from this other tool is already presented in other places, such as the Properties view. I don't want to duplicate that information in the dashboard, only provide quick access to some obvious things to get the user into her model. I'm not even convinced that I (speaking for myself) want a validation widget; it's just there to illustrate my wireframe sketch and to suggest the kinds of widgets we might accommodate. > I have a feeling that if we want to add similar kind of information to the > Welcome page in the Papyrus model editor, it must be able to scale it using > multiple tabs. Yeah, that's just it. I don't really want to make so much information available in this page. I really just want to fix the problem of an empty editor being unusable by giving users a place to start with a model that had never been opened before.
(In reply to Christian W. Damus from comment #7) > Much of what you listed from this other tool is already presented in other > places, such as the Properties view. I don't want to duplicate that > information in the dashboard, only provide quick access to some obvious > things to get the user into her model. I completely agree that lots of the stuff in the "other modeling tool" is available elsewhere, such as in the properties view and that the duplication shall be avoided. I just listed what is the different tabs in that tool just to give an indication how the tabs are being used there. Don't see it as a proposal on what shall be included. Sorry for not being more clear. But to mention a few things that I currently miss in Papyrus, and which cannot be found anywhere else (at least not to my knowledge), it is the contents on the "References" tab and the "Fragments" tab. Especially when you start scaling your models with lots of models and sub-models. I just saw an opportunity to get such information included on this new Welcome page. But maybe that kind of information needs to be shown elsewhere in Papyrus, whenever we get that kind of functionality, and maybe the Welcome page is not a suitable place for that. I just felt that the Welcome page was completely equivalent to the corresponding functionality in the other modeling tool.
(In reply to Peter Cigehn from comment #8) > But to mention a few things that I currently miss in Papyrus, and which > cannot be found anywhere else (at least not to my knowledge), it is the > contents on the "References" tab and the "Fragments" tab. Especially when > you start scaling your models with lots of models and sub-models. I just saw > an opportunity to get such information included on this new Welcome page. That's a good point. I'll add these to the wiki. I'm not sure what would be the best way to present this content, but this dashboard could be a natural place for it. > But maybe that kind of information needs to be shown elsewhere in Papyrus, > whenever we get that kind of functionality, and maybe the Welcome page is > not a suitable place for that. I just felt that the Welcome page was > completely equivalent to the corresponding functionality in the other > modeling tool. Indeed, a View could be dedicated to references and sub-unit structure. Such view might be stacked with the Model Explorer in the perspective layout. If I'm not mistaken (I could be!), in this other tool, the model editor only has these tabs that you outlined. It doesn't have a set of dynamic tabs for diagram and table editors, is that correct? These are presented in their own discrete editors?
> These are presented in their own discrete editors? Yes, and the Project and Model Explorer are merged, so you don't really get a dead-end similar to Papyrus when you open an editor and the Model Explorer is closed. Eclipse is the top-level editor, and EditorParts are the individual tabs. The Project/ModelExplorer is the overview
(In reply to Christian W. Damus from comment #9) > If I'm not mistaken (I could be!), in this other tool, the model editor only > has these tabs that you outlined. It doesn't have a set of dynamic tabs for > diagram and table editors, is that correct? These are presented in their > own discrete editors? Yes, in that other tool, the model editor *only* have these tabs at the bottom of the model editor in the corresponding as Papyrus model editor have tabs for the different diagrams. In that other tool, each diagram is opened in its own diagram editor. So the different diagrams are found as tabs "on the top" since they are separate diagram editors. This is of course a huge conceptual difference, and hence my proposal of having the tabs to the left or at the top, since the tabs at the bottom is occupied by the tabs of the different diagrams in Papyrus. But sure, the scaling aspect can of course be solved in other ways than having separate tabs.
commit e9ee042e708bfdfdd412802cef9e37457a93a684 on the branch reworks the prototype of a list of diagrams as: * a contribution of a property "tab" (realized as a form-section) via the Properties View Customization framework * a reusable NatTable of hyperlinks with sorting on any column The same table infrastructure is used to likewise add the list of tables. See new plug-ins: oep.infra.editor.welcome.nattable: hyperlink-table infrastructure for Welcome Page oep.infra.gmfdiag.welcome: the list of diagrams based on the above table widget oep.infra.nattable.welcome: the list of tables based on the above table widget
Commit 10dac542edf448047ebd19cdd233e7c31d288120 on the branch adds a new General section to the welcome page with two options: * store page layout in the private workspace metadata area * track the active/visible page in each tab folder in the sash model https://youtu.be/CLwuUA8c0xA
I tried the latest build on the branch, and I bumped into an issue, which possibly is not related to the welcome page as such. Just wanted to provide feedback. When I tried this with arranging the model editor into multiple tab groups (panels), as shown in your latest Youtube-clip, and then re-arranging it back to only one group (panel), then the context menu (including the new Welcome menu choice) when right-clicking on the tabs did now show up any longer. I had to close the model editor and re-open it again, to get the menu to show up again.
(In reply to Peter Cigehn from comment #14) > I tried the latest build on the branch, and I bumped into an issue, which > possibly is not related to the welcome page as such. Just wanted to provide > feedback. Indeed, this problem is not introduced by the Welcome Page feature, as you had suspected it wouldn't be: bug 483309
Commit 3bb6eff7aa7cec159f160141ac51a420ddaba7a5 adds to the Welcome Page the remaining content initially proposed for the Neon release: * table of languages instantiated in the model (General section) * list of hyperlinks to key related views (new Related Views section): properties, model explorer, model validation This also implements a stable layout algorithm that presents sections in two rows and as many columns as needed, in priority order down each column from left to right. Ordering is determined by 'afterTab' relationships between tabs and, where that is indeterminate, the 'priority' attribute. This also integrates the work done on master for bug 434983 to ensure that the toggle item in the menu and the widget in the welcome page that both control the private/shared storage mode for sash layout keep each other up-to-date.
The branch is updated once more (the last update before integration into master for Neon M4). The branch was rebased; a force pull is required to fetch it. This latest change adds drag-and-drop reorganization of the various sections presented in the Welcome Page, which is especially useful when there are more than a few sections (depending on how many plug-ins contribute content and what the user has enabled in the preference page). Demonstrated in brief: https://youtu.be/PNsmTRguOME
New Gerrit change created: https://git.eclipse.org/r/62003
Gerrit change https://git.eclipse.org/r/62003 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=49bd194639354cde35b15717e4ead156f4613754
The initial contribution is now available on master (For Neon/Nightly and then M4 at the end of next week) Several comments on the current implementation: - On windows x64, there are a lot of "No more handles" errors. They are usually related to an important level of nested widgets (composites) that Windows cannot properly handle (Pretty much everytime I click on the Welcome page when it is not already active) - Various leads for usability improvement: - Group all the views under the same group, i.e. avoid the Diagram vs Table distinction. They are all "Pages" or "Views" (For example, the ModelExplorer doesn't make a distinction) - Add a "Filter by name" for Diagrams (Views :) ) & Contexts - Ability to resize the sections or use a different layout (We already discussed this, and this may be a little complex due to the current customization mechanism) - When closing All Diagrams (Including the Welcome page), the Welcome page is closed, then reopened. It shouldn't be closed at all to reduce flickering Anyway, that's a great step forward. Thanks! :)
(In reply to Camille Letavernier from comment #20) > The initial contribution is now available on master (For Neon/Nightly and > then M4 at the end of next week) > > Several comments on the current implementation: > > - On windows x64, there are a lot of "No more handles" errors. They are > usually related to an important level of nested widgets (composites) that > Windows cannot properly handle (Pretty much everytime I click on the Welcome > page when it is not already active) Yikes. Nothing like that on Mac, of course. Isn't this a show-stopper? if we can't fix this by M4, we'll have to disconnect the welcome-page service (which essentially suppress the whole feature). > - Various leads for usability improvement: > > - Group all the views under the same group, i.e. avoid the Diagram vs Table > distinction. They are all "Pages" or "Views" (For example, the ModelExplorer > doesn't make a distinction) Okay, I can do that. But then I'll need a new panel to fill the layout. > - Add a "Filter by name" for Diagrams (Views :) ) & Contexts I saw that coming from a mile away ... :-) > - Ability to resize the sections or use a different layout (We already > discussed this, and this may be a little complex due to the current > customization mechanism) Yeah, I though about using the sash container, but that uses tab folders, which makes it a non-starter. It shouldn't be a huge stretch (no pun intended) to work up a simpler scheme using only basic SWT sash panes. (I don't recall discussing this) > - When closing All Diagrams (Including the Welcome page), the Welcome page > is closed, then reopened. It shouldn't be closed at all to reduce flickering Yes, that's tricky though, because we don't know that this page cannot be closed until all of the others have been closed first, and the "close all" command only knows how to ask whether a page can be closed (there's no additional context such as the intent to close all pages). This needs some thought. > Anyway, that's a great step forward. Thanks! :) :-)
(In reply to Christian W. Damus from comment #21) > (In reply to Camille Letavernier from comment #20) > > - On windows x64, there are a lot of "No more handles" errors. They are > > usually related to an important level of nested widgets (composites) that > > Windows cannot properly handle (Pretty much everytime I click on the Welcome > > page when it is not already active) > > Yikes. Nothing like that on Mac, of course. > > Isn't this a show-stopper? if we can't fix this by M4, we'll have to > disconnect the welcome-page service (which essentially suppress the whole > feature). When I have tested this (rather limited though) on the branch build, I have not see any of these "No more handles" errors. I'm on Windows 7 Enterprise, with a 64-bit JVM. So I guess it is not a general problem at least.
> When I have tested this (rather limited though) on the branch build, I have not see any of these "No more handles" errors. I'm on Windows 7 Enterprise, with a 64-bit JVM. So I guess it is not a general problem at least. Yes, that's the issue with this kind of error: it can only be reproduced on specific platforms; usually the ones with a big "company-specific-layer", such as Ericsson or CEA (The same kind of layer that can also degrade the Eclipse performances to the point it becomes nearly unusable) It seems that clean (standard) Windows installations are less sensitive to this kind of issue
New Gerrit change created: https://git.eclipse.org/r/62255
Gerrit change https://git.eclipse.org/r/62255 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=ed1a7e9b9fd1b85b120546f16d75711c55244330
Updates per the comment 20: Commit 83030f5 adds a hook in the sash-model to prevent closure of the Welcome Page in the case of the "Close All Diagrams" [sic] command. Commit 1658f12 adds a filter field to the Diagrams and Tables lists that filters the items to show those that match the filter in either the diagram/table label, context label, or both. Commit 46ff949 combines the Tables and Diagrams lists into a single Notation Views list. Consequently, the oep.infra.nattable.welcome plug-in is deleted. Hopefully few developers installed it in the mean-time ...
Commit a29d8bc implements sash controls to let the user shape the various sections of the Welcome Page. This and the other enhancements listed in comment 26 are demonstrated in a new video: http://youtu.be/EGAkt2vPiZM
What about the use case when you scale up and have lots of models (and/or sub-models), and you want to control the layout of the welcome page for all of those models at once? I guess it will be rather painful to try to go through all models and align the welcome page for all of them, one by one. I assume the preferences to control which contexts are active are valid for all model editors. But what about also controlling the layout for all those model editors? Is that something that should be considered to be supported?
(In reply to Peter Cigehn from comment #28) It's as though you can read my mind. > I assume the preferences to control which contexts are active are valid for > all model editors. Correct. This is the same subsystem that is responsible for determining what is presented in the Properties view. > But what about also controlling the layout for all those > model editors? Is that something that should be considered to be supported? One of the reasons why the default Welcome object referenced by the page in the DI/Sash model is identified by a custom URI scheme is so that it can be located on-the-fly in the workspace metadata area. This is intended to support setting a custom layout of the Welcome page as the workspace-wide default. That is the next (and probably final) refinement of this welcome-page feature on my to-do list for M4.
(In reply to Christian W. Damus from comment #29) > One of the reasons why the default Welcome object referenced by the page in > the DI/Sash model is identified by a custom URI scheme is so that it can be > located on-the-fly in the workspace metadata area. This is intended to > support setting a custom layout of the Welcome page as the workspace-wide > default. That is the next (and probably final) refinement of this > welcome-page feature on my to-do list for M4. Nice to see that you already had considered this! Looking forward to the next refinement... :)
Commit b00d410 adds support for saving a Welcome Page's layout as the default for other welcome pages. The Papyrus-logo drop-down menu in the toolbar and context menu on the editor tabs now have a "Make Default Welcome Page" action that saves the (probably customized) layout model in the workspace metadata area. All other Welcome Pages that reference the default Welcome model will get this layout; any Welcome Pages currently open in editors will recompute their layouts from this new default if they do not have their own customized layout. A new button is provided also in the Editor Welcome Page preferences that resets the default layout to factory defaults. This removes the welcome model from the workspace metadata area. As above, any open pages that reference the default will recompute their layout accordingly.
(In reply to Christian W. Damus from comment #31) > The Papyrus-logo drop-down menu in the toolbar and context menu on the > editor tabs now have a "Make Default Welcome Page" action that saves the > (probably customized) layout model in the workspace metadata area. This looks nice! I just want to double-check so that I have understood it correctly. If we now want to scale it up further, and ensure that a complete team have the same default layout of the welcome page, then we can simply copy the .metadata\.plugins\org.eclipse.papyrus.infra.editor.welcome\welcome.xmi file into each new workspace that any of the team members use, e.g. using Oomph and a ResourceCreationTask in the .setup-file? Or do you propose some other, better, way of ensuring that a complete team all can have the same welcome page layout?
(In reply to Peter Cigehn from comment #32) > > If we now want to scale it up further, and ensure that a complete team have > the same default layout of the welcome page, then we can simply copy the > .metadata\.plugins\org.eclipse.papyrus.infra.editor.welcome\welcome.xmi file > into each new workspace that any of the team members use, e.g. using Oomph > and a ResourceCreationTask in the .setup-file? Or do you propose some other, Exactly. This is a good use case for the ResourceCreationTask. This is absolutely the best way to accomplish what you're looking for. I suppose we could consider a preference to store this file in some other location, so that it might be shared in Git, for example. If you think that would be valuable, please raise an enhancement request. (I'm not sure that I would recommend it because the default-default welcome model is actually an absent file, which could be confusing)
(In reply to Christian W. Damus from comment #33) > (In reply to Peter Cigehn from comment #32) > > > > If we now want to scale it up further, and ensure that a complete team have > > the same default layout of the welcome page, then we can simply copy the > > .metadata\.plugins\org.eclipse.papyrus.infra.editor.welcome\welcome.xmi file > > into each new workspace that any of the team members use, e.g. using Oomph > > and a ResourceCreationTask in the .setup-file? Or do you propose some other, > > Exactly. This is a good use case for the ResourceCreationTask. This is > absolutely the best way to accomplish what you're looking for. Good to get that confirmed! > > I suppose we could consider a preference to store this file in some other > location, so that it might be shared in Git, for example. If you think that > would be valuable, please raise an enhancement request. (I'm not sure that > I would recommend it because the default-default welcome model is actually > an absent file, which could be confusing) I guess it should sufficient with what is already there. For the tool-smith that configures an installation of Papyrus, e.g. using Ooomph or similar proprietary "wrapper tools" for managing the setup of user workspaces and preferences that should be common to a larger team, it should be sufficient to make the customization of the welcome page once in a "customizaton workspace", and then simply keep a copy of the welcome.xmi file created in the .meta-data for this workspace. We have used that approach for other customization scenarios, and I guess that kind of work flow is sufficient.
