Re: Follow up about X clipboard
- From: Pat Suwalski <pat suwalski net>
- To: Jerry Haltom <wasabi larvalstage net>
- Cc: desktop-devel-list gnome org
- Subject: Re: Follow up about X clipboard
- Date: Sun, 25 Apr 2004 16:42:49 -0400
I'll keep it short-ish...
Jerry Haltom wrote:
1. Non-deterministic shutdown of applications is confusing.
The basis for this argument is that when a user closes the last window
of an application, they expect that process to terminate... as in no
longer be running. The main problem I see with this argument is that
users today have absolutely no concept of what a "process" is anyways.
I disagree. I would say that easily 75% of windows users know what a
process is. Not necessarily by name, maybe by "that thing I have to kill
in the task manager." There will be regular users who use the gnome
system monitor and wonder why the program is still running.
2. Non-deterministic shutdown leaves possibly broken applications
running with no option in the GUI to terminate them.
Good one! After an application closes all it's windows, and frees all
memory required for them (or whatever), it enters a sort of daemon
state, where it keeps running until it no longer owns the clipboard.
I still think it's unreasonable to keep the process going. I see a
better solution as passing off responsibility to the clipd and making
translators smart enough to know how to handle that, what to do.
Something that leaves absolutely no doubt that the copying program was
closed.
3. Some applications are big. It makes no sense to keep them running in
the background forever.
Yes it does. The user has indicated he WANTS to copy (make available
later) a certain amount of data. This means the system is obligated to
either not offer him this feature, or preserve the data in some fashion.
This is just plain wrong. If I mean to hit Ctrl-F to search, and
accidentally hit Ctrl-C, I don't want that program there. Also, what if
I copy from this program, paste into another, then close the copying
program? Why the hell should it stay running in RAM?
> 4. Why don't we just inform the user the clipboard or an amount of
> clipboard data will be lost when he closes a window?
>
> This is directly involving the user in a decision involving a deficiency
> in the implementation. The user does not know what "data types" are. The
I disagree with this wholehartedly. Not only is it extremely clean on
the back-end of things, but it keeps the user informed. There is no
shame in saying that if you close this app from which you copied, you
will not be able to paste into other apps. There are just so many
programs that do that across all platforms. And it makes sense to any
user who gives it half-a-thought. "I closed this window, so where will
my computer keep my copy? I hope it's not on the internet where it could
pick up a virus..."
6. Long running applications with a non-deterministic shutdown provide
more points for fault.
Of course. Any ability we add to anything provides a fault point. I'd
like to believe, based on the other points 1-5 mentioned above, that
such fault points are not as disastrous as they are made out to be.
It's been brought up. Yes, it matters. Say the process is eating 99%
CPU. This is consistent behaviour from soemthing like Adobe's Acrobat
Viewer. The last thing I want with this program is that it disappears
into a spot where I can't easily close it from. That so totally
overrules extended clipboard functionality.
8. Why not implement some sort of Clipboard Daemon (clipd) which has the
logic available to it, either through plug-ins or natively to transform
the data from one type to another.
Consideration of the size of future/present data sets. Linux/Unix today
doesn't have any good examples of widespread software such as
audio/movie editing. However, the ability for this type of data to work
with the system must be addressed. This type of data is generally LARGE.
Again, here's my POV on this. If there's a session-wide clipd, to which
a program can hand (1) its copied data (by reference, until killed), (2)
a group of translators, and then the main program can die, that seems
like a good solution. Magic would still have to happen with large files.
9. Translator framework like BeOS?
I don't know enough about this idea to really totally understand it...
but I will try.
This is the coolest thing I've heard here so far. It doesn't even need a
whole new clipboard semantic. This would be cool to have with the
existing clipboard if implemented somewhere between the GTK and X levels.
My four cents.
--Pat
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]