gnuplot-beta — Developers and beta testers of new gnuplot code

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> So "settransfer" should be OK by itself.
> However, there is a little more to it...

There was a lot there to read.


> The PostScript Language Reference Manual (3rd Edition) says:
> 
>   Because the effect of the transfer function is device-dependent
>   settransfer should not be used in a page description that is intended
>   to be device-independent.

One would think that the PostScript interpretter would be smart enough to separate the settransfer and possibly remove it.  I guess the assumption is that the interpretter might have its own gamma correction.  Not sure.


> I don't think the setcachedevice restriction is relevant to gnuplot,
> but gnuplot's pattern-fill does use PaintProc in uncolored tiling
> patterns.
> 
> No idea what this means in practice, however.  Perhaps it just means
> that the gamma correction wouldn't affect the color of pattern fill
> areas. That would be no big deal.

I was hoping that the "gsave" isolates the transfer function for the image from that for the rest of the plot.  But I'm not sure if PostScript works that way.

Dan

Re: gnuplot 4.2 and aquaterm

[Daniel F. <boy...@gm...>]

Hi Joe,

Thanks for that, this seems quite strange but probably means I'm  
doing something wrong! I just replaced the old version with the new  
developer version (4.2 rc1) in /usr/local/bin and left my system  
configuration the same too. gnuplot 4.2 rc1 gives out the following  
when started:

set term aqua
          ^
".gnuplot", line 1: unknown or ambiguous terminal type; type just  
'set terminal' for a list

Pretty clear then that my version at least don't know what aqua term  
is! Also, in the 'help set term' documentation aqua is not listed as  
an option.

I pulled it from cvs, the actually version of is:
$Revision: 1.16 $, dated $Date: 2006/09/10 10:43:50 $.

I'm running MacOS 10.4.8 with XCode 2.4 on a 1.5Ghz G4 PPC.

Regards,

Daniel.


On 12 Oct 2006, at 17:06, Joe Koski wrote:

> on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote:
>
>> Hello,
>>
>> I have recently need to apply a patch to gnuplot to add some
>> functionality. I applied it to the developer version of gnuplot
>> (4.2). However, it seem that the aqua terminal is not an option for
>> this version. Do you have any advice? Should I apply the patch to the
>> current release version instead? Or are there some compile options
>> that I can turn on to make it available?
>>
>> Regards,
>>
>> Daniel.
>>
> Daniel,
>
> AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X  
> 10.4.8 and
> Xcode-2.4 developer tools. I did nothing more than my old  
> configuration for
> gnuplot-4.0 to build it. All my old gnuplot and octave routines work
> properly with AquaTerm.
>
> The only issue that I have with AquaTerm is that octave now passes  
> figure
> numbers via the gnuplot command line, not with set term. This means  
> that all
> figures are Figure 0 for octave/gnuplot/aqua, which can become  
> confusing
> when several windows are open. The wxt terminal will have the same  
> issue.
>
> Joe
>
>

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

On Thursday 12 October 2006 09:12 am, Daniel J Sebald wrote:
> > "settransfer" is Level 2 PostScript, so your patch needs to
> > check the "level1" flag and/or check for support dynamically.
>
> I thought I read "settransfer" is Level 1 and "setcolortransfer" is
> Level 2. 

You are correct.
I had not realized there was a distinction between them.  

So "settransfer" should be OK by itself.
However, there is a little more to it...
The PostScript Language Reference Manual (3rd Edition) says:

  Because the effect of the transfer function is device-dependent
  settransfer should not be used in a page description that is intended
  to be device-independent. Execution of this operator is not permitted
  in certain circumstances; see Section 4.8.1,  Types of Color Space. 

Section 4.8.1 is rather long, but the relevant bit seems to be:

  In certain circumstances, it is illegal to invoke operators that
  specify colors or other color-related parameters in the graphics
  state. This restriction occurs when defining graphical figures whose
  colors are to be specified separately each time they are used.
  Specifically, the restriction applies: 
  * After execution of setcachedevice or setcachedevice2 in a
    BuildGlyph, BuildChar, or CharStrings procedure of a font dictionary
  * In the PaintProc procedure of an uncolored tiling pattern

