Re: [gnome-love] gnome clipbook program?

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

Hi Cactus:

Thanks for responding to my email.  I actually read the discussions you
referred to, but I took a look at them again to get everything fresh in my
mind.  I do have a fair amount to say about all of this, but I'll put a
little disclaimer here first: I know very little about actual bonobo
programming, and the intracacies of the X clipbard system.  I do feel that I
have thought about this issue a fair amount, so hopefully my input is
somewhat useful.

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.
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.
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.
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.
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.
6. The whole system should play as nicely as possible with existing
applications and the X clipboard.

Of course, my design goals are sloppy, as they cover both design and
implementation, and are all over the design space.  BUT, those are still the
contstraints that I think that we should be working under.

When I was initially thinking about this, it seemed like monikers were going
to be the best way to go.  But, as Cactus has outlined in previous
discussions, if it is just a moniker all the time, if the source data is
modified after the fact, you end up pasting the wrong thing.

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.

My main concern is that the API is pathetically simple to implement.  DnD and
Cut/Copy/Paste seem needlessly complicated right now.  More of the smarts
should be hidden away.  I would not be surprised at all if most/all of this
is dismissed out of hand due to my utter lack of understanding of bonobo
internals, but hopefully something is useful.  I'd be happy to try and work
on this further - at least in higher-level design type issues.

   --Ryan

--------------------------------------------------------------------
Mail2Web - Check your email from the web at
http://www.mail2web.com/ .