Re: [g-a-devel]Patch for bug 91993 in at-poke
- From: "Padraig O'Briain" <Padraig Obriain Sun COM>
- To: michael ximian com
- Cc: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel]Patch for bug 91993 in at-poke
- Date: Wed, 2 Oct 2002 14:35:01 +0100 (BST)
> Subject: Re: [g-a-devel]Patch for bug 91993 in at-poke
> To: "Padraig O'Briain" <Padraig Obriain sun com>
> Cc: accessibility mailing list <gnome-accessibility-devel gnome org>
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
>
> Hi Padraig,
>
> On Tue, 2002-10-01 at 13:25, Padraig O'Briain wrote:
> > The attached patch fixes bug 91993; it does not attempt to select two
elements
> > when no element is selected.
>
> > + if (role == SPI_ROLE_TABLE_COLUMN_HEADER) {
> > + Accessible_unref (child);
> > + continue;
>
> Sounds good to me, but this:
>
> > +static void
> > +selection_changed_cb (GtkTreeSelection *tree_selection, Poker *poker)
> > +{
> > + /*
> > + * When one clicks on a row in the TreeView which currently does not
> > + * have any row selected one first gets notification of selection for
> > + * the first row and then a subsequent notification for the selected
> > + * row if it is different from the first row.
> > + */
> > + if (!poker->selection_changed_idle_id)
> > + poker->selection_changed_idle_id = gtk_idle_add (do_selection,
poker);
> > }
>
> Looks pretty ghastly; ? What happens on the wire when you select a
> table, that hasn't had any row selected before ? is this a gtk+
> limitation ? why do we have to work around it here ? surely this is just
> a large man-trap waiting for other people ?
>
> Then again - I don't quite understand the existing selection_changed_cb
> I must confess; it's always interesting to try and work out who is the
> master / slave in all of this really.
>
> 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.
Thus, selection_changed_cb() is called twice, once because the first node is
selected and then because the requested node is selected. This just seems to be
the behaviour of GtkTreeView. I could log a bug but I am not convinced that it
would be changed.
We do not want to confuse the user by reporting two selections; this is what bug
91993 complains about. We use an idle handler to ensure that if more than one
selection is reported, all except the last is ignored. Using the idle handler
means that only last selection is sent on the wire to the application.
I have tested this with gtk-demo. I fouynd that gailtreeview did not do the
selection correctly when atk_selection_add_selection() was called. This has been
corrected in a recent commit.
Padraig
> Regards,
>
> Michael.
>
> --
> mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]