Mon 22 Jun 2015 09:06:18 PM UTC, comment #13:
Rik,
With JohnD's simple patch it works satisfactorily for me.
Reading back your comments, I realize it didn't even occur to me that ginput() could (should?) also raise the plot window.
I use the key press option of ginput() to return info about features under the cursor on a topographical map or cross-section drawn by Octave, so the plot will always have to be on top.
|
Mon 22 Jun 2015 07:29:16 PM UTC, comment #12:
For the key press, we would need to shift focus from the command window to the plot window, but only when ginput() is called. Theoretically, shg() should do this, but today it only implements drawnow() which refreshes the window and does not bring it to the top of the stack nor set the focus on it.
Probably can be done, but it probably means adding a C++ function for shg() which will then delegate to the correct toolkit which will in turn call something like SetFocus().
|
Mon 22 Jun 2015 07:05:56 PM UTC, comment #11:
OK thanks, I'll have a look.
|
Mon 22 Jun 2015 06:43:56 PM UTC, comment #10:
Works to recognize without first click (although the plot window does need to be active)
|
Mon 22 Jun 2015 06:12:24 PM UTC, comment #9:
Hmmm, I disagree with comment #7. The bug reported in comment #0 hasn't been fixed, has it.
Just compare the course of things with fltk. No need there to make a plot window active; ginput() simply connects to the current plot window handle. A similar thing needs to happen for Qt.
As to the patch, what am I missing here?
The first mouse click was already detected fine, no need to fix that.
|
Mon 22 Jun 2015 05:24:54 PM UTC, comment #8:
Pushed http://hg.savannah.gnu.org/hgweb/octave/rev/efe22f9b53a3
I guess a preferences setting for whether or now the bring the plot to the front could be used
|
Mon 22 Jun 2015 04:31:15 PM UTC, comment #7:
The patch in comment #6 works to recognize the first mouse click.
The code example in comment #0 which uses the keyboard still doesn't work. Instead, I need to do something which makes the window active first, such as clicking on the plot window or using Alt+Tab to switch focus from the command window to the plot window, before ginput will work.
I think that is probably good enough because I know there were users who want the focus to remain with the command window for keyboard input so they can keep entering new commands rather than have the focus pulled over to the plot window.
Thus, I think this patch can be committed and the report closed.
|
Mon 22 Jun 2015 04:09:17 PM UTC, comment #6:
This allows keyboard press to work for me
(file #34292)
|
Thu 30 Apr 2015 09:23:11 PM UTC, comment #5:
Maybe ask the question on the Octave mailing list? Somebody who is following the Qt development closely should have an idea.
|
Thu 30 Apr 2015 09:05:10 PM UTC, comment #4:
How can the Canvas be made active when axes become active?
|
Tue 14 Apr 2015 07:46:09 PM UTC, comment #3:
I just tested on Linux -> same issue -> OS set to Any
|
Tue 14 Apr 2015 07:32:23 PM UTC, comment #2:
Confirmed. Doubtless this is something really small. The callback routine is Canvas::canvasKeyPressEvent in libgui/graphics/Canvas.cc. Debugging with some print statements shows that the callback is never called from Qt until a mouse click has selected the Canvas. Probably this means we need to make the Canvas an active object whenever a figure or axes becomes active.
|
Tue 14 Apr 2015 12:32:53 PM UTC, comment #1:
With gnuplot it all works fine.
|
Tue 14 Apr 2015 12:15:56 PM UTC, original submission:
Steps to reproduce (with qt toolkit):
1. plot ([1 3]) # gives some simple plot
2. [a, b, c] = ginput (1)
3. # position mouse cursor over plot. Hmmm, cursor doesn't change into crosshair like Matlab does and like the fltk toolkit used to do in 3.8.2
4. # press any letter key
# => nothing happens
Now, try again and click somewhere in the plot => ginput catches the mouse click. From now on key presses are recognized in next calls to ginput()
==> Key presses are only recognized after a first mouse click.
This works fine with the fltk toolkit.
|