Community
Participate
Working Groups
For CURSOR_WAIT and CURSOR_IBEAM SWT/Cocoa does not use the system's cursor, but a custom hard-coded image in org.eclipse.swt.graphics.Cursor. These cursors should also use the platform cursors, defined by the selectors 'busyButClickableCursor' and 'IBeamCursor'. The waiting cursor on macOS is animated and blue, while the current one is an ugly black/white filled circle.
New Gerrit change created: https://git.eclipse.org/r/105187
Thanks for the patch. SWT doesn't use the NSCursor.IBeamCursor() because it's almost invisible on a black background. It uses a custom Shadowed IBeam cursor to fix this. Please see Bug 358022 for more details. Regarding busyButClickableCursor, it works well. But, it is not there anywhere in the Apple reference for NSCursor?
Ah, I see. I do not use the dark theme, so I was not aware of that requirement. I will change the patch to just use the waiting cursor and leave IBeam as is. I found a reference to the 'busyButClickableCursor' selector in this code: https://opensource.apple.com/source/tcl/tcl-95/tk/tk/macosx/tkMacOSXCursor.c I came to that while searching for a 'wait cursor selector'.
(In reply to Karsten Thoms from comment #3) > I found a reference to the 'busyButClickableCursor' selector in this code: > https://opensource.apple.com/source/tcl/tcl-95/tk/tk/macosx/tkMacOSXCursor.c > > I came to that while searching for a 'wait cursor selector'. Since it's not part of the NSCursor API & not documented, how safe is it to use the selector? Comments on the patch: The methods in NSCursor.java and the selectors in OS.java are auto-generated by MacGenerator[1] tool (content comes from the *.bridgesupport files in the project). Any other non-generated content will be overwritten by the tool. To include new methods from a Cocoa Class we use the MacGenerator. But, in this case, the method is not part of the API for NSCursor and hence it can't be selected via the tool. You can move the selector from the autogenerated section to editable section of OS.java and call OS.objc_msgSend directly from Cursor class. Since the selector is undocumented, I suggest we add a respondsToSelector() check before calling the selector and use the old code as fallback if it returns false. [1]https://www.eclipse.org/swt/macgen.php
Thanks for your pointers. I'm not sure how safe it is, maybe I should try to have a fallback for the case that the selector is unknown. I will consider your recommendations and provide an update.
Updated the patch. When NSCursor does not respond to the 'busyButClickableCursor', OS.busyButClickableCursor() will return null and Cursor.java will fall back to its old cursor. Tried this by making a typo in the selector name.
Gerrit change https://git.eclipse.org/r/105187 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=00720b46e1bebb3f6d678aaeece1a01bc020b17f
(In reply to Eclipse Genie from comment #7) > Gerrit change https://git.eclipse.org/r/105187 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=00720b46e1bebb3f6d678aaeece1a01bc020b17f > Thanks for the patch, Karsten!
New Gerrit change created: https://git.eclipse.org/r/105814
Gerrit change https://git.eclipse.org/r/105814 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=0ccce6aae49339341b5eed9ffc2e8b0c6f99b90e
Verified with Build I20171016-2000
