gnuplot-beta

Re: [ gnuplot-Bugs-1420675 ] x11 CPU usage proportional to plot window size

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 01 February 2006 12:36 pm, Petr Mikulik wrote:

> Yes, that's amazing that gnuplot on X11 can save every
> drawing as a screenshot into the clipboard. Actually it
> looks rather like an undocumented feature.

Now if someone could only tell me what this is good for...

How can a screenshot be extracted from the clipboard to use
elsewhere?  Why would you want to do this rather than 
generating a *.png image directly from gnuplot?

> What about having this as a 'set term x11' option instead of
> .Xdefaults? Editing this file is not what a normal user
> wants to (can) do.

But ~/.Xdefaults is exactly where individual users are
supposed to configure their preferences.  It's where you
set your favorite fonts, window placement,  color schemes,
are everything else that might be shared among your 
various X11 applications.  If you were to add parsing code
in 'set term x11 ...' for every relevant X resource, it would
be an endless task.

In recent generations of window managers, including both
KDE and gnome, this has been to some degree superseded
by "theming".  But the .Xdefaults mechanism is still need for
applications that are not fully integrated into whatever fancy
desktop you run.  We don't have a KDE-specific "knuplot"
variant that would take these settings from the KDE theme
instead. 

> Considering clipboard and KDE, the bug that "MB1"
> double-click doesn't save mouse coordinate into clipboard
> has not yet been fixed.

It works for me.   
 - double click MB1 in plot window
 - move mouse to editor or other control window
 - click middle mouse button
   -> saved mouse coordinates appear in input character stream

This is independent of  the "gnuplot*exportselection: on/off"
setting.  If the exportselection is "on", the at the same time the
mouse coords are put into the clipboard, then also the plot itself
is  exported.  Exporting the whole plot on each click seems like
bad idea to me, but anyhow that's what it is doing right now.

So what exactly is the bug?
If you want to know why that same string doesn't also appear
in klipper's history list - that I don't know.

	Ethan



