MacOS and Toolbars not retaining settings

Developers Ruby API
1

I have a client who is using my plugins on both Mac (Mojave) and Windows. He is running SU 2018 Pro.

When he toggles the plugin toolbars off on the Mac they don’t retain that status on a restart of SketchUp and reappear. On Windows they behave as expected.

However, if they are re-positioned on the Mac they do retain their new position after restart.

Has anyone else experienced this behavior on a Mac running SU 2018 or 2019? Resolution?

2

After digging through various threads on this board and others it appears I am not the first to encounter this problem.

My question now is how do I fix it? I’m not finding a solid resolution on any other threads. If I have something wrong in my code I am more than happy to correct it.

Here is an example of a chunk of the code which creates part of a toolbar:

cmd7 = UI::Command.new("Global Settings") {

Sketchup.load(File.join(this_dir,"MEDEEK_ELECTRICAL_SETTINGS.rbs"))
Medeek_Engineering_Inc_Extensions::MedeekElectrical::Settings::MedeekMethods.settings_family_menu var1, var2
        }
            	cmd7.small_icon = "images/GLOBALS_ELECT_ICON16.png"
             	cmd7.large_icon = "images/GLOBALS_ELECT_ICON24.png"
             	cmd7.tooltip = "#{MDK_ELECTRICAL}"
            	cmd7.status_bar_text = "Change Global Settings"
            	cmd7.menu_text = "Global Settings"
             	toolbar = toolbar.add_item cmd7
             	toolbar.show
3

When you show a toolbar (like a webdialog), you are forcing it onto the user. It will always pop up!

When you want to show it or not show it depending on what toolbar state SketchUp saved form last time, you need to restore the toolbar’s state. So I would expect the same issue occurs for all your Windows users as well (or show is bugged). Example:
true-bend/main.rb at 25e7daff06b948e9301d3533a52fb4b236f789ef · thomthom/true-bend · GitHub

4

I use this without issues…

  # showing the toolbar
  tb.get_last_state  == TB_NEVER_SHOWN ? tb.show : tb.restore

john

5

I’ve been using this same code since Oct. 2015 (beginning of the truss plugin).

So I’ve had it wrong for years now… wow.

The funny thing is that in windows it remembers the last state and does not show the toolbars if they were turned off, even with the code I am using now. I guess my understanding of the API is flawed.

6

The documentation shows this as the standard method or example of creating a toolbar:

toolbar = UI::Toolbar.new "Test"
# This toolbar icon simply displays Hello World on the screen
cmd = UI::Command.new("Test") {
  UI.messagebox "Hello World"
}
cmd.small_icon = "ToolPencilSmall.png"
cmd.large_icon = "ToolPencilLarge.png"
cmd.tooltip = "Test Toolbars"
cmd.status_bar_text = "Testing the toolbars class"
cmd.menu_text = "Test"
toolbar = toolbar.add_item cmd
toolbar.show
7

The documentation does not give good examples, I wouldn’t take them as standard methods. Many examples date back to the beginning when the API was designed and the developers where yet deeply familiar with conventions in the Ruby community (and people like me didn’t even start programming at all at that time).

  • inconsistent variable naming (camelCase)
  • UI.messagebox in a long loop instead of puts
  • unnecessary boolean checks for method return values that practically always succeed
  • examples that return a new instance of an object without showing what the result looks like or what can be done with it

In the stubs repo we (community developers) started to introduce corrections and some better examples, but the API is extensive, we don’t know whether Trimble employees invest efforts in parallel and before starting one would first need to define goals and guidelines for creating uniform, consistent examples.

8

I appreciate the further clarification. I always assumed that the examples provided in the documentation were “best practice” examples and just took it as gospel. Granted I have come up with my own methods and means but I’m a little disappointed (and even shocked) that the documentation is not more carefully vetted and updated as the need requires.

9

Looks like there was an interesting discussion on the subject here:

It appears there is a bug in the windows version such that the show command behaves differently than on a Mac.

10

not sure @tt_su ever liked into it further, but I believe the mac version behalves correctly…

show will always show and restore will always honour the users last choice…

with extensions that only use restore [as thomas does] the user has to go to the menu and turn it on the first time…

it is also, why I still use the constant for first run…

john

11

It depends on the situation. A user who has just installed an extension should know where to find it.

  • If the toolbar is the main way to invoke the extension it is best practice to show the toolbar on first start.

  • If the extension is rarely used or has another obvious way to invoke it, but I want to provide an optional toolbar so that people who prefer toolbars can enable it manually in the menu, I just register it without making it pop up (restore without show).

12

I wish that wore true :frowning: . I can’t blame you for making that assumption though as it would really make a lot of sense.

To get back to show vs restore I asked this some time back in the API issue tracker: Preferred way to show toolbar? · Issue #125 · SketchUp/api-issue-tracker · GitHub

13

To be fair the method shown above for creating a toolbar is okay, it just doesn’t show you the proper method for initiating your toolbars so that they retain or restore their previous settings. I will take things with a bit of a grain of salt from here on out.