Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 07:55:53
|
The ctrl-c copy was easy enough. Just replace "c" with "ctrl-c"...
Anyway, I see when typing 'h' for a plot to get the key bindings there are these
two at the very top (i.e., follow the button description):
Space raise gnuplot console window
q * close this X11 plot window
[snip]
* indicates this key is active from all plot windows
I'm assuming that by the use of term->(function) the mouse/keyboard interface is
meant to be very general and not restricted to X11. Is that right, i.e., maybe
it can be used on a different window environment and all the bindings behave the
same.
So, I'm wondering
1) Why use the word X11 in the documentation? (Would the user care?)
2) Why the footnote that this key is active for all plot windows? (Aren't all
keys active for all the plot windows? Or does this mean for all window-based
terminals?)
3) Why not simply put the 'q' in the regular list of bindings? It may be that
higher level code doesn't send a GE_keypress code to the mouse do_event() but
instead a GE_reset. However, if one simply binds the 'q' to a function that all
it does is return 'close plot window' for the documentation, it still makes
sense so long as the higher level code. If the user applies the -ctrlq option
the 'q' binding no longer makes sense, but that is still the case the way it
currently is in the documentation. Also, gnuplot shouldn't allow the user to
bind 'q' and 'space'. If I type
bind "q" 'print "great"'
the list of bindings shows
q * close this X11 plot window
[snip]
q `print "great"'
I guess all I'm saying is there doesn't seem to be a need for special
documenting for these so long as we expect in all GUI terminals that 'q' means
'close window' and 'space' means 'raise window'.
4) How does one change bindings for the current builtin-xxxxxx?
|
|
From: Petr M. <mi...@ph...> - 2007-05-31 09:24:29
|
> q * close this X11 plot window > > I'm assuming that by the use of term->(function) the mouse/keyboard interface is > meant to be very general and not restricted to X11. Is that right, i.e., maybe > it can be used on a different window environment and all the bindings behave the > > 1) Why use the word X11 in the documentation? (Would the user care?) q hotkey does not work on OS/2 and Windows (= not implemented) It works on x11 and wxt. On Mac? Should the message be changed? E.g. close this plot window (x11, wxt only) > 4) How does one change bindings for the current builtin-xxxxxx? By the usual bind command. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-05-31 15:44:35
|
On Thursday 31 May 2007 02:24, Petr Mikulik wrote: > > q * close this X11 plot window > > > > I'm assuming that by the use of term->(function) the mouse/keyboard interface is > > meant to be very general and not restricted to X11. Is that right, i.e., maybe > > it can be used on a different window environment and all the bindings behave the > > > > 1) Why use the word X11 in the documentation? (Would the user care?) > > q hotkey does not work on OS/2 and Windows (= not implemented) > It works on x11 and wxt. For some value of "works". I think it was a design mistake to treat 'q' and ' ' as special-case keys, because it seriously interferes with implementing a general hot-key/bind interface. For instance, suppose you want to allow the user to type in plot titles interactively (e.g. 'mouselabels.dem'). How do you explain to the user that his labels can contain any character except 'q' or ' '? You can disable 'q' in x11 by shifting the magic key to 'ctrl-q' instead: gnuplot*ctrlq: on But this is awkward, since it needs to be done externally. Also it doesn't work for the wxt terminal. I would favor getting rid of the 'q' and ' ' hard-wired hotkeys, or at least make them default bindings that can be turned off by a script. > > 4) How does one change bindings for the current builtin-xxxxxx? > > By the usual bind command. Except that you can't bypass 'q' or ' ' this way. IMHO this is a serious bug or design flaw. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 17:37:11
|
Ethan A Merritt wrote: [snip] > Except that you can't bypass 'q' or ' ' this way. > IMHO this is a serious bug or design flaw. I was feeling the same way when reading the documentation. Of course, if there is no mouse, one would still like x11 term to have its 'q' and ' ', but it doesn't seem like it should be difficult to override those or turn them off somehow with a simple chararacter string command to gnuplot_x11. Dan |
|
From: Petr M. <mi...@ph...> - 2007-05-31 16:00:50
|
> I think it was a design mistake to treat 'q' and ' ' as special-case keys,
> because it seriously interferes with implementing a general hot-key/bind
> interface.
These keys were functioning ages before the bind.
> You can disable 'q' in x11 by shifting the magic key to 'ctrl-q' instead:
> gnuplot*ctrlq: on
>
> But this is awkward, since it needs to be done externally.
> Also it doesn't work for the wxt terminal.
>
> I would favor getting rid of the 'q' and ' ' hard-wired hotkeys, or
> at least make them default bindings that can be turned off by a script.
Yes, to be changed via 'bind'.
And there could be
term->set_interactive('hotkey', 'q', 'disable')
term->set_interactive('hotkey', 'q', 'enable')
Well -- is there any possibility to get back the built-in command?
E.g.
bind a 'plot x'
bind a builtin-autoscale
does not work.
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-05-31 16:28:47
|
On Thursday 31 May 2007 09:00, Petr Mikulik wrote:
> Well -- is there any possibility to get back the built-in command?
> E.g.
> bind a 'plot x'
> bind a builtin-autoscale
> does not work.
You can reset using an empty string:
bind a ''
You can reset all bindings at once using
bind!
Neither of these options is well documented.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-05-31 16:36:14
|
On Thursday 31 May 2007 00:55, Daniel J Sebald wrote:
>
> Anyway, I see when typing 'h' for a plot to get the key bindings there are these
> two at the very top (i.e., follow the button description):
>
>
> Space raise gnuplot console window
> q * close this X11 plot window
>
> [snip]
>
> * indicates this key is active from all plot windows
>
>
> 2) Why the footnote that this key is active for all plot windows?
> (Aren't all keys active for all the plot windows?
No. Only the keys with an asterisk next to the binding.
This is the difference between
bind <key> "action"
and
bind allwindows <key> "action"
--
Ethan A Merritt
|
|
From: <tim...@en...> - 2007-05-31 19:33:10
|
> The ctrl-c copy was easy enough. Just replace "c" with "ctrl-c"... > > Anyway, I see when typing 'h' for a plot to get the key bindings there are > these > two at the very top (i.e., follow the button description): > > > Space raise gnuplot console window > q * close this X11 plot window > > [snip] > > * indicates this key is active from all plot windows > > I'm assuming that by the use of term->(function) the mouse/keyboard > interface is > meant to be very general and not restricted to X11. I will try not to repeat what was said by Ethan and Petr, but here are my thoughts on this: "raise console" and "quit plot window" do not go through the event system (because they predate it), they are handled directly by the terminal. That's why ' ' and 'q' are keys that you cannot bind to something else, with the exception of the 'ctrl-q' option in x11 and wxt. There's no term->close right now, nor is there a term->raiseconsole (and that's fortunate, since raising _gnuplot console_ is not the _plot window_ business). > Is that right, i.e., maybe > it can be used on a different window environment and all the bindings > behave the > same. > > So, I'm wondering > > 1) Why use the word X11 in the documentation? (Would the user care?) True, that should be fixed. > > 2) Why the footnote that this key is active for all plot windows? (Aren't > all > keys active for all the plot windows? Or does this mean for all > window-based > terminals?) > Most keys, like the one for 'replot' only work in the active (i.e. current terminal) window. > 3) Why not simply put the 'q' in the regular list of bindings? You need a term->close to do that. That's not difficult to write, most of the code is already in place (for 'set term ... close' in particular). _However_, that way 'q' would not work anymore if wxt (or x11, or any screen terminal that is concerned by this) is not the current active terminal. For example, see the following: set term wxt plot x 'q' -> the window is closed plot x -> the window appears again set term png 'q' -> nothing happens, because events from wxt are no longer processed Read further for ideas to workaround this situation. > If the user applies the -ctrlq option > the 'q' binding no longer makes sense, but that is still the case the way > it > currently is in the documentation. Also, gnuplot shouldn't allow the user > to > bind 'q' and 'space'. If I type > > bind "q" 'print "great"' > > the list of bindings shows > > q * close this X11 plot window > [snip] > q `print "great"' Those problems are a result of 'q' not being really handled by the event system in the first place. Please note that we already have some of the code to change that situation right now: First, there's patch #1474309 to make ' ' be a normal hotkey (writing a similar patch for 'q' would be even smaller). The only issue before committing is precisely the one illustrated above: the key doesn't work anymore if the screen terminal is no longer the active one in the gnuplot session, because events are only processed from the active terminal. We understood the issue, and Ethan even wrote a patch for it : it's #1500654... (read the patch summary, it's exactly the discussion here!) and he closed the patch himself too... I have thought about this for quite a long time, here is my conclusion: We cannot call several term->waitforinput() at the same time, or even sequentially, because they are all blocking calls, so the approach taken by Ethan would not work if we want to use _both_ X11 and wxt in the same session for example. Making term->waitforinput non-blocking means using a poll with a timeout, and I think it's quite bad to do so (i.e. it means regular wakeups, which implies among other things high battery usage on a laptop, see www.linuxpowertop.org). I see two alternatives to this: 1) Choose one (and only one) so-called 'screen terminal' that would be privileged and see its events being processed even if it is not the current one. If wxt is the 'screen terminal', x11 could still be chosen, but it wouldn't get any interactive behaviour (well, actually it would partially, since gnuplot_x11 is able to give mouse coordinated without the core having to say anything) 2) Have a more general event loop system where a terminal could "install" event sources... for example it is easy to watch for *several* file-descriptors on unix-like systems _at the same time_, without polling regularly. In a wxWidgets-on-GTK event loop, these file descriptors would be: -stdin, for gnuplot command-line, -the file descriptor that wxt is using for its connection to the X server, -the file descriptor for the pipe that the x11 terminal uses to talk to gnuplot_x11 That way, the event loop could handle the events from both wxt and x11, and we could make 'q' and ' ' always working, even for an inactive plot window. The only drawback of this approach is that it's slightly platform-specific. On Windows, the loop would most likely wait for so-called 'messages' instead of file descriptors... and note that this is already how it works on Windows ! There's no term->waitforinput() there, only a getc wrapper that actually processes the "messages" and we could write a patch right now that does #2. On Unix, we would have to do something like what is done in x11->waitforinput, where select() is used to wait for stdin _and_ the pipe at the same time... Wow, what a long message... Don't hesitate to comment. Timothée |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 19:55:45
|
Timothée Lecomte wrote:
>>The ctrl-c copy was easy enough. Just replace "c" with "ctrl-c"...
>>
>>Anyway, I see when typing 'h' for a plot to get the key bindings there are
>>these
>>two at the very top (i.e., follow the button description):
>>
>>
>> Space raise gnuplot console window
>> q * close this X11 plot window
>>
>>[snip]
>>
>> * indicates this key is active from all plot windows
>>
>>I'm assuming that by the use of term->(function) the mouse/keyboard
>>interface is
>>meant to be very general and not restricted to X11.
>
>
>
> I will try not to repeat what was said by Ethan and Petr, but here are my
> thoughts on this:
>
> "raise console" and "quit plot window" do not go through the event system
> (because they predate it), they are handled directly by the terminal.
> That's why ' ' and 'q' are keys that you cannot bind to something else,
> with the exception of the 'ctrl-q' option in x11 and wxt.
Right, but the question is why must the documentation for 'q' and ' ' be
special, sitting out on its own? Why can't the 'q' and ' ' simply be placed in
the bindings documentation?
As you explained, the mouse-in-only-one-window limitation came back to me, so
that is why the asterisk. Yet, some would consider the mouse-in-only-one-window
a bug in itself.
> There's no term->close right now, nor is there a term->raiseconsole (and
> that's fortunate, since raising _gnuplot console_ is not the _plot window_
> business).
Petr would think otherwise, I'm guessing from his past posts. There is the
set term x11 close
which could be bound to a key.
> Wow, what a long message... Don't hesitate to comment.
No comment on specific terminal implementations, only that it seems easy to fix
this.
Dan
|
|
From: <tim...@en...> - 2007-05-31 20:03:05
|
> Timothée Lecomte wrote: >>>The ctrl-c copy was easy enough. Just replace "c" with "ctrl-c"... >>> >>>Anyway, I see when typing 'h' for a plot to get the key bindings there >>> are >>>these >>>two at the very top (i.e., follow the button description): >>> >>> >>> Space raise gnuplot console window >>> q * close this X11 plot window >>> >>>[snip] >>> >>> * indicates this key is active from all plot windows >>> >>>I'm assuming that by the use of term->(function) the mouse/keyboard >>>interface is >>>meant to be very general and not restricted to X11. >> >> >> >> I will try not to repeat what was said by Ethan and Petr, but here are >> my >> thoughts on this: >> >> "raise console" and "quit plot window" do not go through the event >> system >> (because they predate it), they are handled directly by the terminal. >> That's why ' ' and 'q' are keys that you cannot bind to something else, >> with the exception of the 'ctrl-q' option in x11 and wxt. > > Right, but the question is why must the documentation for 'q' and ' ' be > special, sitting out on its own? Why can't the 'q' and ' ' simply be > placed in > the bindings documentation? They are. Quote: "By default, the <space> hotkey raises gnuplot's command window. On some terminals (e.g. x11, wx, pm), 'q' closes the graph window. These defaults can be changed to ctrl-space and ctrl-q by starting gnuplot as 'gnuplot -ctrlq', see `x11 command-line-options`, or by the X Resource 'gnuplot*ctrlq'. Note: if <space> (or ctrl-space) does not raise the gnuplot window under X11, see discussion in `raise`." > > As you explained, the mouse-in-only-one-window limitation came back to me, > so > that is why the asterisk. Yet, some would consider the > mouse-in-only-one-window > a bug in itself. > Admittedly. This is another topic though. > >> There's no term->close right now, nor is there a term->raiseconsole (and >> that's fortunate, since raising _gnuplot console_ is not the _plot >> window_ >> business). > > Petr would think otherwise, I'm guessing from his past posts. There is > the > > set term x11 close > > which could be bound to a key. > > >> Wow, what a long message... Don't hesitate to comment. > > No comment on specific terminal implementations, only that it seems easy > to fix this. I'll repeat myself, maybe you lost it in the noise of my message: The easy fix means a big regression; 'q' and ' ' would not always work anymore, but only when the terminal is the active one. > > Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 20:29:34
|
Timothée Lecomte wrote: > They are. Quote: > "By default, the <space> hotkey raises gnuplot's command window. On some > terminals (e.g. x11, wx, pm), 'q' closes the graph window. These defaults > can > be changed to ctrl-space and ctrl-q by starting gnuplot as 'gnuplot -ctrlq', > see `x11 command-line-options`, or by the X Resource 'gnuplot*ctrlq'. > Note: if <space> (or ctrl-space) does not raise the gnuplot window under > X11, > see discussion in `raise`." Right, but I'm saying that the following documenation is equally as good/bad: <Shift-B2-Motion> vertical motion -- change xyplane Space `builtin-raise-window` raise gnuplot console window a `builtin-autoscale` (set autoscale keepfix; replot) b `builtin-toggle-border` e `builtin-replot` g `builtin-toggle-grid` h `builtin-help` l `builtin-toggle-log` y logscale for plots, z and cb logscale for splots L `builtin-nearest-log` toggle logscale of axis nearest cursor m `builtin-toggle-mouse` r `builtin-toggle-ruler` 1 `builtin-decrement-mousemode` 2 `builtin-increment-mousemode` 3 `builtin-decrement-clipboardmode` 4 `builtin-increment-clipboardmode` 5 `builtin-toggle-polardistance` 6 `builtin-toggle-verbose` 7 `builtin-toggle-ratio` n `builtin-zoom-next` go to next zoom in the zoom stack p `builtin-zoom-previous` go to previous zoom in the zoom stack q `builtin-close-window` close this plot window u `builtin-unzoom` Right `builtin-rotate-right` only for splots; <shift> increases amount Up `builtin-rotate-up` only for splots; <shift> increases amount Left `builtin-rotate-left` only for splots; <shift> increases amount Down `builtin-rotate-down` only for splots; <shift> increases amount Escape `builtin-cancel-zoom` cancel zoom region *IF* we say that > I'll repeat myself, maybe you lost it in the noise of my message: The easy > fix means a big regression; 'q' and ' ' would not always work anymore, but > only when the terminal is the active one. is a bug. And then fix it sooner than later. :-) Besides, that's another thing we could easily change. 'q' and ' ' have nothing to do with redrawing, so there is no need to disable those. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-31 20:35:15
|
On Thursday 31 May 2007 12:55, Daniel J Sebald wrote: > As you explained, the mouse-in-only-one-window limitation came back to me, so > that is why the asterisk. Yet, some would consider the mouse-in-only-one-window > a bug in itself. It's not a bug. It's an intrinsic limitation of the way gnuplot operates. Most of the hot-keys, like e=replot l=log-scale, etc, require redrawing the plot from scratch. But that is only possible for the currently active plot window. We have long since lost the context and information needed to redraw old plot windows, so we cannot respond to those hot-keys. Possibly the r=ruler key could default to all windows. I'm not sure. -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 20:56:16
|
Ethan Merritt wrote:
> On Thursday 31 May 2007 12:55, Daniel J Sebald wrote:
>
>>As you explained, the mouse-in-only-one-window limitation came back to me, so
>>that is why the asterisk. Yet, some would consider the mouse-in-only-one-window
>>a bug in itself.
>
>
> It's not a bug. It's an intrinsic limitation of the way gnuplot operates.
Ah, ILOTWIO. I'll have remember that one. :-)
> Most of the hot-keys, like e=replot l=log-scale, etc, require redrawing the
> plot from scratch. But that is only possible for the currently active
> plot window. We have long since lost the context and information needed
> to redraw old plot windows, so we cannot respond to those hot-keys.
>
> Possibly the r=ruler key could default to all windows. I'm not sure.
The allwindows is already in the binding structure, and the code says
new->allwindows = FALSE; /* Can be explicitly set later */
but I don't see where any function making it easy to do so for the builtins and
the binding pointer is tossed. A little change would be needed there. (Maybe
as easy as simply returning the binding pointer from the bind_append routine.)
Dan
|
|
From: Petr M. <mi...@ph...> - 2007-05-31 20:39:48
|
> I'll repeat myself, maybe you lost it in the noise of my message: The easy > fix means a big regression; 'q' and ' ' would not always work anymore, but > only when the terminal is the active one. 'q' and ' ' should work as they are. It is sufficient and a very clean way to switch them on/off by a term->xxxx() command I proposed earlier. --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-31 20:47:38
|
On Thursday 31 May 2007 13:39, Petr Mikulik wrote: > > I'll repeat myself, maybe you lost it in the noise of my message: The e= asy > > fix means a big regression; 'q' and ' ' would not always work anymore, = but > > only when the terminal is the active one. >=20 > 'q' and ' ' should work as they are. It is sufficient and a very clean wa= y=20 > to switch them on/off by a term->xxxx() command I proposed earlier. Petr: It is not as simple as you make it sound. Consider the example Timoth=E9e already mentioned. You have an old x11 plot window open, but the current terminal is something else. Maybe wxt, maybe postscript, ... whatever. In this state, keystroke events in the old x11 plot window will not be=20 delivered to the core gnuplot routines, and so they cannot be handled by the normal "bind" mechanism. We work around this by having gnuplot_x11 handle 'q' locally, but this requires treating it as a special case. If we move the 'q' response into the normal event_keypress() code in mouse.c, it will no longer be possible to close plot windows opened by a previous terminal type. In other words, the problem is not lack of a term->xxxx() mechanism. The problem is in receiving the keystroke event notification. =2D-=20 Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 21:03:21
|
Ethan Merritt wrote: > On Thursday 31 May 2007 13:39, Petr Mikulik wrote: > >>>I'll repeat myself, maybe you lost it in the noise of my message: The easy >>>fix means a big regression; 'q' and ' ' would not always work anymore, but >>>only when the terminal is the active one. >> >>'q' and ' ' should work as they are. It is sufficient and a very clean way >>to switch them on/off by a term->xxxx() command I proposed earlier. > > > Petr: > > It is not as simple as you make it sound. > Consider the example Timothée already mentioned. > You have an old x11 plot window open, but the current terminal > is something else. Maybe wxt, maybe postscript, ... whatever. > > In this state, keystroke events in the old x11 plot window will not be > delivered to the core gnuplot routines, and so they cannot be handled > by the normal "bind" mechanism. Isn't that what the "allwindows" setting is for? We work around this by > having gnuplot_x11 handle 'q' locally, but this requires treating it > as a special case. If we move the 'q' response into the normal > event_keypress() code in mouse.c, it will no longer be possible to > close plot windows opened by a previous terminal type. You're saying that because the terminal was changed, the term->xxxx mechanism will point to the terminal the window is not part of. Can the terminal pointer be saved somewhere, or would that require a new system of linked lists? Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 21:06:59
|
Ethan Merritt wrote:
> I may have mis-counted, but I only see that one built-in ('r') that can
> possibly work for anything but the current window. And I'm not even sure
> about that one. Try hard-wiring it to allwindows=TRUE, and tell me what
> happens :-)
I'm guessing it will change/activate something in the wrong window because we
aren't keeping track of the X11 window number or some similar identifier.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-31 21:10:41
|
On Thursday 31 May 2007 14:06, Daniel J Sebald wrote:
> Ethan Merritt wrote:
>
> > I may have mis-counted, but I only see that one built-in ('r') that can
> > possibly work for anything but the current window. And I'm not even sure
> > about that one. Try hard-wiring it to allwindows=TRUE, and tell me what
> > happens :-)
>
> I'm guessing it will change/activate something in the wrong window because we
> aren't keeping track of the X11 window number or some similar identifier.
Yes we are. That's how the "allwindows" option works.
It passes the window identifier along with the event.
--
Ethan A Merritt Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2007-05-31 21:18:03
|
> > > I'll repeat myself, maybe you lost it in the noise of my message: The=
easy
> > > fix means a big regression; 'q' and ' ' would not always work anymore=
, but
> > > only when the terminal is the active one.
> >=20
> > 'q' and ' ' should work as they are. It is sufficient and a very clean =
way=20
> > to switch them on/off by a term->xxxx() command I proposed earlier.
>=20
> It is not as simple as you make it sound.
> Consider the example Timoth=C3=A9e already mentioned.
> You have an old x11 plot window open, but the current terminal
> is something else. Maybe wxt, maybe postscript, ... whatever.
Then you mean that "bind" command should work always to all screen=20
terminals. Then it seems to be even more easily coded:
for t in "all terminals"
if t is interactive
=09t->xxxx()
of even the hardcoded way (like managing menus, pauses etc.) (but many won'=
t=20
like it):
#if X11
x11_change_hotkey('q', 0);
#if PM
pm_change_hotkey('q', 0);
#if _Windows
#if wxt
---
PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-31 21:24:50
|
On Thursday 31 May 2007 14:17, Petr Mikulik wrote: > >=20 > > It is not as simple as you make it sound. > > Consider the example Timoth=C3=A9e already mentioned. > > You have an old x11 plot window open, but the current terminal > > is something else. Maybe wxt, maybe postscript, ... whatever. >=20 > Then you mean that "bind" command should work always to all screen=20 > terminals. Then it seems to be even more easily coded: I apologize for not explaining clearly enough. I will try once more. There is a problem with moving ' ' or 'q' into the general "bind" mechanism, and the same problem applies to extending "bind all" to handle multiple active terminal types. The problem is not anything to do with handling the event once we see it. The existing code, or trivial extensions, can handle that easily. The problem is that _we do not see_ the keystroke or mouse events from previously active terminals. Only those from the current terminal. =2D-=20 Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-05-31 22:32:36
|
Ethan Merritt wrote: > Yes. That's what it is intended to do, and it works fine. > Now type > > set term png > > and you will see that everything stops working. How much would it take to make gnuplot look for events from all terminals it has accessed? If gnuplot initializes a terminal, it can put that pointer on a linked list (could use dynarray). Then go through the list looking for events. Or is there more to switching terminals in that regard? Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-05-31 22:51:47
|
On Thursday 31 May 2007 15:32, Daniel J Sebald wrote: > > How much would it take to make gnuplot look for events from all terminals it has > accessed? A complete re-write of the input stream multiplexing. -- Ethan A Merritt |
|
From: Petr M. <mi...@ph...> - 2007-06-01 07:51:54
|
>> 'q' and ' ' should work as they are. It is sufficient and a very clean way >> to switch them on/off by a term->xxxx() command I proposed earlier. > >> Then you mean that "bind" command should work always to all screen >> terminals. Then it seems to be even more easily coded: > > There is a problem with moving ' ' or 'q' into the general "bind" > mechanism, and the same problem applies to extending "bind all" > to handle multiple active terminal types. I proposed this bind mechanism for the 2 hotkeys: - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the 'q' and ' ' - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into gnuplot as all the other keys > How much would it take to make gnuplot look for events from all terminals > it has accessed? If gnuplot initializes a terminal, it can put that > pointer on a linked list (could use dynarray). Then go through the list > looking for events. > Or is there more to switching terminals in that regard? This "listen all the time" works on OS/2 (thread + shared memory is used, not waitforinput), but if pm is not the current terminal, then the commands like grid, log etc. are replotted for the other selected terminal. --- PM |
|
From: <tim...@en...> - 2007-06-01 10:41:17
|
>>> 'q' and ' ' should work as they are. It is sufficient and a very clean >>> way >>> to switch them on/off by a term->xxxx() command I proposed earlier. >> >>> Then you mean that "bind" command should work always to all screen >>> terminals. Then it seems to be even more easily coded: >> >> There is a problem with moving ' ' or 'q' into the general "bind" >> mechanism, and the same problem applies to extending "bind all" >> to handle multiple active terminal types. > > I proposed this bind mechanism for the 2 hotkeys: > - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the > 'q' and ' ' > - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into > gnuplot as all the other keys > I doubt it's the right fix: 1) It already exists in the form of the ctrl-q option in x11 and wxt 2) This is doomed to be completely opaque to the user, as is the current ctrl-q solution in my opinion 3) It doesn't really fix the problem (again, this problem is that we cannot listen to events coming from different terminals at the same time in the current design), but only workaround it with a new option... > >> How much would it take to make gnuplot look for events from all >> terminals >> it has accessed? If gnuplot initializes a terminal, it can put that >> pointer on a linked list (could use dynarray). Then go through the list >> looking for events. >> Or is there more to switching terminals in that regard? > > This "listen all the time" works on OS/2 (thread + shared memory is used, > not waitforinput), but if pm is not the current terminal, then the > commands > like grid, log etc. are replotted for the other selected terminal. > Yes, we need to extend and unify _cleanly_ this "listen all the time" behaviour between all platforms and several terminals at a time, and nuke term->waitforinput Timothée |
|
From: Petr M. <mi...@ph...> - 2007-06-01 14:17:45
|
> >>> 'q' and ' ' should work as they are. It is sufficient and a very clean > >>> way > >>> to switch them on/off by a term->xxxx() command I proposed earlier. > >> > >>> Then you mean that "bind" command should work always to all screen > >>> terminals. Then it seems to be even more easily coded: > >> > >> There is a problem with moving ' ' or 'q' into the general "bind" > >> mechanism, and the same problem applies to extending "bind all" > >> to handle multiple active terminal types. > > > > I proposed this bind mechanism for the 2 hotkeys: > > - on -- the current built-in: gnuplot_x11 or gnupmdrv.exe etc. execute the > > 'q' and ' ' > > - off -- planned: these hotkeys will be passed from gnuplot_x11 etc into > > gnuplot as all the other keys > > > > I doubt it's the right fix: > > 1) It already exists in the form of the ctrl-q option in x11 and wxt > 2) This is doomed to be completely opaque to the user, as is the current > ctrl-q solution in my opinion My proposal is different from ctrl-q. It describes the inner way of gnuplot code, not a user interface/option. This must be hidden from the user; user does not care about the implementation of built-in bindings. > 3) It doesn't really fix the problem (again, this problem is that we > cannot listen to events coming from different terminals at the same time > in the current design), but only workaround it with a new option... I comment only on how to enable / disable ' ' and 'q' for binding, not what happens after a 'set term'. --- PM |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X