Re: Cut 'n Paste prob solved & Q

[Owen Taylor <otaylor redhat com>]

Conrad Steenberg <conrad@srl.caltech.edu> writes:

> Hi all
> 
> A few weeks ago I reported a problem in gtk where pasting text into an
> editable widget would make it segfault. I just installed the most recent
> gtk snapshot (last night's) and found that the problem is now gone. Thanks
> to whoever made the changes :-)
> 
> This resolution of the problem may be due to changes in gtkselection.c. I
> note that the function gtk_selection_add_handler is now gone from
> gtk_selection.h, which breaks the spreadsheet widget of Adrian Feiguin :-(
> 
> The calls in that widget were of the form 
> gtk_selection_add_handler (GTK_WIDGET(shentry), GDK_SELECTION_PRIMARY,
>                              GDK_TARGET_STRING, handler_func,
>                              NULL);
> (The second and third arguments do not occur in the normal signal handler
> install function.)
> 
> My question is this: how can I get the same functionality with the newer
> versions of GTK? Reading gtk_selection.[ch] was not helpful...

Here's the RFC about the changes I posted a few weeks ago
on gtk-devel-list a few weeks ago.

Regards,
                                        Owen

From: Owen Taylor <otaylor@redhat.com>
Subject: Selection handling changes
To: gtk-devel-list@redhat.com
Date: 08 Oct 1998 00:13:45 -0400
Resent-From: gtk-devel-list@redhat.com
Reply-To: gtk-devel-list@redhat.com
X-From-Line: gtk-devel-list-request@redhat.com  Thu Oct  8 00:14:36 1998
Return-Path: <gtk-devel-list-request@redhat.com>
Received: from fresnel.labs.redhat.com (fresnel.labs.redhat.com [207.175.45.22])
	by fresnel.labs.redhat.com (8.8.7/8.8.7) with ESMTP id AAA00499
	for <otaylor@fresnel.labs.redhat.com>; Thu, 8 Oct 1998 00:14:36 -0400
Received: from lacrosse.redhat.com
	by fresnel.labs.redhat.com (fetchmail-4.4.4 POP3)
	for <otaylor/fresnel.labs.redhat.com> (single-drop); Thu, 08 Oct 1998 00:14:36 EDT
Received: from mail.redhat.com (mail.redhat.com [199.183.24.239])
	by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id AAA20370
	for <otaylor@lacrosse.redhat.com>; Thu, 8 Oct 1998 00:03:03 -0400
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id AAA06645
	for <otaylor@redhat.com>; Thu, 8 Oct 1998 00:03:02 -0400
Received: (qmail 7607 invoked by uid 501); 8 Oct 1998 04:07:30 -0000
Resent-Date: 8 Oct 1998 04:07:30 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-devel-list-request@redhat.com  Thu Oct  8 00:07:30 1998
Message-ID: <ybezpb7n11i.fsf@fresnel.labs.redhat.com>
X-Mailer: Gnus v5.5/Emacs 20.3
Resent-Message-ID: <"a4xj92.0.gs1.2g37s"@mail2.redhat.com>
X-Mailing-List: <gtk-devel-list@redhat.com> archive/latest/106
X-Loop: gtk-devel-list@redhat.com
Precedence: list
Resent-Sender: gtk-devel-list-request@redhat.com
X-URL: http://www.redhat.com
Lines: 140
Xref: fresnel.labs.redhat.com gtk-devel:302

As some of you know, I've been working recently on re-doing
drag-and-drop handling for GTK+. The interfaces for that are pretty
closely related to that for selections, and I've become a little
disatisfied with the gtkselection interfaces I originally came up
with. So, rather than making DND conform to those interfaces, I'm
proposing changing the selection interfaces a bit.

Unfortunately, these are backwards-incompatible changes, but they are
fairly easy to fix up, and I don't think selection use is all that
extensive yet.

The change consists of dumping the

  gtk_selection_add_handler()

system in favor of registering a list of targets that the widget can
supply for a selection and then having a "selection_get" signal which
is called to get the contents of the selection.

This seemed preferable to me for several reasons:

 - The handlers added a bunch of complexity - where
   possible I think it is better to use signals
   for handlers.

 - I've never seen code that actually sets up
   multiple different handler functions for different
   selections and targets, so there  shouldn't be much 
   disadvantage of simply routing things through a single signal.

The API, as it now stands is:

struct _GtkTargetEntry {
  gchar *target;
  guint  info;
};

void gtk_selection_add_target (GtkWidget           *widget, 
			       GdkAtom              selection,
			       GdkAtom              target,
			       guint                info);
void gtk_selection_add_targets (GtkWidget           *widget, 
				GdkAtom              selection,
				GtkTargetEntry      *targets,
				guint                ntargets);

 "selection_get"           (GtkWidget          *widget,
			    GtkSelectionData   *selection_data,
			    guint               info,
			    guint               time);

The one thing that needs explaining here is the mysterious "guint
info" parameter. The point of this parameter is to make things a bit
easier to avoid gdk_atom_intern()'s all over the place.

When adding a target to the list of targets for a selection, one
supplies a guint that is later returned to you when the
"selection_get" handler is called for that target.

This allows, for instance, things like case statements to be used:

enum {
  STRING,
  TEXT,
  COMPOUND_TEXT
}

  static GtkTargetEntry targetlist[] = {
    { "STRING", STRING },
    { "TEXT",   TEXT },
    { "COMPOUND_TEXT", COMPOUND_TEXT }
  };
  static gint ntargets = sizeof(targetlist) / sizeof(targetlist[0]);
  
  gtk_selection_add_targets (selection_button, GDK_SELECTION_PRIMARY,
			     targetlist, ntargets);

  gtk_signal_connect (GTK_OBJECT(selection_button), "selection_get",
		      GTK_SIGNAL_FUNC (selection_get), NULL);


void
selection_get (GtkWidget *widget, 
	       GtkSelectionData *selection_data,
	       guint      info,
	       guint      time,
	       gpointer   data)
{

[...]

  switch (info)
    {
    case COMPOUND_TEXT:
       [...]
    case TEXT:
       [...]
    case STRING:
       [...]
    }
  
  gtk_selection_data_set (selection_data, type, 8, buffer, len);
}


I think it makes things a bit handier, but could be removed
in favor of making the target lists straight lists of 
GdkAtoms. (Unfortunately, the same capability can't be
provided on the receiving end, since GTK+ doesn't ever
get a list of targets from the app. It is provided on
both ends for DND under some circumstances. I'll elaborate
more on the DND API soon.)

Also, as a gratuitous piece of breakage, I'm planning to
make a minor change to the "selection_received" signal
to add a "time" parameter.

  void "selection_received"      (GtkWidget          *widget,
				  GtkSelectionData   *selection_data,
				  guint               time);

This probably will cause more problems with backwards
incompatibility than the more major changes ... but knowing
the time here is somewhat necessary to speak the selection
protocols correctly.

(You can fish it out of gtk_get_current_event(), but that is
 less than elegant.)

Anyways, comments or suggestions are welcome.

Regards,
                                        Owen