Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 326915

Summary:	Unapply stereotype is very counter-intuitve
Product:	[Modeling] MDT.UML2	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	Christian Damus <give.a.damus>
Status:	VERIFIED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	Kenn.Hussey
Version:	3.0.0	Keywords:	plan
Target Milestone:	M3	Flags:	give.a.damus: luna+ Kenn.Hussey: review+
Hardware:	PC
OS:	Windows Vista
Whiteboard:	Community Support

Description Ed Willink

2010-10-04 09:04:09 EDT

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.

Comment 1 Christian Damus

2013-10-07 17:59:43 EDT

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.

Comment 2 Kenn Hussey

2013-10-08 22:26:30 EDT

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!

Comment 3 Christian Damus

2013-10-08 22:31:01 EDT

(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.  :-)

Comment 4 Kenn Hussey

2013-10-08 23:04:34 EDT

(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). ;)

Comment 5 Christian Damus

2013-10-09 00:47:33 EDT

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.

Comment 6 Kenn Hussey

2013-10-09 10:26:12 EDT

Changes merged and pushed to the 'master' branch in git.

Comment 7 Kenn Hussey

2013-10-14 11:44:08 EDT

The changes are available in an integration build for 4.2.0.