I don't think the setcachedevice restriction is relevant to gnuplot,
but gnuplot's pattern-fill does use PaintProc in uncolored tiling
patterns.

No idea what this means in practice, however.  Perhaps it just means
that the gamma correction wouldn't affect the color of pattern fill
areas. That would be no big deal.

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

Re: gnuplot 4.2 and aquaterm

[Joe K. <jko...@co...>]

on 10/12/06 9:01 AM, Daniel Farrell at boy...@gm... wrote:

> Hello,
> 
> I have recently need to apply a patch to gnuplot to add some
> functionality. I applied it to the developer version of gnuplot
> (4.2). However, it seem that the aqua terminal is not an option for
> this version. Do you have any advice? Should I apply the patch to the
> current release version instead? Or are there some compile options
> that I can turn on to make it available?
> 
> Regards,
> 
> Daniel.
> 
Daniel,

AquaTerm works with gnuplot-4.2.rc1 on my G5 Mac built with OS X 10.4.8 and
Xcode-2.4 developer tools. I did nothing more than my old configuration for
gnuplot-4.0 to build it. All my old gnuplot and octave routines work
properly with AquaTerm.

The only issue that I have with AquaTerm is that octave now passes figure
numbers via the gnuplot command line, not with set term. This means that all
figures are Figure 0 for octave/gnuplot/aqua, which can become confusing
when several windows are open. The wxt terminal will have the same issue.

Joe

gnuplot 4.2 and aquaterm

[Daniel F. <boy...@gm...>]

Hello,

I have recently need to apply a patch to gnuplot to add some  
functionality. I applied it to the developer version of gnuplot  
(4.2). However, it seem that the aqua terminal is not an option for  
this version. Do you have any advice? Should I apply the patch to the  
current release version instead? Or are there some compile options  
that I can turn on to make it available?

Regards,

Daniel.

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

On Wednesday 11 October 2006 11:42 pm, Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> The Adobe book indicates that gamma correction can be implemented 
> with what is called a transfer function (the second level of color mapping).  
> So, as an alternative, I simply added a line before the image definition 
> 
> if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
>     fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);

"settransfer" is Level 2 PostScript, so your patch needs to be check the
"level1" flag and/or check for support dynamically.








> 
> What this does is create the line below:
> 
>   gsave
>   {1.0 0.2 div exp} settransfer
>   875 4740 translate
>   4959 -4240 scale
>   100 10 8
>   [ 100 0 0 10 0 0 ]
>   currentfile /ASCII85Decode filter
>   image
> 
> I'll send you the patch separately so that you may place it on SourceForge.  [Would it be possible to change SF to allow attaching to someone else's bug report?]  Let me know if that works.
> 
> I'm guessing that transfer functions could be widened in scope.  So if you'd like to use a transfer function somehow rather than /pm3dGamma, let me know.
> 
> Dan
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> OK.  I'll have to consult the book to see images can use PostScript's
> gamma feature.  In the mean time, I've put a patch on SourceForge
> with the pow(gray,1.0/gamma) which seems to work.

Petr,

The Adobe book indicates that gamma correction can be implemented with what is called a transfer function (the second level of color mapping).  So, as an alternative, I simply added a line before the image definition (and a little extra cleanup):

if (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY)
    fprintf(gppsfile, "%s{1.0 %g div exp} settransfer\n", space, sm_palette.gamma);

What this does is create the line below:

  gsave
  {1.0 0.2 div exp} settransfer
  875 4740 translate
  4959 -4240 scale
  100 10 8
  [ 100 0 0 10 0 0 ]
  currentfile /ASCII85Decode filter
  image

I'll send you the patch separately so that you may place it on SourceForge.  [Would it be possible to change SF to allow attaching to someone else's bug report?]  Let me know if that works.

I'm guessing that transfer functions could be widened in scope.  So if you'd like to use a transfer function somehow rather than /pm3dGamma, let me know.

