Re: [platform-ui-dev] New editors view

[Jared Burns <jared-eclipse@xxxxxxxxx>]

Ok, thanks. I'm not sure I agree that the cost of writing your own view from 
scratch is less than the cost of delegating the work to me, but it's your 
call. :-)

By the way, I'm aware of the "forced editor activation" issue and my plan for 
dealing with it is to make the resource-based features optional, making it 
clear in the preferences that the option has startup costs.

If the cost of instantiating the editors at startup is the cost of loading the 
plug-ins (this goes back to my question earlier this week), then the 
additional cost will actually be small in many cases. For example, the only 
editors I ever use are the Text editor and the Java editor. Since I work in 
the Java Perspective, the JDT UI is going to get loaded at startup anyway.

The resource-based features (CVS decorators, Team menus, etc.) are so useful 
to me that I'd be willing to take a hit at startup even if it was fairly 
expensive (a couple extra seconds).

- Jared

On Friday 06 December 2002 02:37 pm, Nick_Edgar@xxxxxxxxxx wrote:
> (you may see this message twice due to the mailing list thinking I'm a 
> different person because of my change to the ca.ibm.com domain)
> 
> Jared,
> 
> The reason we rolled our own view was not due to any deficiencies in your 
> implementation.  We started off implementing the drop-down, and then found 
> that it was a small amount of extra work to reuse this code in a view.  I 
> do apologize for not having done a better job of keeping you informed 
> about this process though.
> 
> There are some technical issues with supporting some of the features your 
> view has, which ours doesn't.  For example, in order to support working 
> sets and the object contribution actions in the view's context menu, the 
> item's underlying resource must be known.  With lazy editor activation, 
> the corresponding editor, or even its editor input, may not be known.  So 
> either you need to force activation in order to get these features, or you 
> allow the UI to be inconsistent (sometimes you get the features, sometimes 
> you don't).  Neither of these options is desirable, so we left these 
> features out and are considering alternatives.
> 
> As for what you can do to get contributions accepted, I don't think you 
> did anything wrong in this regard.  You developed an interesting new 
> feature, and discussed with us the possibility of getting it released over 
> the last several months.  Before 2.0, we were unsure whether this was the 
> right approach, and had too many other priorities to consider this.  For 
> the current work, we started off looking at the idea of a drop-down, but 
> then realized we could also make it a view with a small amount of extra 
> work.  So the main reason we rolled our own rather than including your 
> code is that it was actually less work to add the view support to the 
> drop-down code, than to examine your code and take out the features that 
> we were not comfortable with including.  But again, I should have let you 
> know we were going this route.
> 
> Finally, the recently released changes to editor management, including the 
> view, are not necessarily the final answer for 2.1.  We are discussing 
> other options, and may in fact end up rolling back all the changes in 
> favour of a more concerted effort to improve editor management post 2.1. 
> I'd feel more comfortable rolling back our own changes than somebody 
> else's contribution.
> 
> Nick