From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14615 invoked by alias); 14 Jun 2008 15:10:17 -0000 Received: (qmail 14606 invoked by uid 22791); 14 Jun 2008 15:10:16 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jun 2008 15:09:59 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.63) (envelope-from ) id 1K7XO3-0006Oz-NK for gdb-patches@sourceware.org; Sat, 14 Jun 2008 19:09:54 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K7XNZ-0006O5-Nq; Sat, 14 Jun 2008 19:09:22 +0400 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [patch:MI] Observer for thread-changed Date: Sat, 14 Jun 2008 18:52:00 -0000 User-Agent: KMail/1.9.9 Cc: Nick Roberts , Pedro Alves , gdb-patches@sourceware.org References: <18509.7945.19078.399646@kahikatea.snap.net.nz> <200806101027.38454.ghost@cs.msu.su> <20080610132512.GB7986@caradoc.them.org> In-Reply-To: <20080610132512.GB7986@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806141909.37719.ghost@cs.msu.su> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00263.txt.bz2 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