Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Working set changes

If you look at how the breakpoints view has used working sets, the on/off visibility of a working set is not going to be flexible enough. Normal workbench views should allow the user to select among sets with the "resource" context. The breakpoints view should present all working sets with the "breakpoint" context. The "choose working set dialog" or working set menu contributions should be sensitive to the client's context.


Kimberly Horne <kim@xxxxxxxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

10/25/2005 09:40 AM

Please respond to
"Eclipse Platform UI component developers list."

"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
[platform-ui-dev] Working set changes

I've added new features relating to working sets.  As discussed  
previously, we needed a bridge working set that represents the  
contents of all working sets active on a workbench window for those  
clients that aren't able to handle multiple working sets.  I've  
created API for the creation of aggregate working sets.  Aggregates  
are backed by a collection of other working sets and react  
accordingly to changes in their component sets.  Each workbench page  
has such a set available via IWorkbenchPage.getAggregateWorkingSet().

This feature required some new API on IWorkingSet and  
IWorkingSetManager.  For IWorkingSet I added get/setLabel.  The label  
of a working set is a more descriptive user-friendly name for the  
working set.  Unfortunately, up until this point the name of a  
working set was also its unique identifier.  This is problematic when  
we need multiple instances of the "window working set", one for each  
window, and yet have no way to reasonably distinguish between the two  
in a way that leaves the name readable to the user.  By default the  
label attribute is the same as the name attribute unless a label is  
explicitly provided.  Also added was IWorkingSet.isVisible().  The  
idea behind this method is that some working sets should be managed  
by an IWorkingSetManager but not visible to the user in various  
selection dialogs or lists.  I'm not entirely comfortable with  
isVisible() - I think there might be a better way to express this  
requirement (perhaps isSystem() or isUtility()).  IWorkingSetManager  
sees the addition of createAggregateWorkingSet() for creation of  
arbitrary aggregates.

To make use of these new APIs the WorkingSetFilterActionGroup and the  
IWorkingSetSelectionDialog implementation have been enhanced.  The  
dialog now provides the ability to select the window working set, no  
working set, or an arbitrary collection of working sets that will be  
assembled into an aggregate.

The UI surrounding this API is still very much up in the air and the  
API is still marked as experimental.  If you have any comments or  
concerns, please let me know.

platform-ui-dev mailing list

Back to the top