#238 Bind <space> to builtin_raise in mouse.c

open
nobody
None
5
2012-03-25
2006-04-21
No

Currently, each interactive platform (X11, Windows,
OS2) has a separate implementation to raise the gnuplot
console window when the user presses the spacebar in
the terminal window.

This patch moves all the code to mouse.c in a new
function builtin_raise, and binds by default the empty
character (' ') to this new function as it is done for
example with 'a' and builtin_autoscale.

The bindings should work for all terminal windows so
that the spacebar will raise the console window from
any terminal window. This implies a small modification
to make all-windows bindings also work with builtin
bindings.

Motivations :
* the wxWidgets terminal will profit from this global
implementation without having to duplicate code (the
wxWidgets toolkit itself doesn't help for this task at
all).

* the spacebar will profit from all the bindings
capabilities as other keys. Without this patch, the
behaviour of the spacebar is hardcoded and can't be
changed.

Implementation tested on X11 and Windows, but not
tested on OS2, i.e. it may not compile on this
platform. Can somebody try it ?

Discussion

1 2 > >> (Page 1 of 2)
  • Timothée Lecomte

    Implementation in mouse.c and cleanup of original places (not tested on OS2)

     
  • Timothée Lecomte

    • summary: Bind <space> to builtin_raise, implementation in mouse.c --> Bind <space> to builtin_raise in mouse.c
     
  • Bastian Märkisch

    Logged In: YES
    user_id=1180072

    This cannot (and does not) compile on OS/2 for (at
    least) two reasons:

    * On OS/2 pm and x11 terminal can be included at the same
    time. But your code in mouse.c assumes that there's no
    X11 terminal on OS/2.

    * The OS/2 specific code which you moved from os2/gclient.c
    to mouse.c must be executed from within gnupmdrv. This
    is a seperate executable (like gplt_x11) which does not
    include mouse.c.

    I'll see if I can come up with a solution quickly.
    Bastian

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    Bastian and I have discussed this patch offline quite a bit,
    and here are the conclusions so far :

    * The code I proposed can be compiled on OS/2 provided some
    modifications, and can be executed by the main gnuplot
    executable (i.e. it doesn't need a message loop).

    * I am not clear about who manages who, as far as windowing
    systems are concerned. For example :
    - on Unix, X11 is supposed to do all the job
    - on OS/2, according to Bastian, you can have a window
    managed by the OS/2 native API, or managed by X11, and these
    two seem to be mutually exclusive
    - on Windows, there seems to be the same case : a window
    managed by the Windows API, or by X11 via Cygwin

    Currently, as far as I can tell :
    - the Windows version assumes that the console window is
    managed by the Windows API (and it is the case)
    - if you use a X11 version under Windows with Cygwin, it
    will assume that the console window is managed by the
    X server
    - the OS/2 version can use both the PM terminal and the X11
    terminal, so :
    * the PM terminal assumes that the console window is
    managed by the OS/2 API
    * the X11 terminal assumes that the console windows is
    managed by a X server

    Can somebody correct if I am wrong ? Or, if I am right, tell
    me how this mess can work in practise ?

    * Until now, the main executable doesn't need not linked to
    X11 (even if with ./configure it is by default). Changing
    this may not be desirable.

    In any case, please keep in mind in your responses that this
    patch is intended to have a global implementation that the
    wxWidgets terminal won't have to care about.

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-24

    Logged In: YES
    user_id=235620

    you wrote >
    > Until now, the main executable doesn't need
    > not linked to X11 (even if with ./configure
    > it is by default).
    > Changing this may not be desirable.

    Sorry. I don't understand what you are saying here.

    In any event, it is not true that on unix/linux the "console
    window" must be managed by x11. Gnuplot runs just fine from
    a true console or virtual console window. People do run it
    that way (hence the svga driver). Furthermore, so far as I
    can see there is nothing to stop you from running gnuplot
    from a true console window and then opening up an x11 plot
    window on whatever server you have DISPLAY set to. I haven't
    tried it, though.

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    > you wrote >
    >> Until now, the main executable doesn't need
    >> not linked to X11 (even if with ./configure
    >> it is by default).
    >> Changing this may not be desirable.

    >Sorry. I don't understand what you are saying here.

    Oops, I submitted without reading ! I wanted to write :
    Until now, the main executable doesn't need to be
    linked with Xlib, even if the X11 terminal is enabled. Only
    gplot_x11 need to.
    ./configure does put the include & linking flags with Xlib
    for the main executable, but they are not needed.

    > In any event, it is not true that on unix/linux the
    > "console window" must be managed by x11.
    > Gnuplot runs just fine from
    > a true console or virtual console window.
    > People do run it that way (hence the svga driver).
    > Furthermore, so far as I can see there is
    > nothing to stop you from running gnuplot
    > from a true console window and then opening
    > up an x11 plot window on whatever
    > server you have DISPLAY set to. I haven't
    > tried it, though.

    You're right. In this case, WINDOWID is not set in the
    console environment, so <spacebar> won't do anything.

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-24

    Logged In: YES
    user_id=235620

    Comments:

    (1)
    --- old/docs/gnuplot.doc 2006-03-28
    +++ new/docs/gnuplot.doc 2006-04-21
    @@ -1750,8 +1750,8 @@
    + every real editor), except 'q' which cannot be rebound.

    Actually, this is not true. In the current gnuplot you can
    rebind both 'q' and ' ' in x11. I just tried it and it
    works as expected in both cases. What you cannot do is bind
    a key on top of the current exit hotkey. This is by default
    set to 'q', but can be changed to e.g. 'ctrl-q' in the X
    environment.

    (2)
    I very much do not like the idea of moving X11-dependent
    code into mouse.c. The separation between the core gnuplot
    executable and gnuplot_X11 has been clean up until now. The
    only interaction is via a piped communication channel. In
    fact gnuplot_x11 can be running on a different machine than
    gnuplot, and may have a different X environment. So I don't
    see how your proposed patch can work at all in the most
    general case. I'm not sure the current code works either,
    but that's a separate question.

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    you wrote :
    > In the current gnuplot you
    > can rebind both 'q' and ' ' in x11. I just
    > tried it and it works as expected in both cases.
    > What you cannot do is bind a key on top of the current
    > exit hotkey. This is by default set to 'q',
    > but can be changed to e.g. 'ctrl-q' in the X
    > environment.

    Two conclusions :
    * The current documentation is inaccurate, and that's not my
    fault ;-)
    * You probably use the "-ctrlq" resource, because the
    current code in gplot_x11.c definitely can't rebind ' ' when
    "ctrlq" is not set.

    you wrote :
    > I very much do not like the idea of moving X11-dependent
    > code into mouse.c. The separation between the core
    > gnuplot executable and gnuplot_X11 has been clean up
    > until now. The only interaction is via a piped
    > communication channel.

    So the question is :
    How to do this cleanly, and so that the wxWidgets can use it
    without duplicating code ?

    > In fact gnuplot_x11
    > can be running on a different machine than
    > gnuplot, and may have a different X environment.
    > So I don't see how your proposed patch can work
    > at all in the most general case.
    > I'm not sure the current code works either,
    > but that's a separate question.

    Again, you're right : the current code may probably not
    work as expected in such a configuration.

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-24

    Logged In: YES
    user_id=235620

    >So the question is:
    >How to do this [raise the console window] cleanly,
    >so that the wxWidgets can use it without duplicating code ?

    IMHO (which I know Petr disagrees with) this is not worth
    doing at all, and therefore the question is moot. If you
    want your console window to stay on top, then mark it
    "always on top" using the window property mechanism that
    window managers [should] provide. I'm still in favor of
    removing this spacebar hotkey altogether, or at least making
    it a platform-specific option if non-x11 platforms do not
    offer the equivalent of "always on top".

    Having said that, it seems to me that the answer to the
    question is that it would require a new terminal API entry
    to do what you ask. One would define an internal routine:
    void raise_console() {
    if (term->raise_console)
    term->raise_console();
    }

    And then hook this up to a new suboption of the "raise"
    command and let the user bind the spacebar to it:
    bind ' ' "raise console"

    Note that information on which plot window generated the
    event is available if necessary. See the mousing demo, for
    instance.

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-24

    Logged In: YES
    user_id=31505

    The common code, shared by independent terminal executables
    as well as by the gnuplot executable, should go into
    mousecmn.c. Currently there is only mousecmn.h, because no
    more than definitions were needed until now, but the
    reuseable code could be put there; no need for a new
    terminal api.

    > mark it "always on top" using the window property
    mechanism that

    That's NOT what the spacebar hotkey is doing.

    > term->raise_console()

    Hm, this could be an elegant solution... but it would rather
    require the yet not existing
    term_which_is_screen->interactive("raise gnuplot console")
    ... the hotkey must work for whichever terminal currently "set".

    (Yes of course: "raise ..." => INTERACTIVE_ACTION_RAISE_...)

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-24

    Logged In: YES
    user_id=235620

    >term_which_is_screen->interactive(INTERACTIVE_ACTION_RAISE_...)

    Now I am confused. I thought the problem under discussion
    was that for instance on OS2 you could have both an
    OS2-mediated plot window and an x11 window. I don't know
    exactly what that looks like on the screen, but .... the
    term_which_is_screen->() idea misses the point, because it
    might be either x11 or os2. It thought you wanted to raise
    the one corresponding to whatever plot window you just hit
    the spacebar in, whether or not it is the same as the
    default screen terminal.

    Consider the new wxt terminal type. It comes up by default
    as the screen terminal, but in fact the console terminal is
    an xterm. Your term_which_is_screen->() is "wxt" in this
    case, right? But the x11 raise command has nothing in
    particular to do with wxt. Shouldn't it be x11->() that
    gets called? Except that, as I pointed out previously,
    gnuplot_x11 can hypothetically be running on a different
    X-server than gnuplot itself, so this isn't guaranteed to
    work either.

    Argh. This really is confusing. Remind me again why this
    would ever be useful. You say it's NOT to keep the console
    window from being covered by multiple plot windows, which
    is what I previously understood. Then what is it for? Is it
    so that you can start up gnuplot in parallel from 15
    different terminal windows, and use this mechanism to figure
    out which plot belongs to which terminal? If so, why can't
    you instead open your 15 different plot windows from *one*
    terminal window and track them by ID #? set term x11 1;
    plot foo; set term x11 2; plot baz; set term x11 3; plot
    bif; etc...

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-24

    Logged In: YES
    user_id=31505

    > I thought the problem under discussion was that
    > for instance on OS2 you could have both an
    > OS2-mediated plot window and an x11 window.

    Yes, and both are launched from the same gnuplot.exe.

    > I don't know exactly what that looks like on the screen

    E.g. like nowadays on linux launching both wxt and x11 from
    the same gnuplot executable. They live together.
    (X11 windows can run seamlessly on Presentation Manager
    desktop, or within their own fullscreen Xserver.)

    > term_which_is_screen->() idea misses the point, because
    > it might be either x11 or os2.

    No, it will raise the console/terminal window with
    *gnuplot.exe*, not the graphics window where the spacebar
    has been hit! So, it does not matter whether pm or x11 will
    let the gnuplot console raise.

    > Then what is it for?

    Open two sessions in one KDE Konsole, or two xterms, then
    run gnuplot or Octave in them, draw data (e.g. experimental
    data in one, fitting in the other, ... and previous fitting
    in yet another...). For a good fit, you cannot distinguish
    them very well:-) so hit a spacebar and voila! you are at
    the prompt where from you have plotted the graph! Try it!

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    >> term_which_is_screen->() idea misses the point, because
    >> it might be either x11 or os2.
    >
    >No, it will raise the console/terminal window with
    >*gnuplot.exe*, not the graphics window where the spacebar
    >has been hit! So, it does not matter whether pm or x11 will
    >let the gnuplot console raise.

    What happens if you hit the spacebar from the x11 terminal
    while gnuplot.exe is launched in an OS/2 mediated console
    window ?

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-24

    Logged In: YES
    user_id=235620

    >> term_which_is_screen->() idea misses the point,
    >> because it might be either x11 or os2.

    > No, it will raise the console/terminal window
    > with *gnuplot.exe*, not the graphics window where
    > the spacebar has been hit!

    Yes, I understand that. But...

    > So, it does not matter whether pm or x11 will
    > let the gnuplot console raise.

    It does indeed matter, because the pm terminal driver should
    not be expected to know how to raise an x11 console window,
    and conversely the x11 terminal should not be expected to
    know how to raise an os2 console window. You would need to
    send this hypothetical term->raise_console() command to the
    terminal driver that matches the nature of the console
    terminal, not to the one that matches GNUTERM or that
    matches "current plot window".

    Maybe that is what you meant by term_which_is_screen? I had
    interpreted that as shorthand for "the default terminal
    type, e.g. GNUTERM".

    I still think the current x11 code does not work in the
    general case. gnuplot sends a value of gnuplotXID, which
    gnuplot_x11 will later use to send a command XMapRaised(dpy,
    gnuplotXID). But there is no guarantee that the display used
    by gnuplot_x11 and the display used by gnuplot itself are
    the same display. If they are not the same display, then
    gnuplotXID is an id in the wrong server space. So in the
    general case, gnuplot_x11 could raise some random window or
    no window at all, and do so on the wrong display.

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-24

    Logged In: YES
    user_id=31505

    > What happens if you hit the spacebar from the x11 terminal
    > while gnuplot.exe is launched in an OS/2 mediated console
    > window?

    It will raise gnuplot.exe's window it on its appropriate
    desktop. (If both X11 and gnuplot.exe are running in PM or
    in Xserver, it's clear, and if X11 is running under
    fullscreen Xserver while gnuplot.exe is running in PM
    terminal window on PM desktop (maybe difficult to image for
    non-OS/2 users) it will raise it on the PM.) All these work
    fine since many years ago...

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-24

    Logged In: YES
    user_id=31505

    > I still think the current x11 code does not work
    > in the general case.

    Well, until now, it worked for me in all practical cases.
    Yes, nothing happens under X11 if you are under different
    Xservers (you cannot expect raising putty's window on
    Windows by hitting a key on a distance server); if someone
    knows how to fix this, I would enjoy it.

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    >> What happens if you hit the spacebar from the x11
    >> terminal while gnuplot.exe is launched in an OS/2
    >> mediated console window?

    > It will raise gnuplot.exe's window it on its appropriate
    > desktop. (If both X11 and gnuplot.exe are running in PM or
    > in Xserver, it's clear, and if X11 is running under
    > fullscreen Xserver while gnuplot.exe is running in PM
    > terminal window on PM desktop (maybe difficult to image
    > for non-OS/2 users) it will raise it on the PM.) All these
    > work fine since many years ago...

    So, if we had to write a generic function "PM_raise_console"
    which could be called from any terminal (x11, pm, and maybe
    wxWidgets), should it contain the current x11 code, the
    current pm.trm code, or both ?

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-24

    Logged In: YES
    user_id=31505

    > So, if we had to write a generic function
    > "PM_raise_console"
    > which could be called from any terminal (x11, pm,
    > and maybe wxWidgets)

    I think that X11_raise_console() should be used from x11 and
    wxt-X11 (without change also under OS/2), and
    PM_raise_console() for pm and wxt-PM terminals. (I think wxt
    knows whether it is being built with the x11, pm, windows,
    ... toolkits).

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    > I think that X11_raise_console() should be used from x11 and
    > wxt-X11 (without change also under OS/2), and
    > PM_raise_console() for pm and wxt-PM terminals. (I think wxt
    > knows whether it is being built with the x11, pm, windows,
    > ... toolkits).

    I am sorry to ask again, but it is still not clear... That
    should not depend on wxWidgets. I guess wxWidgets is built
    on top of PM, but I should not have to care because what we
    are interested in is the console window, not the wxWidgets
    window, right ?

    So what I would like to write is more a OS2_raise_console().
    Again, what would need to be in 0S2_raise_console() ? Is it
    PM_raise_console(), X11_raise_console(), or both but
    triggered depending on where the console is ?

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-25

    Logged In: YES
    user_id=31505

    I guess you can compile wxWindows against PM or against Xlib
    (like under Windows, where you can compile it against Win32
    or against Xlib). Then, either PM_raise_... or X11_raise_...
    is used (and similarly on Windows, either WIN_raise_... or
    X11_raise_... is to be used).

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    I'm sorry, but I don't get the reason for this.

    Do you assume that the console window is managed by the X
    server when the x11 terminal is used, and that it is managed
    by the PM api when the PM terminal is used ?

    If yes, why should it be always the case ? Can't you open
    gnuplot from a console managed by PM, and plot something to
    a x11 window ?

    Otherwise, it means that both implementations work no matter
    who manages the console window. Then, why do you suggest to
    to choose between PM_raise_... and X11_raise_... if both work ?

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-25

    Logged In: YES
    user_id=235620

    But the question is not answered. How is the wx terminal (or
    any other terminal) expected to know what kind of window the
    gnuplot console itself is running in? That is something
    known only to the gnuplot session itself, not to the
    outboard drivers like gnuplot_x11 or gnupmdrv.

    I am back to agreeing with Timothee's original idea, that
    the only clean way is to have the core code do any such
    "raise" event. But I still dislike the idea of adding x11
    linkage requirements to the core executable.

    My preferred solution:
    Abandon this mechanism altogether.

    Compromise proposal:
    - Create a new terminal API term->raise_console()
    implemented in pm.trm and x11.trm
    - Remove the spacebar as a special-case event in
    gnuplot_x11 and gnupmdrv
    - Allow a "bind '<space>' raise_console" command
    using the general bind hotkey mechanism

    That way the core code can decide for itself (don't ask me
    how!) whether it is running in an xterm or an os2 console
    window or whatever, and call the appropriate driver via the
    new API. No, I don't like this idea all that much, but I
    like it better than the alternative.

     
  • Petr Mikulik

    Petr Mikulik - 2006-04-25

    Logged In: YES
    user_id=31505

    Yes, you are right. So please write an OS2_raise_...
    function. Therein, there should be some mechanism
    implemented to determine whether to call the PM_raise_ or
    the X11_raise_ (I think that env variable WINDOWID should be
    defined only in an X11-like terminal window, but not in OS/2
    command prompt window).

    Note: for the PM_raise_..., take the code after the
    "VK_SPACE" in gclient.c.

     
  • Ethan Merritt

    Ethan Merritt - 2006-04-25

    Logged In: YES
    user_id=235620

    Upon further reflection, I don't think my compromise
    proposal will work. Suppose gnuplot is being run from from
    an xterm window, but using "set term wx" or "set term pm"
    for plotting. In this case there is no instance of
    gnuplot_x11 being run, so asking it to issue a "raise
    window" event is not going to work. Or at the lease you will
    incur a huge overhead of starting up an external process and
    communicating with it via pipes just to have it issue the
    one "raise" command.

    But this must already be a problem in the current code for
    "set term pm" from an xterm window on OS2. Is that correct,
    Petr? I thought you said before that it has been working
    for years...

     
  • Timothée Lecomte

    Logged In: YES
    user_id=1333817

    Ok, I understand now ! Thanks for your patience, Petr.

    So the trick can be :
    * check for WINDOWID, if it is set go on and use the x11 code
    * if WINDOWID is not set, do :
    HSWITCH hswitch = WinQuerySwitchHandle(0,getpid());
    then check for errors with WinGetLastError, which would
    mean that the console window is not managed by PM, and
    continue with WinSwitchToProgram if it's ok.

    So the remaining question is : where to put this code ?

    Ethan's idea to add a new terminal entry in x11.trm and
    pm.trm is attractive, but it implies that these terminals
    are compiled for the spacebar to work with the wxWidgets
    terminal. It also implies that the corresponding executables
    are running, while they should not be needed if the
    wxWidgets terminal is used.

     
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks