Re: [g-a-devel]Patch for bug 91993 in at-poke



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