Re: Selection bug/feature

[James Henstridge <james daa com au>]

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/