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

Re: Character encodings in PostScript driver

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

On Thursday 16 September 2004 02:43 am, Hans-Bernhard Broeker wrote:
> > The chief benefit from this is that new encodings could be
> > added without patching or rebuilding gnuplot from source;
> > you would just have to place an appropriately named file
> > in the path specified by some environmental variable,
> > e.g. GNUPLOT_PSFILES.
>
> The only problem I have with this is that we're slowly developing
> a rather huge and inconsistently named zoo of environment variables.
> I think before we add new ones, we should try to find a way of
> organizing them, and reducing their number.

That's a fair criticism.  But some of these environmental variables are
forced upon us by the support libraries, or by other operating system
components.  For example GDFONTPATH is required directly by libgd.
GNUPLOT_FONTPATH is our choice, but we really don't have much 
control over where the host operating system keeps its fonts.
What we certainly could do, however, is to revise the naming scheme
so that all environmental variables chosen by gnuplot itself begin with
a consistent string (GNUPLOT_ ).  For backward compatibility
we would have to create new names parallel to 
GNUTERMPATH GNUCOLORS GNUHELP FITSCRIPT GNUFITLOG

Hmm. That's not as long a list as I expected. 

> In particular, I think we really
> do need a mechanism that will provide defaults for all gnuplot path
> environment variables that are relative to the gnuplot Aexecutable's
> location, like GCC does it: it searches {bindir}/../include for headers,
> {bindir}/../lib for libraries, and so on, where {bindir} is whatever
> directory the GCC executable you're running found itself to sit.

That's fine with me, but it won't actually change many of the current
choices because most of them either (a) refer to directories used by
other system components or (b) require write access by the current user.

Re: Small bug in post.trm

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

On Thursday 16 September 2004 05:18 am, Harald Harders wrote:
> Could someone delete line 3006 in post.trm,
>
> 	printf("hallo1\n");

done

Small bug in post.trm

[Harald H. <h.h...@tu...>]

Could someone delete line 3006 in post.trm,

=09printf("hallo1\n");

please? It seems to be an old debug line of me.

Thanks,
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: Character encodings in PostScript driver

[Hans-Bernhard B. <br...@ph...>]

On Wed, 15 Sep 2004, Ethan Merritt wrote:

> They are all perfectly legitimate, but I think it is totally
> unreasonable that any substantial fraction of them get hard-coded into
> gnuplot's PostScript terminal driver.

My feelings about this issue aren't quite that strong, but in general I
agree with this.

> The chief benefit from this is that new encodings could be 
> added without patching or rebuilding gnuplot from source;
> you would just have to place an appropriately named file
> in the path specified by some environmental variable,
> e.g. GNUPLOT_PSFILES.

The only problem I have with this is that we're slowly developing
a rather huge and inconsistently named zoo of environment variables.
I think before we add new ones, we should try to find a way of
organizing them, and reducing their number.

> I don't really have much sympathy with limiting gnuplot's options just
> because Windows is poorly designed.

OTOH, Windows users do form a serious share of the user base, and they
would complain rather loudly, and with some justification, too, if we just
broke Windows deliberately.  We have to at least make a serious effort to
support Windows to the extent possible.  In particular, I think we really
do need a mechanism that will provide defaults for all gnuplot path
environment variables that are relative to the gnuplot Aexecutable's
location, like GCC does it: it searches {bindir}/../include for headers,
{bindir}/../lib for libraries, and so on, where {bindir} is whatever
directory the GCC executable you're running found itself to sit.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Character encodings in PostScript driver

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

There are 50+ character encodings currently registered for use
on the internet <http://www.iana.org/assignments/character-sets>
and I have no idea how many more that are not so registered.
They are all perfectly legitimate, but I think it is totally unreasonable
that any substantial fraction of them get hard-coded into gnuplot's
PostScript terminal driver.

I propose that we back out all of the in-line character encodings
from post.trm, and instead have a general mechanism of loading
any requested encoding from an external file.  If you recall, I
coded up a simple patch to do this in the run-up to version 4
because it was needed in order to reduce the total size of 
the terminal driver to the point it could be built for 16-bit DOS/Win.

The idea was dropped when we decided it was OK to
abandon 16-bit support altogether, but I still think it's a good
idea and deserves to be revisited.

The chief benefit from this is that new encodings could be 
added without patching or rebuilding gnuplot from source;
you would just have to place an appropriately named file
in the path specified by some environmental variable,
e.g. GNUPLOT_PSFILES.

