Community
Participate
Working Groups
This task regroups all tasks linked to the user experience with the palette. The current system for the palette is too constrained: impossible to move the elements from a category to another, hard to add new tools on-the-run, etc.
Indeed it is interesting for the end user to customize the palette he(she) wants to use but it is sometimes not intented that all end users can do it as palette customization depends on the process. For industry it is important that tool can be adapted to a given process and that end users can not escape from it as they want (see comment on 291782 task). It underlines the fact that cutomization can exist at two levels : tool configuration (plug-in) or user configuration (workspace). Two solutions can be envisaged: * provide an authorization model so that some commands can be restricted to advanced users * provide a configuration model so that some commands can be registered at tool level or user level.
(In reply to comment #1) > Indeed it is interesting for the end user to customize the palette he(she) > wants to use but it is sometimes not intented that all end users can do it as > palette customization depends on the process. > For industry it is important that tool can be adapted to a given process and > that end users can not escape from it as they want (see comment on 291782 > task). > > It underlines the fact that cutomization can exist at two levels : tool > configuration (plug-in) or user configuration (workspace). > > Two solutions can be envisaged: > * provide an authorization model so that some commands can be restricted to > advanced users > * provide a configuration model so that some commands can be registered at tool > level or user level. The work I did yet was the first step for such a mechanism. We now have to search how to implement this notion of process in the tool.
Created attachment 151119 [details] list of screenshots of the palette configuration setup in TOPCASED
Please find attached a list of screenshots (through .odt document) from a palette configuration mechanism available in TOPCASED tool. This can be contributed quite easily to Papyrus.
Created attachment 151123 [details] illustration of palette configuration available through preferences
Created attachment 151124 [details] screenshot of class diagram palette reduced to a few elements
Created attachment 151125 [details] stateMachine palette reduced to a few elements with same palette configuration
Created attachment 151126 [details] Definition of the palettes through a plug-in
Thanks for your added screenshots! For the palette description using a plugin, I kept the GMF mechanism, as it provides all necessary information. I just modified the way palettes provider woks. You can directly access the various palette configurations through the palette itself. The context menu in the palette shows all available palettes and let the user select the palette(s) he wants to display. The palette to hide or to display are kept in the preferences, so the configuration is shared among diagrams.
This old bug still valid?
I close this task. Some sub-tasks are still open, but they don't really block this one.
