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

Bug 32489

Summary:	[CoolBar] Maintain order when adjunct contributions are used
Product:	[Eclipse Project] Platform	Reporter:	Lynne Kues <lynne_kues>
Component:	UI	Assignee:	Platform-UI-Inbox <Platform-UI-Inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	n.a.edgar, simon_arsenault
Version:	2.1
Target Milestone:	---
Hardware:	PC
OS:	Windows 2000
Whiteboard:

Description Lynne Kues

2003-02-21 10:50:28 EST

When multiple action sets add adjunct contributions to the coolitem for another 
action set, order must be maintained between sessions.  Currently this is not 
happening since action sets are processed in a different order on restore.  
There are 3 solutions to the problem:

1. On restore, action sets get processed in the order in which they are 
initially added.  This is regardless of sort order - it is irrelevant from a 
maintaining the current order (i.e., the order in which the action sets are 
initially added is what matters, whether this is sorted order is not important 
to me, though it does define the order for the user).
2.  I save the toolbar layouts.  Again, this is regardless of any sort order.  
By saving the toolbar layouts I will be able to "recreate" the order in which 
items were added to a toolbar.
3.  I add new groups in sorted order after base groups.  I add new items in 
sorted order after base items.  I add new groups before a particular base group 
in sorted order.  Giving me action sets in sorted order will not make this 
problem any easier for me.  For example:

Initial load action sets in this order:

	B
	C - contributes to B
	E - contributes to B

add action sets via Customize Perspective:

	D - contributes to B
	F - contributes to B

Whenever an add-on contribution comes in I will have to search for the insert 
position regardless of action set order.  Similarly for the beforeGroup.

	B
	C - contributes to B before group b1
	E - contributes to B before group b1

add action sets via Customize Perspective:

	D - contributes to B before group b1
	F - contributes to B before group b1

I can do solution 3  with more code/searching/marking.  Or if action sets were 
processed in the same order on restore, solution 1 would work.

I don't want to do solution 2 if I don't have to.  There is already a bunch of 
coolbar layout information saved...

Comment 1 Lynne Kues

2003-02-21 10:55:44 EST

Plan to implement solution 3 for RC2.

Comment 2 Lynne Kues

2003-02-28 11:47:10 EST

Nick, there is still one case that will not be handled without remembering some 
information about the coolitem layout.  

Assume ActionSetA defined as follows:

A - /Normal/group1
B - /Normal/group2
C - /Normal/group3

Assume ActionSetB defined as follows:

1 - /ActionSetA/C/group4
2 - /ActionSetA/B/group5
3 - /ActionSetA/A/group6

On initial load, the resulting toolbar will be as follows:

| 3 | A | 2 | B | 1 | C

Now suppose you use Customize Perspective to turn off ActionSetA.  The toolbar 
will be as follows:

| 3 | 2 | 1

Further suppose you exit and restart.  At this point I lose information 
about "beforeness" since ActionSetA is not active.  The toolbar will appear as 
follows:

| 1 | 2 | 3 

I handle this case within a session by using group markers in the toolbar.  The 
case is not an issue on initial load because we say that the before group must 
exist and base contributions are processed before adjunct contributions.  The 
case is not handled on save/restore because the before group no longer "exists".

In the short term, I can save information about beforeGroups between sessions.  
In the long term, it seems like more intelligent processing non-visible action 
sets would be the better solution (e.g., ActionPresentation remembers non-
visible action sets, ContributionManagers contain action set items that are not 
active and therefore do not get displayed).  Or maybe there is some reason why 
this was not done in the first place?

Comment 3 Lynne Kues

2003-03-04 15:26:56 EST

Since there is no immediate need for beforeGroup specification for adjunct 
contributions, removed the capability.  The above issue is no longer a 
problem.  If beforeGroup capability added back, there also appears to be the 
desire for specifying before/after within a group.  This capability would 
require some special tag in the toolbarpath or elsewhere to indicate where in 
the group the item should go.

Changes for this bug report are released.  Only open issue was the one with 
beforeGroups described above.

Comment 4 Lynne Kues

2003-03-05 14:55:03 EST

This problem is not solved.  If multiple action sets contribute to different 
groups in the same action set, order is not guaranteed to be the same on 
restore if the base action set has been turned off via Customize Perspective.

Comment 5 Lynne Kues

2003-03-05 15:03:26 EST

Or if an action set contributes to a base group and contributes new groups and 
the base action set is turned off and you exit and restart.  Again, may lead to 
order not being maintained.

Comment 6 Lynne Kues

2003-03-06 12:06:24 EST

Changed algorithm to sort by action set id.

- Within a toolbar group, sort items by action set id.  When a new item is 
added, it will be added before all the items for its action set id (maintains 
the reverse order behavior).
- Within a coolitem, sort groups by action set id.  When a new group is added, 
it will be added after all the groups for its action set id.

Unfortunately, this algorithm is not completely correct when it comes to 
maintaining order when action sets are turned off.  The correct behavior would 
be to sort by group id within a CoolItem (regardless of action set id).

An example of the problem:

Action Set X 
	Action 1 - Search
Action Set B
	Action a - S/Search
Action Set C
	Action A - S/JGrp
	Action B - S/JGrp

Will lead to ==> | A B | a 1 

Turn off Action Set X, exit, re-enter.  

Will lead to ==>  | a | A B

Comment 7 Lynne Kues

2003-03-06 14:58:31 EST

Defer until 2.2.  No simple solution.

Comment 8 Simon Arsenault

2003-03-06 15:40:50 EST

I'm not seeing this issue with menu contribution. I've not been in that code 
for a while so I can't say exactly what is going on. I would need some time to 
put a test plugin together to try this scenario out with menus.

Comment 9 Lynne Kues

2003-03-07 15:24:34 EST

When a new group is added, the correct algorithm would be to sort by action set 
id and within the groups for an action set id sort by group id.  Note that when 
sorting groups by action set id you would need to sort based on the action set 
id that the item is contributing to - not the id of the action set that defines 
the item.

Coolbar is not sorting by group id and groups are sorted by the ids of the 
defining action set, not the action set being contributed to.  This leads to 
some order issues as does the not sorting by group id.  

Not sure exactly what menus are doing.  Order is not maintained though as you 
turn action sets on and off.

Comment 10 Lynne Kues

2003-08-06 09:52:47 EDT

Bottom line -
- action sets are processed in different order depending on whether or not the 
workspace is new or is being restored and action sets will be processed in a 
different order when action sets are turned on and off
- the location of an adjunct toolitem (i.e., a toolitem being added to another 
coolitem) is specified in terms of other coolitems, so how an adjunct toolitem 
will be added depends on what coolitems are available at the time

Since the processing order of actions sets is not deterministic, specifying 
adjunct toolitem location in terms of other coolitems will lead to scenarios 
where order is not maintained.

Comment 11 Michael Van Meekeren

2004-05-21 13:33:03 EDT

Marking for LATER, please comment if you think this is important for 3.0.

Comment 12 Denis Roy

2009-08-30 02:14:49 EDT

As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.