Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-21 17:58:21
|
On Thu, 21 Oct 2004, Per Persson wrote: > I'm considering adding code to make aqua the default terminal to the > stable branch, as in CVS HEAD, but I'm not sure if that qualifies as a > *neccessary* change. I would think it is reasonable to put the fix in there, on the basis of the resulting binary being effectively unusable as designed, without it. The fact that this code hasn't been in CVS at the time of 4.0.0 release was clearly a bug by oversight, so this is a bug fix, and should go in. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-21 18:06:51
|
On Thu, 21 Oct 2004, Daniel J Sebald wrote: > I haven't been following, sorry. How does this default work? It seems > to me that a "default terminal" is something that the user should be > able to configure without having to recompile anything. That's not what this is about. The default terminal driver is the mechanism that lets you just start gnuplot and 'plot x', without setting any terminal driver first, and have the "obviously correct" thing happen: get a plot to X11 on Unix, to Windows GUI on MS Windows, to PM on OS/2, etc. The aquaterm driver forgot to set up this default, so gnuplot would startup with terminal 'unknown'. That's silly. > I know there is some reluctance to add default mechanisms to gnuplot. > Is there some way already of automatically loading a file at startup? Of course there is. "help startup" even tells you what it is ;-) -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2004-10-21 18:17:58
|
Hans-Bernhard Broeker wrote: >On Thu, 21 Oct 2004, Daniel J Sebald wrote: > > > >>I haven't been following, sorry. How does this default work? It seems >>to me that a "default terminal" is something that the user should be >>able to configure without having to recompile anything. >> >> > >That's not what this is about. The default terminal driver is the >mechanism that lets you just start gnuplot and 'plot x', without setting >any terminal driver first, and have the "obviously correct" thing happen: >get a plot to X11 on Unix, to Windows GUI on MS Windows, to PM on OS/2, >etc. The aquaterm driver forgot to set up this default, so gnuplot would >startup with terminal 'unknown'. That's silly. > I tried running gnuplot from outside of X an hour or so ago and saw the 'unknown' so got the idea. Yes, that should be fixed. >>I know there is some reluctance to add default mechanisms to gnuplot. >>Is there some way already of automatically loading a file at startup? >> >> > >Of course there is. "help startup" even tells you what it is ;-) > "startup"! (Not "defaults".) That's what I was looking for. :) Thanks. Dan |
|
From: Per P. <per...@ma...> - 2004-10-21 21:06:05
|
On Oct 21, 2004, at 20:06, Hans-Bernhard Broeker wrote: > The aquaterm driver forgot to set up this default, so gnuplot would > startup with terminal 'unknown'. That's silly. > Actually, on 10.3 and any previous system with X11 installed it will startup with terminal x11. Somewhat better than 'unknown' ;-) /Per |
|
From: Daniel J S. <dan...@ie...> - 2004-10-21 21:54:54
|
Per Persson wrote: > > On Oct 21, 2004, at 20:06, Hans-Bernhard Broeker wrote: > >> The aquaterm driver forgot to set up this default, so gnuplot would >> startup with terminal 'unknown'. That's silly. >> > > Actually, on 10.3 and any previous system with X11 installed it will > startup with terminal x11. > Somewhat better than 'unknown' ;-) Ah. I'm starting to get the picture on how Aqua functions. The suggested fixes all sound logical to me. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-21 22:07:27
|
On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote: > > > > Actually, on 10.3 and any previous system with X11 installed it will > > startup with terminal x11. > > Somewhat better than 'unknown' ;-) > > Ah. I'm starting to get the picture on how Aqua functions. The > suggested fixes all sound logical to me. I hesitate a little to say this, but it seems to me that unless and until aquaterm provides all the features of x11, it is better to default to x11. If there is something in particular that users need from aquaterm, they can easily do a 'set term'. But new users who are presented with aquaterm by default may not even realize that they are missing out on capabilities (Mousing!) they would have had under x11. Per has been doing a great job of developing the aquaterm option, but so far as I can tell it's still not quite up to the level of the other primary gnuplot interfaces. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Per P. <per...@ma...> - 2004-10-22 07:24:32
|
On Oct 22, 2004, at 00:07, Ethan Merritt wrote: > On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote: >>> >>> Actually, on 10.3 and any previous system with X11 installed it will >>> startup with terminal x11. >>> Somewhat better than 'unknown' ;-) >> >> Ah. I'm starting to get the picture on how Aqua functions. The >> suggested fixes all sound logical to me. > > I hesitate a little to say this, but it seems to me that unless and > until aquaterm provides all the features of x11, it is better to > default to x11. No problem. We'll just let it be the default if x11 is not available. > > > If there is something in particular that users > need from aquaterm, they can easily do a 'set term'. But > new users who are presented with aquaterm by default may > not even realize that they are missing out on capabilities > (Mousing!) they would have had under x11. > > Per has been doing a great job of developing the aquaterm > option, but so far as I can tell it's still not quite up to the level > of the other primary gnuplot interfaces. As far as mousing is concerned, I had a quick look and hacked up aquaterm.trm to support passing events from aquaterm windows some time ago. I never finished it because I couldn't figure out how aquaterm events and keyboard events (at the prompt, not in the plot window) were supposed to interact. I seems to me that the driver will have to duplicate the main event loop and take over control while mousing is active. I'm reluctant to have an opininon where I don't intend to put down work, but wouldn't it be cleaner to have a single event loop and an event queue where any input unit (keystrokes at the prompt, mouse clicks etc.) put their events to be processed by the event loop in a timely manner? By making events (i.e. their structure) device independent at the level of the main loop/event queue the drivers would only have to translate an event as it is recieved and could then forget about it. An any case, this is not something I have strong opinions about and in case anyone feels like working on providing event support for the aquaterm driver I'd gladly provide as much help as I can. /Per |
|
From: Daniel J S. <dan...@ie...> - 2004-10-22 15:03:11
|
Per Persson wrote: > > On Oct 22, 2004, at 00:07, Ethan Merritt wrote: > >> On Thursday 21 October 2004 03:22 pm, Daniel J Sebald wrote: >> >>>> >>>> Actually, on 10.3 and any previous system with X11 installed it will >>>> startup with terminal x11. >>>> Somewhat better than 'unknown' ;-) >>> >>> >>> Ah. I'm starting to get the picture on how Aqua functions. The >>> suggested fixes all sound logical to me. >> >> >> I hesitate a little to say this, but it seems to me that unless and >> until aquaterm provides all the features of x11, it is better to >> default to x11. > > > No problem. We'll just let it be the default if x11 is not available. That sounds OK for 4.0 errata, but I'd suggest for 4.1 and CVS to make Aqua the default if Aqua is what is running. That encourages its use and users give feedback about the terminal. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-22 16:45:04
|
On Friday 22 October 2004 12:24 am, Per Persson wrote: > > I seems to me that the driver will have to duplicate the main event > loop and take over control while mousing is active. > > I'm reluctant to have an opininon where I don't intend to put down > work, but wouldn't it be cleaner to have a single event loop and an > event queue where any input unit (keystrokes at the prompt, mouse > clicks etc.) put their events to be processed by the event loop in a > timely manner? That is the way it works now for x11 and ggi, yes. The driver provides a routine (*term)->waitforinput() that merges the input stream from the keyboard and from the plot window[s]. Events pulled from this merged input stream are either handled by the caller, e.g. interpret new command line, or by the mousing code, e.g. do_event() in mouse.c. > By making events (i.e. their structure) device independent at the level > of the main loop/event queue the drivers would only have to translate > an event as it is recieved and could then forget about it. Yep. That's the idea, and the core code is already in place. It's just that up until now not many of the drivers actually use it. But it sounds to me that most of the work in adding mousing to aquaterm would consist of (1) providing an AQUA_waitforinput() routine, and (2) implementing the terminal-specific draw commands for mouse-coordinate printout and rulers (optional). The rest of it, including hot-keys and zooming, should "just work". > An any case, this is not something I have strong opinions about and in > case anyone feels like working on providing event support for the > aquaterm driver I'd gladly provide as much help as I can. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-10-25 10:40:53
|
> As far as mousing is concerned, I had a quick look and hacked up > aquaterm.trm to support passing events from aquaterm windows some time > ago. > I never finished it because I couldn't figure out how aquaterm events > and keyboard events (at the prompt, not in the plot window) were > supposed to interact. > > I seems to me that the driver will have to duplicate the main event > loop and take over control while mousing is active. Currently, there are 3 approaches for mouse communication, see src/README. E.g., OS/2 uses a thread. --- PM |
|
From: Per P. <per...@ma...> - 2004-10-21 21:05:54
|
On Oct 21, 2004, at 19:58, Hans-Bernhard Broeker wrote: > The fact that this code hasn't been in CVS at the time of 4.0.0 release > was clearly a bug by oversight, so this is a bug fix, and should go in. > OK, I'll fix that then. /Per |
