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

[Kristian Rietveld <kris gtk org>]

On Thu, 2002-10-03 at 13:58, Michael Meeks wrote:
> 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'm seeing this behaviour, and it annoys me too (:. I don't know about
the rationale of selecting the first item when the treeview gets focus
(maybe keynav related -- not sure). IIRC the plan to fix this is using
TreeView modes, once the TreeView modes API is ready.


	Kris

> 
> 	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
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list