Dan

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote:
> 
>>I have just filled in the enclosed bug (announced to me by another
>>gnuplot user) ... could someone figure out an appropriate "filter"
>>for the postscript "image" operator so that the gamma correction
>>works also for "with image" as it works for "with pm3d"?
> 
> 
> Shouldn't the gamma be a per-image correction rather than something
> to do with the current palette?  I would have thought that the
> gamma correction belongs in the routine that reads in the data.
> That makes it terminal-independent.

Well, I was just writing a reply and wondering that myself:

....

Hmm, well let's see.  I think one of these is preferred over the other, but not sure which.  With (2), would that mean cb2gray() is altered in some way?  Or is there another function that would be applied?  E.g., gray2gamma(cb2gray()).  Don't know... I think conceptually we'd like to keep our data non-tranformed.

I kind of like the way "test palette" behaves.  That is a really powerful tool in a way.  I'm thinking to avoid (2).  Agreed?

...

Let me point out something else I've noticed.  Using "test palette", the gamma correction looks different between X11 and PostScript.  Or at least it looks that way to me.  The reason I say that is because in the X11 output I can't see the "0" within the black area, but I can see "0" within the black area in the PostScript file.

Dan

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> Hmm, well let's see.  I think one of these is preferred over the 
>> other, but not sure which.  With (2), would that mean cb2gray() is 
>> altered in some way?
> 
> 
> no, you would call pow(gray, 1.0/gamma) before writing each pixel to the 
> file.
> 
>> gray2gamma(cb2gray()).  Don't know... I think conceptually we'd like 
>> to keep our data non-tranformed.
>> I kind of like the way "test palette" behaves.  That is a really 
>> powerful tool in a way.  I'm thinking to avoid (2).  Agreed?
> 
> 
> Yes.

OK.  I'll have to consult the book to see images can use PostScript's gamma feature.  In the mean time, I've put a patch on SourceForge with the pow(gray,1.0/gamma) which seems to work.

Dan

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

> Hmm, well let's see.  I think one of these is preferred over the other, but 
> not sure which.  With (2), would that mean cb2gray() is altered in some way?

no, you would call pow(gray, 1.0/gamma) before writing each pixel to the 
file.

> gray2gamma(cb2gray()).  Don't know... I think conceptually we'd like to keep 
> our data non-tranformed.
> I kind of like the way "test palette" behaves.  That is a really powerful 
> tool in a way.  I'm thinking to avoid (2).  Agreed?

Yes.

> Let me point out something else I've noticed.  Using "test palette", the 
> gamma correction looks different between X11 and PostScript.  Or at least it 
> looks that way to me.  The reason I say that is because in the X11 output I 
> can't see the "0" within the black area, but I can see "0" within the black 
> area in the PostScript file.

For me, they look pretty similar. (On the other hand, for publications, I 
like to change gamma...)

BTW, there was a bug in 'test palette' which I've just fixed.

---
PM

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>>On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote:
>>
>>>I have just filled in the enclosed bug (announced to me by another
>>>gnuplot user) ... could someone figure out an appropriate "filter"
>>>for the postscript "image" operator so that the gamma correction
>>>works also for "with image" as it works for "with pm3d"?
>>
>>Shouldn't the gamma be a per-image correction rather than something
>>to do with the current palette?
> 
> 
> Yes, it is; palette is updated (changed, written to ps file, ...) before 
> each plot
> 
> 
>>I would have thought that the gamma correction belongs in the routine that 
>>reads in the data. That makes it terminal-independent.
> 
> 
> No, it is for displaying, as all "set palette" properties. There, postscript 
> is the only terminal that avoids calling cb2color because it implements this 
> function by postscript primitives, so it should do it for "palette gray 
> gamma" as well.

Well, this may be the reason that PostScript looks different to me.  On your treminals please try the following and look at all the output:

set palette gray gamma 1.5
test palette
set term png
set output 'foo.png'
test palette
set output
set term postscript eps
set output 'foo.eps'
test palette
set output

I see that the PostScript gamma implementation is slightly lighter near the "0" in the colorbox.

I also see that the PNG output does not have the colorbox lined up with the axis borders as do the X11 and PostScript outputs.

Dan

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

