directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Date Mon, 17 Aug 2009 09:32:31 GMT
Hi Stefan,
More inline...

On Sat, Aug 15, 2009 at 10:32 PM, Stefan Seelmann <>wrote:

> Hi guys,
> thanks Pierre-Arnaud for bringing this to top. We already discussed on
> IRC about that problem. Today, while washing the dishes, I had an idea
> to solve the dilemma.
> Let me begin with a quotation from [1] about the Eclipse workbench
> concepts:
> View: ... Modifications made in a view are saved immediately.
> Editor: ... It is typically used to edit or browse a resource. ...
> Modifications made in an editor follow an open-save-close lifecycle model.
> So IMO we should consider the current "Entry Editor" (and also the
> "Search Result Editor") as view, although is lives in the editor area.
> It doesn't follow the open-save-close lifecycle model but saves
> modifications immediately.

You're right. According to the Eclipse concepts, the current Entry Editor is
definitely a view living in the editors area.

> I'd like to bring the following points to discussion:
> We keep the current "Entry Editor" as is. We rename it to "Entry View"
> (view is a bad name but I can't find a better one). We add a new
> checkbox to the preferences: "Open 'Entry View' while browsing" which is
> checked by default. This way the current behaviour is kept. When
> unchecking the checkbox the "Entry View" isn't opened automatically. We
> add a new action "Open Entry View" to the context menu to open it. If
> opened it automatically loads and shows the attributes of the selected
> entry. The new extension point isn't used here. The open mode isn't used
> here.

Although, it helps us to be more consistent between releases by keeping the
"standard" mode, I'm a little concerned by this because it makes the current
Entry Editor a really special case that is not included in our newly defined
Entry Editors feature.

The new extension point only allows new editors that follow the
> open-save-close lifecycle model. These editors behave like normal
> Eclipse editors. There is always one editor per entry, so multipe editor
> could be opened. These editors use the open mode (double-click by default).

Actually, the new extension point allows new editors, and then it's up to
the editor to decide if it wants to use the open-save-close lifecycle model,
and/or display one editor per entry or one editor for all the entries (our
'multiWindow' boolean flag).
The current Entry Editor is nothing than an editor with a view behavior, and
maybe other entry editors will need this behavior too.

> There are two minor issues:
> - Currently on double click the entry is expanded/collaped and its
> children are shown/hidden. When the open mode is "double-click" we
> should disable the expand/collapse.

I'm not sure we should disable this behavior. When I was playing with the
open mode implementation, it was feeling natural to me that the children
were shown and the editor was opened at the same time.

> - In single-click open mode both, the "Entry View" and the editor are
> opened. Maybe it makes sense to uncheck/disable the "Open 'Entry View'
> while browsing" checkbox in that case.

This can be a much more serious issue. Having two editors opened at the same
time is not really clean for our users I think.

> My prefered setting would be the default: While browsing the "Entry
> View" is used to show the attributes and to do quick modifications. On
> demand I double-click the entry or select "Open with" from context menu
> and a new entry editor is opened. This could be used for larger
> modifications or to compare different entries.
> Another setting is to disable the "Entry View" thing. In that case there
> are multiple options to see the attributes:
> - double-click the entry, however this opens a real editor following the
> open-save-close lifecycle
> - select "Open Entry View" form context menu which opens the view
> I think this has less impacts to the current behaviour but allows huge
> improvments with new editors.
> Thoughts?

Actually, in this discussion I think there are two main aspects: the entry
editors and the open mode.

As I said earlier in this mail, I think the current implementation of the
"Entry Editor/View" should not be seen as an exception to entry editors but
should be a regular Entry Editor.
Of course, by default, it should be defined as the default one with the
highest priority rank.

About the open mode, we all agree that we should continue to support the
current way Studio works and stay consistent between versions, but also that
we need to support the general Eclipse open mode.

As Eclipse default open mode is the opposite of ours, it's obvious that we
need a new preference setting that can be toggled to switch between the
historical Studio behavior and the use of the Eclipse open mode property.

What I had in mind are the following things.

- A preference page where the user can define its default entry editor and
order them according to its preferences, with the current implementation of
the Entry View/Entry defined as the default one.
- Another preference page (or another part of the previous pref page)
dedicated to the open mode with two radio buttons.
    - The first radio button is checked by default and correspond to the
historical Studio behavior.
    - The second radio button allows the user to re-use the general Eclipse
open mode.

I believe it should enough to bring the new features we wanted to bring,
keep the existing behavior and stay consistent.

Thoughts ?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message