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

[Andrew Cagney <cagney@redhat.com>]

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
>