As I recall, the only real objection at the time was a fear that
these external files containing the character encoding info
would get lost under Windows because there is no standard
directory in which to put such things.  I don't really have much
sympathy with limiting gnuplot's options just because Windows
is poorly designed.  

Are there other objections in addition to that one?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Tcl/Tk demo cleanup and bugs

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

I've shaken the bugs out of the Tcl/Tk "demo demo" and updated the=20
patch.  The main problem was that the Tcl/Tk "open" was directing=20
gnuplot's output to stdout.  That caused the buffer to fill up, and then =

the program froze.  Another problem was that the fontfile.dem and=20
fontfile_latex.dem files would change the terminal to something other=20
than x11 and break in the middle before they could restore the terminal=20
via "pop".  Hence gnuplot terminal was stuck in "post" such that it=20
appears as though the program was hung because the x11 window would no=20
longer be drawn to... easy fix.

Inside the "reread.bor" file I changed

replot
reread

to

replot
pause -1 "Hit return to continue"
if (bb!=3D0) reread;

That way, the 'border.dem' demo behaves like all others in that it plots =

16 different border styles in response to a keyboard hit and then stops.

I added "borders.dem", "charset.dem" and "vector.dem" to "all.dem".

=3D=3D=3D=3D=3D=3D=3D=3D

Here is a bug in current CVS I added to SourceForge:  There is a demo 've=
ctor.dem' in the /demo subdirectory.  I seems to run fine.  However, it f=
ails after running the demo 'pm3dcolors.dem' and type 'reset' in between =
doesn't fix things.  The following error occurs.

splot vtot(x,y) w l
                            ^
         "vector.dem", line 60: `using` with 4 parameters but surface wit=
hout `pm3d` or `palette`

And I believe I can pinpoint this error, for someone else to fix.  Below =
is the section of code from plot3d.c causing the problem.  Notice that th=
e portion of code issuing the error follows the if/else statement.  One o=
f the variables in the conditional test is df_no_use_specs.  But df_no_us=
e_specs is a variable associated with datafile.c and is only set when df_=
open() is called.  Now look at the "splot" command above and notice that =
it is a function, not a data file.  Hence, the demo "pm3dcolors.dem" sets=
 the value of df_no_using_specs to 4.  Then when the vector.dem demo is r=
un, df_no_use_specs is 4, it is unaffected by reset and it never gets set=
 to something else because df_open() never gets called.  A quick solution=
 is to put "   df_no_use_specs =3D 0;" right after the /* function to plo=
t */ else bracket... or if someone knows how to determine the number of c=
olumns of data from the function, that is even better.



	    if (isstring(c_token)) {	/* data file to plot */
<snip>
		specs =3D df_open(MAXDATACOLS, MODE_SPLOT);
<snip>
	    } else {		/* function to plot */
<snip>
	    }			/* end of IS THIS A FILE OR A FUNC block */

<snip>

