From users-return-2637-apmail-directory-users-archive=directory.apache.org@directory.apache.org Mon Aug 17 09:32:55 2009 Return-Path: Delivered-To: apmail-directory-users-archive@www.apache.org Received: (qmail 61827 invoked from network); 17 Aug 2009 09:32:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Aug 2009 09:32:55 -0000 Received: (qmail 80151 invoked by uid 500); 17 Aug 2009 09:33:02 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 80116 invoked by uid 500); 17 Aug 2009 09:33:02 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 79887 invoked by uid 99); 17 Aug 2009 09:33:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2009 09:33:01 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pajbam@gmail.com designates 209.85.220.222 as permitted sender) Received: from [209.85.220.222] (HELO mail-fx0-f222.google.com) (209.85.220.222) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2009 09:32:51 +0000 Received: by fxm22 with SMTP id 22so2523685fxm.9 for ; Mon, 17 Aug 2009 02:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=NOKInZHhUK7bdhJoKK4QR0uiNdEVDyjJMH04s2gvJls=; b=rgAjaQotHRC48LeQeRuIJyyxVAt/LFGWa5oPtLZd7rkHK03slUtAbKv8IiBTtv8d++ HV7Fv5YGfFidrl+Hr9BfYaQm3HR0xTe56OmWWMw33KkIgtRqoOLpLNesV2c8zTJgFi4w q+o4Anhc8sHsrW7AGERuCm/bzGyn9jfwUmEoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=xGyDtnhdR5Z2biaCd1p+v2eghbzda7AtxhX7A7cVshG7cQ2PQn15uOC9tABpUKkI+5 3HLBONi/3W6/i2LyKGQ0BJpP2CMHYpSxcLF1Wdf5lk8quKCsgkKmmPCajkihyarYAG5S 3snYow++omQPy19L9wlWx8AXbmQ5xY/Gx+3oo= MIME-Version: 1.0 Sender: pajbam@gmail.com Received: by 10.204.38.79 with SMTP id a15mr2487920bke.145.1250501551073; Mon, 17 Aug 2009 02:32:31 -0700 (PDT) In-Reply-To: <4A871B6C.205@apache.org> References: <98d8c0860908140854r383035d6na9b88029591c5822@mail.gmail.com> <4A871B6C.205@apache.org> Date: Mon, 17 Aug 2009 11:32:31 +0200 X-Google-Sender-Auth: 6da06fb33a95b82f Message-ID: <98d8c0860908170232s651dc88ete1a528357b440ceb@mail.gmail.com> Subject: Re: [Studio] Cruel dilemma with Editor Open Mode in Studio From: Pierre-Arnaud Marcelot To: users@directory.apache.org Cc: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0003255590dabe2b350471531429 X-Virus-Checked: Checked by ClamAV on apache.org --0003255590dabe2b350471531429 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 ? Thanks, Pierre-Arnaud --0003255590dabe2b350471531429--