Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2006-06-03 00:35:05
|
Dear all, I have several questions regarding the use of cursors and icons in the wxWidgets terminal : 1) Petr Mikulik reported that the cross cursor was not working properly for him. This is the default cursor when the mouse is on the graph. It is supposed to be a black cross surrounded by a white border so that it is visible on a dark background, with a transparent "hole" in the center. On Petr's machine, the cross is all white. Have the other people that have tried the wxWidgets terminal seen this ? (by the way, how many of you actually tried it or use it ?) 2) Lars Hecking reported that 'make check' before 'make install' will complain (just a warning) because it doesn't find the PNG icons used in the toolbar. Indeed they have to be installed in PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to replace the PNG icons by XPM icons included at compile time. Then the problem of finding the icons vanishes, but the executable's size grows. As I said to Lars : "A 16x16 PNG file is ~700 Bytes. A 16x16 XPM file is ~2.5 kBytes, plus a second XPM file for the alpha channel (so that the icons look good), ~700 Bytes. There are 9 icons in the terminal's toolbar, so using XPM icons would include ~30 kBytes into the source files. I don't really know if these 30 kBytes are somewhat compressed into the final binary, but at worst we add 30 kBytes." What do you think about this ? Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-03 01:02:54
|
On Friday 02 June 2006 05:34 pm, Timoth=E9e Lecomte wrote:
>
> 1) This is the default cursor [...] is supposed to be a black cross=20
> surrounded by a white border so that it is visible on a dark
> background, with a transparent "hole" in the center.
> (by the way, how many of you actually tried it or use it ?)
I have been using it routinely.
The only problems I notice are that=20
(1) You must do a manual replot after resizing the terminal
(else the mouse coords are wrong among other things)
(2) I have to hack the source to make it ignore 'q'
We've got to come up with an equivalent to the ctrlq X-resource
On a related topic, are you happy with the state of the
"Bind <space> to builtin_raise in mouse.c" patchset?
If so, let's commit it to CVS.
=20
> 2) Lars Hecking reported that 'make check' before 'make install' will
> complain (just a warning) because it doesn't find the PNG icons used
> in the toolbar. Indeed they have to be installed in
> PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to
> replace the PNG icons by XPM icons included at compile time.
I'd rather keep the PNG icons, and think about generalizing the
mechanism so that users can configure their own new buttons and
supply an icon to go with it.
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: <tim...@en...> - 2006-06-03 01:27:51
|
> The only problems I notice are that > (1) You must do a manual replot after resizing the terminal > (else the mouse coords are wrong among other things) > (2) I have to hack the source to make it ignore 'q' > We've got to come up with an equivalent to the ctrlq X-resource In the spirit of the patch for the spacebar, we could bind 'q' to a new mechanism in mouse.c based on the codes for "set <term> close" and the "winid" field in the gp_event_t structure. See below for limitations of this approach. > On a related topic, are you happy with the state of the > "Bind <space> to builtin_raise in mouse.c" patchset? > If so, let's commit it to CVS. *I* am happy with it, but I aknowledge a regression of this approach : th= e events from the terminal have to be processed to be taken into account. For example : set term wxt plot x <press space> =3D> the gnuplot console is raised set term x11 plot x <press space in the wxt window> =3D> nothing happens <press space in the x11 window> =3D> the gnuplot console is raised set term wxt plot x <press space in the x11 window> =3D> nothing happens <press space in the wxt window> =3D> the gnuplot console is raised set term png <press space in the x11 window> =3D> nothing happens <press space in the wxt window> =3D> nothing happens Without the patch, in any case the gnuplot console is raised. If this is acceptable, then the patch should be committed. >> 2) Lars Hecking reported that 'make check' before 'make install' will >> complain (just a warning) because it doesn't find the PNG icons used >> in the toolbar. Indeed they have to be installed in >> PREFIX/share/gnuplot/4.1/png before they can be used. I proposed to >> replace the PNG icons by XPM icons included at compile time. > > I'd rather keep the PNG icons, and think about generalizing the > mechanism so that users can configure their own new buttons and > supply an icon to go with it. The both solutions are not mutually exclusive. The point is that dealing with hard-coded paths is quite a nightmare to make it work in every situation. Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-04 04:41:02
|
On Friday 02 June 2006 06:27 pm, Timoth=E9e Lecomte wrote: > > On a related topic, are you happy with the state of the > > "Bind <space> to builtin_raise in mouse.c" patchset? > > If so, let's commit it to CVS. >=20 > *I* am happy with it, but I aknowledge a regression of this approach : the > events from the terminal have to be processed to be taken into account. > set term png > <press space in the x11 window> =3D> nothing happens > <press space in the wxt window> =3D> nothing happens > Without the patch, in any case the gnuplot console is raised. > If this is acceptable, then the patch should be committed. It's acceptable to me, but then I intend to turn this behavior off anyhow. The question is whether it is acceptable to people who actually use it. Petr? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2006-06-04 09:32:09
|
> plot x > <press space in the x11 window> => nothing happens > <press space in the wxt window> => the gnuplot console is raised > set term png > <press space in the x11 window> => nothing happens > <press space in the wxt window> => nothing happens > > Without the patch, in any case the gnuplot console is raised. > If this is acceptable, then the patch should be committed. I would prefer that this hotkey works always. Could this be organized? Are not the messages from gnuplot_x11 delivered always to gnuplot? Executation of this code does not depend on current terminal. Considering 'q' hotkey: I propose to allow its rebounding, and in this case gnuplot_x11 to close itself, without dispatching this message to gnuplot. When binding 'q' or init of terminal, gnuplot should write to terminal 'use key "x" to quit'. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-04 15:54:41
|
On Sunday 04 June 2006 02:31 am, Petr Mikulik wrote: > > I would prefer that this hotkey works always. Could this be organized? So far no one has suggested how this can be done. > Are not the messages from gnuplot_x11 delivered always to gnuplot? Yes, but not immediately. It's the same old problem: gnuplot mixes the input streams from the keyboard and the current terminal into a single queue. Thus both terminal events and keyboard input are read via term->waitforinput(). If you change the terminal, you change the input routine and no longer read events from the previous terminal. The events are not lost; they are delivered eventually when the terminal is set back to the original type and term->waitforinput() is next called. > Considering 'q' hotkey: I propose to allow its rebounding, and in this case > gnuplot_x11 to close itself, without dispatching this message to gnuplot. The problem for 'q' is slightly different. Key bindings are handled by gnuplot itself; the terminal drivers do not know about them. So then the problem is how do you tell gnuplot_x11 that it should send 'q' as an event to the main program rather than exiting? > When binding 'q' or init of terminal, gnuplot should write to terminal 'use > key "x" to quit'. In the case of x11, gnuplot does not know this. gnuplot_x11 reads it from an X resource. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-06-04 22:43:32
|
Ethan A Merritt wrote:
> On Sunday 04 June 2006 02:31 am, Petr Mikulik wrote:
> =20
>> I would prefer that this hotkey works always. Could this be organized?
>> =20
>
> So far no one has suggested how this can be done.
> =20
Let's suggest something...
> =20
>> Are not the messages from gnuplot_x11 delivered always to gnuplot?=20
>> =20
>
> Yes, but not immediately.
> It's the same old problem: gnuplot mixes the input streams from the
> keyboard and the current terminal into a single queue. Thus both
> terminal events and keyboard input are read via term->waitforinput().
> If you change the terminal, you change the input routine and no longer
> read events from the previous terminal. =20
> =20
As far as I can tell, term->waitforinput() could be replaced by=20
something like term->processevents(), which would process any pending=20
events and return. Then, this would be called repeatedly by the core=20
after a select() timeout on stdin, or the equivalent functions on=20
different platforms.
Until now, nothing different from what is done currently.
Then, several *term*->processevents() could be called, for each=20
interactive terminal previously initialized. If "term" is the current=20
terminal, all the events
will be processed. Otherwise, only events like "raise" (ie "spacebar=20
pressed" in the default setting) or "close terminal" (ie "q pressed" in=20
the default setting) would be processed.
To sum up : the getc() wrapper is a loop on :
select(...STDIN,TIMEOUT...) on Unix, GetMessage(...) on Windows,=20
SomeEquivalent(...) on OS/2
first_interactive_term->processevents()
second_interactive_term->processevents()
...
Regards,
Timoth=E9e
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-04 22:35:52
|
On Sunday 04 June 2006 08:54 am, Ethan A Merritt wrote: > It's the same old problem: gnuplot mixes the input streams from the > keyboard and the current terminal into a single queue. Thus both > terminal events and keyboard input are read via term->waitforinput(). > If you change the terminal, you change the input routine and no longer > read events from the previous terminal. =20 On the other hand, the only terminals that implement term->waitforinput seem to be x11, wxt, and ggi. I think we can ignore ggi, if not delete it from the tree altogether. And other than for debugging/comparison, I=20 can't think why you would routinely be switching back and forth between x11 and wxt. So the real issue is when you are using either x11 or wxt, but shift temporarily to a different terminal for printing. Perhaps the answer is that in such a case gnuplot could continue to channel input through the previous driver's waitforinput() routine. I think maybe this can be done in two steps: - When a new terminal is set, we conditionally set a new variable if (term->waitforinput) current_waitforinput =3D term->waitforinput; - Replace existing references to term->waitforinput() by the new pointer current_waitforinput. I found 3 occurrances in command.c and another 3 in readline.c I have placed a small patch on SourceForge that does this. It seems to work for x11, with a few glitches that appear minor but may turn out to be profound. However, if the terminal is set to wxt and than to something else, this patch causes a lot of binary junk to spew back to the console terminal window. I don't understand this at all. Timoth=E9e, can you have a look to see why this happens? =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-06-04 23:09:34
|
Ethan, your message arrived as I was sending mine, it is nice to see=20 that our ideas are not so different. Here are some thoughts : Ethan A Merritt wrote: > On Sunday 04 June 2006 08:54 am, Ethan A Merritt wrote: > =20 >> It's the same old problem: gnuplot mixes the input streams from the >> keyboard and the current terminal into a single queue. Thus both >> terminal events and keyboard input are read via term->waitforinput(). >> If you change the terminal, you change the input routine and no longer >> read events from the previous terminal. =20 >> =20 > > On the other hand, the only terminals that implement term->waitforinput > seem to be x11, wxt, and ggi. I think we can ignore ggi, if not delete > it from the tree altogether. And other than for debugging/comparison, = I=20 > can't think why you would routinely be switching back and forth between > x11 and wxt. > =20 Agreed, but supporting several waitforinput() should not be that hard,=20 see my previous message. > So the real issue is when you are using either x11 or wxt, but shift > temporarily to a different terminal for printing. Perhaps the answer > is that in such a case gnuplot could continue to channel input through > the previous driver's waitforinput() routine. I think maybe this can > be done in two steps: > > - When a new terminal is set, we conditionally set a new variable > if (term->waitforinput) > current_waitforinput =3D term->waitforinput; > > - Replace existing references to term->waitforinput() by the new > pointer current_waitforinput. I found 3 occurrances in command.c > and another 3 in readline.c > =20 That's indeed the first step of the simplest approach... The value of=20 "term" has to be changed too when calling current_wiaitforinput() so=20 that the event system calls the right term->puttmptext() and friends. > I have placed a small patch on SourceForge that does this. > It seems to work for x11, with a few glitches that appear minor but > may turn out to be profound. However, if the terminal is set to wxt and > than to something else, this patch causes a lot of binary junk to spew > back to the console terminal window. I don't understand this at all. > Timoth=E9e, can you have a look to see why this happens? > =20 I see exactly the same binary junk with the X11 terminal ! What you see=20 is the binary PNG output sent to stdout, I think. If you try with the=20 postscript terminal, you see the ascii output of the postscript commands=20 instead... Regards, Timoth=E9e |
|
From: <tim...@en...> - 2006-06-06 21:21:35
|
Ethan Merritt wrote: > On Friday 02 June 2006 05:34 pm, Timoth=E9e Lecomte wrote: > =20 >> 1) This is the default cursor [...] is supposed to be a black cross=20 >> surrounded by a white border so that it is visible on a dark >> background, with a transparent "hole" in the center. >> =20 > > =20 >> (by the way, how many of you actually tried it or use it ?) >> =20 > > I have been using it routinely. > The only problems I notice are that=20 > (1) You must do a manual replot after resizing the terminal > (else the mouse coords are wrong among other things) > =20 I reproduced the problem with the mouse coords (y-axis) that are wrong=20 when you resize the wxWidgets terminal. I will commit a patch soon. Do=20 you see any other problem with the resizing behaviour ? By the way, the wxWidgets terminal differs from others in the fact that=20 it keeps the aspect ratio (width/height) of the plot and that it scales=20 the font sizes and linewidths when you resize the window. We discussed=20 that a little before the commit. Now that several of you (at least Ethan=20 and Petr) have tried it, can you tell me how you feel about that behaviou= r ? Best regards, Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-06 21:31:49
|
On Tuesday 06 June 2006 03:16 pm, you wrote: > By the way, the wxWidgets terminal differs from others in the fact > that it keeps the aspect ratio (width/height) of the plot > Now that several of you have tried it, can you tell me how you feel > about that behaviour ? I would rather the plot filled the window. Another option is to honor the setting of "set ratio", if any, but otherwise fill the window. This has been suggested for x11 also, but nobody has offered a patch :-) Ethan -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: Petr M. <mi...@ph...> - 2006-06-06 21:40:53
|
> By the way, the wxWidgets terminal differs from others in the fact > that it keeps the aspect ratio (width/height) of the plot > > Now that several of you have tried it, can you tell me how you feel > about that behaviour ? OS/2 PM terminal has a check menu item where you can set which behaviour you like at the moment. I preferred non-aspect ratio for most plots, and aspect ratio for maps. Now, with other terminals, I prefer the x11 way -- the ration can be set by 'set size ratio -1'. > it scales the font sizes and linewidths when you resize the window. I prefer fixed sizes; you can still read&monitor the plot in a small window. --- PM |
|
From: <tim...@en...> - 2006-06-06 22:12:39
|
Ethan Merritt wrote: > I would rather the plot filled the window. > Another option is to honor the setting of "set ratio", if any, > but otherwise fill the window. This has been suggested for=20 > x11 also, but nobody has offered a patch :-) > =20 > I am afraid there's a confusion here. The wxWidgets terminal always=20 honor the settings of "set size ratio <r>" when you plot something. The=20 question only affects what happens immediately when you resize a window. gnuplot> plot x =3D> the plot window is filled, let's say it is 600x40= 0 [you resize the window to 200x200] =3D> the plot will be scaled to=20 200x133, (font sizes and linewidths rescaled) gnuplot> plot x =3D> the plot window is filled again, the plot is=20 200x200, the font sizes and linewidths are back to original. I like this behaviour because gnuplot has carefully taken the font sizes=20 into account to draw something with a good layout, so this layout should=20 not be messed up when you resize your window (remember that we can't=20 call 'replot' automatically as it is not compatible with multiplot). I admit that linewidths could not be scaled, I don't really mind. But=20 font sizes seem more important to me as they are the base of gnuplot=20 layout computations. Petr Mikulik wrote: >> By the way, the wxWidgets terminal differs from others in the fact >> that it keeps the aspect ratio (width/height) of the plot >> >> Now that several of you have tried it, can you tell me how you feel >> about that behaviour ? > > OS/2 PM terminal has a check menu item where you can set which=20 > behaviour you like at the moment. I preferred non-aspect ratio for=20 > most plots, and aspect ratio for maps. Now, with other terminals, I=20 > prefer the x11 way -- the ration can be set by 'set size ratio -1'. Same remark as above : "set size ratio <r>" is relevant to the time when=20 gnuplot computes the plot, not when you resize your window between two=20 different "plot <something>". Anyway, I think that the x11 way doesn't=20 respect "set size ratio -1" (for example) : gnuplot> set term x11 gnuplot> set size ratio -1 gnuplot> plot x =3D> the plot window is is 600x400, the axes are a squ= are [you resize the window to 200x200] =3D> the plot is scaled to 200x200,=20 (font sizes and linewidths not rescaled), it loses its square aspect,=20 whereas you explicitely asked for it gnuplot> plot x =3D> nothing changes With the wxWidgets terminal : gnuplot> set term wxt gnuplot> set size ratio -1 gnuplot> plot x =3D> the plot window is is 600x400, the axes are a squ= are [you resize the window to 200x200] =3D> the plot is scaled to 200x133,=20 (font sizes and linewidths rescaled), it keeps its square aspect gnuplot> plot x =3D> gnuplot recomputes the plot, it profits better=20 from the new window size, the axes are still square With the wxWidgets terminal, the plot is always square, whereas it's not=20 with the x11 terminal ! > >> it scales the font sizes and linewidths when you resize the window. > > I prefer fixed sizes; you can still read&monitor the plot in a small=20 > window. In any case, as soon as you hit 'replot' (via the icon, the key, or in=20 the command line), gnuplot computes the plot again and take the default=20 sizes. I was thinking exactly the same as you ... but in favor of the rescaling=20 : "I prefer to rescale font sizes, so that you can still have a clean=20 plot in a small window, without the labels and the lines overlapping=20 each other". Best regards, Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-07 05:27:44
|
On Tuesday 06 June 2006 04:08 pm, Timoth=E9e Lecomte wrote: > Ethan Merritt wrote: > > I would rather the plot filled the window. > gnuplot> plot x =3D> the plot window is filled, let's say it is 600x400 > [you resize the window to 200x200] =3D> the plot will be scaled to=20 > 200x133, (font sizes and linewidths rescaled) > gnuplot> plot x =3D> the plot window is filled again, the plot is=20 > 200x200, the font sizes and linewidths are back to original. >=20 > I like this behaviour because gnuplot has carefully taken the font sizes= =20 > into account to draw something with a good layout, so this layout should= =20 > not be messed up when you resize your window (remember that we can't=20 > call 'replot' automatically as it is not compatible with multiplot). X11 manages to resize multiplots just fine, so it's not impossible. Even if resizing a wxt window works slightly differently for multiplots, I would still rather have the plot continually redrawn to fill the plot area as the window is resized in the normal case. =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-06-07 06:16:50
|
Ethan A Merritt wrote: > On Tuesday 06 June 2006 04:08 pm, Timoth=E9e Lecomte wrote: > =20 >> Ethan Merritt wrote: >> =20 >>> I would rather the plot filled the window. >>> =20 > > =20 >> gnuplot> plot x =3D> the plot window is filled, let's say it is 600= x400 >> [you resize the window to 200x200] =3D> the plot will be scaled to=20 >> 200x133, (font sizes and linewidths rescaled) >> gnuplot> plot x =3D> the plot window is filled again, the plot is=20 >> 200x200, the font sizes and linewidths are back to original. >> >> I like this behaviour because gnuplot has carefully taken the font siz= es=20 >> into account to draw something with a good layout, so this layout shou= ld=20 >> not be messed up when you resize your window (remember that we can't=20 >> call 'replot' automatically as it is not compatible with multiplot). >> =20 > > X11 manages to resize multiplots just fine, so it's not impossible. > =20 Well, it does, but not by calling 'replot', which should be the ultimate solution. > Even if resizing a wxt window works slightly differently for multiplots= , > I would still rather have the plot continually redrawn to fill the plot > area as the window is resized in the normal case. > =20 Let's discuss on a practical case, and on a specific aspect of the problem : the fonts scaling (the aspect ratio behaviour is related, if I give up on fonts, I will give up on the aspect ratio immediately). I loaded multiplt.dem on both wxt and x11 with their default sizes which are in the order of 600x400, and then resized both windows to make them smaller. Here is the final screenshot : http://tipote.free.fr/resize.png I honestly prefer the wxt output, even if none of them are really readabl= e. Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2006-06-07 06:31:14
|
> Let's discuss on a practical case, and on a specific aspect of the > problem : the fonts scaling (the aspect ratio behaviour is related, if I > give up on fonts, I will give up on the aspect ratio immediately). > I loaded multiplt.dem on both wxt and x11 with their default sizes which > are in the order of 600x400, and then resized both windows to make them > smaller. > Here is the final screenshot : http://tipote.free.fr/resize.png > I honestly prefer the wxt output, even if none of them are really readable. What about adding an check icon to the menu to switch on/off font scaling? (Switching off would help to adjust font sizes before output to png or ps, for example.) --- PM |
|
From: <tim...@en...> - 2006-06-07 06:45:19
|
Petr Mikulik wrote: >> Let's discuss on a practical case, and on a specific aspect of the >> problem : the fonts scaling (the aspect ratio behaviour is related, if= I >> give up on fonts, I will give up on the aspect ratio immediately). >> I loaded multiplt.dem on both wxt and x11 with their default sizes whi= ch >> are in the order of 600x400, and then resized both windows to make the= m >> smaller. >> Here is the final screenshot : http://tipote.free.fr/resize.png >> I honestly prefer the wxt output, even if none of them are really=20 >> readable. > > What about adding an check icon to the menu to switch on/off font=20 > scaling? > (Switching off would help to adjust font sizes before output to png or=20 > ps, for example.) > Again, I think there's a confusion here : just hit 'replot' and it will=20 use the default font size. To explain that in picture : http://tipote.free.fr/resize2.png window 0 : 'plot x' at the default window size window 1 : 'plot x' at the default window size, downsized, and 'replot' window 2 : 'plot x' at the default window size, downsized As you can see, hitting 'replot' is just what you want. Timoth=E9e |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-07 06:46:59
|
On Wednesday 07 June 2006 12:01 am, you wrote: > > > Let's discuss on a practical case, and on a specific aspect of the > problem : the fonts scaling (the aspect ratio behaviour is related, if I > give up on fonts, I will give up on the aspect ratio immediately). > I loaded multiplt.dem on both wxt and x11 with their default sizes which > are in the order of 600x400, and then resized both windows to make them > smaller. > Attached is the final screenshot. I honestly prefer the wxt output, even > if none of them are really readable. But you are focusing on the size (big/small) rather than the aspect ratio. Most of the time if I want to resize a window it is to spread out the plot either horizontally or vertically. The whole point of the exercise is to change the aspect ratio. Making it bigger or smaller is just a side effect. I really don't care much about the fonts in such a case. Example: The 4th plot of 'histograms.dem' works much better if the plot is taller than it is wide. If I step through the demo in x11 I can just drag the bottom edge of the window down and it spreads itself out nicely. Dragging the bottom edge of the wxt window down accomplishes exactly nothing, at least not without a subseqent replot command. The more common case for me is examining plots of a time-series. I have standard scripts, but the length of time covered by the data can vary. I load the script and a plot pops up; if it corresponds to a long run, then I immediately want to stretch it in the horizontal in order to separate closely space features in the plot. This works quite naturally (to me) in x11, but again accomplishes nothing in the wxt terminal unless I explicitly replot after stretching the window. My thinking is that if the user changes the size/shape of the window, it is because he wants the plot to be that size/shape. Making the pure horizontal or pure vertical stretch operations be effectively no-ops seems a strange choice. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <tim...@en...> - 2006-06-07 07:02:56
|
Ethan A Merritt wrote: > On Wednesday 07 June 2006 12:01 am, you wrote: > =20 >>> =20 >>> =20 >> Let's discuss on a practical case, and on a specific aspect of the=20 >> problem : the fonts scaling (the aspect ratio behaviour is related, if= I=20 >> give up on fonts, I will give up on the aspect ratio immediately). >> I loaded multiplt.dem on both wxt and x11 with their default sizes whi= ch=20 >> are in the order of 600x400, and then resized both windows to make the= m=20 >> smaller. >> Attached is the final screenshot. I honestly prefer the wxt output, ev= en=20 >> if none of them are really readable. >> =20 > > But you are focusing on the size (big/small) rather than the aspect > ratio. Most of the time if I want to resize a window it is to spread o= ut > the plot either horizontally or vertically. The whole point of > the exercise is to change the aspect ratio. Making it bigger or smalle= r > is just a side effect. I really don't care much about the fonts in > such a case. > > Example: > The 4th plot of 'histograms.dem' works much better if the > plot is taller than it is wide. If I step through the demo in x11 > I can just drag the bottom edge of the window down and it spreads > itself out nicely. Dragging the bottom edge of the wxt window > down accomplishes exactly nothing, at least not without a subseqent > replot command. > > The more common case for me is examining plots of a time-series. > I have standard scripts, but the length of time covered by the data > can vary. I load the script and a plot pops up; if it corresponds > to a long run, then I immediately want to stretch it in the horizontal > in order to separate closely space features in the plot. This works > quite naturally (to me) in x11, but again accomplishes nothing in the > wxt terminal unless I explicitly replot after stretching the window. =20 > > My thinking is that if the user changes the size/shape of the window, > it is because he wants the plot to be that size/shape. Making the > pure horizontal or pure vertical stretch operations be effectively > no-ops seems a strange choice. > =20 Your example are convincing. And the statement that the terminal should=20 follow the user's change makes sense. But to my mind, only a full=20 'replot'-based solution is satifactory, otherwise resizing doesn't=20 respect 'set size ratio -1' for example. I am coming to the conclusion that it's not really a big deal, that it=20 can be solved later and definitely by hacking on 'replot'. What I can do to make the behaviour more understandable is to make the=20 window background gray, maybe adding a message somewhere (in the status=20 bar probably) that hitting 'replot' will fill the window. Timoth=C3=A9e |
|
From: Petr M. <mi...@ph...> - 2006-06-07 07:47:50
|
> As you can see, hitting 'replot' is just what you want. > only a full 'replot'-based solution is satifactory I see. Then it's OK with me. > adding a message somewhere (in the status bar probably) that hitting > 'replot' will fill the window. Good idea, sth like "note: need replot to ..." BTW: if I resize the x11 graph window so that it is small, the font sizes are still the same. However, the distance between x-axis and x-tic values (same for y-) is very narrow and even they overlap. The wxt terminal works properly. What's the problem with x11? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-06-12 18:15:27
|
On Wednesday 07 June 2006 12:47 am, Petr Mikulik wrote: > > BTW: if I resize the x11 graph window so that it is small, the font > sizes are still the same. However, the distance between x-axis and > x-tic values (same for y-) is very narrow and even they overlap. The > wxt terminal works properly. What's the problem with x11? wxt is built on top of a library that guarantees nice scalable fonts. x11 is not. Many x11 fonts these days _are_ scalable, but the driver doesn't know which ones are and which ones are not. This could be changed, but I think it would require that some extra information is passed: set term x11 scalable font "arial" 10 It is in any case a matter of taste whether the wxt behavior is desirable or not. Arguably if I specify a font size, I want that size regardless of whether I manually resize the plot window later. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