> On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote:
>> I have just filled in the enclosed bug (announced to me by another
>> gnuplot user) ... could someone figure out an appropriate "filter"
>> for the postscript "image" operator so that the gamma correction
>> works also for "with image" as it works for "with pm3d"?
>
> Shouldn't the gamma be a per-image correction rather than something
> to do with the current palette?

Yes, it is; palette is updated (changed, written to ps file, ...) before 
each plot

> I would have thought that the gamma correction belongs in the routine that 
> reads in the data. That makes it terminal-independent.

No, it is for displaying, as all "set palette" properties. There, postscript 
is the only terminal that avoids calling cb2color because it implements this 
function by postscript primitives, so it should do it for "palette gray 
gamma" as well.

---
PM

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

On Wednesday 11 October 2006 10:07 am, Petr Mikulik wrote:
> I have just filled in the enclosed bug (announced to me by another
> gnuplot user) ... could someone figure out an appropriate "filter"
> for the postscript "image" operator so that the gamma correction
> works also for "with image" as it works for "with pm3d"?

Shouldn't the gamma be a per-image correction rather than something
to do with the current palette?  I would have thought that the
gamma correction belongs in the routine that reads in the data.
That makes it terminal-independent.




>
> Thanks, Petr
>
> ---------- Forwarded message ----------
> Subject: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for
> postscript output
>
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1575425&
>group_id=2055 Summary: "with image" ignores gamma for postscript
> output
>
> Initial Comment:
> Setting of "palette gray gamma <g>" is ignored for
> "with image" output into a postscript file (it is ok
> for "with pm3d"). The following script demonstrates this:
>
> set table "t.dat"; splot x; unset table
> reset
>
> set autoscale fix
> set palette gray gamma 0.2
>
> plot "t.dat" with image
> #set term post color eps "Helvetica" 25
> set term post mono eps "Helvetica" 25
> set output  "t.eps"
> replot
> set out; set term pop
>
> ---------------------------------------------------------------------
>---- Using Tomcat but need to do more? Need to support web services,
> security? Get stuff done quickly with pre-integrated technology to
> make your job easier Download IBM WebSphere Application Server
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121
>642 _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

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

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

>> I'm guessing that the gamma correction is part of the palette created
>> in the PostScript file and the image code is not using the palette.
>> I'll investigate.  May not be a quick fix.
>
> Actually the fix might not be too bad.  Here is the issue:

Yes, gamma plays a role only for the gray palette (not for colour palette).

> I would like to keep the images condensed if possible.  Is there a way to 
> tell if the grayscale is linear from within post.trm?
> Or should I write a short little routine to verify it is?

It is when "pm3dGamma != 1.0/1.5", so just one "if" is sufficient.

Actually, there are two possibilities:

(1) apply the gamma by a ps code: then there should be a bit advanced filter 
when reading the image -- something like that in pm3dConvertToImageGray.awk

(2) apply the gamma when post.trm is writing the image numbers into the 
postscript file, and ignore pm3dGamma within the ps file

The case (2) seems very easy to to code, but maybe you find a solution to 
(1).

---
PM

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> I'm guessing that the gamma correction is part of the palette created
> in the PostScript file and the image code is not using the palette.
> I'll investigate.  May not be a quick fix.

Actually the fix might not be too bad.  Here is the issue:

    /* Color and gray scale images do not need a palette and can use
     * the 5 operand form of the image routine.
     */
    if ((color_mode == IC_RGB) || (sm_palette.colorMode == SMPAL_COLOR_MODE_GRAY) || !ps_params->color)
        five_operand_image = TRUE;
    else
        five_operand_image = FALSE;

I would like to keep the images condensed if possible.  Is there a way to tell if the grayscale is linear from within post.trm?  Or should I write a short little routine to verify it is?

I never new the default grayscale palette had gamma=1.5.  Well, now I do.

Dan

Re: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
> I have just filled in the enclosed bug (announced to me by another gnuplot 
> user) ... could someone figure out an appropriate "filter" for the 
> postscript "image" operator so that the gamma correction works also for 
> "with image" as it works for "with pm3d"?

I'm slowly losing fondness for the Greek letter gamma.  :-)

