Adding new top level menu

Is there a way to add a menu to the top level menu?

I have a slightly complex set of tools that I would like to add to the top level menu to save the use from even more clicks to get to and use my tools.

There is no add function for UI.menu. I would really like to add a menu, for example “JohnnyTools”. Is there any way to do that or to configure what top level menu items are displayed.

The first question is an API question. I guess the second question is a general sketchup use question.

Thanks for any help!

No. The API does not expose this feature. (If it did, there would be too many top level menus.)

Probably best to put them under a custom submenu beneath the “Tools” menu.

Because the UI::menu module method returns a Sketchup::Menu class instance object.
The #add_submenu instance method is called upon one of these menu instances to add a submenu.

(They are not functions, because in Ruby a function is a specific global method that does type conversion and has the name of a class to convert to. Most coders do not use them and instead use instance methods that begin with the suffix "to_".)


I understand that you wish to add a top level menu, but this is not exposed for good reason. But if it were, it would be likely an application UX level method so most likely a dedicated UI module method like "#add_topmenu" (or similar.) It would also return a newly instanced Sketchup::Menu class instance object.

The only thing you can do is create a submenu and perhaps also a toolbar. A toolbar allows a single click on a button. The submenu items allow the end user to create keychord shortcuts to your tools (regardless of nesting level.)


Otherwise, you can open a API request in the official tracker.
Issues · SketchUp/api-issue-tracker · GitHub

…or
“The Ruby HtmlDialog class allows you to create and interact with HTML dialog boxes from Ruby. This is the best way to generate complex, embedded UIs inside SketchUp, but it does generally require HTML and JavaScript expertise.”

… except that using web dialogs does not have a nice way of switching the focus back to the application window. (We’ve asked for this for like 10 years!) This can be an issue when trying to activate tools. (There are “hacks”. Search this category for “focus”.)

2 Likes

Thanks Dan and Dezmo. I am going to go the toolbar route. I have used (and may still use) html in the past for complex UIs. But this is a complex set of tools that hope to make things simpler for the user. When they have a simple task to perform, I don’t want them to have to click 3 or 4 menus deep to do it. But as the project grows the simple dialogs that I have now will become more sophisticated and I will need to use HTML/Javascript/dbs/etc to finish the job. Thanks for your responses!

As I encouraged above, if you also have menu items, the users can assign shortcut keychords. Don’t deny them that feature.

Both the menu item block and the toolbar button block can simply call the same command method. Doing it this way also makes debugging easier as a change can be immediately active by reloading the code file rather than closing and restarting SketchUp.

def my_nifty_tool
  # tool code
end

if !defined?(@loaded)
  @loaded = true

  # my_menu defined

  my_menu.add_item("Nifty Tool") { my_nifty_tool() }

  # my_toolbar defined

  my_toolbar.add_item("Nifty Tool") { my_nifty_tool() }

end

Vote for this then.

We recommend extensions to group their menus to a sub-menu. This allows the user to install multiple extensions without the top level menus becoming too long.

As Dan mentions, keyboard shortcuts are important to users, having menus for your commands will allow your users to assign keyboard shortcuts.

Typically menus are the main source for extension commands. Then toolbars and webdialogs are supplemented for alternative invocations.

Personally I group the way I use commands in SketchUp into three categories:

  1. Frequently used commands (I assign these to keyboard shortcuts)
  2. Occasionally/semi-fruently used commands, I access these via toolbars.
  3. Everything else I access from menu when needed.

It’s a pattern I see often among power users.

There is however a number of users that don’t use keyboard shortcuts that often, and will use most things via toolbars.