Re: [Usability] clipboard manager comments

[Gregory Merchan <merchan phys lsu edu>]

On Wed, Oct 16, 2002 at 09:55:58PM +0200, Philip Van Hoof wrote:
> On Wed, 2002-10-16 at 21:28, Gregory Merchan wrote:
> 
> > GdkAtom and Atom are no longer the same type. You'll need to do:
>  
> >   XGetSelectionOwner (gdk_display, gdk_x11_atom_to_xatom (manager));
>  
> > It's an OK check. You could try to find a name for the existing owner
> > and present an alert to allow the user to replace the existing clipboard
> > manager (CM). If the existing manager is also GCM, you could either exit
> > quietly or pop up whatever window GCM might display. Another thing you
> > might do is wait until the existing CM gives up CLIPBOARD_MANAGER; that's
> > probably too messy with too little benefit.
> 
> Hmm, Because GNOME Clipboard Manager might once become more like a
> deamon I don't think a Gnome popup box is a good idea here ... 

Yeah. It's not really necessary. You could just replace the other CM
if it isn't GCM on the assumption that if the user does something to
run it, like logging in to a GNOME session, he intends to do. But you
wouldn't want any later instance of GCM to stop an earlier one because you'd
lose history data. You'd lose history by stopping any other CM too, but
this should be a problem for most users because - well, who switches CMs?
If for any reason it does become a problem, then an extension of CM protocols
will have to be standardized to say, "All your clipping are belong to us"
and blah blah blah.


>                                                            Or it
> should be called from for example .xinitrc files using gcm& in stead of
> just gcm .. (else such a modal dialog could block the starting of the X
> session). It would be possible with the current source of GNOME
> Clipboard Manager to wait until the other CM gives up. It would not make
> the code messy; maybe a little bit less predictable ... as GCM will just
> sit there and wait until the other CM gives up. I will have to implement
> this using a timeout idle_func I guess.. so it would mean that GCM has
> to poll the CLIPBOARD_MANAGER selection ownership until it's released
> :-\ and then claim ownership of the CLIPBOARD_MANAGER selection and
> CLIPBOARD selection.
<snip>

Eep! You don't have to poll. When the other CM gives up it must destroy the
window that owned the manager selection. You just select that event and
the X server will tell you. Something like this, though this will
block processing:

Bool
destroyed_predicate (Display *d, XEvent *ev, XPointer arg)
{
  if (ev->type == DestroyNotify &&
      ev->xdestroywindow.window == (Window) arg) {
    return True;
  } else {
    return False;
  }
}

void
blocking_test_for_owner (Display *d, Atom manager_atom)
{
  Window w;

  w = XGetSelectionOwner (d, manager_atom);

  if (w) {
    XEvent ev;
   
    XSelectInput (d, w, StructureNotifyMask);

    XIfEvent (d, &ev, destroyed_predicate, (XPointer) w);
  }
}

Once blocking_test_for_owner() returns, there is no CLIPBOARD_MANAGER
owner. Though, another one could appear at any time. For that we have
events sent to root and timestamps.

With Gdk you'll do something like this:

GdkFilterReturn
destroy_filter (GdkXEvent *xevent, GdkEvent *event, gpointer data)
{

	/* Take over and clean up */

	return GDK_FILTER_REMOVE;
}

gboolean
test_for_owner (Display *d, Atom manager_atom)
{
  Window     xwin;

  xwin = XGetSelectionOwner (d, manager_atom);

  if (xwin) {
    GdkWindow *gwin;

    gwin = gdk_window_foreign_new (xwin);

    gdk_window_set_events (gwin, GDK_STRUCTURE_MASK);

    gdk_window_add_filter (gwin, destroy_filter, NULL);

    return FALSE;
  } else {
    return TRUE;
  }
}

This way will not block processing. (But I don't know what a clipboard
manager program might do when not managing. ;-)

Any polling with X that isn't waiting or checking for an event is probably
an error.


Cheers,
Greg Merchan