[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-ui-dev] Working sets on a workbench window
|
Seems to me there's significant overlap here with Mylar. If
the Platform adds this kind of functionality then, if you're not already
planning this, it should be done in such a way that Mylar could take
advantage of it instead of being an alternative to it.
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
