Cursor issue interacting with graphics on Mac

[dnfarias]

First, I want to thank you for your incredible work on revitalizing IRAF. I was able to install IRAF (from Github) on a macOS Monterey machine (run_tests only showed 2 failed and 1 skipped, so remarkably good).

I installed XQuartz to run xterm and verify if most of the tasks I use (noao onedspec/twodspec, etc) work fine (they do but there's s a minor issue with some printed messages in APALL). I also installed X11iraf flawlessly (although I'm not using xgterm right now). Then, I installed the latest PyRAF version from this GitHub repository in order to run a Python code that I modified (not mine; it uses STSDAS, but I was not able to install that external package from their Github [by their words, it is nonfunctional]); imcopy, imarith and the tracing/extraction of the spectra in APALL (a test) work fine in PyRAF.

The only problem that I currently have is that the first frame of the interactive plot in APALL (the plot to define the apertures) doesn't behave correctly: I attach a short video (it is just an example) showing the problem: the first frame only allows certain keys to function: in this case, I used 'l', which worked; after that, I tried 'u', but the "cursor" got stuck at the center of the plot: it may "escape" from that position briefly, but returns almost immediately. The same happens for 'a', 'n', 'm' keys. The interesting part is that 'b' always works, so the plot to fit the background pops out and the fitting of the background ('f') runs OK. I can return to the first frame ('q'), but the problem still persists. 'b', 'f' and 'q' worked again in the second try.

So, I've been reading the Python codes of PyRAF, and I could figure out, for example, that to stop the blinking of the cursor, we can comment out line "hideTkCursor(self)" of the function "activateSWCursor" in "Ptkplot.py" file. About the major problem, I haven't solved it yet although I think I located the files related with that. This is my question: as I'm a macOS newbie, I don't know if someone ever faced this kind of behaviour in an older macOS or linux distributions (I remember I had a similar issue with CentOS and PyRAF many years ago but I don't remember the solution). Any help would be great!

Thanks.

apall.mov

[dnfarias]

Hello again. I think that I found a bug in the Canvas object, at "Ptkplot.py" file, "_tkDrawCursor" function. If I comment out the lines

pyraf/pyraf/Ptkplot.py

Lines 276 to 278 in 155b0e1

	# Draw the crosshairs. __window is a Tk Canvas object
	self.__tkHorLine = self.__window.create_line(0, y, ww, y, fill='red')
	self.__tkVerLine = self.__window.create_line(x, 0, x, wh, fill='red')

in that function in order to not draw the "red big cross", the code run flawlessly while keeping commented out the hideTkCursor(self) in "activeSWcursor" function, plus adding the line self['cursor'] = 'tcross' on the same function (to make the cursor visible as a little cross). The apall plot is not the same as it is in IRAF, but as far as I have tested, works well. I attached a video showing how the plots ended up.

I know this is only a workaround, but I guess it could be useful for now

apall2.mov

[olebole]

I now tried to reproduce this, however for me everything worked. Unfortunately, I don't have a Mac, so I did this on a VirtualBox instance (macOS 11.6.4). As #130 describes a similar problem, and they also use macOS 12, this may be connected to the new macOS version. Unless I can reproduce this, I hesitate a bit with just applying the patch; for reference here is however your proposal:

From: dnfarias <dnfarias@uc.cl>
Date: Thi, 07 Nov 2021 15:51:30 +0000
Subject: [PATCH] Use a tcross cursor instead of self-drawn crosshair cursor

---
 pyraf/Ptkplot.py | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/pyraf/Ptkplot.py b/pyraf/Ptkplot.py
index fc7c062..232b65c 100644
--- a/pyraf/Ptkplot.py
+++ b/pyraf/Ptkplot.py
@@ -151,7 +151,7 @@ class PyrafCanvas(Canvas):
         return self._isSWCursorActive
 
     def activateSWCursor(self, x=None, y=None, type=None):
-        hideTkCursor(self)
+        self['cursor'] = 'tcross'
         # ignore type for now since only one type of software cursor
         # is implemented
         self.update_idletasks()
@@ -273,10 +273,6 @@ class FullWindowCursor:
         x = self.lastx * ww
         y = (1.0 - self.lasty) * wh
 
-        # Draw the crosshairs.  __window is a Tk Canvas object
-        self.__tkHorLine = self.__window.create_line(0, y, ww, y, fill='red')
-        self.__tkVerLine = self.__window.create_line(x, 0, x, wh, fill='red')
-
     def _tkEraseCursor(self):
 
         if self.__tkHorLine is not None:
-- 
2.34.1

[dnfarias]

Hi @olebole, thanks for keeping this alive. You're right, it is a MacOS 12 issue, not related with PyRAF specifically. I was able to draw the cross by doing other changes (like doing #self.unbind(" < Motion > " ) in DeactivateSWCursor function and uncommenting the self.__tkHorlines lines from above, although it is not vital), but the funny thing is that I don't have any issue with plotting with the original code after a massive installation of libraries. The only problem is that I cannot backtrack all of the work I did in the meantime, but I just wanted to clarify that my "patch" was just temporal and now it works fine. Sorry to not be more useful, but it got fixed unintentionally.

[temuller]

Hi, I have a question about this issue. @dnfarias I want to confirm that your solution for drawing the red cross is:

• Comment out hideTkCursor(self) and add self['cursor'] = 'tcross' under the activateSWCursor function.
• Comment out self.unbind("<Motion>") under the deactivateSWCursor function.

I don't have to comment out self.__tkHorLine or self.__tkVerLine, right?

[dnfarias]

Hi Tomás,

In the second workaround, yes, it should work with only those two steps (but truth to be told, the mandatory "comment out" should be self.unbind("")... self['cursor']='cross' was needed because I didn't see any cursor with the first workaround)

I'm fairly sure the the first workaround is safest given that there was a gap between both workarounds and I cannot be 100% sure that I didn't do something else in between OS-wise. To draw or not the big red cross is just aesthetic.

Let me know if it works!

[olebole]

Since I think this is basically a Tk issue: could you specify the Tk version where this problem appears? And, @dnfarias since you don't observe it anymore: what is the Tk version where it doesn't appear?

[temuller]

Thanks @dnfarias. I am not the one trying out these solutions (I don't have a macOS), but I'll let you know what the tester finds.

[dnfarias]

@olebole I'm using Python 3.9.0, Tcl/Tk version 8.6.

[olebole]

@dnfarias since this seemed to silently went away, it may be important to have further details: microversion, and which build. Is this Tk for X11 or a macOS native version? The one provided with macOS or something else?
@temuller what about your version?

[temuller]

@olebole, my tester is using Python 3.7.11 and Tk 8.6.

[dnfarias]

@olebole The microversion is 8.6.11. I'm using an Anaconda environment with Python 3.9.0 (so Anaconda Build), therefore this Tk should not be related to the macOS version I have (8.6.10).

[olebole]

For both: can you try to use the version that comes with macOS?

[temuller]

My tester tried the first workaround suggested by @dnfarias and it worked!
By the way, my tester is also using an anaconda environment.