I'm guessing that the gamma correction is part of the palette created in the PostScript file and the image code is not using the palette.  I'll investigate.  May not be a quick fix.

Dan

[ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript output (fwd)

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

I have just filled in the enclosed bug (announced to me by another gnuplot 
user) ... could someone figure out an appropriate "filter" for the 
postscript "image" operator so that the gamma correction works also for 
"with image" as it works for "with pm3d"?

Thanks, Petr

---------- Forwarded message ----------
Subject: [ gnuplot-Bugs-1575425 ] "with image" ignores gamma for postscript
     output

https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1575425&group_id=2055
Summary: "with image" ignores gamma for postscript output

Initial Comment:
Setting of "palette gray gamma <g>" is ignored for
"with image" output into a postscript file (it is ok
for "with pm3d"). The following script demonstrates this:

set table "t.dat"; splot x; unset table
reset

set autoscale fix
set palette gray gamma 0.2

plot "t.dat" with image
#set term post color eps "Helvetica" 25
set term post mono eps "Helvetica" 25
set output  "t.eps"
replot
set out; set term pop

Re: Date/Time (xrange) wont work

[Nibbler <rea...@ho...>]

Thank you Dan.
Now the values of x-range work perfectly.


Daniel J Sebald wrote:
> 
> Nibbler wrote:
> 
>> I have tried to do like this, 
>> set xdata time
>> set format x "%Y/%m/%d/%H:%M"
>> set timefmt "%Y/%m/%d/%H:%M:%S"
> 
> Think in terms of the C scanf() function, I guess.  Maybe try:
> 
> set timefmt "%Y-%m-%d %H:%M:%S"
> 
> where the dash and white space match exactly what you have in the file.
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 

-- 
View this message in context: http://www.nabble.com/Date-Time-%28xrange%29-wont-work-tf2414481.html#a6750777
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 10/10/06 3:23 PM, Ethan Merritt at merritt@u.washington.edu wrote:

> On Tuesday 10 October 2006 02:04 pm, Joe Koski wrote:
>> 
>> On a Mac, as with X11, one window at a time has, what I think X11
>> calls focus, i. e., only one window is interactive at a time. The wxt
>> window refuses to become an interactive window, and you can't drag it
>> around the screen with the cursor on the border like you can other
>> windows.
> 
> ???   That last bit is really strange.  "Focus" controls where the
> input event go.  If you type on the keyboard, who is listening?
> If you click the mouse, who gets first chance to respond?
> 
When you have not selected a particular window, the Mac "Finder" is what you
are interacting with. There are keyboard shortcuts you can use, and you
always have your pull down menus at the top of the screen, the dock at the
bottom of the screen, the trash, etc. All of these remain fully functional
with the wxt window on the screen. You just can't select the wxt window and
do anything with it (or drag it).

> But dragging the window around the screen does not require the
> window to have focus; it is handled by the window manager / desktop,
> not by the program controlling the window.
> 
> Can you use 'top' or 'ps' to see if the process controlling the
> wxt window is burning CPU cycles?  Note that if it's a thread,
> you may have to give extra options on the command line:
> ps auxm

When you look at gnuplot while executing a script with top in another shell,
you see a burst of gnuplot cpu usage to near 100 per cent (full use of one
processor) for a brief time on my 2 cpu machine, then cpu usage falls to 0.2
per cent, and remains there while the wxt window is open. There is no big,
churning 100 per cent process when gnuplot is just paused for display. While
I was composing this, gnuplot continued to use 0.2 per cent of the cpu, and
accumulated a few seconds of cpu time over several minutes of real time.

When you enter ps auxm in another terminal shell while a wxt window is open,
you see what I captured in the attached text file. To my untrained eye, it
doesn't look like anything is wasting a large percentage of cpu cycles there
either.

In the past, I have also looked at the crash logs, and didn't see clues
there either.

I hope this helps, but I don't think so. My totally uneducated guess would
be that something is wrong with the initial wxwidget calls that set up the
wxt window with the Mac Finder. It's strange that everything else seems to
be working, including pm3d.

Joe

Re: Building wxt terminal for OS X

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

On Tuesday 10 October 2006 02:04 pm, Joe Koski wrote:
>
> On a Mac, as with X11, one window at a time has, what I think X11
> calls focus, i. e., only one window is interactive at a time. The wxt
> window refuses to become an interactive window, and you can't drag it
> around the screen with the cursor on the border like you can other
> windows.

???   That last bit is really strange.  "Focus" controls where the
input event go.  If you type on the keyboard, who is listening?
If you click the mouse, who gets first chance to respond?

But dragging the window around the screen does not require the
window to have focus; it is handled by the window manager / desktop,
not by the program controlling the window.

Can you use 'top' or 'ps' to see if the process controlling the
wxt window is burning CPU cycles?  Note that if it's a thread,
you may have to give extra options on the command line:
	ps auxm

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

Re: Building wxt terminal for OS X

[Joe K. <jko...@co...>]

on 10/10/06 3:33 AM, Timoth=E9e Lecomte at tim...@en... wrote:

> Joe Koski wrote:
>> on 10/9/06 2:07 PM, Timoth=E9e Lecomte at tim...@en... wrote:
>>=20
>>  =20
>>> Joe Koski wrote:
>>>    =20
>>>> on 10/8/06 2:54 PM, Timoth=E9e Lecomte at tim...@en... wrote:
>>>>=20
>>>>  =20
>>>>      =20
>>>>> Hi Joe !
>>>>>=20
>>>>> I'm sorry you did not succeed, but those errors are normal: wxWidgets
>>>>> comes in different flavours depending on the platform: wxGTK (as Etha=
n
>>>>> told you), wxMSW for Windows, wxMAC which you logically installed, an=
d
>>>>> others. There are a couple of places where it is necessary to choose
>>>>> between two possible behaviours (two threads or one) in the terminal
>>>>> code. Since I only have access to Linux (wxGTK) and Windows (wxMSW), =
I
>>>>> have chosen to enable the compilation for those two only.
>>>>>=20
>>>>> However, attached is a patch that enables the compilation for wxMAC. =
I
>>>>> will be very glad to see you try it. Apply it in src/wxterminal and t=
ry
>>>>> to build again. Hopefully it will work. Don't hesitate to report any
>>>>> issue.
>>>>>=20
>>>>> Thank you very much for your efforts.
>>>>>=20
>>>>> Best regards,
>>>>>=20
>>>>> Timoth=E9e
>>>>>    =20
>>>>>        =20
>>>> Timoth=E9e,
>>>>=20
>>>> I applied the patch, borrowed fontconfig from X11 with an export
>>>> PKG_CONFIG_PATH, and successfully built gnuplot-4.2.rc1 with a wxt
>>>> terminal.
>>>> (I'll send you a screen shot separately.)
>>>>=20
>>>> To test, I started gnuplot, set term wxt, and did a plot [-4:4] sin(x)=
 to
>>>> see what would happen.
>>>>  =20
>>>>      =20
>>> The plot is rendered properly, that's a good point !
>>>=20
>>>    =20
>>>> I got the plot, but I could not get "focus" or whatever you call it fo=
r the
>>>> plot window. When I placed the cursor in the plot window area, all I g=
et
>>>> was
>>>> a twirling icon telling me to wait. This happens any time the cursor
>>>> crosses
>>>> the wxt window.
>>>>      =20
>>> Do you mean that the plot window is just like dead ? Is the cursor
>>> position updated in the status bar for example ?
>>> If it's the case, there is probably an issue with the GUI loop running
>>> in a separate thread.
>>>=20
>>>    =20
>> Timoth=E9e,
>>=20
>> I realized after I sent the message I should have been more clear on thi=
s
>> point. Clicking inside the window does not get the focus, and the bar at=
 the
>> top is always grayed out as it is in the screen shot that I sent you. Yo=
ur
>> question about the screen being "dead" is a good description.
> I'm not familiar at all with MacOS. Is it a behaviour that you've
> already observed in other situations ? (with X11, when the application
> is dead, the screen is no longer updated and you get gray surfaces when
> you drag another app on top of the dead one, for example)
>=20
Timoth=E9e,

Any time you drag the cursor across the wxt window, it changes from an arro=
w
pointer into a twirling color "pinwheel." Note that the red, yellow and
green lights at the upper left of the wxt window are gray, an indication
that the window is not active.

Typically you see this behavior on the Mac when an application is hung, and
you have to use "force quit" to exit the application. "Force quit" is
probably the UNIX kill command with a nice gui. For wxt, the behavior is a
different. The terminal.app window where the the interaction with gnuplot
occurs, is still usable, and as soon as you exit gnuplot, the wxt window
also disappears, as it should. This is not like any behavior I have observe=
d
with X11 on a Mac, but only about 10 percent of what I do is in X11, and
those interactions are with well debugged applications.

On a Mac, as with X11, one window at a time has, what I think X11 calls
focus, i. e., only one window is interactive at a time. The wxt window
refuses to become an interactive window, and you can't drag it around the
screen with the cursor on the border like you can other windows.

>=20
>> The cursor
>> position at the lower left is frozen as it shows in the screen shot, and
>> does not change when you move the cursor.
>>=20
>> I have done a bit more testing. I can get octave-2.9.9 to open wxt windo=
ws,
>> and display plots,
>=20
> Can you display several plots successively ? That would be another
> argument in favor of the dead gui thread, because the plot rendering is
> done in the main thread.
>=20

Yes, several plots will stack up, but the only way to see the lower levels
is to use Apple Expos=E9, which is a quick way (press F9) of displaying
miniatures of all open windows, so you can click on the one to bring to the
front. Each wxt plot window comes forward as it should for viewing.

>> which is good, but it doesn't display legend information
>> that displays in both X11 and AquaTerm.
> Do you mean the mouse cursor position as above ?
No, this is an additional problem that the legend text describing the lines
is not displayed on the plot (usually upper right). This is a problem for
later, and may be cured when we fix the other problems anyway.

>=20
> Thanks, best regards,
>=20
> Timoth=E9e

This is getting wordy. Perhaps we should take this discussion off-list unti=
l
we have something significant to report. I should be available for trying
things for the next few weeks. I'm an old Fortran programmer who uses octav=
e
and gnuplot for data analysis, so I can't be too helpful with C or C++
issues. Are there any questions that I should be asking of the wxwidgets
folks? Let me know.

Joe

Re: How to automaticaly label points in gnuplot ?

[<br...@ph...>]

Fabien Salvignol wrote:

> I wonder if it is possible to set labels automaticaly in gnuplot
> Is it possible to label, in a function curve, indiquating a column where the 
> point's names are ?

I'm afraid whatever you were trying to ask was lost in translation from 
French thought to English sentence.  You'll have to restate the question
more clearly.

Until then, I think you should get the 4.2 release candidate and see 
whether the new data-strings feature might be what you're looking for.

Re: Date/Time (xrange) wont work

[Daniel J S. <dan...@ie...>]

Nibbler wrote:

> I have tried to do like this, 
> set xdata time
> set format x "%Y/%m/%d/%H:%M"
> set timefmt "%Y/%m/%d/%H:%M:%S"

Think in terms of the C scanf() function, I guess.  Maybe try:

set timefmt "%Y-%m-%d %H:%M:%S"

where the dash and white space match exactly what you have in the file.

Dan

Re: Date/Time (xrange) wont work

[<br...@ph...>]

Nibbler wrote:
> Hi.
> 
> I would like to set date/time in the x-range.
> My date/time is like this: 2006-10-05 10:30:05.
> How I should set timefmt so the gnuplot would understand the the time
> format? 

Such that it matches your actual data, of course!

> set timefmt "%Y/%m/%d\t%H:%M:%S"

This rather obviously doesn't.  What made you put / in your format, 
whereas your data clearly has '-'?

Re: Problem with pause -1 ?

[<br...@ph...>]

Ethan A Merritt wrote:

> You cannot control the execution of a script using 'pause -1'.

Actually, you can.  But you have to run it as a script for that to work, 
not as redirected stdin.  There's a difference between

	gnuplot file
and
	gnuplot < file

which is why we run

	gnuplot all.dem </dev/null

to shoot through all the demo plots without interaction.