Community
Participate
Working Groups
This is the task list to discuss about the Papyrus Properties editor. link to the document: https://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/plugins/developer/org.eclipse.papyrus.doc/propertyView/RequirementsSpecificationOfPapyrusPropertiesEditor_v1.0.doc
*** Bug 299257 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > This is the task list to discuss about the Papyrus Properties editor. > link to the document: > https://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/plugins/developer/org.eclipse.papyrus.doc/propertyView/RequirementsSpecificationOfPapyrusPropertiesEditor_v1.0.doc fixed link: http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/plugins/developer/org.eclipse.papyrus.doc/propertyView/RequirementsSpecificationOfPapyrusPropertiesEditor_v1.0.doc
Here some comments about your Property View specification document: - You talk about code generation (Req_004): The generated code will use extension points or will only use full java implementation ? - Developer might be able to implement custom component and behavior for a property. We should provide him a way to add custom component and/or override an existing component. - Does the generated code be relative to a diagram plugin or is it a single plugin for all the managed property views ? - Do you plan to apply the specifications to the appearance part ?
(In reply to comment #3) > Here some comments about your Property View specification document: > > - You talk about code generation (Req_004): The generated code will use > extension points or will only use full java implementation ? The kind of implementation has not chosen yet: either full java code generation or a mix java runtime and extension points and/or xml configuration files. From my point of view, the extension points have a major disadvantage: they are defined once by one plugin, so the runtime using them has to implement the customization abilities. I believe that a xml configuration file (that can be provided by a plugin like it is done for the palette configuration) is much more flexible. I would prefer a configuration file, which is easier to configure using preferences rather than full java, as the customization is easier (according to my experience only!). > - Developer might be able to implement custom component and behavior for a > property. We should provide him a way to add custom component and/or override > an existing component. Ok > - Does the generated code be relative to a diagram plugin or is it a single > plugin for all the managed property views ? As I see it, it is very hard to restrict the property view to the concept of diagram plugin. For example, property view is accessible when elements are selected in the model explorer. Thus, a full configuration should be provided by a plugin (or splitted in several plugins, but I do not see on which criteria the properties could be splitted (uml levels?). Each diagram plugin could then redefine the property views for elements described in the diagram. Do you have any preferences on that point, or advices ? > > - Do you plan to apply the specifications to the appearance part ? I would prefer to put the focus on the semantic properties, but why not appearances also.
(In reply to comment #0) > This is the task list to discuss about the Papyrus Properties editor. > link to the document: > https://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/plugins/developer/org.eclipse.papyrus.doc/propertyView/RequirementsSpecificationOfPapyrusPropertiesEditor_v1.0.doc An additional requirement: common properties should be visible and editable on a multiple selection of element of the same kind.
The property editors should also be usable/reusable in other plugins. They should not be restricted to the Property View. (A Property editor == an editor for one single property.) For example, any property editor should be reusable in the preferences view. This allows to edit the preferences in the same way as the property itself. This improve consistency. Another application can provide a wizard called from a menu and allowing to edit a particular property.
The property view framework is already present in the papyrus tool. It should be improved in the release 0.8.0
Created attachment 174924 [details] Truncated labels
(In reply to comment #7) > The property view framework is already present in the papyrus tool. It should be > improved in the release 0.8.0 As can be seen in https://bugs.eclipse.org/bugs/attachment.cgi?id=174924, sometimes only the tooltip allows one to guess what the label is supposed to be. It does not seem to be a matter of room (there?s plenty of room on the screen to show the full label).
I close this task
