From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22625 invoked by alias); 23 Feb 2007 00:33:48 -0000 Received: (qmail 22616 invoked by uid 22791); 23 Feb 2007 00:33:47 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rgminet01.oracle.com (HELO rgminet01.oracle.com) (148.87.113.118) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Feb 2007 00:33:41 +0000 Received: from rgmsgw01.us.oracle.com (rgmsgw01.us.oracle.com [138.1.186.51]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l1N0XSZL004322; Thu, 22 Feb 2007 17:33:28 -0700 Received: from ca-server1.us.oracle.com (ca-server1.us.oracle.com [139.185.48.5]) by rgmsgw01.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l1N0XQmG016865 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Feb 2007 17:33:27 -0700 Received: from kvanhees by ca-server1.us.oracle.com with local (Exim 4.63) (envelope-from ) id 1HKONK-00075w-Jq; Thu, 22 Feb 2007 16:33:26 -0800 Date: Fri, 23 Feb 2007 00:33:00 -0000 From: Kris Van Hees To: Andrew Cagney Cc: Kris Van Hees , Frysk List Subject: Re: Question on CLI vs GUI, and today's call Message-ID: <20070223003326.GA21099@ca-server1.us.oracle.com> References: <20070221183908.GA13807@ca-server1.us.oracle.com> <45DE0F2B.8090008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45DE0F2B.8090008@redhat.com> User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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/msg00159.txt.bz2 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. 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. Mixing them up tends to lead to inconsistencies in UI between e.g. CLI and GUI. 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. However, does that mean this will be implemented as a UI change? Or a change in the core? Or both? Cheers, Kris On Thu, Feb 22, 2007 at 04:46:19PM -0500, Andrew Cagney wrote: > Kris, > > Can you be a little more specific? > > Yes, we need to be careful that the UI's behavior isn't defined by > limitations of the core, and in that regard, I thought the discussion > was very positive. It was most satisfying to be in on a discussion that > at no stage limited the UI possibilities due to to limitations further > down. Instead the talk seemed to focus on identifying semantics that > would be clear to a user - for instance separate continue-thread and > continue-threads buttons. And with that decided, they can be quickly > and efficiently implemented using the core. > > The internals discussion I noted was on the details of "advance-a-line" > when in a non-inner frame; there the discussion was highlighting the > confusion in some of the operations, for instance how "step" applied to > the inner-most frame and not the currently selected frame. Recognizing > that led to the decision to enable "advance" but not "step" when a > non-inner frame is selected. > > Andrew > > Kris Van Hees wrote: > >First of all, am I right that the CLI and GUI interfaces are mere shells > >on top of the actual debugger/monitor core that handles all actual > >functionality, and leaves the user interaction portion to the CLI and > >GUI code? That largely seems to be the case, and I just wanted to > >confirm that this strict separation of focus is adhered to everywhere. > > > >Which leads to another question, or comment... Especially today's call > >made me wonder a bit about the separation of processing core vs UI > >because it seemed (at least to me) that part of the discussion turned > >into the mechanics of stepping in the presence of multiple threads > >rather than the user interaction part only. Generally, when discussing > >UI aspects, if it is not clear what a certain button, menu item, or > >other element (or combination thereof) is wired to in the processing > >core, there is a fundamental problem. It indicates that either the > >separation between presentation and processing is lost, or that the > >behaviour at the processing level is not defined well enough to make it > >clear how the user should interact with it. > > > >I think it would make the calls a bit more targeted if we can recognize > >when the conversation becomes more about the underlying mechanics and > >defer that to discussion in a non-UI forum? > > > >As always, all comments are welcome. > > > > Cheers, > > Kris > > >