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

[Andrew Cagney <cagney@redhat.com>]

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