Re: State of the X clipboard, and perhaps a solution
- From: Jerry Haltom <wasabi larvalstage net>
- To: Pat Suwalski <pat suwalski net>
- Cc: desktop-devel-list gnome org
- Subject: Re: State of the X clipboard, and perhaps a solution
- Date: Thu, 22 Apr 2004 20:05:26 -0500
> I'm not terribly comfortable with having window-less desktop programs
> running. I can think of many situations where something would go wrong
> and would go unnoticed, or be difficult for the average user to kill. If
> there were some bizarre communication problem with the clipboard daemon,
> it might even be that no program would shutdown cleanly.
A lot of people feel the same way about gconf, gnome-session,
gnome-settings-daemon, and others. I think they have worked out pretty
well. Anyways, my idea does not have a clipboard daemon? It uses X's
existing clipboard handling, which all GTK programs use RIGHT NOW.
Right?
> The idea of a clipboard daemon, of course, is good. And your idea to
> just plop everything into it actually appeals more to me. There would
> simply have to be a limit to how much it could store. Maybe available
> ram over four. Maybe a policy that once something large-ish is pasted,
> it would be wiped from the clipboard.
The idea of a clipboard daemon is bad and inherently flawed. The only
way the code and data necessary to generate the content of any
negotiated type can exist, is to never go away. My post clearly
described how a clipboard daemon was the WRONG idea, so I'm confused
what you mean.
> You could even combine both ideas. When there is communication between a
> program and the clipd, upon exiting the program, if the contents of the
> clipboard are large, tell the user "Contents of clipboard too large to
> maintain when program exits. Your clipboard will be cleared. Are you
> sure you want to continue?". This could be best for the user.
The user should not know. The user has no business, nor does he likely
care, to know such details of implementation. The user needs to copy and
paste and have it work clearly and consistently.
> Similar ideas have been implemented in Windows (think multiclipboard,
> back in the day), the way there were extensions on the Mac to allow the
> clipboard to do more, and more recently, late versions of the CorelDRAW
> suite. Upon exit, they ask if you want to keep the contents of the
> clipboard available.
Windows supports content negotiation while the clipboard owner is alive,
and copies the default data type to a central clipboard when the owner
exits. This is ideal in no way whatsoever. It's worth pointing out that
Microsoft themselves found this so bad that they had to re-implement the
clipboard in Office. This is not the way we do things. Once again,
prompting the user about a detail such as that is counterintuitive.
--
Jerry Haltom <wasabi larvalstage net>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]