Re: [platform-ui-dev] Initial General Purpose Navigator proposal

["Michael Valenta" <Michael_Valenta@xxxxxxxxxx>]

Knut

About reuable actions:

We haven't implemented the support for
these in the sync view yet. I has a quick look and didn't find the reusable
bits. We'll do a more thourough investigation when we add the actions to
the sync view and let you know if there are areas were reuse is not possible.

About hiding folders:

You are precisely right. You do not
want to remove folders as the user expands them. So the 2 options are to
leave them in or determie ahead of time which folders you need. We choose
the later for the sync view since the tree could be sparsly populated.
We did this by caching the visible resources (and their parent folders)
and adjusting the set based on resource delta and model specific deltas
(in our case, remote changes).

Michael

Knut Radloff/Raleigh/IBM@IBMUS Sent by: platform-ui-dev-admin@xxxxxxxxxxx 17/06/2003 03:12 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-ui-dev] Initial General Purpose Navigator proposal

Michael,
Thanks for kicking off a discussion. Here are my thoughts.

Viewers:
The plan is to allow only a TreeViewer for the presentation. I think one
of the major aspects of the Navigator will be the content providers, how
they can be contributed at various tree levels, customized and reused.
You 
could regard a table content provider simply as one that only supplies
root elements with no children. We can keep this in mind going forward
with the design but I'm not sure we should even allow alternate 
presentations. If we have a multitude of Navigator views with different
content then the only common denominator would be the tree presentation.
I'm not sure a Navigator would still be recognizable as such if this basic
presentation can change (even if we are saying it can only change to be
a 
table vs. a tree). Again, we can consider it but I don't think it should
be a priority.

I don't think any of the standard actions are tied to a tree viewer. Copy,
Paste, Move, Rename, Delete should all be useable outside the navigator
context. Rename is special because it supports inline rename if you are
supplying a tree widget. You don't have to supply one though. Am I wrong?

Filters:
The empty folders is an interesting problem, especially if you don't know
the content of a container node. When you expand a container all its 
children may be filtered out by one or more filter extensions. It would
probably be unexpected if the container then suddenly gets removed.

Action Contribution:
I was thinking we could just use the IActionFilter mechanism. However,
that only works for actions that operate on your own elements (e.g., 
IJavaElements). To control action visibility for existing elements (that
already adapt to IActionFilter) we could have IActionFilters that are 
specified explicitly in the extension (e.g., class = ). I believe that
would also address your subscriber scenario.

Knut




"Michael Valenta" <Michael_Valenta@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
06/17/2003 12:39 PM
Please respond to platform-ui-dev

 
        To:     platform-ui-dev@xxxxxxxxxxx
        cc: 
        Subject:        Re: [platform-ui-dev]
Initial General Purpose Navigator proposal




Knut, 

Here are some comments and questions: 

Provide a viewer that displays hierarchical data. 

Will the navigator be strictly a TreeViewer on the inside? The new Live
Sync Vew (available in today's integration build) can optionally show a
table containing the filtered changes. It would be great if the general
purpose navigator could support this as well. However, if that is not 
possible or practical, it would be very helpfull if the general actions
(cut, copy, paste, etc) were reusable (i.e. not tied to a TreeViewer) so
we would not have to reinvent everything (The way it stands now, we will
need to do this because many of the "reusable" resource navigator
actions 
are tied to a TreeViewer). 

Allow filters 

We've done some similar filtering in the new sync view. One interesting
challange is the pruning of empty directories from the view (i.e. those
directories that existed but whose files were filtered out). We had to
cache all visible files so we cold know which folders needed to be shown.

Action Contributions and Modes 

We had this requirement in the sync view as well. The logical elements
in 
the view are always the same type (IResource) but the selected subscriber
(CVS workspace, CVS merge or some other subscriber like FTP or WebDAV)
determines which resources appear and which actions are available. We had
to create our own object contributions to support this because, as far
as 
I know, the current objectContributions only filter by project nature and
persistant properties on the project. A more general objectContribution
filtering mechanism would be helpful. 

Michael Valenta 






Knut Radloff/Raleigh/IBM@IBMUS 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx 
10/06/2003 05:55 PM 
Please respond to platform-ui-dev 
        
        To:        platform-ui-dev@xxxxxxxxxxx
        cc:         
        Subject:        [platform-ui-dev]
Initial General Purpose 
Navigator proposal



An intial proposal of the work involved for this plan item has been 
released on the Eclipse UI team web site - this was one of our 3.0 M1 
objectives. Please see 
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/navigator-proposal/general_purpose_navigator_proposal.html

Please post feedback/comments to the platform-ui-dev mailing list or 
annotate the plan item bug report: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36961

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



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