Menu
▾
▴
gnuplot-beta
|
From: <tim...@en...> - 2005-06-28 22:39:01
|
Hi ! Here some news about the wxwidgets terminal I'm writing. Most of the=20 drawing functions are implemented, as you can see in the two following=20 screenshots : http://tipote.free.fr/wxt3.png http://tipote.free.fr/wxt4.png Mouse support is partially implemented : rotation, scaling (3D) and zoom=20 (2D) work. Thanks to our discussion about setjmp/longjmp, I have got a working=20 terminal-to-gnuplot communication for commands which may raise errors.=20 In particular, it allows me to rescale the plot properly when the size=20 of the window changes. This is not really impressive compared to x11, windows, or OS/2=20 functionnalities, but for me it's already huge : it's the first time I=20 write more than 50 lines for a program (currently 1200 in the terminal) ! The next step : complete mouse capabilities (based on the behaviour of=20 the x11 terminal) : ruler, zoombox, etc. And then : either enhanced text, or cleanup, or (the most attractive to=20 me) a modified mouse behaviour based on a toolbar plus menus for some=20 properties (labels to begin). Please feel free to give me your ideas ! Greetings, Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-28 22:58:50
|
On Tuesday 28 June 2005 05:39 pm, Timoth=E9e Lecomte wrote: > Please feel free to give me your ideas ! I'm still not clear on why you can't wrap your widget set around a window and then use gnuplot's existing x11 terminal driver to draw in that window. Probably I am misunderstanding the control flow. As I understand it, the widgets act like the hotkeys=20 bound by the `bind <key> "action"`. So it is a new channel of input. Is that right? But to implement this new input channel seems a separate task from duplicating the output to an x11 plot. Am I missing the point? =2D-=20 Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From:
<br...@ph...> - 2005-06-29 02:30:46
|
Ethan Merritt wrote: > input. Is that right? But to implement this new input channel > seems a separate task from duplicating the output to an x11 plot. > > Am I missing the point? Partly so, by my understanding. A large part of the idea behind having a wxwidgets output driver is that it will work not just on X11. Once completed, we should have a GUI terminal driver that works on all major platforms (and maybe some minor ones, too). The way I look at it, maybe its strongest promise is that it may allow us to put the old MS Windows driver to rest. |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-06-29 03:43:45
|
On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote: > Ethan Merritt wrote: > > Am I missing the point? > > Partly so, by my understanding. A large part of the idea behind having > a wxwidgets output driver is that it will work not just on X11. I see. I was confused by Timoth=E9e's screen shots, which showed the plot in an X-window. So you're saying that wxwidgets layers on top of X if the system supports X, and layers on top of something else on systems that don't support X? > The way I look at it, maybe its strongest promise is that it may allow > us to put the old MS Windows driver to rest. At the cost of accepting C++. But I suppose that's a net win :-) =2D-=20 Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-06-29 04:40:41
|
Ethan A Merritt wrote: > On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote: >=20 >>Ethan Merritt wrote: >> >>>Am I missing the point? >> >>Partly so, by my understanding. A large part of the idea behind having >>a wxwidgets output driver is that it will work not just on X11. >=20 >=20 > I see. I was confused by Timoth=E9e's screen shots, which showed the > plot in an X-window. I too thought the plot looked exactly like the X11 plots and was misleadi= ng, but I assumed there was more to come in the way that Hans describes. > So you're saying that wxwidgets layers on top > of X if the system supports X, and layers on top of something else > on systems that don't support X? >=20 <snip> >=20 > At the cost of accepting C++. But I suppose that's a net win :-) But you described before that it should be insulated, right? I.e., some = drivers would be broken out, which means the wxwidgets need only be the o= ne compiled under C++ so long as there is a compatible function call/retu= rn. I guess I can see some advantages to the wxwidgets. For example, I think= it would be a step toward what Octave developers have been pining, i.e.,= a graphics system that resembles Matlab. They've already made moves in = that direction using other plotting engines. (They've a scheme, I think,= to move the plotting engine outside the core so that people can choose w= hat to use; but I've not totally understood what they have in mind.) Dan |
|
From: <tim...@en...> - 2005-06-29 08:56:18
|
Daniel J Sebald wrote: > I guess I can see some advantages to the wxwidgets. For example, I=20 > think it would be a step toward what Octave developers have been=20 > pining, i.e., a graphics system that resembles Matlab. They've=20 > already made moves in that direction using other plotting engines. =20 > (They've a scheme, I think, to move the plotting engine outside the=20 > core so that people can choose what to use; but I've not totally=20 > understood what they have in mind.) > > Dan You're right. I think Octave and Maxima can take advantage in an=20 improved graphic system. Gnuplot has wonderful capabilities, so=20 polishing its backend seems really worthwhile. I plan to send a message to the mailing-lists of Octave and Maxima to=20 ask for their needs and ideas. Timoth=E9e |
|
From: <tim...@en...> - 2005-06-29 08:48:22
|
Ethan A Merritt wrote: >On Tuesday 28 June 2005 07:33 pm, Hans-Bernhard Br=F6ker wrote: > =20 > >> =20 >> >>A large part of the idea behind having >>a wxwidgets output driver is that it will work not just on X11. >> =20 >> > >I see. I was confused by Timoth=E9e's screen shots, which showed the >plot in an X-window. > I'm sorry ;-). The "X" icon is just the default one for wxwidgets apps=20 compiled with gtk. >So you're saying that wxwidgets layers on top >of X if the system supports X, and layers on top of something else >on systems that don't support X? > =20 > Exactly. The screenshots come from the gtk+2 version of wxwidgets, but=20 it can be compiled with the Windows, MacOS, OS/2 versions to get native=20 appearance. >>The way I look at it, maybe its strongest promise is that it may allow >>us to put the old MS Windows driver to rest. >> =20 >> > >At the cost of accepting C++. But I suppose that's a net win :-) > > =20 > This C++ code shouldn't be intrusive, as it's limited to gui=20 functionnalities. Greetings, Timoth=E9e |
|
From: Petr M. <mi...@ph...> - 2005-06-29 13:00:26
|
> I'm still not clear on why you can't wrap your widget set around > a window and then use gnuplot's existing x11 terminal driver to > draw in that window. Probably I am misunderstanding the control > flow. In addition to portability of this GUI-based terminal (with menus), there will be one immediate gain for current X11 users: speed. As the gnuplot -> gnuplot_x11 is still ascii with millions of sprintf() and sscanf(), the new wx terminal will have the transfer speed of the Windows terminal. Drawing maps, surfaces and images will be considerabl faster. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2005-06-29 16:53:40
|
Petr Mikulik wrote: >> I'm still not clear on why you can't wrap your widget set around >> a window and then use gnuplot's existing x11 terminal driver to >> draw in that window. Probably I am misunderstanding the control >> flow. > > > In addition to portability of this GUI-based terminal (with menus), > there will be one immediate gain for current X11 users: speed. As the > gnuplot -> gnuplot_x11 is still ascii with millions of sprintf() and > sscanf(), the new wx terminal will have the transfer speed of the > Windows terminal. Drawing maps, surfaces and images will be considerabl > faster. A comparison should be done, but I wouldn't immediately reach that conclusion. The use of sscanf is definitely not a winner, but Hans' and Ethan's discussion with that speed bug one user reported suggests the problem lies in long lines that have many elements to be scanned. (I.e., that principle Hans' concluded a few years ago in a different discussion list and then forgot.) The sscanf's in the X11 driver are of the variety where only a few items are read (e.g., coordinates) followed by a newline character. That means there are a *lot* of lines in the plot buffer, but they are short and avoid the slow-down issue somewhat. Furthermore, if one chooses the "binary transfer" option I implemented for large data sets such as images and pm3d surfaces (which I think is on by default now and over the past year there have been no complaints about treating an ASCII character as 8 bits of binary data), that should help matters. I don't know what the overhead for refreshing an X11 widget based plot are, but my experience is that the refresh of gnuplot_x11 seems not too bad. A comparison would be interesting. Dan |
|
From: Juergen W. <wie...@fr...> - 2005-06-29 10:49:31
|
Timoth=E9e Lecomte wrote: > Here some news about the wxwidgets terminal I'm writing. Most of the > drawing functions are implemented, as you can see in the two following > screenshots : > > http://tipote.free.fr/wxt3.png > http://tipote.free.fr/wxt4.png The pm3d plot is transparent! Looks nice, but is it intended to be so? Juergen |
|
From: <tim...@en...> - 2005-06-29 11:23:20
|
Juergen Wieferink wrote: >Timoth=E9e Lecomte wrote: > =20 > >>Here some news about the wxwidgets terminal I'm writing. Most of the >>drawing functions are implemented, as you can see in the two following >>screenshots : >> >>http://tipote.free.fr/wxt3.png >>http://tipote.free.fr/wxt4.png >> =20 >> > >The pm3d plot is transparent! Looks nice, but is it intended to be >so? > > >Juergen > =20 > I had to chose in which order things are drawn. Until now, I've decided=20 to group things by categories : polygons, lines, text, fillboxes. And I=20 draw polygons before lines, so lines appear over the pm3d plot, as if it=20 were transparent. However, I can change its behaviour to make things=20 drawn exactly in the order that gnuplot give. I guess that border lines=20 only will be hidden, as you can see with x11 terminal. Timoth=E9e |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-06-29 15:46:46
|
On Wednesday 29 June 2005 06:23 am, Timoth=E9e Lecomte wrote: > > > I had to chose in which order things are drawn. Until now, I've decided=20 > to group things by categories : polygons, lines, text, fillboxes. And I=20 > draw polygons before lines, so lines appear over the pm3d plot, as if it= =20 > were transparent. However, I can change its behaviour to make things=20 > drawn exactly in the order that gnuplot give. I think it is important that objects are drawn in the order given by gnuplot. Otherwise the "front" and "back" qualifiers lose their meaning, and certain plot styles may be oddly rendered (e.g. candlesticks+fill;=20 histograms+errorbars). The plot styles could, if necessary, be rewritten to omit the occluded elements rather than over-writing them with a solid fill, but to me it seems there is value in having the core code be able to control the order of drawing. =2D-=20 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-29 17:01:17
|
Ethan Merritt wrote: > On Wednesday 29 June 2005 06:23 am, Timoth=E9e Lecomte wrote: >=20 >>I had to chose in which order things are drawn. Until now, I've decided= =20 >>to group things by categories : polygons, lines, text, fillboxes. And I= =20 >>draw polygons before lines, so lines appear over the pm3d plot, as if i= t=20 >>were transparent. However, I can change its behaviour to make things=20 >>drawn exactly in the order that gnuplot give. >=20 >=20 > I think it is important that objects are drawn in the order given by > gnuplot. Otherwise the "front" and "back" qualifiers lose their meanin= g, > and certain plot styles may be oddly rendered (e.g. candlesticks+fill;=20 > histograms+errorbars). The plot styles could, if necessary, be rewritte= n > to omit the occluded elements rather than over-writing them with a soli= d > fill, but to me it seems there is value in having the core code be > able to control the order of drawing. Agreed. This also makes one's life easier. That would still leave open = the possibility for altering the plot after the fact via something like t= kwidgets, but at the driver level maintain order. Dan |
