You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Pierre-Arnaud Marcelot <pa...@marcelot.net> on 2009/08/14 17:54:02 UTC
[Studio] Cruel dilemma with Editor Open Mode in Studio
Hi all,
As we're adding extensibility to the entry editor, we need to refactor the
way editors are opened.
We want to offer various ways to open the entry editor compared to the
hard-coded single-click mode we currently have.
We'd like to reuse an already existing Eclipse mechanism for open mode,
combined with the standard Eclipse "General" preference page [1].
This page allows the user to choose whether editors open on double-click or
single-click events (with even more options in that second case).
This preference page comes with any Eclipse version we support and is also
already included in the Apache Directory Studio RCP Application.
Looking at the picture I've drawn, that's a lot of benefits, but... there's
one down side...
This down side is that the default value for open mode is "Double click" on
that preference page, which is the opposite of what the user is currently
using on Studio (with our hard-coded single click open mode).
So, we're facing a cruel dilemma where we greatly want to use this
preference setting because it offers to the user a lot more control and it's
very handy to be able to define a preferred open mode, but, on the other
hand, between versions (1.4 to 1.5), consistency is not maintained. Version
1.4 by default opens an entry editor on a single click event (or single move
with the arrow keys) while version 1.5 would by default open an entry editor
on a double click event.
>From my POV, I think the benefit is really worth the inconsistency, but I'd
really like to get more feedback from you.
Thanks,
Pierre-Arnaud
[1] - http://people.apache.org/~pamarcelot/EclipseGeneralPreferencePage.png
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Stefan Seelmann <se...@apache.org>.
Pierre-Arnaud Marcelot wrote:
> 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.
Ok, sounds good. Let's try this.
Kind Regards,
Stefan
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Stefan Seelmann <se...@apache.org>.
Pierre-Arnaud Marcelot wrote:
> 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.
Ok, sounds good. Let's try this.
Kind Regards,
Stefan
Source build issue
Posted by Ioannis Mavroukakis <im...@gameaccount.com>.
Good morning :-)
I'm getting this while trying to build the latest trunk/
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.directory.shared:shared-parent:pom:0.9.15-
SNAPSHOT
Reason: Cannot find parent: org.apache.directory.project:project for
project: org.apache.directory.shared:shared-parent:pom:0.9.15-SNAPSHOT
for project org.apache.directory.shared:shared-parent:pom:0.9.15-
SNAPSHOT
Is this something that's at fault at my end?
Thanks,
Yiannis
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Stefan,
More inline...
On Sat, Aug 15, 2009 at 10:32 PM, Stefan Seelmann <se...@apache.org>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 ?
Thanks,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Stefan,
More inline...
On Sat, Aug 15, 2009 at 10:32 PM, Stefan Seelmann <se...@apache.org>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 ?
Thanks,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Martin Alderson <ma...@salfordsoftware.co.uk>.
Hi Stefan,
That sounds quite good. Some thoughts...
There are some users (some technical users even) that often forget
whether they are supposed to single click or double click to open an
item. It might be a bit confusing for them (or just new users in
general) if they double click an entry and end up with two views on the
same entry.
I'm also thinking that if you have an option to disable the "entry view"
you might as well also have an option to disable the "entry editor".
You could have the entry editor disabled by default which would allow
double clicking to expand / contract a container entry as it does now.
With this you kill two birds with one stone - you don't have confusion
with double click opening two editors and you don't lose the current
expand / contract functionality. Even with this option the entry editor
should be available from the context menu.
Finally, I think it would be useful if multiple entry editors could be
opened for the same entry. There are times when I would like to take a
snapshot of an entry then compare it to its state a little bit later on.
I'm not sure if this is already the plan - I just wanted to bring it
up since you mentioned "there is always one editor per entry".
Thanks,
Martin
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.
>
> 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.
>
> 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).
>
> 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.
> - 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.
>
> 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?
>
> Kind Regards,
> Stefan
>
>
> [1]
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-02b.htm
>
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Stefan Seelmann <se...@apache.org>.
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.
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.
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).
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.
- 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.
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?
Kind Regards,
Stefan
[1]
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-02b.htm
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Stefan Seelmann <se...@apache.org>.
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.
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.
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).
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.
- 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.
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?
Kind Regards,
Stefan
[1]
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/qs-02b.htm
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Kiran,
Thanks for this feedback. :)
More inline.
On Fri, Aug 14, 2009 at 6:16 PM, ayyagarikiran <ay...@gmail.com>wrote:
>
> I like to have the double-click mode as default (remembering how many times
> entry editor got opened when I accidentally selected an entry in the DIT)
Same thing here. And it's even worse if you're using the arrow keys to
navigate in the tree.
> coming to the consistency, I would prefer to leave the existing behavior as
> default if that is possible (may be based on other users' choice too)
>
Now, here's the hard of the business... Because we're modifying this setting
across the whole Eclipse.
When you're using the Apache Directory Studio RCP Application, that's not an
issue, but when you're in a standard Eclipse distribution, if we modify this
setting, this will also affect the other perspective (Java perspective for
example). I'm sure it will make our users upset.
Maybe what we could propose is a little popup window that is launched when
the LDAP, or Schema Editor perspectives are opened. This popup would explain
that we're now using this setting and ask the user if he wants to keep its
current setting.
> thanks for including this feature and other EntryEditor stuff( that I
> didn't understand completely ;) )
The Entry Editors stuff is the ability to have multiple editors to choose
from for opening entries, like our standard editor, or an LDIF editor which
opens the entry as an ldif record you can edit. Or something else... As it
is an extension point, anyone will be able to add a new entry editor.
Regards,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Alex Karasulu <ak...@gmail.com>.
On Fri, Aug 14, 2009 at 7:16 PM, ayyagarikiran <ay...@gmail.com>wrote:
>
>
> Pierre-Arnaud Marcelot wrote:
>
>>
>> So, we're facing a cruel dilemma where we greatly want to use this
>> preference setting because it offers to the user a lot more control and it's
>> very handy to be able to define a preferred open mode, but, on the other
>> hand, between versions (1.4 to 1.5), consistency is not maintained. Version
>> 1.4 by default opens an entry editor on a single click event (or single move
>> with the arrow keys) while version 1.5 would by default open an entry editor
>> on a double click event.
>>
>
> I like to have the double-click mode as default (remembering how many times
> entry editor got opened when I accidentally selected an entry in the DIT)
>
Oh yes I kind of hate that too. Such a pain.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Kiran,
Thanks for this feedback. :)
More inline.
On Fri, Aug 14, 2009 at 6:16 PM, ayyagarikiran <ay...@gmail.com>wrote:
>
> I like to have the double-click mode as default (remembering how many times
> entry editor got opened when I accidentally selected an entry in the DIT)
Same thing here. And it's even worse if you're using the arrow keys to
navigate in the tree.
> coming to the consistency, I would prefer to leave the existing behavior as
> default if that is possible (may be based on other users' choice too)
>
Now, here's the hard of the business... Because we're modifying this setting
across the whole Eclipse.
When you're using the Apache Directory Studio RCP Application, that's not an
issue, but when you're in a standard Eclipse distribution, if we modify this
setting, this will also affect the other perspective (Java perspective for
example). I'm sure it will make our users upset.
Maybe what we could propose is a little popup window that is launched when
the LDAP, or Schema Editor perspectives are opened. This popup would explain
that we're now using this setting and ask the user if he wants to keep its
current setting.
> thanks for including this feature and other EntryEditor stuff( that I
> didn't understand completely ;) )
The Entry Editors stuff is the ability to have multiple editors to choose
from for opening entries, like our standard editor, or an LDIF editor which
opens the entry as an ldif record you can edit. Or something else... As it
is an extension point, anyone will be able to add a new entry editor.
Regards,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by ayyagarikiran <ay...@gmail.com>.
Pierre-Arnaud Marcelot wrote:
>
> So, we're facing a cruel dilemma where we greatly want to use this
> preference setting because it offers to the user a lot more control and
> it's very handy to be able to define a preferred open mode, but, on the
> other hand, between versions (1.4 to 1.5), consistency is not
> maintained. Version 1.4 by default opens an entry editor on a single
> click event (or single move with the arrow keys) while version 1.5 would
> by default open an entry editor on a double click event.
I like to have the double-click mode as default (remembering how many times entry editor got opened when I accidentally
selected an entry in the DIT)
coming to the consistency, I would prefer to leave the existing behavior as default if that is possible (may be based on
other users' choice too)
thanks for including this feature and other EntryEditor stuff( that I didn't understand completely ;) )
Kiran Ayyagari
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by ayyagarikiran <ay...@gmail.com>.
Pierre-Arnaud Marcelot wrote:
>
> So, we're facing a cruel dilemma where we greatly want to use this
> preference setting because it offers to the user a lot more control and
> it's very handy to be able to define a preferred open mode, but, on the
> other hand, between versions (1.4 to 1.5), consistency is not
> maintained. Version 1.4 by default opens an entry editor on a single
> click event (or single move with the arrow keys) while version 1.5 would
> by default open an entry editor on a double click event.
I like to have the double-click mode as default (remembering how many times entry editor got opened when I accidentally
selected an entry in the DIT)
coming to the consistency, I would prefer to leave the existing behavior as default if that is possible (may be based on
other users' choice too)
thanks for including this feature and other EntryEditor stuff( that I didn't understand completely ;) )
Kiran Ayyagari
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Martin,
On Fri, Aug 14, 2009 at 7:01 PM, Martin Alderson <
Martin.Alderson@salfordsoftware.co.uk> wrote:
>
> I'm not a fan of pop-ups like this but I guess if it only shows up one time
> it isn't going to kill me. It would be great to have a tab open the first
> time a version of Studio is run with a welcome page showing the release
> notes etc which would in this case include a note about this change in
> behaviour. That way you don't have to dismiss it if you just want to do
> something. I can imagine that people might want to open up the preferences
> themselves to see this option before dismissing the pop-up telling them
> about it, for example.
>
I really like this idea. Displaying the release notes and the noteworthy
changes is, indeed, something that could be interesting to do.
Does this mean that Studio will be capable of opening multiple entry editors
> at the same time? That would be useful.
Exactly! ;)
> I wouldn't have thought this kind of option would be changed often enough
> by anyone to warrant it being on the toolbar. I don't think it will bother
> me either way though.
>
That's also true.
Thanks a lot for feedback.
Regards,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Emmanuel Lecharny <el...@apache.org>.
Martin Alderson wrote:
> Hullo,
>
>
>> Maybe what we could propose is a little popup window that is launched
>> when the LDAP, or Schema Editor perspectives are opened. This popup
>> would explain that we're now using this setting and ask the user if he
>> wants to keep its current setting.
>>
>
> I'm not a fan of pop-ups like this but I guess if it only shows up one time it isn't going to kill me. It would be great to have a tab open the first time a version of Studio is run with a welcome page showing the release notes etc which would in this case include a note about this change in behaviour. That way you don't have to dismiss it if you just want to do something. I can imagine that people might want to open up the preferences themselves to see this option before dismissing the pop-up telling them about it, for example.
>
Totally +1.
>
>
>>> Now, when multiple entries are opened, we shoul dbe able to navigate
>>> through them when simple clicking on the entries (a bit like for the
>>> Java editor : when the classes are open, a simple click change the tab
>>> to the opened file.
>>>
>
> Does this mean that Studio will be capable of opening multiple entry editors at the same time? That would be useful.
>
I think they are working toward such a solution, to allow usesr to
compare entries, for instance. Usefull, indeed.
>
>
>> We already have that "General" preference page, but maybe we could add a
>> specific element in the toolbar for fast switching.
>>
>
> I wouldn't have thought this kind of option would be changed often enough by anyone to warrant it being on the toolbar. I don't think it will bother me either way though.
>
Probably true.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Martin Alderson <Ma...@salfordsoftware.co.uk>.
Hullo,
> Maybe what we could propose is a little popup window that is launched
> when the LDAP, or Schema Editor perspectives are opened. This popup
> would explain that we're now using this setting and ask the user if he
> wants to keep its current setting.
I'm not a fan of pop-ups like this but I guess if it only shows up one time it isn't going to kill me. It would be great to have a tab open the first time a version of Studio is run with a welcome page showing the release notes etc which would in this case include a note about this change in behaviour. That way you don't have to dismiss it if you just want to do something. I can imagine that people might want to open up the preferences themselves to see this option before dismissing the pop-up telling them about it, for example.
> > Now, when multiple entries are opened, we shoul dbe able to navigate
> > through them when simple clicking on the entries (a bit like for the
> > Java editor : when the classes are open, a simple click change the tab
> > to the opened file.
Does this mean that Studio will be capable of opening multiple entry editors at the same time? That would be useful.
> We already have that "General" preference page, but maybe we could add a
> specific element in the toolbar for fast switching.
I wouldn't have thought this kind of option would be changed often enough by anyone to warrant it being on the toolbar. I don't think it will bother me either way though.
Martin
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Emmanuel,
Thank you too for this fast feedback.
More inline.
On Fri, Aug 14, 2009 at 6:16 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
> All the eclipse applications I have used are opening elements when I
> double-click. I think that is the standard behavior, and we have diverged
> from this standard from day one.
Exactly, that's what is causing us these consistency issues.
> Now, when multiple entries are opened, we shoul dbe able to navigate
> through them when simple clicking on the entries (a bit like for the Java
> editor : when the classes are open, a simple click change the tab to the
> opened file.
That mechanism will work exactly the same in the LDAP Browser view if you
activate the "Link with editor" button, just like you did in the Java
perspective.
That's very handy.
> In any case, a preference to toggle the simple/double click is mandatory.
We already have that "General" preference page, but maybe we could add a
specific element in the toolbar for fast switching.
Regards,
Pierre-Arnaud
Re: [Studio] Cruel dilemma with Editor Open Mode in Studio
Posted by Emmanuel Lecharny <el...@apache.org>.
Pierre-Arnaud Marcelot wrote:
> Hi all,
> As we're adding extensibility to the entry editor, we need to refactor the
> way editors are opened.
>
> We want to offer various ways to open the entry editor compared to the
> hard-coded single-click mode we currently have.
>
> We'd like to reuse an already existing Eclipse mechanism for open mode,
> combined with the standard Eclipse "General" preference page [1].
>
> This page allows the user to choose whether editors open on double-click or
> single-click events (with even more options in that second case).
>
> This preference page comes with any Eclipse version we support and is also
> already included in the Apache Directory Studio RCP Application.
>
>
> Looking at the picture I've drawn, that's a lot of benefits, but... there's
> one down side...
>
> This down side is that the default value for open mode is "Double click" on
> that preference page, which is the opposite of what the user is currently
> using on Studio (with our hard-coded single click open mode).
>
All the eclipse applications I have used are opening elements when I
double-click. I think that is the standard behavior, and we have
diverged from this standard from day one.
Now, when multiple entries are opened, we shoul dbe able to navigate
through them when simple clicking on the entries (a bit like for the
Java editor : when the classes are open, a simple click change the tab
to the opened file.
In any case, a preference to toggle the simple/double click is mandatory.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org