Re: [g-a-devel]Patch for bug 91993 in at-poke
- From: Michael Meeks <michael ximian com>
- To: Padraig O'Briain <Padraig Obriain sun com>
- Cc: accessibility mailing list <gnome-accessibility-devel gnome org>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: [g-a-devel]Patch for bug 91993 in at-poke
- Date: 03 Oct 2002 12:58:33 +0100
Hi Padraig,
On Wed, 2002-10-02 at 14:35, Padraig O'Briain wrote:
> > Curious as to why we have to have an 'idle' handler there, the
> > potential for race conditions etc.
> We are dealing here with the case where at-poke is driving the application. We
> select a node in the Select Treeview by pressing the mouse button when over the
> node.
>
> If there is currently no node selected because Clear has been pressed, the code
> in gtktreeview.c (gtk_tree_view_button_press) first selects the ifrst row of the
> TreeView when it calls gtk_widget_grab_focus() and then subsequently selects the
> requested node.
I'd really prefer to have this 'fixed' in gtk+ if that's possible;
simply because adding an idle handler to ensure that we eliminate bogus
clicks is really shoddy.
Also; if people using a GtkTreeView are reacting to a selection in some
way that might alter say a side-pane [ eg. in a mail reader ] - with a
noticable mail fetch latency - this will lead to either a load of cut
and paste idle handlers around the place discarding random events - or,
flicker and pain in other places, or worse a whole superstition culture
of idle-izing everything :-)
I'd be most interested in whether Jonathan sees this as a bug, and
indeed whether it's fixable at root.
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]