Re: Follow up about X clipboard

[Thorsten Wilms <t_w_ freenet de>]

On Sun, Apr 25, 2004 at 02:53:53PM -0500, Jerry Haltom wrote:
 
> Furthermore, clipboard data can and should have a timeout. 

No! That would lead to unpredictable behaviour. If any user will 
at only one time notice this mechanism, he will lose his trust on 
the system.
And elsewhere you wrote something like that the user copying something 
means he wants to have that content available at a later time. Nobody 
would say: I want this data available in the clipboard, but only for the 
next 5 minutes.
Sure, after some time it's likely the user has forgotten about clipboard 
content, but any assumption for a timeout will be unsafe!


> 5. Remove copy paste menus totally and use traditional X clipboard.
> There is no problem.

I agree with Jerry here. And I would like to add:
Yes, sure copying images with middle mouse button ...


> 9. Translator framework like BeOS?
> 
> I don't know enough about this idea to really totally understand it...
> but I will try.
> 
> Every application would provide modules to the system that allow its
> internal data representations to be transformed to other formats. These
> modules could run independently from the apps, so that a module could be
> used to hold the clipboard content after an application is closed
> (really closed). Such a framework additionally would allow much greater
> import/export capabilities in all programs.

You're trying to understand by just quoting me (without indicating so)?
Not a big deal, but it's not good style.

> Back to our MP3/WAV example. The system would have plug-ins (in some
> form), such as wav2mp3 and mp32wav. Most likely these plug-ins would be
> installed in some central place such as /usr/share/translators or some
> such. When a user copies from the MP3 program, the actual MP3 data goes
> to the clipd (...)

Actualy I was talking about modules for handling internal representations 
of data, that would be used as parts of the applications, but could be 
used independently. For keeping clipboard after app shutdown, all of 
an application would shudown, only this special module would persist. 
(It could be a seperate process right from start, if that makes any sense.)
Therefor I don't see the translator concept tied to using a clipd.

Maybe transfering missing translators could be part of the content 
negotiation on remote setups. 


> All of this is blissfully ignoring how slow it would be to copy 60MB, or
> 600MB between remote X servers, heck, remote anything. This however goes
> right back to the implementation of a better transport between
> applications. And, these days, with gigabit networking showing up, such
> a scenario might not be as unreasonable for much longer.

But this problem with huge transfers in remote setups is the same, 
no matter if we have persistent clipboard selections and/or translators, 
or have I missed something?


> Here is a little bit of soapbox about how, to me, it feels as if
> applications should be implemented.
> 
> Programs, are servers, essentially. They are servers which provide
> services such as text editing, audio manipulation, email reading. They
> are manifested to the user as UI elements, but they are not purely so.
> The UI component of a program is simply one of the services it provides
> to the user. The UI component of a piece of software does not need to be
> directly tied to the lifetime of the program itself. The lifetime of a
> program should only be tied to how long it's "doing something useful".
> This does not ignore the principle that when a piece of software is not
> doing anything useful, it should terminate to save memory for the
> system. It just extends the definition of "doing something useful" from
> "showing a window" to "providing data to the user". I believe this
> abstraction is genuinely useful.

This idea of programs being servers providing services, with the ui 
being only one of them, is the basis of my translator proposal 
(BeOS translators + splitting apps up into modules(/services)).


---
Thorsten Wilms