> Priority: 5
> Submitted By: Kevin Hobbs (gargon_the_rat)
> Assigned to: Ethan Merritt (sfeam)
> Summary: x11 CPU usage proportional to plot window size
>
> Initial Comment:
> I've noticed that CPU usage increases when I make a
> gnuplot window large. Usage stays high even without
> interaction with the plot.
>
> The process that's doing the actual work seems to be X.
> When I look at the output of top I see that X isn't
> even on the list until I open a plot window. When I
> open the plot window X jumps to 10%. If I make the
> window small X drops off again, if I make the window
> large X usage goes up as high as 50%. ( There is
> another high usage process. )
>
> The gnuplot is today's cvs configured with:
> ./configure --prefix=/opt/gnuplot-cvs/
> --enable-history-file --with-x --with-readline=gnu
>
> the machine is
> uname -a
> Linux gargon.hooperlab 2.6.14-1.1656_FC4 #1 Thu Jan 5
> 22:13:55 EST 2006 x86_64 x86_64 x86_64 GNU/Linux
>
> ---------------------------------------------------------------------
>-
>
> >Comment By: Petr Mikulik (mikulik)
>
> Date: 2006-02-01 20:36
>
> Message:
> Logged In: YES
> user_id=31505
>
>
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2006-02-01 20:35
>
> Message:
> Logged In: YES
> user_id=235620
>
> Added to cvs.
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2006-02-01 16:58
>
> Message:
> Logged In: YES
> user_id=235620
>
> gnuplot*ctrlq:  on
> This changes the "magic character that closes plot windows"
> from 'q' to '<control>q'.  I will add an explanation to the
> documentation.
>
> As to the clipboard documentation - sorry, I do not really
> understand it myself.  Why would you want a plot on the
> clipboard?  What would you do with it once it is there?
> These are all mysteries to me.  I see from the comments that
> Lars had a hand in that code. Perhaps he can explain what it
> is intended to accomplish.
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Petr Mikulik (mikulik)
> Date: 2006-02-01 15:38
>
> Message:
> Logged In: YES
> user_id=31505
>
> Thanks for fixing this! One my slower computer suffered from
> this last week...
>
> I just looked into 'help x11 other_resources', and
> - It writes
>       gnuplot*ctrlq:  off
>   but there is no word what "ctrlq" means. Someone knows and
> can it complete?
>
> - "By default the contents of the current plot window are
> exported to the X11 clipboard in response to X events in the
> window." -- this sentence is not clear for normal users. At
> least I don't understand it properly. What does it want to
> say? "By default snapshot of the current plot window is
> copied to the X11 clipboard as a bitmap (?? what
> resolution??) if/when ... ???"
> Could you please rewrite this section?
>
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Kevin Hobbs (gargon_the_rat)
> Date: 2006-02-01 14:56
>
> Message:
> Logged In: YES
> user_id=1064206
>
> I applied your patch and rebuilt gnuplot.  I re-enabled
> klipper. I made a plot with the new gnuplot, and made it
> really big. CPU usage drops back down a few seconds after
> the resize. As far as I'm concerned the patch worked.
>
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2006-02-01 07:24
>
> Message:
> Logged In: YES
> user_id=235620
>
> And now that I have a system which can be made to exhibit
> this problem....
>
> Very strange behaviour.  Gnuplot_x11 says "I want to export
> a plot".  Klipper goes into a loop, saying "Give me the
> pixels; give me the colormap" over and over again until you
> manually clear the clipboard.  I have no idea why it does
> this, but anyhow the attached patch limits gnuplot_x11 to
> sending one copy each of the pixmap and colormap before
> taking itself off the selection list.
>
> Please test and report any problems.  And if you don't ever
> want plots on the clipboard in the first place, use the
> .Xdefaults file as shown in the previous comment.
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2006-01-31 19:39
>
> Message:
> Logged In: YES
> user_id=235620
>
> Right. Then the following should fix your problem
> temporarily
>
>   echo "gnuplot*exportselection:  off" | xrdb -merge
>
> And the permanent fix is to add a line to your ~/.Xdefaults file
>
>   gnuplot*exportselection:  off
>
>
> What this has to do with KDE's kicker is a mystery to me.
> The connection to klipper is obvious, but it should only
> trigger on a mouse click.  That might point to a bug of some
> sort in gnuplot_x11, or it might be a weird problem in
> kicker+klipper.
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Kevin Hobbs (gargon_the_rat)
> Date: 2006-01-31 18:17
>
> Message:
> Logged In: YES
> user_id=1064206
>
> I am running KDE.  Now that you mention it, I see that
> kicker is also acting up.  Bug #1225866 mentioned Klipper (
> I hate the thing ) I looked in Klipper and I see several
> pictures of my plot.  If I disable Klipper the crazy usage ends.
>
> I do think itmay be worth a cross post to KDE... I never
> would have figured it out on my own.
>
> ---------------------------------------------------------------------
>-
>
> Comment By: Ethan Merritt (sfeam)
> Date: 2006-01-31 17:21
>
> Message:
> Logged In: YES
> user_id=235620
>
> Something similar has been reported a couple of times, but
> so far as I recall it has turned out to be a problem or bug
> in shell usage (#930426) or in the window manager (#1225866)
> rather than in gnuplot per se.
>
> Having said that, there must still be something in
> gnuplot_x11 that triggers this badness, but I don't know what.
>
> Please report what window manager you are using, and other
> possibly relevant details like mouse focus policy,
> iconification settings, and anything else you can think of.
>
> If you are running KDE, please check CPU usage by "kicker".
> That was the culprit in at least one previous report, and
> now that I check my brand-spanking-new system running KDE
> 3.4.2 I see that kicker is indeed eating unreasonable
> amounts of CPU time while gnuplot_x11 is running. I wonder
> if it's worth a bug report or query to the KDE project?
>
> The only other thing I can think of to check on is font
> usage.  I have occasionally seen other apps cause X11 to
> chew through CPU cycles if they use a font that is found in
> an obsolete font cache.
>
> ---------------------------------------------------------------------
>-
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1420675&
>group_id=2055

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: [ gnuplot-Bugs-1420675 ] x11 CPU usage proportional to plot window size

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 01 February 2006 02:10 pm, Ethan Merritt wrote:
> It works for me.
>  - double click MB1 in plot window
>  - move mouse to editor or other control window
>  - click middle mouse button
>    -> saved mouse coordinates appear in input character stream
>
> This is independent of  the "gnuplot*exportselection: on/off"
> setting.

I spoke too soon.  There does seem to be an interaction between
exportselection and the mouse coordinate saving.

> If you want to know why that same string doesn't also appear
> in klipper's history list - that I don't know.

The documentation for klipper states that the button in the
connfiguration menu marked
   o Synchronize contents of the clipboard and the selection
will cause all clipboard events to appear in klipper's selection
history.  It doesn't. 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

clipboard & klipper in X11 terminal

[<tim...@en...>]

Interesting entry today on the blog of one of the klipper developpers :

http://www.kdedevelopers.org/blog/280
title =3D "why klipper is good"

Basically he describes how the clipboard works in X since the early ages
and how klipper manages to handle a history of clipboard contents.
He explains why there can be so much copies of a bitmap in klipper. The
problem may appear in gnuplot, but it is also a problem of openoffive
and mozilla.
Indeed gnuplot is quoted as a problematic app here :

http://bugs.kde.org/show_bug.cgi?id=3D101087

The proposed solution is to set TIMESTAMP. I don't know much more
unfortunately. Details here :
http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
And by the way he implemented a workaround for apps that don't set
TIMESTAMP which will be included in kde 3.5.2

Best regards,

Timoth=E9e Lecomte

Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Another detail from http://tronche.com/gui/x/icccm/sec-2.html
(official convention document for interprocess communication between X
applications)

_____________________________
2.1. Acquiring Selection Ownership
A client wishing to acquire ownership of a particular selection should
call SetSelectionOwner, which is defined as follows:

SetSelectionOwner selection :     ATOM
owner :     WINDOW or None
time :     TIMESTAMP or CurrentTime

The client should set the specified selection to the atom that
represents the selection, set the specified owner to some window that
the client created, and set the specified time to some time between the
current last-change time of the selection concerned and the current
server time. This time value usually will be obtained from the timestamp
of the event that triggers the acquisition of the selection. Clients
should not set the time value to CurrentTime , because if they do so,
they have no way of finding when they gained ownership of the selection.
Clients must use a window they created so that requestors can route
events to the owner of the selection.2

Convention

    Clients attempting to acquire a selection must set the time value of
the SetSelectionOwner request to the timestamp of the event triggering
the acquisition attempt, not to CurrentTime . A zero-length append to a
property is a way to obtain a timestamp for this purpose; the timestamp
is in the corresponding PropertyNotify event.

If the time in the SetSelectionOwner request is in the future relative
to the server's current time or is in the past relative to the last time
the specified selection changed hands, the SetSelectionOwner request
appears to the client to succeed, but ownership is not actually
transferred.
_____________________

Guess what ? We are using CurrentTime in the x11 terminal...

Timoth=E9e

Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Thursday 02 February 2006 06:20 am, Timoth=E9e Lecomte wrote:
> Interesting entry today on the blog of one of the klipper developpers
>
> http://www.kdedevelopers.org/blog/280
> title =3D "why klipper is good"
>
> Basically he describes how the clipboard works in X since the early
> ages and how klipper manages to handle a history of clipboard
> contents. He explains why there can be so much copies of a bitmap in
> klipper.=20

Thank you for pointing this out.
I will have to read that and the related links carefully when
I next have some free time.

> Indeed gnuplot is quoted as a problematic app here :
> http://bugs.kde.org/show_bug.cgi?id=3D101087
> The proposed solution is to set TIMESTAMP.=20

I will explore setting XA_TIMESTAMP as an explicit target,
but I am dubious that this will fix anything by itself.

You later quote the following with regard to TIMESTAMP:
  "Clients should not set the time value to CurrentTime"
As you point out, we are using CurrentTime in gnuplot_x11.

It is hard for me to understand what sense it makes to call
something a "timestamp" if it does not, in fact, contain the
current time.

However,....
I don't think this is the problem.  The failure mode described in
the section you quote is that the client [gnuplot_x11 in this case]
may not properly obtain ownership.  That is not what I see happening.
We gain ownership just fine.  The problem is that if we do not
explicitly *relinquish* ownership, then klipper keeps sending
its requests over and over again.  I think this cannot be correct
behaviour by klipper.  It should request once, and only [maybe]
request again if the first request fails.

> I don't know much more unfortunately. Details here :
> http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
> And by the way he implemented a workaround for apps that don't set
> TIMESTAMP which will be included in kde 3.5.2

Meanwhile, I have updated gplt_x11.c in CVS to separately request
export of either the mouse coordinate string or the pixmap+colormap,
but not both at the same time.  This seems to make klipper happier,
since it now notices the the string export whereas before it did not.
However, I still find it necessary to explicitly remove gnuplot_x11 from
the selection list after replying once; otherwise klipper loops
ad nauseum.

Update:
A very quick test indicates that even if I set XA_TIMESTAMP as a target,
klipper never requests it.  So I think that diagnosis is wrong.  I=20
tried:

static Atom targets[] =3D { XA_PIXMAP, XA_COLORMAP, XA_TIMESTAMP };
=2E..
XChangeProperty(dpy, reply.xselection.requestor,
                                reply.xselection.property,
                                reply.xselection.target,
                                32, PropModeReplace, targets, 3);
=2E..
            } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
                fprintf(stderr, "TIMESTAMP request\n");

