Question on CLI vs GUI, and today's call

Question on CLI vs GUI, and today's call

[Kris Van Hees]

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

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

[Andrew Cagney]

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
>   

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

[Kris Van Hees]

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

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

[Sami Wagiaalla]

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

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

[Andrew Cagney]

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