[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] New editors view
|
Within our limited context of the SDK, including JDT, the hit is not too
bad. However, for larger products like WSAD which have many heavyweight
editor in different plugins, the hit can be much worse.
We always need to keep in mind the larger context in which Eclipse is used.
Nick
|---------+--------------------------------->
| | Jared Burns |
| | <jared-eclipse@xxxxx.c|
| | om> |
| | Sent by: |
| | platform-ui-dev-admin@|
| | eclipse.org |
| | |
| | |
| | 12/06/02 04:34 PM |
| | Please respond to |
| | platform-ui-dev |
| | |
|---------+--------------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: platform-ui-dev@xxxxxxxxxxx |
| cc: |
| Subject: Re: [platform-ui-dev] New editors view |
| |
>------------------------------------------------------------------------------------------------------------------------------|
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
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev
