Re: crosscompiling installing js bits

[<pl...@pi...>]

On 04/25/12 17:31, sfeam (Ethan Merritt) wrote:
> On Wednesday, 25 April 2012, pl...@pi... wrote:
>> On 04/25/12 10:24, pl...@pi... wrote:
>>> On 04/24/12 23:47, Ethan A Merritt wrote:
>>>>
>>>> In general it would be great if there were a way to translate the
>>>> coordinate output formats (dates or otherwise) from gnuplot's own
>>>> C-like format to something usable in javascript so that the svg
>>>> and canvas terminals could use it.  But I failed to find any such
>>>> C ->    javascript conversion library that could be linked to for
>>>> this purpose.
>>>>
>>>
>>> Perhaps the current default is not the most logical choice. I would have
>>> thought that what has been chosen for the graph would be the obvious
>>> default for the label and the live coord read out , both in interactive
>>> and js context.
>>>
>>> In this case I have
>>> set timefmt  "%H:%M:%S"
>>> set format x "%02Hh%02M"
>>>
>>> Now timefmt is what is required by the *input* data , not the graph
>>> output. Never the less this is what is provided with an integer arg of 3
>>>
>>> Similarly an argument of 5 will get me a simple hh:mm format which  may
>>> or may not be the same as my displayed x coord. In this case not.
>>>
>>> help states:
>>>
>>>     The following formats are available:
>>>
>>>      0   default (same as 1)
>>>      1   axis coordinates                    1.23, 2.45
>
> You're looking at the help for mouse formats, right?
> I'm afraid that whole section of the documentation applies
> only to the gnuplot mouse code itself (in mouse.c), not to
> anything that happens outside the program.  So basically
> only to the old interactive terminals (windows, x11, wxt, pm,
> not sure about qt). And it may be out of date even for those
> terminals.

I'm comparing this to wxt. mouse coords in wxt are the same within the 
proviso that both 5 and 3 do the same in js.

All comments about defaults apply to both.

>
>>> This is wrong. Neither 0 nor 1 display what I have on the axis
>>> coordinates . In fact if I select "1" I get a decidedly unhelpful
>>> 15032.4 instead of a legible time coord.
>
> At a guess, that is indeed the axis coordinate (time in seconds).
>
Yup, a lousy default.

>> PS
>>
>> I've just tested this and the svg js is always producing hh:mm:ss
>> output. ie option 3 is that same as option 5 .
>>
>> 5 on interactive produces a short time format  like 3:18 or 21:50
>> 5 on js term give output like 04:21:52
>>
>> Presumably fixing the bug I noted in last msg will catch this too.
>
> No. The js time code knows nothing about format options inside
> gnuplot.  That's where this thread started.


gnuplot is feeding something that is determined by the set mouse format 
options. I've done it this morning, it does make a difference.

I understand that the long time format is drawn from the system running 
the viewer (browser in this case) not run system running gnuplot, where 
that is different.

I can see that timefmt is not transmitted to the js code and it would 
maybe load js code too much to start parsing that in js.


   This means that 5 is effectively the same as 3. Perhaps a note in 
help could clarify the limitations.

Also I found the help quite hard to follow at first since there is no 
explicit declaration of the syntax nor example for the integer form of 
the command.  I think that needs to be clearer.

Also an error in the last eg.
   7   format from `set mouse mouseformat`, e.g. "mouse x,y = 1.23, 
2.450"


Best regards, Peter.




The js code uses
> whatever format is provided by the javascript interpreter's
> Date() module.  The only control currently built into the
> gnuplot terminals (canvas, svg) is to toggle Date/Time/both.
>
> Gnuplot's time/date code is IMHO a creaky relic of an earlier era.
> I am reluctant to touch the code, and I try not to use it for
> plotting.  In that regard I am fortunate in having to deal
> with time data only rarely.
>
> The mouse coordinate-tracking code is also showing its age.
> It used to be that the small number of terminal drivers that
> offered mousing (windows, x11, pm) all used the same support
> routine in the core gnuplot code.   That is no longer true;
> some of the interactive terminals contain separate code for
> "-persist" mode, and the offline terminals like canvas and svg
> rely on self-contained javascript support.
>
> So the intersection (tracking time coords while mousing)
> is a particular weak spot.  Any suggestions of how to improve
> this are welcome.  An improved system need not necessarily
> replicate the current hodge-podge.
>
> 	Ethan
>
>>
>>
>> Peter.
>