<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Anybody checked the project gclipboard ?<br>
a global solution crossworking with X.<br>
<br>
<a class="moz-txt-link-freetext" href="http://opencjk.org/projects/gclipboard/index.html">http://opencjk.org/projects/gclipboard/index.html</a><br>
<br>
<blockquote type="cite" cite="mid200501011530.59941.l.lunak@suse.cz">
  <pre wrap="">Dne pá 31. prosince 2004 4:22 Philip Van Hoof napsal(a):
  </pre>
  <blockquote type="cite">
    <pre wrap="">On Thu, 2004-12-30 at 18:11 -0800, John Davidorff Pell wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">On 30 Dec 2004, at 17:12, Philip Van Hoof wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">On Thu, 2004-12-30 at 16:03 -0800, John Davidorff Pell wrote:
        </pre>
        <blockquote type="cite">
          <pre wrap="">btw. History could be added by having some application catch all
changes to whichever clipboard it is listening to and storing it,
which  is what your clipboard manager would do anyway.
          </pre>
        </blockquote>
        <pre wrap="">I mentioned keeping histories. My exact words where that it could be an
option in the form of a plugin for that clipboard manager. As a matter
of fact there are a few applications today doing this for you. One
example is Klipper. Many people use Klipper. Others don't. Therefor
keeping clipboard history isn't going to be the main purpose.

Making it easy for applications like Klipper to pop/push and query this
history would be delegated to such a plugin.
        </pre>
      </blockquote>
      <pre wrap="">If the X server kept track of the contents of the clipboard, then
klipper would continue to work exactly as it does today, no changes
necessary. :-)
      </pre>
    </blockquote>
    <pre wrap="">yes, however. At this moment are applications like Klipper (gcm) using
hacks and tricks to do the task for which they are designed. I'd be
better if they didn't have to perform hacks and tricks to get the job
done.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
 I think these days no hacks or tricks are needed anymore (indeed, that means 
only 'really needed' - there are enough broken apps that just don't happen to 
cooperate nicely without hacks and tricks). XFixes can give notifications 
about clipboard changes. There are proposals for notifying about apps owning 
the clipboard quiting, for limiting the size of the transfers, there are 
mimetypes.

 Which again makes me wonder what exactly you'd like to fix and how. I 
personally find your list of problems and your proposal too vague.

  </pre>
  <blockquote type="cite">
    <pre wrap="">I've e-mailed with the author of Klipper (Aaron Seigo).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
 This must be a misunderstanding. I doubt Aaron Seigo has even touched 
internals of Klipper, let alone being its author. The original author of 
Klipper is Andrew Stanley-Jones, Carsten Pfeiffer used to be the maintainer 
until recently, and Esben Mose Hansen is the current maintainer 
(<a class="moz-txt-link-freetext" href="http://webcvs.kde.org/kdebase/klipper/toplevel.cpp?rev=1.168&view=markup">http://webcvs.kde.org/kdebase/klipper/toplevel.cpp?rev=1.168&amp;view=markup</a> - 
search for 'createAboutData'). I'm actually not sure how much these people 
know about the underlying X details, because they're shielded by the 
high-level QClipboard API. The person fixing the underlying X details usually 
happens to be me.


  </pre>
</blockquote>
<br>
</body>
</html>