GNOME Bugzilla – Bug 316552
GtkTextView needs intra-app copy/paste with TextTags (Win32)
Last modified: 2005-09-20 08:03:57 UTC
Under WIN32 (I don't know about Linux) I noticed that Drag/Drop does handle Text *and* TextMarks. Using Copy/Cut/Paste, it doesn't. Only the text is pasted. I think GtkTextView/GtkTextBuffer must also support at least the TextTags, to be of more use for "real" users. Maybe an On/Off thing? Other information:
What are TextMarks and TextTags? You say the current implementation does handle TextMarks?
Sorry, I meant: GetTextTag s. And I shouldn't have said anything about GtkTextMarks. Because I really is about GtkTextTag s. Essentially what happens is that the markup, provided by the GtkTextTags isn'y copied to and from the clipboard along with the text. You can try it out in the gtk demo.
Hmm, are you talking about intra-app or inter-app copy/paste here? I couldn't get any markup copy-pasted between two instances of gtk-demo on OpenSUSE. But inside the same gtk-demo instance, yes. On Win32, nope, true. Is this the problem? Or are you expecting it to work between separate GTK+ applications? Or perhaps even between GTK+ and non-GTK+ applications?
I would be *very much* delighted if it would work in the same GTK+ application. I consider it a lot of work to let it work between two Gtk applications or even between Gtk applications and non-Gtk apps; and maybe even not appropriate. It would require some intermediate format that is used between Apps. On windows, this could very well be RTF (uch!). This is not a requirement for me. At this moment I'm working around the problems (as I'm developing on Win32), however, I don't especially like to work around different behaviour on Unix and Win32.
Clarifying the Summary then... (Presumably, making GTK markup pass *from* a GTK+ app to a non-GTK+ app (that understands Rich Text) would not be that hard. I assume the GTK+ markup structures have mor or less straightforward equivalents in Rich Text.)
So, is it clear then, that only copy/paste within the same Gtk+ application is a requirement for me?
Yes.
The root cause for this problem seems to be that gdk_selection_owner_get_for_display() in gdkselection-win32.c always returns NULL for GDK_SELECTION_CLIPBOARD. This causes gtktextbuffer.c to not use the GTK_TEXT_BUFFER_CONTENTS data (which in reality is a pointer to internal GTK data inside the process's address space), as it thinks it's from another process. Changing gdk_selection_owner_get_for_display() to not return NULL will require a thorough review and rewrite of the Win32 dnd code, sigh. This code is pretty hairy as is. The comment explaining why gdk_selection_owner_get_for_display() returns NULL says: /* Return NULL for CLIPBOARD, because otherwise cut&paste inside the * same application doesn't work. We must pretend to gtk that we * don't have the selection, so that we always fetch it from the * Windows clipboard. See also comments in * gdk_selection_send_notify(). */
Fixed now in gtk-2-8 and HEAD. There is no reason to always return a NULL owner for CLIPBOARD any longer. (There are however other problems and confusion in the Win32 selection/property/clipboard implementation, and a more thorough cleanup and partial rewrite is necessary, see bug #168173. But I'll make sure that this bug won't reappear after such a cleanup.) 2005-09-20 Tor Lillqvist <tml@novell.com> * gdk/win32/gdkselection-win32.c (gdk_selection_owner_get_for_display): Do return the correct owner for CLIPBOARD (i.e., the owner of the Windows Clipboard, if it is a window GDK knows about). The reason to return NULL seems to have gone when in the fix for bug #163702 the artificial GDK_SELECTION_CLEAR event generation was removed from gdk_selection_send_notify_for_display(). Fixes bug #316552.