Re: [platform-ui-dev] Working sets on a workbench window

[Randy Hudson <hudsonr@xxxxxxxxxx>]

I think you are confusing working sets
with (type) filters.  Working sets are most often used to filter your
*own* set of resources. For example, if I just want to work with the core
GEF projects and maybe a few examples, I'll choose my "core"
working set. If I want to see my www project, ISV.doc plug-ins, features,
etc., I'll pick that set. Type filters are most often used to filter other
people's classes.

So, you are suggesting that the user
be able to easily change the granularity of debugging by having quick access
to multiple type filter sets. This could also filter the "Open Type"
dialog and content assist, but I wouldn't go as far as blocking editors
from opening. This sounds cool but I think it's completely separate from
working sets.

-Randy

Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

09/10/2005 11:22 PM

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

To	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-ui-dev] Working sets on a workbench window

Its great to see working sets getting more teeth.  Are there any plans
to go further and actually scope what user can open/manipulate in a window?
 for example, if I use Open Type and open something that comes from
outside the current working set, what happens?  Some possibilities

- open it anyway.  Greatly diminishes the usefulness of workingsets
since I can never trust that what is in window really belongs

- notify the user that they are going "out of scope" and allow
them to do it anyway.  Offer a "dont tell me again" option.
 If the user is only offered OK/Cancel, they are bummed because they
have to go find/create an evironment where they can open the file.  Perhaps
an "Open in new window" or "Open in other window" option
could be given? 

Note that the open editor case is likely the bulk of htem but it is conceivable
that managing elements in a view may have the same issues.  Not sure
what to do there.  Perhaps the views just need to be aware and use
similar strategies.  Perhaps the code used for limiting editor opening
will be sufficiently general to be used in more cases?


On a separate note, not being a UI guy I am a little confused by terminology.
 What is the scope of this new setting?  I have seen global,
window, and page discussed.  I'm not sure of the relationship between
page and perspective.  I work in a world of one perspecitve per window
so the distinction is immaterial for me.  Others however will be bummed
if they have a debug perspective and a Java perspective in the same window
and the Debugger refuses to show information about or open editors for
things that are not in the current working set.  Clearly you need
to debug outside just about any working set. 

Jeff

Michael Van Meekeren/Ottawa/IBM@IBMCA
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

09/09/2005 11:21 AM

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

To	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc	John Arthorne/Ottawa/IBM@IBMCA
Subject	Re: [platform-ui-dev] Working sets on a workbench window

If Kim does not mind, let me explain... 

This mostly addresses bugs: 

45212  [WorkingSets] Link the working sets for Projects, Package...
108149         [WorkingSets] Global workingsets

and possibly 
15590  [Working Sets] Propagate working set in "Open in new wind...

Basically the user needs to go to many different places to configure working
sets (Package Explorer, Problems View, Heirarchy View, Project Menu etc...).
 What we are proposing is that there be one place per page (essentially
per Window) to choose which working sets one would like to filter on for
that page, and have all views use the selected working sets as the current
working sets if possible.  This also removes a significant amount
of localized clutter regarding menus and tool items for configuring working
sets on each view. 

/michael

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

09/09/2005 10:39 AM

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

To	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc
Subject	Re: [platform-ui-dev] Working sets on a workbench window

Yes.  For instance, the package explorer currently has a menu item
to  
select the visible working sets (when you're in the working set  
mode).  With this new API, you could simply show all working sets
 
that are of the java type and listen for changes so that you can  
update your tree appropriately.

On 9-Sep-05, at 10:27 AM, Dirk Baeumer wrote:

> Kimberly
>
> can you explain the purpose of the new API to me. Is the idea that
 
> view
> parts listen to these
> changes and update there current working set accordingly.
>
> Dirk
>
>
>
>
>              Nick Edgar
>              <Nick_Edgar@xxxxx
>               
> m.com>                
                     
              To
>              Sent by:    
             "Eclipse Platform
UI component
>              platform-ui-dev-b
        developers list."
>              ounces@xxxxxxxxxx
        <platform-ui-dev@xxxxxxxxxxx>
>               
> g                    
                     
               cc
>
>                    
                     
                     
    
> Subject
>              09/09/2005 04:03  
       Re: [platform-ui-dev]  
> Working sets
>              PM      
                 on a workbench
window
>
>
>              Please respond to
>              "Eclipse Platform
>                UI component
>              developers list."
>              <platform-ui-dev@
>                eclipse.org>
>
>
>
>
>
>
> Is there any kind of notification (e.g. property change event) when
 
> it's
> changed?
> How would a view tracking this know to update?
>
> Nick
>
>
>
>
> Kimberly Horne <kim@xxxxxxxxxxxxx>
> Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
> 09/09/2005 08:20 AM
> Please respond to
> "Eclipse Platform UI component developers list."
>
>
> To
> "Eclipse Platform UI component developers list."
> <platform-ui-dev@xxxxxxxxxxx>
> cc
>
> Subject
> [platform-ui-dev] Working sets on a workbench window
>
>
>
>
>
>
> Next weeks integration build will introduce the following new API
on
> IWorkbenchPage:
>
> IWorkingSet[] getWorkingSets();
> void setWorkingSets(IWorkingSet[])
>
> The intention of these methods is to allow you to specify what
> working sets should be visible across all components within a given
> workbench window.  Currently this API is not being used by any
> downstream component but we're making it public (and visible) now
to
> gauge interest.
>
> By visible I am referring to a new action that's been added to the
> Resource Navigation action set.
>
> You will see in your toolbar and in your Window menu a pulldown
> action called Working Sets.  The children of this action represent
> all working sets registered with the system IWorkingSetManager and
> are either checked or unchecked.  If they're checked, they're
> contained in the array returned by IWorkbenchPage.getWorkingSets().
>
> The notable problems with the implementation as it currently sits
are
> as follows:
>      The "Edit..." action currently opens
the "Select Working Set"
> dialog despite there being no selection required.  We will replace
> this with a more particular editing dialog at some later point.
>      The dropdown won't scale when the user has a large
number of
> working sets.
>      The action needs a toolbar icon.
>      The action probably doesn't belong in the Resource
Navigation
> action set.
> Please don't log these bugs.  We've already done so :)
>
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>
>
> _______________________________________________
> platform-ui-dev mailing list
> platform-ui-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
>

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev