Tooltips for Toolbar Icons with macOS

Developers Ruby API
1

A few weeks ago I made an update to the Truss and Wall plugins to try and fix a long standing macOS issue with my toolbars, more specifically with the way the tooltips were displayed.

After some testing by certain power users it was found that when the toolbars are oriented vertically as shown below the tooltip does show but the icon does not “darken” or “depress” as it does in Windows.

MacOs Tooltips Vertical
MacOs Tooltips Vertical548×1380 114 KB

When the toolbars are oriented horizontally the tooltips do not display at all:

MacOs Tooltips Horizonal
MacOs Tooltips Horizonal812×680 103 KB

My typical code that defines these toolbar icons is given in the example below:

cmd3.small_icon = "images/mdkplg_tool_icon48_4.png"
cmd3.large_icon = "images/mdkplg_tool_icon64_4.png"
cmd3.tooltip = 'Draw Truss Set'
cmd3.status_bar_text = 'Draw Truss Set'
cmd3.menu_text = 'Truss Set'
toolbar = toolbar.add_item cmd3

Am I doing something wrong here or is this a known issue with macOS. This question is mostly directly at other developers and to the SketchUp gurus who are a pay grade above me.

2

this is a known issue with macOS for a long time

4 Likes
3

This is what ChatGPT responded with in answer to my question:

You’re not doing anything “wrong” in that snippet — you’ve run into a long-standing SketchUp-for-macOS toolbar/palette bug/limitation, not a Ruby API usage issue.

What’s going on (macOS)

On macOS, extension toolbars are those floating Tool Palettes. There’s a known issue where:

  • If a palette is horizontal (snapped to the top edge), tooltips don’t show. SketchUp Community+2SketchUp Community+2
  • Switching orientation often requires a SketchUp restart before tooltips behave again. SketchUp Community+1
  • Related: “hover/press feedback” and command appearance updates are also inconsistent for plugin palettes on macOS (validation/state/visual response not updating as expected). GitHub+1

SketchUp’s own API issue tracker has this logged as an API/UI bug affecting tooltips, status bar text, and command appearance for plugin toolbars (palettes) on macOS. GitHub

Why your icon doesn’t “darken/depress” like Windows

Windows and macOS are using different native UI implementations for these toolbars/palettes. On macOS, extension palettes have multiple documented UI behavior gaps (including the “pressed/highlight” and command-state rendering). GitHub+1

If what you really want is a “toggled/checked” look (not just a momentary press effect), the intended API mechanism is a validation proc:

cmd3.set_validation_proc {
  tool_active? ? MF_CHECKED : MF_UNCHECKED
}

…but note: on macOS palettes this has historically been unreliable (it’s part of the same family of issues). GitHub+1

One small code nit (not the cause, but worth fixing)

This line:

toolbar = toolbar.add_item cmd3

add_item returns an integer id, so that overwrites your toolbar object. Prefer:

toolbar.add_item(cmd3)

Again: this isn’t what’s breaking tooltips; it just prevents you from adding more items afterwards.

Practical workarounds you can suggest to Mac users (today)

  1. Keep extension palettes vertical (dock to the left side) if they want tooltips. SketchUp Community+2SketchUp Community+2
  2. If they change orientation, quit + relaunch SketchUp to get tooltips back. SketchUp Community+1
  3. If you want better “remembered” palette behavior, prefer toolbar.restore over toolbar.show (more about visibility/positioning than tooltips, but it’s the recommended pattern on Mac). SketchUp Community
  4. Encourage power users to place a few critical commands in the main (top) toolbar via Customize Toolbar, since the worst behavior tends to be with separate extension palettes. GitHub

Bottom line: your command setup is fine; the tooltip + visual feedback problems you’re seeing match a known macOS palette issue in SketchUp.

1 Like
4

Yep, one of the reasons I can’t wait for the new ui.

For this long lasting bug to be fixed

1 Like
5
I second the AI suggestion here ...

… except the AI is incorrect (as it often is) with regard to the return value.
Here the AI is confounding Sketchup::Menu#add_item with UI::Toolbar#add_item.
It is the former that returns an Integer ID.

The UI::Toolbar#add_item method is meant for call chaining. Ex:

toolbar.add_item(cmd1).add_item(cmd2).add_item(cmd3)

The usage pattern …

toolbar = toolbar.add_item(cmd)

… comes from a poor example in the SketchUp Ruby API documentation.

It really makes no good sense to assign the toolbar reference to the return value of toolbar.add_item because the code must have already assigned a UI::Toolbar object to the toolbar reference (likely via use of the class constructor.)