Re: Selection bug/feature

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.


Email: james daa com au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]