The fprintf never triggers.
Maybe I've done something wrong, but that code fragment is exactly
parallel to the XA_PIXMAP and XA_STRING target code that is already
working.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Ethan Merritt wrote:

> I will explore setting XA_TIMESTAMP as an explicit target,
>
>but I am dubious that this will fix anything by itself.
>
>You later quote the following with regard to TIMESTAMP:
>  "Clients should not set the time value to CurrentTime"
>As you point out, we are using CurrentTime in gnuplot_x11.
>
>It is hard for me to understand what sense it makes to call
>something a "timestamp" if it does not, in fact, contain the
>current time.
>
>However,....
>I don't think this is the problem.  The failure mode described in
>the section you quote is that the client [gnuplot_x11 in this case]
>may not properly obtain ownership.  That is not what I see happening.
>We gain ownership just fine.  The problem is that if we do not
>explicitly *relinquish* ownership, then klipper keeps sending
>its requests over and over again.  I think this cannot be correct
>behaviour by klipper.  It should request once, and only [maybe]
>request again if the first request fails.
> =20
>
Indeed, it may not be the problem.

>Meanwhile, I have updated gplt_x11.c in CVS to separately request
>export of either the mouse coordinate string or the pixmap+colormap,
>but not both at the same time.  This seems to make klipper happier,
>since it now notices the the string export whereas before it did not.
>However, I still find it necessary to explicitly remove gnuplot_x11 from
>the selection list after replying once; otherwise klipper loops
>ad nauseum.
> =20
>
I've just checked current CVS. Results : mouse coordinate appear in
PRIMARY, so that they can be pasted with the third mouse button, and
they appear in klipper. That's good.
The plot graph appears in klipper, but I can't paste it anyway but after
selecting it in klipper. If I don't select it in klipper, or if klipper
is not launched, I have nothing at all to paste ! I've tried with both
kde apps (KolourPaint) and non-kde (Gimp). I'm not sure this is the
expected behaviour ;-)
That's probably because you "remove gnuplot_x11 from the selection
list". As far as I understand, the app is intended to keep the ownership
of the clipboard as long as it provides something in it.

