Re: Question on CLI vs GUI, and today's call

[Kris Van Hees <kris.van.hees@oracle.com>]

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
> >  
>