Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2005-06-21 06:53:14
|
Now would be a good time for me to update some of the patches on S.F. if any of the developers are interested. I think the key-cleanup and enhancement patch(es) is a good one. I recall there being two patches for that. The first patch was only cleanup, adding no new functionality but making the current layout options more robust. What was good about this patch, if I remember correctly, is that it took a step toward making plot layout for 2D and 3D similar. The second patch of this pair was one that added a few more options for laying out the key so that it can be placed basically anywhere inside or outside the plot borders. Let me know if you are interested in this one. Also, should it be kept as two different patches? Or should it be combined into one mondo-patch. Dan PS: Is it maybe time to start thinking about a new release? Developers have been diligent about not letting CVS accumulate bugs; this is the time of year when most people will have free time; and after only 14 months the release process should still be fairly fresh in people's minds. |
|
From: Petr M. <mi...@ph...> - 2005-06-22 14:42:10
|
> I think the key-cleanup Yes, that's interesting. Please update it for current cvs. There, I propose to change ... outside | below | <position>} to outside | below | at <position>} as giving raw numbers is always confusing. > and enhancement patch(es) is a good one. I see not two but one patch. Please cite patch numbers. > PS: Is it maybe time to start thinking about a new release? Developers have > been diligent about not letting CVS accumulate bugs; this is the time of year > when most people will have free time; and after only 14 months the release > process should still be fairly fresh in people's minds. Myself, I will have more time in autumn. Some ideas for future: - We should clean patch, bugs and requests section... - I always apply the "raise" patch, I think we had some proposals via email how to change it (new terminal API "term->interactive(...)" to send commands to interactive terminals, like "close", "raise", "hide mouse menu", "don't use q hotkey to quit" etc, is it is currently done non-consistently over terminals. - I would like to see "set xtics in|out scale ..." to separate them from the default "set ticscale ...; set tics in|out". - Recently I have noticed that it would be convenient to be able do set termoptions close to be able to close the window under x11/windows/pm et al. terminals (later raise, etc.). Can somebody implement this for X11? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-06-22 17:44:42
|
Petr Mikulik wrote: >> I think the key-cleanup > > > Yes, that's interesting. Please update it for current cvs. > There, I propose to change > ... outside | below | <position>} > to > outside | below | at <position>} Alright, good point. I'm right in the process of updating this patch with CVS changes since last year. > I see not two but one patch. Please cite patch numbers. OK, my memory isn't so great either. I see I combined that into a single patch last fall. I'll drop a note when a new patch is ready. > >> PS: Is it maybe time to start thinking about a new release? >> Developers have been diligent about not letting CVS accumulate bugs; >> this is the time of year when most people will have free time; and >> after only 14 months the release process should still be fairly fresh >> in people's minds. > > > Myself, I will have more time in autumn. That's fine, I think ramping up over a few month time frame is a good idea. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-06-23 22:21:21
|
Petr Mikulik wrote:
>> I think the key-cleanup
>
>
> Yes, that's interesting. Please update it for current cvs.
> There, I propose to change
> ... outside | below | <position>}
> to
> outside | below | at <position>}
>
> as giving raw numbers is always confusing.
OK. It's changed, consistent with "labels" placement:
Syntax:
set key {on|off} {default}
{{inside | outside} | {at <position>} | {above | below}}
{left | right | center} {top | bottom | center}
[...]
The output of 'key.dem' is at:
http://www.acer-access.com/~ds...@ac.../gnuplot/key.pdf
I'll be leaving town shortly, so I've put an up-to-date patch on S.F. However,
there is one detail left. It has to do with a discussion between Hans and I
about manually set margins. I couldn't recall the exact issue, but I have all
the old emails. (The problem is that ybot is a global variable set all over the
place. This fix was right in the middle of some code that gets tossed by the
new patch.)
Dan
#if 0
/* Dan Sebald 21jun2005: Hans had added this hunk of code after
* a new key patch was created. It was placed somewhere that made
* no sense in the new patch. Sorry if this has created a bug,
* but I can't exactly recall what the issue was. Perhaps if
* that bug crops up again we can find a proper home for this code.
*/
/* HBB 20040725: leave manually set bmargin alone */
if (bmargin < 0) {
ybot += key_entry_height * key_rows
+ (int) (t->v_char * (ktitl_lines + 1));
ybot += (int) (key->height_fix * t->v_char);
}
#endif
|
|
From: Daniel J S. <dan...@ie...> - 2005-06-29 09:23:29
|
Daniel J Sebald wrote:
> #if 0
> /* Dan Sebald 21jun2005: Hans had added this hunk of code after
> * a new key patch was created. It was placed somewhere that made
> * no sense in the new patch. Sorry if this has created a bug,
> * but I can't exactly recall what the issue was. Perhaps if
> * that bug crops up again we can find a proper home for this code.
> */
> /* HBB 20040725: leave manually set bmargin alone */
> if (bmargin < 0) {
> ybot += key_entry_height * key_rows
> + (int) (t->v_char * (ktitl_lines + 1));
> ybot += (int) (key->height_fix * t->v_char);
> }
> #endif
OK, I've looked at this hunk of code. It appears I've already accounted for the above with the new logic:
if (key->flag == KEY_AUTO_PLACEMENT && key->region == GPKEY_EXTERIOR) {
if (key->stack_dir == GPKEY_HORIZONTAL || key->hpos == CENTRE) {
if (key->vpos == JUST_BOT && bmargin < 0) {
ybot += key_entry_height * key_rows
+ (int) (t->v_char * (ktitl_lines + 1));
ybot += (int) (key->height_fix * t->v_char);
} else if (key->vpos == JUST_TOP && tmargin < 0) {
ytop -= key_entry_height * key_rows
+ (int) (t->v_char * (ktitl_lines + 1));
ytop += (int) (key->height_fix * t->v_char);
}
}
That is, flag==KEY_AUTO_PLACEMENT and region==GPKEY_EXTERIOR and vpos==JUST_BOT and hpos==CENTRE is now the equivalent of the old TUNDER.
So, I've removed that hunk of code above which was commented out anyway. If the developers disagree with behavior it is very easy to fix the current tests at a later date. I think it should do fine for now.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2005-06-29 09:38:14
|
And with that, I think now is as good a time as any to consider the key layout patch and the exterior X window patch. Please give them a try. I have a short open window of time here. After this weekend's holiday there is a good chance I will ramp up consulting work again and not be free for quite a while. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-29 23:11:41
|
On Wednesday 29 June 2005 02:42 am, Daniel J Sebald wrote:
> And with that, I think now is as good a time as any to consider the key layout patch
Looks basically OK. I'm fine with it.
But there are some compile-time warnings, and at least part of
the original syntax seems to have broken: set key <position>
graphics.c:1108: warning: unused variable `keybox_half_height'
graphics.c:1109: warning: unused variable `keybox_half_width'
save.c:321: warning: enumeration value `CENTRE' not handled in switch
save.c:329: warning: enumeration value `JUST_CENTRE' not handled in switch
cd tutorial; make clean; make
set key 15,-10
^
"eg3.plt", line 7: unknown key option
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2005-06-30 04:57:37
|
Ethan Merritt wrote:
> On Wednesday 29 June 2005 02:42 am, Daniel J Sebald wrote:
>
>>And with that, I think now is as good a time as any to consider the key layout patch
>
>
> Looks basically OK. I'm fine with it.
> But there are some compile-time warnings,
Aee, I keep forgetting to turn on warnings. Can we turn warnings on by default? :)
and at least part of
> the original syntax seems to have broken: set key <position>
Well, this is what Petr suggested the other day, i.e., that it should be
set key at <position>
His point was that the position alone didn't give enough indication that it in fact meant position; whereas "at" inherently suggests position. Furthermore, "at" is consistent with
Syntax:
set label {<tag>} {"<label text>"} {at <position>}
Either way is fine with me. Which do list members prefer?
>
>
> graphics.c:1108: warning: unused variable `keybox_half_height'
> graphics.c:1109: warning: unused variable `keybox_half_width'
> save.c:321: warning: enumeration value `CENTRE' not handled in switch
> save.c:329: warning: enumeration value `JUST_CENTRE' not handled in switch
I'll fix those.
>
> cd tutorial; make clean; make
>
> set key 15,-10
> ^
> "eg3.plt", line 7: unknown key option
Oh yeah, I see... eg6.plt (tutorial.tex), bivariat.dem and electron.dem also have this. I will fix these if the list thinks "at" should be required.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-06-30 06:23:31
|
On Wednesday 29 June 2005 10:01 pm, Daniel J Sebald wrote:
\>
> Syntax:
> set label {<tag>} {"<label text>"} {at <position>}
>
> Either way is fine with me. Which do list members prefer?
Document it as requiring "at", but for backwards-compatibility
it must also accept the old syntax.
> > cd tutorial; make clean; make
> >
> > set key 15,-10
> > ^
> > "eg3.plt", line 7: unknown key option
>
> Oh yeah, I see... eg6.plt (tutorial.tex), bivariat.dem and electron.dem
> also have this. I will fix these if the list thinks "at" should be
> required.
Yes, if the new syntax requires "at" then the tutorial and the demos
should use it. But changing the demos will not magically change people's
existing scripts, so the code still must accept the at-less form also.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-30 19:12:59
|
I think this is almost ready for inclusion, barring some extraneous messages from time-travellers like the one below: +#if 0 /* 29jul2005 Seems like outdated cruft. Keybox computations are done later. */ + /* we divide into columns, then centre in column by + * considering ratio of * key_left_size to + * key_right_size + * + * key_size_left/(key_size_left+key_size_right) * + * (xright-xleft)/key_cols do one integer division to + * maximise accuracy (hope we don't overflow !) + */ + keybox.xl = xleft - key_size_left + + ((xright - xleft) * key_size_left) + / (key_cols * (key_size_left + key_size_right)); + keybox.xr = keybox.xl + key_col_wth * (key_cols - 1) + + key_size_left + key_size_right; + keybox.yb = t->ymax * yoffset; + keybox.yt = keybox.yb + key_rows * key_entry_height + + ktitl_lines * t->v_char; + keybox.yt += (int) (key->height_fix * t->v_char); +#endif The only other glitch I notice is that the default placement of "set key below" seems to have changed from "below center" to "below right". E.g. set key below plot sin(x) now places the key at the bottom right corner of the page, rather than centering it under the plot. Please fix that, because I'm sure this will be triggered by a *lot* of existing scripts. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-06-30 20:11:29
|
Ethan Merritt wrote: > I think this is almost ready for inclusion, barring some extraneous > messages from time-travellers like the one below: :) I'll take that out. It can always be gotten from CVS. > The only other glitch I notice is that the default placement of > "set key below" seems to have changed from "below center" to > "below right". E.g. > set key below > plot sin(x) > now places the key at the bottom right corner of the page, rather > than centering it under the plot. Please fix that, because I'm > sure this will be triggered by a *lot* of existing scripts. I overlooked that. Yes, "under" alone should be centered. Should "under" by a synonym for "outside bottom center", or just "outside bottom" so that "under left" is valid? Should I add a series of conflicting keyword error messages? E.g., should "under inside" complain or simply override the "outside" inherent in "under"? Dan |
|
From:
<br...@ph...> - 2005-06-30 23:58:19
|
Daniel J Sebald wrote: > I overlooked that. Yes, "under" alone should be centered. Yes. > Should "under" by a synonym for "outside bottom center", or just > "outside bottom" so that "under left" is valid? Both ;-) I.e. both "below" and "below left" should be valid, with the former being equivalent to "below center". > Should I add a series of conflicting keyword error messages? E.g., > should "under inside" complain or simply override the "outside" inherent > in "under"? An error might be too harsh. An int_warn() should do. |
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 01:38:22
|
Hans-Bernhard Br=F6ker wrote: > Daniel J Sebald wrote: >=20 >> I overlooked that. Yes, "under" alone should be centered. >=20 >=20 > Yes. >=20 >> Should "under" by a synonym for "outside bottom center", or just=20 >> "outside bottom" so that "under left" is valid? >=20 >=20 > Both ;-) >=20 > I.e. both "below" and "below left" should be valid, with the former=20 > being equivalent to "below center". But, isn't there some memory in gnuplot options? That is, set key left set key center has an end state of=20 set key left center not set key below center It may not be apparent what the issue is until attempting to use this. >=20 >> Should I add a series of conflicting keyword error messages? E.g.,=20 >> should "under inside" complain or simply override the "outside"=20 >> inherent in "under"? >=20 >=20 > An error might be too harsh. An int_warn() should do. OK. Basically the same code. No problem. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-07-04 08:29:03
|
Daniel J Sebald wrote: > But, isn't there some memory in gnuplot options? That is, > > set key left > set key center > > has an end state of > set key left center It may have that effect. Or one option may override the default specified by another, if it comes after that. The memory is in the internal status variables, not necessarily in the syntax seen by the user. |
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 01:20:37
|
Ethan Merritt wrote: > I think this is almost ready for inclusion, OK, one last question; a real specific one. Basically, do people think there is enough control of key placement for "outside", or should there be slightly more independent control? That is, in the case of "inside" there are 9 positions for placement, regardless of vertical or horizontal key elements. On the other hand, in the case of "outside" there are 12 positions for placement. Have a look at demo plots 3 and 4 of http://acer-access.com/~ds...@ac.../gnuplot/key.pdf You'll see that one can't (without manual placement) have a vertical element key under and to the left or right. I assumed no one would want to do such a thing because it wastes space. (The same holds for putting a horizontal element key to the side of a plot.) But who knows? Perhaps there is a non-obvious reason to want to do that. 1) Should there be that flexibility? 2) If so, what is a good syntax for achieving that? (Note that this means "vert|horiz" no longer have any influence on placement.) a) Order of options? That is, "outside left top" is different from "outside top left"? b) Add a third option for {above|below|side}? Then, for example "outside above right" and "outside side right top" can pinpoint placement. c) A variation on b that might have more obvious meaning? Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-07-01 02:47:08
|
On Thursday 30 June 2005 06:24 pm, Daniel J Sebald wrote: > You'll see that one can't (without manual placement) have a vertical > element key under and to the left or right. I assumed no one would want > to do such a thing because it wastes space. (The same holds for putting > a horizontal element key to the side of a plot.) But who knows? > Perhaps there is a non-obvious reason to want to do that. > > 1) Should there be that flexibility? I don't think so. If you want to put the key in strange places, you still have the manual placement mode. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 03:03:50
|
Ethan A Merritt wrote: > On Thursday 30 June 2005 06:24 pm, Daniel J Sebald wrote: >> >>1) Should there be that flexibility? > > > I don't think so. If you want to put the key in strange places, > you still have the manual placement mode. OK. I've posed a different scheme in another email. I'm completely flexible, but I just worry a bit that vert/horiz having influence on position is a lingering confusion users will never get used to, and fixing syntax after the fact is not good... It's up to the list. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 02:58:57
|
Daniel J Sebald wrote:
> c) A variation on b that might have more obvious
> meaning?
I may have a syntax solution here. If you think "vert/horiz" shouldn't have influence on placement, how about:
Syntax:
set key {on|off} {default}
{{inside | margin | above | below} | {at <position>}}
{left | right | center} {top | bottom | center}
[...]
WITH the backward compatible "outside" meaning the same as "right margin"? I like this idea.
If one says "inside", then left/right/center/top/bottom can pick out positions as represented pictorially as
1 2 3
4 5 6
7 8 9
Now the tricky part, the outside positions. As I said, there are twelve; pictorially:
10 11 12
21 13
20 14
19 15
18 17 16
We can choose these positions as follows:
"above" combined with left/center/right: 10 11 12
"right margin" combined with top/center/bottom: 13 14 15
"below" combined with right/center/left: 16 17 18
"left margin" combined with bottom/center/top: 19 20 21
I know the documentation would suggest typing "margin right", but if users want to think more naturally as "right margin", fine.
Aside from the errors inherent in the syntax brace placement, the following will give warnings:
"above" combined with top/bottom
"below" combined with top/bottom
You'll notice that in the current scheme, "outside" is position number (unlucky) 13, i.e., the right margin.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 04:59:07
|
Daniel J Sebald wrote:
> Daniel J Sebald wrote:
>
>> c) A variation on b that might have more obvious
>> meaning?
>
>
> I may have a syntax solution here. If you think "vert/horiz" shouldn't
> have influence on placement, how about:
>
> Syntax:
> set key {on|off} {default}
> {{inside | margin | above | below} | {at <position>}}
> {left | right | center} {top | bottom | center}
Ehh... the above may be a confusing dud as well. Now that I think about it,
"right margin top"
would be equivalent to
"top margin right"
and top margin is a concept that will cause confusion as being equal to "above".
How about
Syntax:
set key {on|off} {default}
{{inside | tmargin | bmargin | lmargin | rmargin} | {at <position>}}
{left | right | center} {top | bottom | center}
where
"above" = "tmargin"
"below" = "bmargin"
"outside" = "rmargin" + "top"
?
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-01 20:57:29
|
Ethan Merritt wrote:
> On Thursday 30 June 2005 10:03 pm, Daniel J Sebald wrote:
>
>>How about
>>
>>Syntax:
>> set key {on|off} {default}
>> {{inside | tmargin | bmargin | lmargin | rmargin} | {at <position>}}
>> {left | right | center} {top | bottom | center}
>>
>>where
>>
>>"above" = "tmargin"
>>"below" = "bmargin"
>>"outside" = "rmargin" + "top"
>
>
> Looks reasonable.
Oh yeah, "under" = "outside".
Why not take this one step further and cover all bases? Having corner position influenced by "vert/horiz" may be a nice feature, for those people who don't want to think to much. How about the slight variation on the above:
Syntax:
set key {on|off} {default}
{{inside | outside} | {at <position>}
| {tmargin | bmargin | lmargin | rmargin}}
{left | right | center} {top | bottom | center}
{vertical | horizontal} {Left | Right}
[...]
where
"above" = "tmargin"
"below" = "bmargin"
"below" without left/right appearing on line = "bmargin" + "center"
"under" = "below"
"outside" without left/right = "rmargin" (can use top/bottom/center
for positioning)
"outside" with left/right determines corner positions based
upon "vertical/horizontal"
The groupings of {inside|outside} {at } and {tmargin|bmargin...} are very natural, I think. Backward compatibility is maintained. There is a slight
problem that
set key left
set key outside
or
set key right
set key below
might not work as expected, but I think that is minor.
Sorry for having gone around in circles here a bit. [I think all I've done is propose adding {tmargin|bmargin|...}.] I'll create a version with the above syntax tomorrow.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2005-07-04 09:38:42
|
Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > >> But, isn't there some memory in gnuplot options? That is, >> >> set key left >> set key center >> >> has an end state of >> set key left center > > > It may have that effect. Or one option may override the default > specified by another, if it comes after that. The memory is in the > internal status variables, not necessarily in the syntax seen by the user. I'm working on it. I have something close to this I think. Patch soon. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-07-05 18:52:00
|
I just noticed the key is programmed so that settings are adjusted immediately upon interpretation. Thus if there is a syntax error in a line, settings up to that error will be changed. Isn't it preferable that nothing be changed until the whole line is verified as valid? Should I make alterations into a temp key structure then copy that temp key structure to the actual key structure at the end of "set key" line? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-07-05 19:00:16
|
On Tuesday 05 July 2005 11:56 am, Daniel J Sebald wrote: > I just noticed the key is programmed so that settings are adjusted immediately upon interpretation. Thus if there is a syntax error in a line, settings up to that error will be changed. > > Isn't it preferable that nothing be changed until the whole line is verified as valid? Not really. Why would it be? I think I'd rather get as much of my command as possible, even if the last option has a typo. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2005-07-05 19:52:37
|
Ethan Merritt wrote: > On Tuesday 05 July 2005 11:56 am, Daniel J Sebald wrote: > >>I just noticed the key is programmed so that settings are adjusted immediately upon interpretation. Thus if there is a syntax error in a line, settings up to that error will be changed. >> >>Isn't it preferable that nothing be changed until the whole line is verified as valid? > > > Not really. Why would it be? > I think I'd rather get as much of my command as possible, even if the last option has a typo. I don't know, there's just something random about a portion of a line being processed. If there is an error, I'm not likely going to think "Alright, now which properties changed? And which do I have left to change?" Rather, I think most people have a habit of hitting the up arrow to recall the last line and fix it (or just fix the line in a script file) then rerun the command. I'll leave it as is. The other side of the coin is someone types in a command with "exploratory syntax" to see if something works, an error results, the user decides it is fine as is, yet some parameter has changed. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-07-06 07:56:22
|
Does the following warning make sense to people?
gnuplot> set key lmargin top right
warning: Ignoring left/center/right; incompatible with lmargin/tmargin.
That is, the region (lmargin/rm/tm/bm) trumps position (l/r/t/b/c) and "right" is ignored in this case.
The above type of warning should definitely be issued. How about warnings such as
gnuplot> set key right outside top right
^
warning: Multiple horizontal position settings
where the second occurrence of the horizontal position overrides the first occurrence? This would be setting a precedent perhaps for multiple specs for all commands? All/nothing? Take out?
Dan
|