>Update:
>A very quick test indicates that even if I set XA_TIMESTAMP as a target,
>klipper never requests it.  So I think that diagnosis is wrong.  I=20
>tried:
>
>static Atom targets[] =3D { XA_PIXMAP, XA_COLORMAP, XA_TIMESTAMP };
>...
>XChangeProperty(dpy, reply.xselection.requestor,
>                                reply.xselection.property,
>                                reply.xselection.target,
>                                32, PropModeReplace, targets, 3);
>...
>            } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
>                fprintf(stderr, "TIMESTAMP request\n");
>
>The fprintf never triggers.
>Maybe I've done something wrong, but that code fragment is exactly
>parallel to the XA_PIXMAP and XA_STRING target code that is already
>working.
> =20
>
I tried myself, and got it working with the attached diff (against cvs
before your patches).
Basically, I used :
        XA_TIMESTAMP =3D XInternAtom(dpy, "TIMESTAMP", False);
and :
... } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {

        FPRINTF((stderr, "timestamp request from %d : %ld\n",
reply.xselection.requestor, export_time));

        XChangeProperty(dpy, reply.xselection.requestor,
                reply.xselection.property, reply.xselection.target,
                32, PropModeReplace, (unsigned char *) &(export_time), 1)=
;
...

When klipper is launched, the fprintf is regularly triggered, and the
pixmap/colormap cases are just triggered once ! The loop is on the
timestamp case, which was the expected bahaviour according to the docs
in the previous mail.
There's one (small) problem that I don't understand : the first graph
(when it is first plotted) appears twice in klipper, and the
pixmap/colormap cases are triggered twice for this first time.

Hope that will help.

Timoth=E9e

Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Friday 03 February 2006 09:51 am, Timoth=C3=A9e Lecomte wrote:
> The plot graph appears in klipper, but I can't paste it anyway but
> after selecting it in klipper. If I don't select it in klipper, or if
> klipper is not launched, I have nothing at all to paste ! I've tried
> with both kde apps (KolourPaint) and non-kde (Gimp). I'm not sure
> this is the expected behaviour ;-)
> That's probably because you "remove gnuplot_x11 from the selection
> list". As far as I understand, the app is intended to keep the
> ownership of the clipboard as long as it provides something in it.

