Re: Selection bug/feature

[Owen Taylor <otaylor redhat com>]

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.)

I'd suggest that:

 - For GTK+-1.2, you use a GtkInvisible widget to hold the selection;
   this could be a bit ineffficient if you had _lots_ of widgets, 
   but shouldn't be a problem on the scale of a few or few dozen
   editing widgets.

 - For GTK+-2.0, you use GtkClipboard, which handles everything for
   you and avoids the problem of having to having to have a window.

Regards,
                                        Owen