Re: [patch:MI] Observer for thread-changed

[Vladimir Prus <ghost at cs dot msu dot su>]

On Tuesday 10 June 2008 17:25:12 Daniel Jacobowitz wrote:
> On Tue, Jun 10, 2008 at 10:27:38AM +0400, Vladimir Prus wrote:
> > The question, then, if whether -thread-select should output this notification?
> > Suppose a frontend uses -thread-select to get some data in some thread without
> > making it selected. Then, if a notification is emitted, the frontend has to 
> > take special care not to mark the thread as selected in GUI.
> > 
> > As an aside, this is similar to notifications/signals in GUI libraries -- for
> > example, line edit control often has 'text changed' signal. If this signal is
> > emitted even when the text is changed programmatically, the application 
> > often has to specially prevent signals emitted as result of programmatic change
> > to be handled as if it was the user input.
> > 
> > So, I think that -thread-select *should not* emit thread-changed notification.
> > With the original version of your patch, it would be a one-line change, it's
> > probably a bit harder with the last version.
> 
> One method I use is to ask myself how complicated the documentation
> for something will be.  It's much clearer to say "the notification is
> emitted whenever the active thread changes" than "... unless it
> changed because of -thread-select".

I'm afraid you are oversimplifying -- the "the notification is
emitted whenever the active thread changes" is very nice, but it's very
likely that every frontend author will not realize he has to ignore this
notification from -thread-select. So, the documentation should either say
that the notification is better ignored, or say that is not emitted. Now, what
is better?

I'd like this notification to communicate, from GDB to frontend, that GDB
has encountered a command that indicates explicit user desire to change
the thread he looks at, and that frontend typically should react by making
that thread selected in UI. 

Maybe, the notification should be called something like:

	=thread-selection-request

to indicate this better? Of course, we can also have another notification,
that is emitted each time inferior_ptid changes, but then the notification
should be named

       =inferior-ptid-changed

In other words, I argue for notification to be designed with the view of
what frontend is supposed to do with it, not with what internal detail of
GDB is been reported.


Alternatively, may I suggest we rename this notification? Let me be

   =user-has-explicitly-requested-that-the-current-thread-be-changed

In which case it's apparent 

> Will detecting notifications due to its own commands be that
> complicated for any IDE?

Probably not very complicated, but it's easier if a frontend should
not care about this.

- Volodya