That does not make much sense to me.
If the original source is still available for selection, then you can
copy-and-paste without going through klipper at all.

Normally if I select something it continues to appear in the klipper
history even after the original app exits.  That way you can paste
things selected earlier in your session, long after the original
place you selected it from is gone.    Isn't that the whole point of
klipper? =20

> I tried myself, and got it working with the attached diff (against
> cvs before your patches).

You are doing better than I am :-)
So your diff is against the cvs version from before 1 Feb 2006?
I'll have a look.

I worry a bit that in changing the code to work with KDE
we may lose compatibility with whatever environment it was
originally written for.  Since I have never used this cut-and-paste
of whole plot image myself, I don't have any historical usage to
compare with.

> There's one (small) problem that I don't understand : the first graph
> (when it is first plotted) appears twice in klipper, and the
> pixmap/colormap cases are triggered twice for this first time.

In following one trail of links from the klipper bug report you sent
earlier, I came across a separate bug report that klipper was
sometimes  triggering selection events from its own selection buffer,
causing double entries.  Perhaps this is an example.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Ethan Merritt wrote:

>On Friday 03 February 2006 09:51 am, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>The plot graph appears in klipper, but I can't paste it anyway but
>>after selecting it in klipper. If I don't select it in klipper, or if
>>klipper is not launched, I have nothing at all to paste ! I've tried
>>with both kde apps (KolourPaint) and non-kde (Gimp). I'm not sure
>>this is the expected behaviour ;-)
>>That's probably because you "remove gnuplot_x11 from the selection
>>list". As far as I understand, the app is intended to keep the
>>ownership of the clipboard as long as it provides something in it.
>>   =20
>>
>
>That does not make much sense to me.
>If the original source is still available for selection, then you can
>copy-and-paste without going through klipper at all.
>
>Normally if I select something it continues to appear in the klipper
>history even after the original app exits.  That way you can paste
>things selected earlier in your session, long after the original
>place you selected it from is gone.    Isn't that the whole point of
>klipper?
> =20
>
Of klipper, yes, but not the point of the clipboard/selection in
general. Klipper stores a copy of each content in the clipboard, so that
it can be used even if the app is not running anymore, but if you don't
have klipper launched, I'm pretty sure you lose everything, unless you
use some tricks that may be implemented in toolkits.
My point is that unless I use klipper I can't get the copied graph. It
is the same with your patches or with my patch or without any of them.
That may be why nobody seemed to know that the x11 terminal has this
feature.
However, there must be a way to make the graph available more directly,
as gtk/wxwidgets/qt are able to do it... With my terminal (which has
problems too with the clipboard by the way) if I copy the graph to the
clipboard, I just have to click on "paste" and it effectively pastes,
even without klipper.

