Sat 10 Aug 2013 04:39:42 PM UTC, comment #16:
Thanks. I've pushed the changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/4407606d0939
|
Sat 10 Aug 2013 01:12:17 PM UTC, comment #15:
On other distros I don't know, but on my Debian jessie apparently it works perfectly.
Many thanks again,
Cristian
|
Sat 10 Aug 2013 02:55:51 AM UTC, comment #14:
I've invested some time studying the code and have come up a new patch. This one works for me on MacOSX, but I'm not sure if it will on Linux. So, I'd appreciate more help. TiA
(file #28803)
|
Fri 09 Aug 2013 09:15:17 AM UTC, comment #13:
For me the patch works partially: the semi-transparent rectangle is now in place, aligned with the mouse pointer.
On the other hand, the area of the figure that is shown afterwards is vertically misaligned with respect to what the semi-transparent rectangle showed.
The misalignment depends of course on the axes unit.
For example if I draw a red square at the center of the figure, like that
and then with the right mouse button I highlight the red square for zooming, what I get is not a zoom on the red area: a part of the black area is shown at the bottom, and a part of red area is not shown at the top.
As "usual", if the uimenu bar is not present the zooming works well, without vertical misalignment.
Let me know if the above explanation is not clear enough.
|
Thu 08 Aug 2013 11:41:28 PM UTC, comment #12:
Opps. Ignore the prior changeset. I enabled my right mouse button and discovered that change didn't work.
I'm attaching a changeset that works for me. I'm not confident I understand how this part of the code works, so I'll delay pushing until someone more familiar can comment (status -> need info), or until I have the time to study it.
(file #28802)
|
Thu 08 Aug 2013 09:54:29 PM UTC, comment #11:
Cristian,
Zooming doesn't work for me on MacOSX (I haven't bothered to figure out how to enable the right mouse button yet).
However, I suspect the problem is easily fixed. Please apply the patch and let me know if it fixed the problem. To apply the patch to your sources, just enter the command below from the root of your archive.
(file #28801)
|
Thu 08 Aug 2013 08:42:58 PM UTC, comment #10:
After that the bug report was closed, I noticed that the same issue arises in fltk for zooming: after pressing the right mouse button and moving the pointer a little, usually a semi-transparent rectangle appears, representing the coordinates for zooming when the same button is released.
Such a rectangle appears shifted vertically by the height of the uimenu bar.
So this is not the same bug but has similar causes I guess.
|
Thu 08 Aug 2013 05:08:13 PM UTC, comment #9:
Thanks for the follow-up. I'm closing this bug report
|
Thu 08 Aug 2013 05:00:04 PM UTC, comment #8:
Many thanks. It works perfectly now also for me.
|
Wed 07 Aug 2013 10:36:57 PM UTC, comment #7:
I thought I'd fixed this, but I only fixed the figure's currentpoint.
The changeset below works for me.
http://hg.savannah.gnu.org/hgweb/octave/rev/d23fcc227fa9
|
Wed 07 Aug 2013 08:10:48 PM UTC, comment #6:
Here is the same script with a few lines of code that I forgot.
(file #28789)
|
Wed 07 Aug 2013 08:02:56 PM UTC, comment #5:
When I click once, the height of the overall plot window shrinks but the plot window doesn't move otherwise. That seems wrong to me.
|
Wed 07 Aug 2013 07:51:22 PM UTC, comment #4:
I forgot to describe the function of the code that I attached:
it is a short script that requires user interaction to show the bug, and it works by reading the "currentpoint" property of the current figure.
Two mouse clicks are required: the first one in the presence of the uimenu bar, the second one in its absence. After every mouse click, a white horizontal line is drawn in the figure.
If two lines are present after clicking twice in the very same point on the figure, it means that there is an offset between the detected y-value with and without the uimenu bar.
If only one line is present, there is no such offset and hence no bug.
|
Wed 07 Aug 2013 07:41:35 PM UTC, comment #3:
Here is a code snippet that on my platform highlights the bug:
octave dev version 3.7.5, Debian testing.
(file #28788)
|
Thu 14 Mar 2013 02:58:28 AM UTC, comment #2:
No response for a year. Closing report.
|
Fri 17 Feb 2012 01:42:14 AM UTC, comment #1:
Please provide a simple script which demonstrates this problem.
|
Tue 31 Jan 2012 12:57:23 PM UTC, original submission:
If a menubar is used (uimenu), all mouse functions supply a wrong y-value. The error corresponds to the height of menubar.
|