#ifdef PM3D
	    if (df_no_use_specs=3D=3D4 &&
		!(this_plot->lp_properties.use_palette ||
		  pm3d.where[0] || this_plot->pm3d_where[0] || this_plot->plot_style & =
PM3DSURFACE))
		int_error(c_token, "`using` with 4 parameters but surface without `pm3d=
` or `palette`");
#endif

Re: Run in an X window - Feature request.

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

-------- Original Message --------
Subject: Re: Run in an X window - Feature request.
Date: Mon, 13 Sep 2004 15:46:17 -0500
From: Daniel J Sebald <dan...@ie...>
To: merritt@u.washington.edu
References: <109...@rg...> 
<200409131017.55301.merritt@u.washington.edu> 
<414...@ie...> <200409131151.28968.merritt@u.washington.edu>



Ethan Merritt wrote:

>Sorry,  I don't understand this at all, but I don't have time to look
>into it any further right now.  Why should the plot not have an id number 
>just because it went into a specified X window?  I don't see what
>the two things have to do with each other.

Well, that is the question I raised.  How should this behave?  I 
certainly could have programmed it either way.  I wasn't certain which 
way would be better at the time, but now I'm feeling that not attaching 
the XID to a plot number is better.  (Still not completely sure of that, 
however.)

I guess this boils down to the following:  Should there be multiple ways 
to access the same plot window, i.e., either via # or via XID?  Or, should 
there be only one way to access a window?  My gut tells me the latter is 
better.  I could be convinced otherwise.

Dan

Re: Run in an X window - Feature request.

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

Ethan Merritt wrote:

>On Monday 13 September 2004 10:21 am, Daniel J Sebald wrote:
>  
>
>>For developers' sake, the change isn't too drastic.  The one conceptual 
>>change is that I moved the code that keeps track of the "most recent 
>>plot number" to inside gnuplot_x11.c instead of x11.trm.  (You see, if 
>>x11.trm keeps setting the number every time it does a plot, then the 
>>non-numbered plots lose the "current_plot" status.
>>    
>>
>
>What is a "non-numbered plot"?
>

A non-numbered plot is one for which the command

 > set term x11 window <XID>

is given.  When the feature come to the list, I raised the question of 
whether the XID should be associated with a numbered plot.  Dave 
suggested it didn't have to be.  I agreed and programmed it that way.

There are two things in a plot array in gplt_x11.c, the plot number and 
the window ID.  The list of plots can be searched for either element. 
 So conceptually, one should think of two "banks of plots"--those with 
numbers, those with window IDs.

>Surely if x11 is processing a "replot" command, this needs to go to
>the last window that x11.trm itself knew about.  What else could it mean?
>I don't see how gnuplot_x11 can know this better than x11.trm itself.
>

It is the same difference, so long as the link between the two isn't broken.

>>I see no reason for 
>>x11 to change "current_plot" except during a "set term x11" command... 
>>

"current_plot" is a variable inside gplt_x11.c.  The equivalent inside 
x11.trm is "X11_plot_number".

But the current CVS does just what you say it shouldn't.  Inside 
X11_graphics(), which I believe is called for all plots, is

    PRINT2("G%d %lu\n", X11_plot_number, windowid);

which changes the plot in the case where I had just issued, say,

 > set term x11 window '200002e'

First, I altered the PRINT2() above so that the plot number isn't part 
of the G command.  And one's response would be, so that should be 
enough.  Yes, but when I did this I thought "why shouldn't gnuplot_x11 
be keeping track of the most recent plot number in the case where it 
can't find the current plot number in the linked-list (because it was 
deleted) and it must create a new plot?"  Before gnuplot_x11 would just 
create a plot with number zero.

In other words, the addition of a "most_recent_plot_number" is a small 
addition to gplt_x11.c, and I think it takes care of the problem.  Look 
at it another way.  If what you are saying above is true, that x11 
should change the plot number only when there is a "set term x11 #" 
command, why should x11.trm keep track of the plot number?

If the case arises that some more sophisticated organization is needed. 
 Say, gnuplot keeps track of the plot commands for every open window and 
can switch back and forth between them, then x11 can certainly override 
gnuplot_x11.c.

Dan

Re: Run in an X window - Feature request.

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

On Monday 13 September 2004 10:21 am, Daniel J Sebald wrote:
> 
> For developers' sake, the change isn't too drastic.  The one conceptual 
> change is that I moved the code that keeps track of the "most recent 
> plot number" to inside gnuplot_x11.c instead of x11.trm.  (You see, if 
> x11.trm keeps setting the number every time it does a plot, then the 
> non-numbered plots lose the "current_plot" status.

What is a "non-numbered plot"?
Surely if x11 is processing a "replot" command, this needs to go to
the last window that x11.trm itself knew about.  What else could it mean?
I don't see how gnuplot_x11 can know this better than x11.trm itself.

> I see no reason for 
> x11 to change "current_plot" except during a "set term x11" command... 

I don't see "current_plot" anywhere in x11.trm.  Could you please mention
specific lines of code, or give the actual variable name?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Run in an X window - Feature request.

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

Donald Burns wrote:

>Do you think your patch will make it into
>the mainstream gnuplot release?
>  
>

It needs to be tested by others for syntax and behavior.  Plus this is 
one of those things where I'd like to confirm that non-numbered windows 
are properly cleaned up if the outside app closes the window.  (So far, 
it seems to do so.)

For developers' sake, the change isn't too drastic.  The one conceptual 
change is that I moved the code that keeps track of the "most recent 
plot number" to inside gnuplot_x11.c instead of x11.trm.  (You see, if 
x11.trm keeps setting the number every time it does a plot, then the 
non-numbered plots lose the "current_plot" status.  I see no reason for 
x11 to change "current_plot" except during a "set term x11" command... 
 unless of course gnuplot_x11 stops and needs to be restarted, but I've 
not seen that happen for a while.  Anyway, some control logic could be 
put inside x11.trm in addition.  It's just that I think it isn't necessary.)

Dan

Re: Shredded X11 coordinate text bug

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

On Monday 13 September 2004 08:55 am, Daniel J Sebald wrote:
> >>>>I believe I can duplicate the shredded coordinate text now. 
> Anyway, I was certain this just started happening out of the blue.  I
> just went back and confirmed that this doesn't happen in 4.0.
>
> Trying to think back a few months, hold on.  There was a change in the
> animation behavior, then after that I see some list entries regarding
> "Mouse coord lag (Re: An observation in animate demo.)" around 6/15.
>  That sounds about right to me.  The kinds of discussion that seemed to
> be going on within that thread were:
>
> That may be a good place to start.

I am not seeing this behaviour, perhaps because I run my X servers
with "BackingStore: on".  In any case, I agree with a suggestion made
already that the answer is probably to force a complete re-draw whenever
there is an expose event.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: Shredded X11 coordinate text bug

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

Dave Denholm wrote:

>Harald Harders <h.h...@tu...> writes:
>
>  
>
>>On Mon, 13 Sep 2004, Hans-Bernhard Broeker wrote:
>>
>>    
>>
>>>On Mon, 13 Sep 2004, Daniel J Sebald wrote:
>>>
>>>      
>>>
>>>>I believe I can duplicate the shredded coordinate text now.  (Finally!!)
>>>>        
>>>>
>>>[...]
>>>      
>>>
>>I have got the same problem. I am using the window manager icewm under
>>Linux. In many cases, the x11 windows starts at a position that the
>>coordinates are hidden behind the start menu. If I than move up the
>>gnuplot-x11 window, the numbers get shredded. It seems that it is the same
>>problem which Hans-Bernhard has described. Shouldn't the numbers be
>>reprinted without xor at least at every raise of and every click on the
>>window?
>>
>>    
>>
>
>Should be able to ask the XServer to send expose events when bits of
>window become visible after being hidden. That would be a more
>reliable indicator.
>

But in the case of moving the window partially off screen, does X think 
that it isn't visible?

Anyway, I was certain this just started happening out of the blue.  I 
just went back and confirmed that this doesn't happen in 4.0.

Trying to think back a few months, hold on.  There was a change in the 
animation behavior, then after that I see some list entries regarding 
"Mouse coord lag (Re: An observation in animate demo.)" around 6/15. 
 That sounds about right to me.  The kinds of discussion that seemed to 
be going on within that thread were:

*  core change within is the use of XCheckEvent
*    while (XCheckTypedWindowEvent(dpy, event->xany.window, 
ConfigureNotify, event));

That may be a good place to start.

Dan

Re: Run in an X window - Feature request.

[Donald B. <dm...@re...>]

Hi Dan,

Liked the patch and demo a lot and am only sorry I didn't have more time
to spend on the demo myself. Do you think your patch will make it into
the mainstream gnuplot release?

Donald.

Re: breaking out of script

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

Hans-Bernhard Broeker wrote:

>Send a SIGINT to the child?  Send it a literal Ctrl-C character?
>Send it an 'exit' or 'quit' command?
>

Ethan suggested SIGINT.  Those literal characters are treated simply as 
any other character by "pause".  I needed something to break out of the 
current running demo, to start a different demo.

proc loadDemo {x y} {
    global dirName
    global gpfd

    # Send ctrl-C to gnuplot in case a different demo is running.
    exec kill -INT [pid $gpfd]
    set file [file join $dirName [.sel.f.list get @$x,$y]]
    gnuplot "load \"$file\""
}

But thinking about this right now.  I bet there may be an issue with 
timing.  The "kill" command is system level and that doesn't necessarily 
complete before Tcl/Tk stuffs "load \"$file\"" into the pipe.  So, what 
could happen occassionally is the SIGINT happens _after_ some characters 
move through the pipe and the command gets partially destroyed, 
confusing gnuplot.  Hmmm...

Dan

Re: Shredded X11 coordinate text bug

[Dave D. <dde...@es...>]

Harald Harders <h.h...@tu...> writes:

> On Mon, 13 Sep 2004, Hans-Bernhard Broeker wrote:
>
>> On Mon, 13 Sep 2004, Daniel J Sebald wrote:
>>
>> > I believe I can duplicate the shredded coordinate text now.  (Finally!!)
>> [...]
>
> I have got the same problem. I am using the window manager icewm under
> Linux. In many cases, the x11 windows starts at a position that the
> coordinates are hidden behind the start menu. If I than move up the
> gnuplot-x11 window, the numbers get shredded. It seems that it is the same
> problem which Hans-Bernhard has described. Shouldn't the numbers be
> reprinted without xor at least at every raise of and every click on the
> window?
>

Should be able to ask the XServer to send expose events when bits of
window become visible after being hidden. That would be a more
reliable indicator.

(If the X server uses backing store, it may not bother sending them,
since no screen contents are lost)


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: Shredded X11 coordinate text bug

[Harald H. <h.h...@tu...>]

On Mon, 13 Sep 2004, Hans-Bernhard Broeker wrote:

> On Mon, 13 Sep 2004, Daniel J Sebald wrote:
>
> > I believe I can duplicate the shredded coordinate text now.  (Finally!!=
)
> [...]

I have got the same problem. I am using the window manager icewm under
Linux. In many cases, the x11 windows starts at a position that the
coordinates are hidden behind the start menu. If I than move up the
gnuplot-x11 window, the numbers get shredded. It seems that it is the same
problem which Hans-Bernhard has described. Shouldn't the numbers be
reprinted without xor at least at every raise of and every click on the
window?

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: breaking out of script

[Hans-Bernhard B. <br...@ph...>]

On Sun, 12 Sep 2004, Daniel J Sebald wrote:

> I've spruced up the Tcl/Tk demo a bit.  A list box selects the demo to 
> run.  There is the "Next" button that Donald included.  I want to 
> include a "Stop" button for breaking out of the demo.  In other words, I 
> want the "Stop" button to behave as a cntrl-C to gnuplot.  Any idea of 
> how to do that from a non-command-line environment?  I'm guessing that 
> may be system dependent.  Is there an escape character I can send to 
> gnuplot when in pause mode that will stop it executing any script files? 

Send a SIGINT to the child?  Send it a literal Ctrl-C character?
Send it an 'exit' or 'quit' command?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Shredded X11 coordinate text bug

[Hans-Bernhard B. <br...@ph...>]

On Mon, 13 Sep 2004, Daniel J Sebald wrote:

> I believe I can duplicate the shredded coordinate text now.  (Finally!!)
[...]

Hmm... so this would mean that gnuplot doesn't successfully detect all
possible "have to redraw from scratch" situations for the mouse coordinate
output area.  I've seen somewhat similar behaviour on MS Windows, too.  
The problem AFAICS is that we're currently displaying the mouse
coordinates in 'no-flicker' mode, by using XOR based drawing techniques
--- if the content of the window changes for any reason the drawing engine
doesn't know about, that approach breaks.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Shredded X11 coordinate text bug

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

I believe I can duplicate the shredded coordinate text now.  (Finally!!)

1) Create an X11 window of any plot where the mouse is active.

2) Move that plot  window off the bottom of the screen so that the 
coordinate text is no longer seen on the screen.

3) *Let go of the window*

4)  Grab the window again and move it onto the screen so that the 
coordinate text is visible again.

5)  Let go of the window and move the mouse around on the plot.

The text is shredded.  I think I've seen this happen other ways.  This 
started happening about three or four months ago.  If you want to fix 
the coordinate text

6)  Raise another other window on top of the gnuplot plot window and 
then raise the gnuplot plot window to the top again.  That fixes the 
shredded text.

Dan

Re: Run in an X window - Feature request.

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

I've put the patch that allows connecting gnuplot_x11 to an external X 
window up on SourceForge.  In there I've updated Donald's demo with some 
of the tk8.3 demos.  There is a screen capture at

http://acer-access.com/~ds...@ac.../gnuplot/gpdemos.png

The demo is a Tcl/Tk script I placed in the /demo subdirectory called 
"gpdemos.tcl".  It is self-explanatory.

It turned out fairly well, but there are a couple problems with the 
demo.  Some of the demo scripts hang and can't be broken from.  I think 
it has something to do with the pipe/flush communication between the 
Tcl/Tk program and gnuplot.  (What else is new?)  I suspect that because 
before I implemented a clean exit, often when it would hang and I'd quit 
all the queued up demos would first execute in gnuplot/gnuplot_x11 and 
then that would exit.

The other thing is I can't figure out a way in Tcl/Tk to generate a 
frame that does not grab ahold of the mouse button.  Hence, the mouse 
action can't be handed over to gnuplot_x11.

Dan

breaking out of script

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

I've spruced up the Tcl/Tk demo a bit.  A list box selects the demo to 
run.  There is the "Next" button that Donald included.  I want to 
include a "Stop" button for breaking out of the demo.  In other words, I 
want the "Stop" button to behave as a cntrl-C to gnuplot.  Any idea of 
how to do that from a non-command-line environment?  I'm guessing that 
may be system dependent.  Is there an escape character I can send to 
gnuplot when in pause mode that will stop it executing any script files? 
 I've tried sending ESC (0x1b) or CAN (0x18), but I think gnuplot would 
have to be programmed to break upon seeing those characters.  Worth 
patching somehow?

Dan

Re: The external x11 window patch.

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

On Sunday 12 September 2004 10:56 am, Daniel J Sebald wrote:
> The patch for supplying an external X11 window has fallen out of
> discussion.  Should I just put that patch on SourceForge?

Sure.  I have no time to look at it, and consider it of rather low
priority until a specific application comes along begging for it.
At which point I expect the application's author can use a
SourceForge patchset as a starting point to get something that
really does the needed job.  Until that point we would just be
guessing at the details needed.

The external x11 window patch.

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

The patch for supplying an external X11 window has fallen out of 
discussion.  Should I just put that patch on SourceForge?  I think it is 
fairly near a complete usable product, but I expect few conflicts with 
CVS modifications.  I'll see if I can enhance the demo that Donald sent 
to allow selecting, via widget, which demo to run and add that to the 
patch.  (It would be a "demos.trm" file that could be added to the /demo 
subdirectory...  of course, it wouldn't run under Windows so it may 
require some error message if someone attempts to do so.)

Dan

Re: Problem with new binary input code

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> On Sunday 12 September 2004 10:15 am, Daniel J Sebald wrote:
> 
>>Hans-Bernhard Broeker wrote:
>>
>>>Better yet, Someone[^TM] take this as motivation to finally create the
>>>long overdue "properties of a plotting style" data structure.
> 
> 
> 
>>I'm not aware
>>of what the groups ideas for "properties of a plotting style" are.
> 
> 
> typedef enum int {

There's no such thing as "enum int" ;-)

> LINES, POINTSTYLE, LINESPOINTS, IMPULSES, .....
> } plot_style;

May be better to name it t_plot_style or plot_style_number or something 
like that...

> typedef struct {
> int plot_style;		/* The identifying number */

No "int" here, please.  This element is inherently of the type of
the above enum, so that's what its type should be.

> TBOOLEAN has_points; 	/* replaces the PLOT_STYLE_HAS_POINT bitflag */
> TBOOLEAN has_fill;	/* replaces the PLOT_STYLE_HAS_FILL bitflag */
> [.. more bitflags ..]
> int min_columns;
> int max_columns;
> int default_columns;
> [.. and so on ..]
> } t_plotstyle;
> 
> extern struct t_plotstyle plotstyle[] =
> { ... initialization array ... };

Exactly.  I.e., what I'm envisioning here is a modification roughly
similar to my "axis struct" project a couple of years ago.

Re: Problem with new binary input code

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

Ethan Merritt wrote:

>>I'm not aware
>>of what the groups ideas for "properties of a plotting style" are.
>>    
>>
>
>typedef enum int {
>LINES, POINTSTYLE, LINESPOINTS, IMPULSES, .....
>} plot_style;
>
>typedef struct {
>int plot_style;		/* The identifying number */
>TBOOLEAN has_points; 	/* replaces the PLOT_STYLE_HAS_POINT bitflag */
>TBOOLEAN has_fill;	/* replaces the PLOT_STYLE_HAS_FILL bitflag */
>[.. more bitflags ..]
>int min_columns;
>int max_columns;
>int default_columns;
>[.. and so on ..]
>} t_plotstyle;
>
>extern struct t_plotstyle plotstyle[] =
>{ ... initialization array ... };
>
>
>Everywhere that explicitly tests against the definitions currently
>in gp_types.h gets modified to test against this structure instead.
>
>Old:	If (<foo> & PLOT_STYLE_HAS_FILL) ...
>New:	If (plotstyle[<foo>].has_fill) ...
>

Yes, makes sense.  So that would get rid of the encoding of the 
properties within the style enumeration itself.  My opinion is that 
would be good.  That encoding of the properties within the style is kind 
of creative but it harks back to the days of squeezing memory 
consumption out of every bit you have available.  In fact, yes, when I 
created this table you raised question about, I specifically looked at 
how I could encode that in the plot style number as well.  I thought 
that to be too much rocking the boat, and furthermore I believe the 
enumeration would run out of bits.

Dan