>>I tried myself, and got it working with the attached diff (against
>>cvs before your patches).
>>   =20
>>
>
>You are doing better than I am :-)
>So your diff is against the cvs version from before 1 Feb 2006?
> =20
>
Yes, it is.

>I'll have a look.
>
>I worry a bit that in changing the code to work with KDE
>we may lose compatibility with whatever environment it was
>originally written for.  Since I have never used this cut-and-paste
>of whole plot image myself, I don't have any historical usage to
>compare with.
> =20
>
Me too.
I would say -apart from kde or whatever window manager- we should comply
with ICCCM conventions, explained in the previous links. In particular :

"TIMESTAMP - To avoid some race conditions, it is important that
requestors be able to discover the timestamp the owner used to acquire
ownership. Until and unless the protocol is changed so that a
GetSelectionOwner request returns the timestamp used to acquire
ownership, selection owners must support conversion to TIMESTAMP,
returning the timestamp they used to obtain the selection."

>>There's one (small) problem that I don't understand : the first graph
>>(when it is first plotted) appears twice in klipper, and the
>>pixmap/colormap cases are triggered twice for this first time.
>>   =20
>>
>In following one trail of links from the klipper bug report you sent
>earlier, I came across a separate bug report that klipper was
>sometimes  triggering selection events from its own selection buffer,
>causing double entries.  Perhaps this is an example.
> =20
>
Maybe ! In all cases, it's definitely better than the initial situation
of an unlimited number of copies in klipper !

Best regards,

Timoth=C3=A9e

Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Friday 03 February 2006 11:03 am, Timoth=C3=A9e Lecomte wrote:
> if=20
> you don't have klipper launched, I'm pretty sure you lose everything,=20
> unless you use some tricks that may be implemented in toolkits.

Simple test:

1) open new xterm
2) do something in it
3) select text using   MB1down+drag+MD1up
4) kill xterm window
5) move focus to another xterm or standard x app
6) MB2
    hey presto!  the selected text appears

So it appears to me that the standard X clipboard is persistent,
and the selections remain even after the originating app
has exited.

> I would say -apart from kde or whatever window manager- we should
> comply with ICCCM conventions, explained in the previous links.

Seems like a good idea to comply with standards -
so long as they don't break anything in real life.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Ethan Merritt wrote:

>On Friday 03 February 2006 11:03 am, Timoth=C3=A9e Lecomte wrote:
> =20
>
>>if=20
>>you don't have klipper launched, I'm pretty sure you lose everything,=20
>>unless you use some tricks that may be implemented in toolkits.
>>   =20
>>
>
>Simple test:
>
>1) open new xterm
>2) do something in it
>3) select text using   MB1down+drag+MD1up
>4) kill xterm window
>5) move focus to another xterm or standard x app
>6) MB2
>    hey presto!  the selected text appears
>
>So it appears to me that the standard X clipboard is persistent,
>and the selections remain even after the originating app
>has exited.
> =20
>
Ok !
Other test : open an existing file with kwrite/kate or another kde text
editor, select some text and copy it (ctrl-c), close kwrite/kate =3D> you
can't paste antyhing !
We may conclude that the text selection, known as PRIMARY (intended to
be pasted with MB2) is kept in memory by X, whereas the CLIPBOARD may
not be.
One thing is sure : the clipboard in X is tricky !!!

