Re: [gnome-love] gnome clipbook program?

[ERDI Gergo <cactus cactus rulez org>]

Hi Ryan,

Sorry for the late reply, I've been busy and I am still going to be busy
for the next week.

[ I moved this from gnome-love to gnome-components-list, I hope you are
subscribed to this as well. ]

On Sun, 17 Jun 2001, rpmuldoon students wisc edu wrote:

> To start out with, I think it is important to outline what I see to be the
> central design goals.
> 1. Easy to use API.  I abhor the gtk 1.2 clipboard handling.  It requires way
> too much of the developer.  It should really just come down to identifying
> what has been selected, what the mime type is, and handing it off to the
> clipboard server.  For selection retrieval, I should just be able to accept
> the top thing off of the stack, or select a selection id, and insert it into
> my existing data.

With my current proposal, if you don't want to do application-specific
persistency optimalizations, all you need to put data on the clipboard is
to create one or two monikers.
Getting data from the clipboard also simply means getting and using a
moniker.

> 2. Selections should stick around after the app is closed.  This is something
> that should Just Work.  This suggests that applications should not own their
> cut/copy data, but rather a clipboard server should.

Yes, several solutions to this problem have been outlined in the Bonobo
Clipboard thread. I think having a general solution but offering
applications to do their own is the way to go.

> 3. This should play nice with allowing for a history of cut/copy data.  That
> is, we should be able to query the clipboard server for a list of everything
> it stores.  the user should be able to decide how big the history is.  It
> also has to be smart enough to filter out duplicates.

This is entirely up to the clipboard server implementation.

> 4. We should have a nice application (like I outlined before in my previous
> email) that can display all of the clipboard content, with a nice way to drag
> and drop it into applications.  Like I said, this should be a bonobo content,
> with potentially a MIME-types filter, so an app can embed it to only show the
> mime types it can handle.

This should be doable as a completely standalone component that simply
uses the Bonobo Clipboard API.

> 5. The clipboard server should be configurable to who it is visible to, and
> it should have the ability to save data across sessions/instances.  The
> user-visible clipbook should be able to use multiple clipboard servers as
> data stores.

This is something I have no idea about. Should the clipboard be
per-display? per-user? Should it span across multiple sessions? 


> 6. The whole system should play as nicely as possible with existing
> applications and the X clipboard.

Can you store anything else than text/plain on the X clipboard? If it is a
text/plain-only thing, see my proposed solution about saving the clipboard
via PersistStream and exporting it from the bonobo clipboard server to the
X clipboard. It could even do what xclipboard does.

> One thing that wasn't suggested, but is probably extremely kudgy, is the
> following.  While the API shouldn't expose this, there should be cut/copy
> logic that looks at the size of the copied data.  If it is small, just send
> it over the wire to the clipboard server.  There's basically no performance
> hit, storage is minimal, and everything works as the user expects it to.
> (which, in my opinion, is what matters most here)  Furthermore, the clipboard
> server will need to store stuff like this anyway, because it is going to have
> to poll the X clipboard for non-bonobo apps cutting/copying data. If it is
> big enough that sending it over the wire makes a difference, save the
> document with a temporary name tied to the id of the selection itself.  Make
> a moniker based on that document.  When the selection is removed from the
> clipboard, remove the document too.  (Pity linux doesn't have a cooler
> filesystem, because this could be trivial and cheap with a real journalling
> system.)  This would also solve the problem of the user changing the
> document.  Like I said, it is ugly, but at least it works, and it is hidden
> from the application developer.

Uhhh. I really don't like this automagical approach. If your application
works on large datasets, you should be able to provide specialized
optimazations to retrieving previous states of the selection, so you
bypass the stock ClipboardStore and provide the pasting moniker yourself.
If it is not worth the trouble because the application works on small
data, you just use the ClipboardStore that will take care of storing the
selection's state.

> My main concern is that the API is pathetically simple to implement.  DnD and
> Cut/Copy/Paste seem needlessly complicated right now.

I haven't mentioned D&D before because this is a problem space I haven't
researched, but my gut feeling is that d&d and c&p have a lot of
overlapping issues (both are about getting either static or linked data
from app A to app B).

Bye,
	"All Talk and No Code" Cactus (well that is hopefully going to
change soon:)

-- 
   .--= ULLA! =----------------------.   `We are not here to give users what
   \    http://cactus.rulez.org       \   they want'  -- RMS, at GUADEC 2001
    `-----= cactus cactus rulez org =--'
Friends help you move; Real friends help you move bodies.