RE: [gnome-love] gnome clipbook program?

["Ryan Muldoon" <rpmuldoon students wisc edu>]

> -----Original Message-----
> From: ERDI Gergo [mailto:cactus cactus rulez org]
> Sent: Thursday, June 21, 2001 9:24 AM
> To: rpmuldoon students wisc edu
> Cc: gnome-components-list gnome org
> Subject: Re: [gnome-love] gnome clipbook program?
>
>
> Hi Ryan,
>
> Sorry for the late reply, I've been busy and I am still going to be busy
> for the next week.
>

No problems...
> [ 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.
>
yeah, I realize.  I was just trying to outline what I saw as the eventual
goal...not necessarily disagreeing with anything you say.

> > 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.
>
Yep...just trying to outline what I think the user should be able to do.
While it is not strictly an API concern, sometimes it helps to think about
usage when developing an API.

> > 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.
>
Same comment as above. ;-)

> > 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?
>
I think what would make the most sense is to default to per display, but
there should be options to allow for per-user.  I'd like to see it be able
to span across multiple sessions, as it seems like a logical part of the
point of session management.

Eventually I would consider it to be extremely cool if there were options to
share clipboard data with other users, whether or not they are on the same
machine.  This may impact how monikers are named, I'm not sure.

>
> > 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.
>
My understanding is that the X clipboard can handle quite a few different
MIME types.  I think it is just that most X applications don't really do
much more than allow cutting/pasting text, even though other types are
supported.  But I'm sure others know far more about this than I.

> > 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.
>
I don't particularly like it either, but I don't see how the issue of
pasting the correct data after the source has changed is resolved otherwise.
I didn't really see the answer in any of the previous threads on this.
Maybe I just missed it.  But, the problem with monikers are that they link
to current data, not data at a given point in time.  So how do you resolve
the issue other than pushing the actual data to the clipboard store, or
having the app save the data specially client-side, and serve it up as
requested?  Both of these seem to not be compatible with monikers as I
understand them.

> > 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).
>
I think that you're right, but I know even less about D&D than I do about
cut/copy/paste.  ;-)

	--Ryan