Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Changes to the Editors preference page

It seems like I'm confused by the purpose of this change and that some of my comments
> were/are not accurate.

The purpose of changing the defaults for "close editors automatically" would be entirely for performance and memory reasons.

The purpose of changing the default from "reuse" to "open new" would be to improve the user experience.

The purpose of increasing the default number of open editors would be to make the change less noticeable for users who are accustomed to the current behavior.

We could consider increasing it further if you think it would help -- if the number of tabs before closing is larger than what you'd normally let it grow to before running "close all editors", there would be no change in behavior at all -- it would only affect those users who never run "close all editors"... which is good because those are also the users who are most affected by the performance concerns. Would 30 editors be more palatable?

> I'm really using the order of tabs (open editor in my understanding) as a history


The change we're discussing would only kick in for editors that aren't in the 20 most recent tabs. In my experiments, it only seems to affect editors which have already disappeared from the tabs and are currently hidden in the chevron, not tabs which are currently visible... but I can't state with certainty that it would never affect a visible tab (do we still use MRU tab visibility? If so, we could state this with certainty.)

Is there a reason you wouldn't want to use alt-left-arrow rather than ctrl-pgup to navigate to the previous editor? I think it would address all the use-cases without the performance cost. Also, you'd probably want to use the dropdown below the back button rather than the dropdown in the tabs -- but that seems preferable for your use case since the order below the back button really reflects the navigation history whereas the order in the chevron is alphabetical.

However, I actually do not care if there is actually an editor "active" for a tab that doesn't have
> focus: if the editor is disposed when I don't use it and re-instantiated when I select the tab, that's fine.

I agree that would be ideal... if we could destroy and recreate the editor entirely without leaving any user-visible footprint. Unfortunately, the best approach we support at the moment does leave some user-visible side-effects. Namely: the closed editors disappear from the ctrl-e menu and the number shown in the chevron is lower.

My argument is that this user-visible side-effect is minimal enough to be acceptable given the considerable performance gains that come with it.

Ok, I trust you. It's just that I don't feel it at usage. Maybe because I'm just accustomed to it.

Since the entire justification of one of the changes pivots on the presence of these performance issues, asking me to back up that claim with evidence you can inspect is perfectly reasonable.

  - Stefan

On Mon, Mar 14, 2016 at 12:22 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
Hi Stefan,

It seems like I'm confused by the purpose of this change and that some of my comments were/are not accurate. Anyway, I'll try to be more precise.

On 03/14/2016 07:59 PM, Stefan Xenos wrote:
The preference I'm talking about has nothing to do with the history stack and the back button. The history stack is based on editor inputs and it works just as well even if you enable the "close automatically" preference and set the number of editors to 1.
1. That it would cause editors to disappear unexpectedly. Response: The editors we're talking about have already disappeared from the tabs. If you're not referring to the tabs, please state specifically which part of the UI you expected to see the editor in but could not find it.
I'm not using the history stack, I'm really using the order of tabs (open editor in my understanding) as a history. I also do it in Firefox and all other tabbed applications. In Firefox, I would hate to see tab disappear or page closed automatically. I have the same feeling with the IDE.
However, I actually do not care if there is actually an editor "active" for a tab that doesn't have focus: if the editor is disposed when I don't use it and re-instantiated when I select the tab, that's fine. I'm actually attached to nothing automatic happening to the tabs, not much about how and when the content of the editor is disposed/created.

3. That there is actually no performance problem if you have a large number of realized editors. Response: Confirmed via profiler output, end-user reports, and static analysis of the code involved.
Ok, I trust you. It's just that I don't feel it at usage. Maybe because I'm just accustomed to it.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev


Back to the top