Re: Discontinuation of GNOME Clipboard Manager



On Iau, 2004-04-01 at 23:59, Philip Van Hoof wrote: 
It doesn't have to be fundamentally slow. A mechanism to transfer huge
amounts of data from one application-instance to another is not 'very'
difficult to create at all. It is, however, pretty difficult to make all
applications agree on 'a' standard for this data-transfer process.

Remember that you can pass a reference to a third party object transfer
as one of your clipboard types. So that should mean you can
pass a big object both as image/jpeg and also a small
"x-fdo-reference/corba" or some such type to be invented which enhanced
clipboard apps would prefer.

I prefer not to create yet another technically imperfect solution for
this problem. The problem should be solved at it's roots. We should not
want to create a fix on top of a problem, a patch on top of an
never-healing wound.. we should want to fix the wound, heal it. Period.

Beware the evil compatibility monster. It has to be back compatible.

It's not nice and even more nor easy to create such a page without
creating huge amounts of havoc and anger. I am, for sure, not a
candidate for it. However, most of the clipboard related problems are
indeed, problems in the applications.
 
Link it to a FAQ on fixing the apps. Seriously a lot of it depends
whether you say "Applications that are not fully compliant" or "sucky
crap written by a total bozo" 8)

peered network-setup and one for keeping a history of clipboards?
Perhaps it's overkill today, but will it be overkill in a new era?

And if Miguel had said "I need a svg aware desktop with virtual
file systems, themeing, spreadsheet, etc etc" , gosh that might be
hard lets not start" ?

The fact about this is: You cannot know that. And lets not make the same
mistakes of the past: designing while keeping in mind that hardware is
slow and stupid.

fast and stupid 8)

The hardware is quite happy copying 10Mbytes/second over your lan, 
its all the software layers on top.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]