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

[Nick Roberts <nickrob at snap dot net dot nz>]

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

You could say the same about user-defined functions that use the "threads"
command.

I don't think MI should be used as a programming language.  I don't think
-thread-select should be used by the front end except when the user explicitly
requests to change threads.  In fact, I would even suggest that there should be
no -thread-select and that all MI commands should be reflective and not change
the state of GDB or the inferior.  With a complete set of notifications,
the usual CLI commands could be used to change state and the front end could
just parse the MI output.

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

But the first patch was wrong for other reasons, as Pedro pointed out.

-- 
Nick                                           http://www.inet.net.nz/~nickrob