> =20
>
>>I would say -apart from kde or whatever window manager- we should
>>comply with ICCCM conventions, explained in the previous links.
>>   =20
>>
>
>Seems like a good idea to comply with standards -
>so long as they don't break anything in real life.
> =20
>
Agreed. In this case, I think these are pretty old and common
conventions, dated 1994, and they won't break anything as they consist
of supplying an *additionnal* peace of information.

Best regards,

Timoth=C3=A9e

Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Friday 03 February 2006 12:00 pm, you wrote:
> We may conclude that the text selection, known as PRIMARY (intended
> to be pasted with MB2) is kept in memory by X, whereas the CLIPBOARD
> may not be.

Amazingly enough, this is explained via the Help panel in klipper
itself:
   klipper->Configure->Help->Clipboard/Selection Behavior

> we should comply with ICCCM conventions, 
> explained in the previous links.

I've just had a look at 
   <http://tronche.com/gui/x/icccm/sec-2.html#s-2.6>

It seems to me that klipper is not acting in accordance with
section 2.6.1.3.   As I read the standard, it says that when
"another client" [in this case gnuplot_x11] acquires ownership
of the clipboard, then the "special client" [klipper] is supposed
to request the exported data and then immediately reacquire
ownership for itself.  

This section does talk about synchronizing via the TIMESTAMP,
but it mandates that the special client reacquire ownership
regardless of the success or failure of TIMESTAMP match-up.

klipper is not doing this.  So far as I can tell, gnuplot_x11
retains ownership of the clipboard until either it voluntarily
gives it up [that was my 2 Feb patch] or some 3rd party
application intervenes.

Your patch may indicate that klipper regains ownership properly
only if the TIMESTAMP comparison succeeds, even though section
2.6.1.3 says it should regain ownership in all circumstances.

> I think these are pretty old and common
> conventions, dated 1994, and they won't break anything as they 
> consist of supplying an *additionnal* peace of information.

Agreed. But I think the bug we are working around is in klipper.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: clipboard & klipper in X11 terminal

[<tim...@en...>]

Ethan Merritt a =C3=A9crit :
>> we should comply with ICCCM conventions,=20
>> explained in the previous links.
>>    =20
> I've just had a look at=20
>    <http://tronche.com/gui/x/icccm/sec-2.html#s-2.6>
>
> It seems to me that klipper is not acting in accordance with
> section 2.6.1.3.   As I read the standard, it says that when
> "another client" [in this case gnuplot_x11] acquires ownership
> of the clipboard, then the "special client" [klipper] is supposed
> to request the exported data and then immediately reacquire
> ownership for itself. =20
>
> This section does talk about synchronizing via the TIMESTAMP,
> but it mandates that the special client reacquire ownership
> regardless of the success or failure of TIMESTAMP match-up.
>  =20
> klipper is not doing this.  So far as I can tell, gnuplot_x11
> retains ownership of the clipboard until either it voluntarily
> gives it up [that was my 2 Feb patch] or some 3rd party
> application intervenes.
>  =20
You're right. The first link ( http://www.kdedevelopers.org/blog/280 )=20
explains that klipper used to behave that way, but changed later :
"Another possible solution was to use the fact that the clipboard owner=20
gets notified when it looses the ownership, so Klipper for quite some=20
time also tried to solve the polling this way. Klipper took ownership of=20
the clipboard and whenever it lost it, Klipper immediately asked the new=20
owner about the new text in clipboard and then took ownership again,=20
with this new text. This is not used anymore, Klipper no longer claims=20
clipboard ownership unless explicitly told so, as it causes some=20
trouble. First there's the problem if the clipboard content set by the=20
app is not text then it gets lost, and secondly, such extensive usage of=20
the QClipboard class was a good stress test for it. So good in fact that=20
it had revealed several bugs there that otherwise had gone unnoticed and=20
QClipboard maintainer at TrollTech is even allergic to bugreports about=20
QClipboard and Klipper even if they contain patches (you can find=20
evidence if you grep qclipboard_x11.cpp for klipper :-). There were KDE=20
releases that unfortunately had bad problems because of such bugs."
> Your patch may indicate that klipper regains ownership properly
> only if the TIMESTAMP comparison succeeds, even though section
> 2.6.1.3 says it should regain ownership in all circumstances.
>  =20
Yeah, they may have dropped the best solution for reasons that are not=20
true now, but finally it's not that hard to satisfy klipper needs with=20
"TIMESTAMP"... In any case, your patch seems to work too.

