Re: Discontinuation of GNOME Clipboard Manager
- From: Alan Cox <alan lxorguk ukuu org uk>
- To: spamfrommailing freax org
- Cc: Murray Cumming <murrayc murrayc com>, gtk-app-devel-list gnome org, gnome-devel-list gnome org, "desktop-devel-list gnome org" <desktop-devel-list gnome org>
- Subject: Re: Discontinuation of GNOME Clipboard Manager
- Date: Fri, 02 Apr 2004 15:37:37 +0100
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]