Re: [Usability]clipboard manager comments

[Philip Van Hoof <spamfrommailing freax org>]

On Fri, 2002-10-11 at 02:22, Maciej Stachowiak wrote:
> On 09Oct2002 04:13PM (-0400), Havoc Pennington wrote:
 
> The Mac doesn't come with any kind of program for viewing the
> clipboard contents, and no one seems to particularly want one. The
> main things that make cut and paste work better on the Mac are:
> 
> 1) If you copy something and quit the app you copied from, the data
> does not get lost.

This can only be solved using a process that stores a copy of the data.
I am not sure if it is technically possible to only store this data if
an application that ownes the selectionownership exits. Afaik you must
'always' store the copy and claim the selection yourselve if you are
such a process. This is exactly what GNOME Clipboard Manager does by the
way. You can already have his functionality using GNOME Clipboard
Manager by setting the max amount of collected items in the preferences
to 1. Maybe it would be a better solution to use a nonGUI deamon to get
and store these selections.. and eventually a GUI that communicates with
the nonGUI deamon to Manage it. However, if I was going to program this
GUI then I would still use Gtk libraries.. the X libraries for doing
clipboard stuff are not very easy imho. (So, actually, once the
mainwindow of GNOME Clipboard Manager is hidden the application could be
used as the deamon). I am investigating possibilities on this subject.


> 2) Cut and paste of data types besides plain text (rich text, images,
> etc) actually works and is usable between multiple apps.
> These are the important problems to solve.

[CUT]

The problem here is not to be solved by an application like GNOME
Clipboard Manager. It should be solved by the application that uses the
clipboard and sets the clipboard (a.k.a. converting and receiving the
selection and claiming ownership of the selection). Also documentation
about what these application can deliver and standards should be made.
For example .. one application (Mozilla) uses Unicode for the text/html
target and another application uses UTF-8 and ... and because of such
issues NONE applications can use the text/html target. Try copypasting
stuff from Mozilla to OpenOffice.org. It is possible and it would be
very easy for OpenOffice.org to implement; but they are not doing it?
The reason why this works good on the Microsoft platform is that
Microsoft ownes all the Office applications and can use his own
protocols and standards.

Copypasting data from Microsoft Access to Microsoft Excell works
perfectly. It is not normal that we (the OpenSource community) sit here
and do 'the talking about the problem' because we have the handicap that
we must agree on standards AND implement them.

ps. It are features like I described here that office-users want. Yes,
that means copypasting 30.000 rows of data from a database frontend to
Gnummeric and then save it as an HTML-email. That is exactly what they
want. And if GNOME, Red-Hat, Mandrake and other distrubutions want
office-users to start using their desktop environment then they will
have to fix these issues and make 'that' possible.

ps. And each time I tell about this, hundreds of whining people tell me
that the selection-protocol of X was never designed to transfer such
amounts of data between applications. Well my opinion is : then change
the design of X. The ofice-users need it, period.

ps. Because I do not belive that a short term solution will be achieved
I started writing my own (stupid) solution. One of my ideas is to write
plugins for my application that convert targetdata to other targetdata
right after the application fetches the targetdata. For example convert
text/html to text/richtext and the OpenOffice.org XML-formatted
targetformats. The basesystem for loading plugins and a working
sampleplugin is already finished and available in the gcm-2 module in
CVS. I am also going to write networking support (sending clipboards to
another host running GNOME Clipboard Manager) using such plugins. So
don't worry : GNOME Clipboard Manager will not be bloated ;). But the
plugins will make it possible to bloat the application




-- 
Philip Van Hoof