Re: Clipboard details

[ERDI Gergo <cactus cactus rulez org>]

On 20 Jul 2001, Mike Kestner wrote:

> module Bonobo {
>     module Clipboard {
>         interface Registry {
>             void addContainer (in UIContainer uic,
>                           in Selection sel);
>             void removeContainer (in UIContainer uic);
>         };
> 
> The clipboard merges UI elements, and therefore we don't have a pile of
> duplicated code in every application just to implement the standard menu
> items. 

So this is for an automatic Edit/Copy and Edit/Cut, right? See below for
how I would go implementing this inside libbonoboui.

> In the event driven container responsible model, there are some
> traps like how does the container know when to release a copied/cut
> item.  It can't do it on a change event, because it will get one of
> those even when it initially sets the clipboard.  

You bring up a good point here -- there has to be a way to notify the
current data source when the clipboard changes, to enable it to do things
like freeing up the buffer where it stores the data copied to clipboard
(in case it doesn't use the ClipboardStore).
However, I think the fact that the old pasting and linking monikers are
unref'd by the clipboard when a new one is set is enough to achieve this
-- just do the disposing in the destructor of your moniker.


> I think this approach makes the container implementation simpler and
> puts the clipboard more in control of the functionality, instead of
> having the clients duplicate a lot of control logic.

I think this kind of thing would belong in libbonoboui and not Bonobo.
A very user-friendly API would be possible to be built upon the current
interfaces:

typedef void (*BonoboClipboardClientRecieveFn) (Bonobo_Moniker  moniker,
						gpointer        closure);

typedef void (*BonoboClipboardClientRequestFn) (Bonobo_Moniker *pasting,
						Bonobo_Moniker *linking,
						gpointer        closure);

void bonobo_clipboard_client_merge_edit_menu_recieve
	(BonoboUIContainer uic,
	 BonoboClipboardClientRecieveFn paste_cb,
	 BonoboClipboardClientRecieveFn link_cb,
	 gpointer closure);

void bonobo_clipboard_client_merge_edit_menu_request
	(BonoboUIContainer uic,
	 BonoboClipboardClientRequestFn copy_cb,
	 BonoboClipboardClientRequestFn cut_cb,
	 gpointer closure);

Of course now that I think about it, we should use GClosures here to give
less headaches to the binding authors.

Anyway. This API would create automatic Edit/Paste, Edit/Link here,
Edit/Copy and Edit/Cut menu items and toolbar items, with the application
author really having to implement only what is necessary.
Another approach would be a GObject emitting signals, but that would be
basically just the same.

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
Kinos pillanat,amikor az ember kikop a csukott autoablakon.