Best regards,

Timoth=C3=A9e

Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Friday 03 February 2006 11:57 am, you wrote:
> Ethan Merritt a =C3=A9crit :
> >> we should comply with ICCCM conventions,
> >> explained in the previous links.
>
> You're right. The first link ( http://www.kdedevelopers.org/blog/280
> ) explains that klipper used to behave that way, but changed later

I see.  So klipper is deliberately not following the standard.
Well, so much for solving problems on our end through strict
standards compliance.

> Yeah, they may have dropped the best solution for reasons that are
> not true now, but finally it's not that hard to satisfy klipper needs
> with "TIMESTAMP"... In any case, your patch seems to work too.

I am afraid it may be messier than that.  The blog entry, and the
other entries it points to, document that klipper has been broken
in different ways in different versions of KDE.  Furthermore it will
change again in 3.5.* and probably break things in new ways.
So I am afraid that nothing we do will fix it for all versions of=20
KDE, and I don't have a clue what similar problems lurk under
Gnome or other desktops.

I have no objection to exporting TIMESTAMP, as in your patch.
But I think we should also keep the limitation of one-copy-per-export
in place, because we already know that failing to do this can
eat up the CPU entirely if the app on the other end is badly
written.

I predict the effect of this will be that if you are running klipper
then the only way to transfer a plot pixmap is through klipper.
Only one copy is allowed, and klipper will ask for it first before
anyone else can. But if you are *not* running klipper, then you
can copy-and-paste that one copy directly to another app.
Since apparently the current (3.4.2) klipper is also broken in
the presence of either Gimp or OOffice, my guess is that many
people using graphics will disable klipper.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

paste graph and coords under X11 (was: Re: [ gnuplot-Bugs-1420675 ] ...)

[Petr M. <mi...@ph...>]

>> Yes, that's amazing that gnuplot on X11 can save every
>> drawing as a screenshot into the clipboard. Actually it
>> looks rather like an undocumented feature.
>
> Now if someone could only tell me what this is good for...

PM and Windows terminals has menu item "copy plot to clipboard" and 
obviously that's how "typical office users" get their images into 
presentations. The trouble of x11 is that it does not have such a menu.

> How can a screenshot be extracted from the clipboard to use
> elsewhere?  Why would you want to do this rather than
> generating a *.png image directly from gnuplot?

Well, I've just tried it ... make "test" in gnuplot's X11 terminal, run 
OpenOffice.org with a presentation, click MB2 ... and your graph is there in 
the size it was on screen! Fast, easy, user friendly and productive! So easy 
even under Linux!

I tried on KDE .. is it the same on other WMs?

Then, it should be noted in the x11 docs -- I think this feature is a good 
publicity for gnuplot (octave, etc.).

>> What about having this as a 'set term x11' option instead of
>> .Xdefaults? Editing this file is not what a normal user
>> wants to (can) do.
>
> But ~/.Xdefaults is exactly where individual users are
> supposed to configure their preferences.

Well, if the bug is fix, this default behaviour is fine with me.

>> Considering clipboard and KDE, the bug that "MB1"
>> double-click doesn't save mouse coordinate into clipboard
>> has not yet been fixed.
>
> It works for me.

Aha, it pastes into non-KDE apps (gvim) but not to KDE apps (kvim).
Strange.

> The documentation for klipper states that the button in the
> connfiguration menu marked
>   o Synchronize contents of the clipboard and the selection
> will cause all clipboard events to appear in klipper's selection
> history.  It doesn't.

Klipper's bug?


---
PM