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]