From: <pl...@pi...> - 2011-05-12 06:35:42
|
Hi, I work quite a lot with time data (years and month scale) . Although gnuplot is very flexible in reading time data and labelling x axis the mouse cursor seems a bit challenged. If I have "%Y %m" , having 6.004538e+09 as mouse coord is really little more than useless. Since the scaling is available for axis labels why isn't this applied to the mouse coords? It would seem to be very simple and I can't see the utility in the current date in seconds. Is this just an oversight? regards, Peter. |
From: sfeam (E. Merritt) <eam...@gm...> - 2011-05-12 15:14:11
|
On Wednesday, 11 May 2011, pl...@pi... wrote: > Hi, > > I work quite a lot with time data (years and month scale) . Although > gnuplot is very flexible in reading time data and labelling x axis the > mouse cursor seems a bit challenged. > > If I have "%Y %m" , having 6.004538e+09 as mouse coord is really little > more than useless. > > Since the scaling is available for axis labels why isn't this applied to > the mouse coords? It would seem to be very simple and I can't see the > utility in the current date in seconds. > > Is this just an oversight? Mouse coordinate readout is available in 5 or 6 different formats, including user-specified. See "help mouseformat" and the help message printed by typing "h" in the plot window. In general you can cycle through the different options using the characters "1" and "2" as hotkeys. |
From: <pl...@pi...> - 2011-05-12 17:51:24
|
On 05/12/11 17:13, sfeam (Ethan Merritt) wrote: > On Wednesday, 11 May 2011, pl...@pi... wrote: >> Hi, >> >> I work quite a lot with time data (years and month scale) . Although >> gnuplot is very flexible in reading time data and labelling x axis the >> mouse cursor seems a bit challenged. >> >> If I have "%Y %m" , having 6.004538e+09 as mouse coord is really little >> more than useless. >> >> Since the scaling is available for axis labels why isn't this applied to >> the mouse coords? It would seem to be very simple and I can't see the >> utility in the current date in seconds. >> >> Is this just an oversight? > > Mouse coordinate readout is available in 5 or 6 different formats, > including user-specified. See "help mouseformat" and the help > message printed by typing "h" in the plot window. > In general you can cycle through the different options using the > characters "1" and "2" as hotkeys. > > Hi Ethan, thanks for that. It appears that there is not mouseformat help but I did find it under mouse. gnuplot> help mouseformat Sorry, no help for 'mouseformat' gnuplot> help mouse I had tried the h key help but had not appreciated what those variables referred to: 1 `builtin-decrement-mousemode` 2 `builtin-increment-mousemode` Maybe those terms could be more explicit, it's not clear what they refer to. The content of the various modes is equally a bit arcane and the help doesn't: >> This corresponds to the key >> bindings '1', '2', '3', '4' (see the driver's documentation) I find no detail for example in help wxt. What does this comment refer to? While the subject is being raised , may I suggest a couple of possible feature improvements in this area? 1) This cycling of "mode" could also be done by clicking on the status message (click is mapped to "1" key). This would avoid switching mouse to keyboard which can be handy. 2) As I understand it this only shows x1y1 coords. It would clearly be useful when using x2y2 as well if those were available in this read-out. One way to trigger this would be a click on the legend entry for a line or on/near the relevant axis. (some thought needed to avoid ambiguity with the new SVG toggle , pause mouse or other functions. ) Not priority issues but hopefully useful. best regards, Peter. |
From: sfeam (E. Merritt) <eam...@gm...> - 2011-05-13 03:27:45
|
On Thursday, 12 May 2011, pl...@pi... wrote: > > I had tried the h key help but had not appreciated what those variables > referred to: > > 1 `builtin-decrement-mousemode` > 2 `builtin-increment-mousemode` > > Maybe those terms could be more explicit, it's not clear what they refer > to. > > The content of the various modes is equally a bit arcane and the help > doesn't: > > >> This corresponds to the key > >> bindings '1', '2', '3', '4' (see the driver's documentation) > > I find no detail for example in help wxt. What does this comment refer to? I was surprised to find that the documentation is seriously out of date, as in "doesn't describe the actual behavior of any gnuplot version since before the start of the CVS repository". I have now updated the 4.5 documentation a bit. > While the subject is being raised , may I suggest a couple of possible > feature improvements in this area? > > 1) This cycling of "mode" could also be done by clicking on the status > message (click is mapped to "1" key). This would avoid switching mouse > to keyboard which can be handy. Could be done, certainly, but there is currently no code to interpret the mouse location in terms like "on the status message". > 2) As I understand it this only shows x1y1 coords. It would clearly be > useful when using x2y2 as well if those were available in this read-out. > One way to trigger this would be a click on the legend entry for a > line or on/near the relevant axis. (some thought needed to avoid > ambiguity with the new SVG toggle , pause mouse or other functions. ) Huh. For me the x2y2 axes are echoed properly if they are active in the current plot. Tested on wxt, x11, and canvas. It is true that I ignored x2y2 in the very recent svg mouse-tracking code. What terminal are you using that fails to show them? Ethan |
From: <pl...@pi...> - 2011-05-13 14:21:50
|
On 05/13/11 05:27, sfeam (Ethan Merritt) wrote: > On Thursday, 12 May 2011, pl...@pi... wrote: >> >> I had tried the h key help but had not appreciated what those variables >> referred to: >> >> 1 `builtin-decrement-mousemode` >> 2 `builtin-increment-mousemode` >> >> Maybe those terms could be more explicit, it's not clear what they refer >> to. >> >> The content of the various modes is equally a bit arcane and the help >> doesn't: >> >> >> This corresponds to the key >> >> bindings '1', '2', '3', '4' (see the driver's documentation) >> >> I find no detail for example in help wxt. What does this comment refer to? > > I was surprised to find that the documentation is seriously out of date, > as in "doesn't describe the actual behavior of any gnuplot version since > before the start of the CVS repository". I have now updated the 4.5 > documentation a bit. OK, thanks, glad you caught that one. > >> While the subject is being raised , may I suggest a couple of possible >> feature improvements in this area? >> >> 1) This cycling of "mode" could also be done by clicking on the status >> message (click is mapped to "1" key). This would avoid switching mouse >> to keyboard which can be handy. > > Could be done, certainly, but there is currently no code to interpret the > mouse location in terms like "on the status message". Well there is click on graph area (pause mouse etc) so I would have thought x_bottom_graph and x_bottom_window would be close to what is needed. > >> 2) As I understand it this only shows x1y1 coords. It would clearly be >> useful when using x2y2 as well if those were available in this read-out. >> One way to trigger this would be a click on the legend entry for a >> line or on/near the relevant axis. (some thought needed to avoid >> ambiguity with the new SVG toggle , pause mouse or other functions. ) > > Huh. For me the x2y2 axes are echoed properly if they are active in the > current plot. Tested on wxt, x11, and canvas. It is true that I ignored > x2y2 in the very recent svg mouse-tracking code. What terminal are you > using that fails to show them? Sorry , my incorrect recollection. It most likely was in relation to the SVG changes that I'd retained that idea. > > Ethan > |
From: Bastian M. <bma...@we...> - 2011-05-13 14:56:58
Attachments:
mousemode.patch
|
Am 13.05.2011 14:35, schrieb pl...@pi...: >>> While the subject is being raised , may I suggest a couple of possible >>> feature improvements in this area? >>> >>> 1) This cycling of "mode" could also be done by clicking on the status >>> message (click is mapped to "1" key). This would avoid switching mouse >>> to keyboard which can be handy. >> >> Could be done, certainly, but there is currently no code to interpret the >> mouse location in terms like "on the status message". > > Well there is click on graph area (pause mouse etc) so I would have > thought x_bottom_graph and x_bottom_window would be close to what is > needed. Mouse events outside the graph area don't get passed on to the gnuplot kernel. It would be straight forward to translate those events to keyboard events, though. A trivial patch for Windows is attached. Bastian |