Include RubyCocoa in Ruby distribution on Mac

[Fredosixx]

REQUEST / SUGGESTION: Could you consider including RubyCocoa in the Ruby pack for MacOSX.

This would give more or less the same capability as Win32API and Win32OLE for the Mac platform.

Alternatively, you may consider an alternative framework on Mac if better or more appropriate.

Currently, there are limitations on Mac because AppleScript cannot be used by Sketchup to script itself. So, things like giving focus to the main Sketchup window can be done with Win32API, but not with AppleScript. Same if you wish to detect the mouse position outside the viewport.

[thomthom]

What are the things you are wishing to do with it? (Beyond focusing windows)

I gather this is related to better UI integration/capabilities?

[Fredosixx]

I did not explore the capabilities yet, but I am looking for something equivalent to Win32API on Mac. Things like know the mouse position, state of keys and buttons, etc... could be useful. On Windows, there are a lot of possibilities, but the corresponding functions on Mac are not accessible, unless you develop a binary.

[DanRathbun]

Carbon and Cocoa are obsolete I believe.

[thomthom]

On Windows, there are a lot of possibilities, but the corresponding functions on Mac are not accessible, unless you develop a binary.

I wasn't even aware there was any way on macOS similar to what Win32 can do. But I was looking for that in the past. Would be interesting to see if RubyCocoa can do that. (Have you tried it?)

One thing that concerns me about RubyCocoa is that there hasn't been any release since 2015. Looks to have gone stale...

Carbon and Cocoa are obsolete I believe.

I think I heard that Apple was moving to another UI framework. That's another reason RubyCocoa is a challenge. Win32 on the other hand is generic Windows API - not UI framework spesific, so that makes it more flexible.

Things like know the mouse position, state of keys and buttons, etc... could be useful.

For Win32 the things I used it for was to set focus and change the window border style. Those are things we could add to the API. I wanted to include it into HtmlDialog back in the day, but they fell off the list due to competing priorities. However, I've been sorting incoming reports and grouping them, the UI pool is significant enough to warrant a project in itself to improve the UI integration for extensions.

Things I know (from the top of my head) that keeps coming up:

• Control focus between SU app and web/htmldialogs.
  • Mark htmldialogs to never steal focus.
• Get/set size of htmldialogs.
• Get/set client size of htmldialogs.

Cursor position outside of the viewport, what are you looking for there? In the context of a Ruby tool?

[Fredosixx]

I did not try RubyCocoa and I don't even know if it applies in the case of Sketchup on Mac. I guess Trimble has enough developers familiar with OSX and Sketchup that they can advise if there is anything similar to Win32API on Mac-OSX.

[Fredosixx]

Things I know (from the top of my head) that keeps coming up:

• Control focus between SU app and web/htmldialogs.

  • Mark htmldialogs to never steal focus.
• Get/set size of htmldialogs.
• Get/set client size of htmldialogs.

Cursor position outside of the viewport, what are you looking for there? In the context of a Ruby tool?

On HtmlDialog, do not forget the other issues which are simply critical bugs (bring_to_front, set_size and set_position forcing focus, can_close, drag&drop, etc.... These bugs are in UI::HtmlDialog and not in UI::WebDialog, and most of them have no workaround at all.

The position of the cursor outside the viewport is required on Windows, to be at par with Mac. On Mac, when the mouse button is down, onMouseMove and onLButtonUp are received even if the mouse is outside the viewport or hovering a dialog box. That's not the case on Windows. I came across this functional requirement when I had to implement my own Orbit/Pan for Preview modes because the standard tools do not process the view_draw graphics while orbiting or panning.

[thomthom]

On Mac, when the mouse button is down, onMouseMove and onLButtonUp are received even if the mouse is outside the viewport or hovering a dialog box.

Huh! I wasn't aware of that. But I have run into that on Windows. Since it works on Windows I'd label that as a bug.