From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2345 invoked by alias); 23 Feb 2007 14:37:40 -0000 Received: (qmail 2337 invoked by uid 22791); 23 Feb 2007 14:37:40 -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 14:37:31 +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 l1NEaE3c028332; Fri, 23 Feb 2007 09:36:34 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l1NEYmQl007342; Fri, 23 Feb 2007 09:34:58 -0500 Received: from [172.16.14.55] (toner.toronto.redhat.com [172.16.14.55]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l1NEYbxq015227; Fri, 23 Feb 2007 09:34:38 -0500 Message-ID: <45DEFB7B.9050503@redhat.com> Date: Fri, 23 Feb 2007 14:37:00 -0000 From: Sami Wagiaalla User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: Kris Van Hees CC: Andrew Cagney , 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> In-Reply-To: <20070223003326.GA21099@ca-server1.us.oracle.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/msg00160.txt.bz2 Kris, I think that we are all very strongly agreeing here :) > I'll try to clarify more specifically what I mean, and actual your first > comment is the perfect lead-in for that. Yes, indeed the UI behaviour > (be it CLI or GUI) should not be defined by limitations of the core. > However, equally important is that the UI should not impose limitations > upon the core. Nor should the UI define the functionality of the core. > There is a fine distinction in that functionality is of course driven by > user interaction scenarios, and user interaction defines how various > tasks are decomposed in their individual steps, and the core has to > provide the functionality to make those steps possible. But that is an > abstract concept, disconnected from specific UI design. > > Ultimately, the user interaction model is what drives the functionality > that is required from the core, and the UI (CLI and GUI alike) provide > the presentation to the user for that functionality. > Agreed, and this is definitely Frysk policy. Once in a while we forget and we get stuck in implementation details :), but we quickly get off the topic and back to user goals. One example of this is back in the day we had a button that said "Attach", and only when you have attached can you then go and add observers. Now there is only "add observer" if the core sees that an attach is needed in order to add that observer it does so transparently. > To me it felt like the discussion was a mixture of abstract user > interaction (semantics -- "what should happen if the user does blah"), > visualization ((G)UI -- "what should this look like; should icons be > hidden or shaded), and core functionality (implementation -- "how do we > implement user action blah"). The first two are UI-related though at a > very different level, and the fine line between them is very important. > I think this is probably a misunderstanding the goal of the discussion was to figure out what the user wants so that we can use the core primitives in place to implement that goal. > 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. > 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. Cheers, Sami Wagiaalla