Re: Clipboard history idea.

[Matthew Newhall <odinson flatclub ml org>]

Hello

Some of your ideas sound really good.

On Sat, 3 Oct 1998, Blake wrote:

> > > I think that a simply filo buffer for a gcp app would be enough,
and it
> > > could use standard unix signals, or perhaps it could use IP. If a program
> > > copies, it sends it via IP, which could be to a gcp on another machine. This
> > > makes a lot of sense if you run a lot of remote prosseces under X.
> > 
> > Hello
> > 
> >   That took about ten minuets.  I guess that a filo buffer could
> > also be easy enough to implement.  It would just mean you would have to
> > juggle the information between two stacks, for each data type of some
> > description, when you wanted to recall a type midway in the stack.
> > 
> 
> Maybe I should say, it uses an internet to send clipboard data. But, in
> order to keep in with things, the server should provide CORBA services. Too
> bad I don't know much about those.

Nor do I.  I am starting to docs but...

> 
> >   I do know a little about networks.  Did you mean a gcb client server
> > setup? The gcb server receives the signal, retrieves the data pack, and
> > sends a signal to al the waiting gcb clients?   This would prevent
> > redundant copies from being stored.  Is the rest of Gnome setup
> > that way?  If it is consistant it sounds good to me.
> > 
> >   I am concerned about security.  Is it an unfounded fear to think of
> > someone using this to request sensitive cut or copied data that they
> > shouldn't have access to?
> 
> No, Security is a good issue here. I think that perhaps each user should have a
> private gcb started for each gnome-session, or have to log onto a gcb on
> another machine manually. Hmm, I do like the idea, it would make
> cut-and-paste between two workstations a lot easier.
> 
Perhaps one gcb should be associated with each instance of gnome session
starting when it's gnome session starts and ending when it's gnome session
ends.  I was thinking that Gclipboard could make the request for
headers(thumbnails, text clip, etc) when the user starts it up.  If the
applet was running it would just make the request to see if any data of a
certain type is availible, in turn lighting up a signal on the panel.

Their would be some kind of method by two gcb's agree it's
appropriate to communicate, a login of some sort (probobly command line
grandma won't be fooling with this feature, at least not visibaly.  Maybe 
a front end could pop up later.) It should also be decided at the gcb
login whether, gcb #.#.#.3 should send data to gcb #.#.#.41 no access the
oppisite way, the reverse, two mutually accessable archives, or which one
should archive all data accessable to both.  Gcb could communicate with
another gcb on port x.  This would make it easy to block or support gcb
over firewalls.

Unfortunatly I think sending that kind of data, even over a LAN would have
to involve encription to be safe. That makes it sound a bit more involved.
Is there a way that the packets can be protected without intergrating
encryption in gcb.  Gcb should be as lightweight and non-obtrusive as
possible, are we getting too crazy here?  After all once the cut/copy
data_copied_signal is hacked into (ORBit??), any number of history
scenerios/apps can be created to use it, as long as they follow the
protocol/call used by the hack.   


> >   I realize there are potentially infinate data types so perhaps if
> > gclipboard was setup in such a way that it was easy to write and add a
> > definition for selecting and display of each data type?  Of course it
> > should be setup by default to cope with plain text and imadges. For
> > plain text it would display the first 50 characters of the text.  And 
> > for imadges it would caculate a thumbnail, or maybe show the imadge at
> > full size when right clicked(send a cut signal when left clicked.) Maybe
> > it should have a sort of plugin interface after that.  So if a certain
> > type of medical record would show 10 characters of the first 3 fields of
> > data.  And a sound clip would show a pix of a pair of notes that then in
> > turn would play the clip if right clicked?
> > 
> 
> How about using MIME types for data definitions. This would also make
> cut-and-paste from gnome-aware browsers (ie. mnemonic) a lot easier and
> logical. And these data types could be handled by a global plugin. This
> might mean that every browser/clipboard/wordpreccesing app would use this
> data in the same manner, kinda like the Global URL Repository. Actually, I
> think this last idea is too complicated(except the MIME idea).

I got the same vibe thinking about the nastyness involved with trying to
visibly index so many data types.  How would the MIME types be able to
diplayed?  The user should be able to audiably or visibly browse the
selections.  


> 
>    -Blake
> 

Matthew Newhall