How to get a toolbar to appear on first load of a plugin?

Developers Ruby API
1

I’ve noticed some plugins have their toolbars appear the first time you load them into Sketchup, while with others, you have to go into ‘View’ → ‘Toolbars’ and ‘check’ the toolbar you just installed so it will appear.

I’ve noticed that the plugins that this happens with (toolbar appearing on first load) have the following line of code relating to the toolbar variable:

    UI.start_timer(0.1, false) {
        toolbar.restore
      }

I’ve seen in many plugins that use this code for a completely different reason… which is to fix some old bug that has to do with toolbar stretching…!? And I understand it isn’t relevant anymore - as in this link:

So… to my questions:

  1. I personally prefer it when a newly installed plugin’s toolbar appears on first load… (so I don’t have to go searching for it’s name etc…) but what do others think?

  2. Is that an intended behavior or really a by product of the bug-fix?

  3. If I want this behavior… is this the ‘right’ way to do it?

2

I tend to use variants of this…


# showing the toolbar on first run, while allowing the user to turn it off for next session...
      tb.get_last_state == -1 ? tb.show : tb.restore

I don’t use the timer, but I don’t support <v8…

john

3

Try to use the global constants to avoid issues:

# Showing the toolbar on first run, while allowing
#   the user to turn it off for next session ...
tb.get_last_state == TB_NEVER_SHOWN ? tb.show : tb.restore

which is the same as:

if tb.get_last_state == TB_NEVER_SHOWN
  tb.show
else
  tb.restore
end

By the way, the timer workaround may even fail if a loading error occurs (during startup) and the modal “LoadError” dialog causes blocking.

4

Thanks for the all the helpful info! :slight_smile:

5

The timer thing is an artifact of old obsolete versions of SU. I couldn’t even find a version that demonstrated what the code comment suggest it’s trying to address. I’d not use that any more.

In general I’d recommend that you use toolbar.restore - as it have the appropriate checks to only show the toolbar if the user haven’t explicitly hidden it. (And it will show it by default). so there is no need for get_last_state when using that.

Now, oddly enough, toolbar.show behave exactly the same as toolbar.restore in SU2018. Though I find that the be unexpected behaviour. I’m pretty sure that didn’t always behave like that. (I’ll have to do some more tests on older versions.)

But the short story is; use toolbar.restore and let SketchUp deal with the state of the toolbar.

3 Likes
6

does it depend on the state when it’s called?

# during runtime
:show # will open a closed toolbar
:restore # will never open a closed toolbar

john

7

In SU2018 toolbar.show doesn’t open a closed toolbar if the user previously closed it.

8

really?

tb_show

is this a mac only…

john

9

Hmm… there might indeed be platform specific behavior going on. What you show there is what I’d expect .show to do. Allowing an extension to manage its own toolbar.

But by default one should be using .restore to respect user preference.

10

but the user HAS turned it off, so :restore should keep it off…

and :show should work as seen…

a few people use my mac toolbar memory to restore a default configurations…

without :show it would not be possible…

I agree that any extension loader script should use :restore…

john

1 Like
11

Yes, that’s the use case for having .show in the first place. But it doesn’t appear to work right on Windows. At least no in my tests… :confused:

1 Like