Community
Participate
Working Groups
The unapply stereotypes is very counter-intuitive. First time, I just couldn't get anything to work, so I used a text editor. Next time I decided to file a bug, and only then suddenly understood it. The problem is you have to select "Add" inorder to unapply. Simple suggestion: improve label headings from "Feature" which suggests it is the current state to "Stereotype to Apply" or "Stereotype to Unapply". rename buttons from "Add"/"Remove" to "Select"/Deselect". More elaborate suggestion, justifying the presence of up/down: Merge Apply/Unapply so that the two columns are: "Available Stereotypes" and "Applied Sterotypes" then it wouldn't be confusing.
I have pushed a new UI for apply/unapply stereotypes and profiles in a new branch bugs/326915 (commit 29f0b568d2a4a9c9c7600c3dfd2f6d6347991183). This creates a new ChooserDialog, initially based on EMF's FeatureEditorDialog, that provides more flexibility in the availability and labelling of UI elements. In particular: * only the Apply stereotype/profile dialog has up/down buttons because there may conceivably be a reason to specify the order of new stereotype/profile application objects, but there is no meaning in ordering the deletion of these objects in the Unapply dialog * the Add/Remove buttons are labelled more clearly as "Apply/Unapply" * the "Feature" list (right-hand side of the dialog) is labelled more clearly as "Stereotypes/Profiles to Apply/Unapply" according to the kind of element and the operation This new dialog is also the basis for a pending fix for 268444, in which we want to let users create stereotype applications in some resource other than the one containing the base element.
Thanks, Christian! Here's my feedback: - I would prefer a name like "...Choice..." over "...Chooser..." - there seems to be a lingering reference to "_UI_FeatureEditorDialog_title" in ChooserDialog - references to "dialog.getReturnCode() == FeatureEditorDialog.OK" should probably be replaced with "dialog.getReturnCode() == ChooserDialog.OK" (or, even better, ChoiceDialog :) ) Otherwise, looks fantastic!
(In reply to Kenn Hussey from comment #2) > Thanks, Christian! Here's my feedback: > > - I would prefer a name like "...Choice..." over "...Chooser..." How about "TwoPaneChoiceDialog"? > - there seems to be a lingering reference to "_UI_FeatureEditorDialog_title" > in ChooserDialog Oops, I should create a new title string, even if it looks the same as that one ;-) > - references to "dialog.getReturnCode() == FeatureEditorDialog.OK" should > probably be replaced with "dialog.getReturnCode() == ChooserDialog.OK" (or, > even better, ChoiceDialog :) ) Ugh, yes, indeed. Actually, these references should be Window.OK: it's a static field! > Otherwise, looks fantastic! Thanks. :-)
(In reply to comment #3) > How about "TwoPaneChoiceDialog"? Maybe. But given there's already a(n unqualified) dialog named "OptionsDialog", "ChoicesDialog" seems more consistent (and equally ambiguous). ;)
I have pushed a new commit a6d98eb to branch bugs/326915 to address the code review comments. I have also added some (very minimal) javadoc to the new API classes, at least to indicate the release in which they were introduced.
Changes merged and pushed to the 'master' branch in git.
The changes are available in an integration build for 4.2.0.
