Re: [platform-ui-dev] Re: [Editor Mgmt]

[Jared Burns <jared-eclipse@xxxxxxxxx>]

See my comments below:

On Friday 25 October 2002 09:01 am, Nick Edgar wrote:
> I like what you've done with your view.  In particular, the working set
> support looks cool, although I haven't used it in serious development yet.
> Have you gotten much feedback about this feature?

No, I haven't received any feedback on the working set support. My impression 
is that the view is only used by a handful of people.

> However, I don't think that simply releasing your view in the platform is
> the right answer, for the following reasons:
<snip>
> 2. A view takes extra screen real-estate (have you gotten much feedback
> about this, whether it's a problem, and how people position it?)

A quick tour of the office shows the editor view positioned in the top or 
bottom corner on the left side of the screen - either above or below the 
outliner.

> 3. It's not easily accessible for keyboard-only users -- you have to use
> the Ctrl+F7 view switcher to get to it (actually, Enter doesn't seem to
> work to activate the selection currently).

Agreed, and it's unfortunate. I wonder if the current keyboard navigation 
support (Ctrl+F6) is considered acceptable by keyboard-only users.

> 4. We need to be careful about introducing extra dependencies on Core
> Resources in the Workbench proper.  It's fine to do so in the standard
> components (Navigator etc.) but not in the basic editor management support.

I know this contradicts your goal of not providing multiple ways of doing 
things, but I think I prefer to keep the editor view as a standard component. 
There are people who only want a small number of editors open at once. An 
editor view is probably overkill for these people, so they should be able to 
close it and just use the current support. I think the editor view would ship 
in the org.eclipse.ui.views plugin.

> What we're thinking of doing for M3 is:
> - make some improvements to basic editor tabs:
>   - get rid of the ... in favour of a couple of extra characters in the
> name, and just let it clip
>   - make the scrunchiness factor adjustable in the prefs
>   - consider getting rid of the icon in favour of more space for the name

It sounds like this would improve the situation a bit, but I think the real 
problems with the tabs is inherent - they just don't scale well.

> - provide a drop-down that takes the best from the editor switcher, the
> editors dialog, and your view, and get rid of the others
<snip>

The pull-down idea is interesing. I don't want to speculate about it, though. 
I'd like to try using it for real work and see how it goes. Are there any 
plans to prototype this idea? Famous last words: It sounds like it should be 
simple to implement, no?

> I do apologize if you were given the impression that we were going to
> simply release your view as-is.  All along I've been hoping to learn from
> your and others' experience with your view, and take ideas from it, if not
> the implementation.  It's just taken longer than any of us would like, for
> various reasons.

No sweat. I was given the impression that people were interested in exploring 
it as a candidate for inclusion. That appears to be what's going on.

I wrote the view becase I had an itch that needed scratching. The view solves 
my problems so I'm happy. If other people find it useful, great. If not, no 
problem - I still have the view to use for myself. :-)

> Hopefully you'll be able to continue working with us on improving basic
> editor management.  It would be great if you and possibly others in MIN
> could do early evaluations of the work we'll be doing for M3.

I'd be glad to.

- Jared

P.S. On the topic of the editor view, last night I wrote some code to wrapper 
IEditorReferences with IAdaptable objects that will give me an IResource to 
enable to Team menus in the view. I wrote the code while watching the World 
Series (boo Angels), so I plan to review it over the weekend before releasing 
it on Monday.