From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5898 invoked by alias); 23 Feb 2007 16:14:47 -0000 Received: (qmail 5889 invoked by uid 22791); 23 Feb 2007 16:14:46 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Feb 2007 16:14:41 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l1NGEOtX026914; Fri, 23 Feb 2007 11:14:24 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1NGENbP014458; Fri, 23 Feb 2007 11:14:23 -0500 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1NGEMlk010762; Fri, 23 Feb 2007 11:14:23 -0500 Message-ID: <45DF12D8.4060801@redhat.com> Date: Fri, 23 Feb 2007 16:14:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Sami Wagiaalla , Kris Van Hees CC: Frysk List Subject: Re: Question on CLI vs GUI, and today's call References: <20070221183908.GA13807@ca-server1.us.oracle.com> <45DE0F2B.8090008@redhat.com> <20070223003326.GA21099@ca-server1.us.oracle.com> <45DEFB7B.9050503@redhat.com> In-Reply-To: <45DEFB7B.9050503@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00161.txt.bz2 Sami Wagiaalla wrote: >> Mixing them up tends to lead to inconsistencies in UI between e.g. CLI >> and GUI. >> > Agreed, if UI get too thick code should be matured, rewritten more > generically, and then pushed down to core. Yes, for instance the step engine was prototyped as part of the gnome code, but then pushed down into the run-time model where both the gnome and hpd interfaces could share it. Importantly, this made possible common interaction such as a HPD step being reflected in the UI. >> I do agree that the discussions are very positive and constructive. I >> do however feel that there is a tendency (as it always happens) to mix >> the areas quite a bit. And that can be quite dangerous. >> >> Your example of the 'advance-a-line' function is a good one for this. >> As you state, there was confusion as to the exact semantics of specific >> operations, like "step" vs "advance". The decision was to enable >> "advance" but not 'step" when a non-inner frame is selected. > This is a good example. The discussion was about what the goal of the > user is after they have filtered through a stack of calls which they > are not interested in, and he or she clicks "step". Do they mean go > down to that frame which I have already dismissed and step one line ? > Or transparently finish all those frames, arrive to the one they are > "looking at" and step one line ? Does the use really need to be > presented with both "step" and "advance" or can the need for both be > eliminated by improving the concept of " the frame the user is looking > at" >> However, >> does that mean this will be implemented as a UI change? Or a change in >> the core? Or both? >> > I might not be the person to answer this, but I would guess core :) In > order to maintain the thinness of UI's, and consistency of behavior > between them. It's actually both :-) -> the core will need to be tweeked so that an "advance" request specifies the frame it is being applied to This change will occure in what's become known as the "middle-end" - frysk.rt here - that is built over lower level primatives. -> the graphical component needs to be tweaked so step is disabled when the frame is non-inner - thus preventing the user from initiating a step (of course "step" is still there and will apply to the inner most frame). I think an occasional brief dally into the middle-end - so that the developers understand broadly the implementation and at least that it is feasable - is ok; but taking your point on board, we need to be careful that we don't stray into low-level core details. Andrew