From:
platform-ui-dev-bounces@xxxxxxxxxxx
[mailto:platform-ui-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jeff McAffer
Sent: Monday, September 12, 2005 8:44 PM
To: Eclipse Platform UI component
developers list.
Subject: Re: [platform-ui-dev]
Working sets on a workbench window
I had never heard of type filters until they were
mentioned here. They look interesting but...
-
they are a negative statement. I know what I want, not what I don't want.
-
I am not able to list by project. That is, I want all the stuff from
these 4 projects
-
the function is hidden way under some preferences. Perhaps they are surfaced
somewhere else but I couldn't find it. The bug MVM mentions may address
this. It is vital that people know things are being filtered out. I
typically assume that if a type does not show up it does not exist.
In
any event the sort of effect that is interesting here (regardless of what
technologies are used to implement) is that when I set the context for a
window, the window shows only things that fit in that context. Otherwise,
I can set up a working set (whatever) and within minutes of opening types or
using F3 etc, the window is full of types that do not fit in the working set. So
what was the point? If you only ever navigate the world using views that
are filtered using working sets, you are a happy camper. The
proliferation of other access paths/techniques however means that that is
increasingly rare. For example, it is extremely rare that I use the
Package Explorer. Ctrl-Shift-T, Ctrl-T and F3 all rock.
I
am clearly not a UI guy. The symptom from which I suffer is loss of
context due to a progressive decrease in brain capacity. It would be
great if I could rely on the windows to maintain context for me. One
window for my stuff, one for other stuff, one for ...
Jeff
p.s.,
heres another implementation idea. What if there was a dynamic type
filter that allowed only types from the current working set to be shown and
selected?
p.p.s.
Note that the problem space is wider than just Java types. If I use
Ctrl-Shft-R to open resources, I would hope to get the same sort of filtering.
|
Michael Van
Meekeren/Ottawa/IBM@IBMCA
Sent
by: platform-ui-dev-bounces@xxxxxxxxxxx
09/12/2005 09:08 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
|
|
Just FYI, I've logged a bug:
92095 [open type dialog] Support access to
"Type Filters" preferences directly from the Open
talking about making type filters more accessible as well.
/michael
|
Randy Hudson
<hudsonr@xxxxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
09/11/2005 11:28 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
|
|
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
_______________________________________________
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
