Re: Selection bug/feature

[Roy Wood <roy wood filogix com>]

>I think the problem is a little more straight forward: if you unrealize 
>the window (destroying the window), you lose the X selection.  Roy: is 
>the Anjuta code actually unmapping/unrealizing the window, like you 
>described in your email?  If so, then that is your problem.

What happens is that Anjuta takes the notebook widget containing the 
Scintilla widgets, does a gtk_container_remove() to remove the notebook 
from the current window, creates an hpaned widget, and then does a 
gtk_container_add() to add the notebook back into the new hpaned widget.  

I've traced through the code, and the Scintilla widgets have their unmap 
and unrealize handlers called, which is not surprising.  And when they 
are added to the hpaned widget, the map/realize handlers are also called. 
 Note that the widget itself isn't destroyed-- it just changes containers.

Tracing through the gtk/gdk selection code, it appears to use some 
combination of the widget pointer as well as the associated window, which 
is where things break.  For example, if I try to do a new copy and claim 
the clipboard, gtk/gdk notices that I am still the same widget, and still 
own the clipboard, so it doesn't modify its internal data structures.  
However, when I request the clipboard, gtk/gdk uses the window reference 
to try to find me, which doesn't work.

Any thoughts there then?


Also, as an unrelated matter, I notice that the gtk selection handling 
code uses a GList to maintain the relevant information about who owns the 
selections.  As well, there is no special locking done (that I can see) 
to maintain the integrity of this information in the event of pre-emption 
of the code by another thread or process.  I'm sure that something is 
done somewhere to basically serialize acess to thiscode though, and I was 
hoping some gtk guru could shed some light on that for me.  Any takers?


Thanks....


-Roy




You said:

>Owen Taylor wrote:
>
>>Roy Wood <roy wood filogix com> writes:
>>
>>>I've been doing a little work on Anjuta, a gtk-based IDE, and have 
>>>tracked down a problem that's causing copy/paste to break.  It turns out 
>>>that the gtk/gdk selection handling code tracks a widget via its gdk 
>>>parent window, and Anjuta sometimes reparents its Scintilla editing 
>>>widget (sticks it an an hpane or a vpane).  This breaks things since any 
>>>attempt to retrieve the selection fails (gtk/gdk can't find the editing 
>>>widget properly after it's been reparented).
>>>
>>>The simplest way to get around this in Anjuta seems to be to relinquish 
>>>ownership of the "CLIPBOARD" selection when the editing widget is 
>>>unrealized/unmapped, and then to reclaim it when the widget is 
>>>realized/mapped after being reparented.  This seems to work nicely.
>>>
>>>
>>>Questions though:
>>>
>>>1) Anyone see any problems doing it this way?
>>>
>>>2) Is it worth trying to keep the Scintilla widget in an intermediate 
>>>container, and reparent that container, rather than directly reparenting 
>>>the Scintilla?
>>>
>>>3) Is it better to reclaim the "CLIPBOARD" selection when mapped or 
>>>realized?
>>>
>>>4) Is it better to tweak the gtk/gdk selection code to deal with this 
>>>reparenting directly?
>>>
>>
>>Basically, the GTK+ selection code doesn't really work on no-window
>>widgets, which I'd have to guess is your problem. (Though I don't
>>immediately see how this happens in detail from your description....
>>I'd guess the Scintilla widget does h ave a window.)
>>
>Last I checked, the GtkScintilla widget had a window.
>
>I think the problem is a little more straight forward: if you unrealize 
>the window (destroying the window), you lose the X selection.  Roy: is 
>the Anjuta code actually unmapping/unrealizing the window, like you 
>described in your email?  If so, then that is your problem.
>
>James.
>
>-- 
>Email: james daa com au
>WWW:   http://www.daa.com.au/~james/
>
>
>
>_______________________________________________
>gtk-devel-list mailing list
>gtk-devel-list gnome org
>http://mail.gnome.org/mailman/listinfo/gtk-devel-list