They are called (among other terms) “flyout toolbars” or “flyout buttons”.
They are actually 2 buttons. The “active” command area (which displays the icon of which of it’s subordinate command items are active and acts like any normal toolbar button,) and the flyout area designated by some kind of arrow icon that displays the flyout toolbar. AutoCAD started in r12 with simple flyouts that only had buttons without text (ie, they looked like child toolbars, not popup menus.)
AutoCAD has had them since release 12 (1992) on the PC, at least. (There was also a Mac edition released for v12.)
I had been asking, politicking, whining, bitchin’, etc. etc. for them for extension developers, (meaning exposed as API classes and objects,) since the SketchUp version 7.0 release (ie, 2008.). (LayOut may have had them since the beginning, but has always used a different UI framework in it’s code than SketchUp.)
They were finally implemented with SketchUp version 2014, but only natively (ie, no API exposure,) and only those few flyouts that make SketchUp seem more akin to the LayOut UI. Which is what the intention of that release was aimed at.
I have since requested 10 other native flyouts, but still no more in the subsequent 2 years.
Anton Synytsia has tried it, (I think it was him,) and might have released some code that works on the PC only. (It would be posted over at SketchUcation in the Developer forum.)
To do it you need to be familiar with the Microsoft Windows C API and the MFC framework, and in making C calls from Ruby using either Win32API (which is obsolete) or Fiddle libraries. But all this will be platform specific to MS Windows.
There are actually several C classes. Several for native toolbars, one for Ruby toolbars. I could see adding a “add_flyout(toolbar_object)
” method to a subclass of the UI::Toolbar
Ruby class.
Any flyout button should be able to host any previously instantiated Ruby toolbar object as it’s child popup toolbar.
As stated above, (traditionally) there is a current active command which changes as the child toolbar is used, and users can just click the icon area to re-use the active command. The smaller “flyout” area with the down arrow, is clicked to show the child toolbar, to select a different active command.
I don’t know, it seems that might be overkill.
You need to determine whether the parent toolbar is floating and vertical or horizontal, or whether it is docked and which docking port (top, bottom,right or left,) it is docked into. From there you would decide what the orientation of the popup toolbar should be, so as to display with all it’s commands on screen to be selectable, and hanging off of the parent flyout button which you also need to know it’s location.
This has been done for so many projects it is likely already available from some OpenSource project, or perhaps even Microsoft SDK examples. It would probably be in C or C++.
One way would be a mixin module that other devs could include
in their custom sub-classes.
module JoeCoder
module SomePlugin
require "Dorst/GUI/Flyouts"
class NiftyToolbar < UI::Toolbar
include Dorst::GUI::Flyout
# other custom code
end
@@child_toolbar = UI::Toolbar::new("Certain Tools")
# add several command items here
@@parent_toolbar = NiftyToolbar::new("Some Plugin")
@@parent_toolbar.add_flyout(@@child_toolbar)
# add more command items or flyouts here
end
end
But yes, if you also had a custom toolbar class in your GUI
module (which would most likley also include
the same mixin module,) … devs not needing to do further customization could simply use your custom subclass.
These are just discussion examples. In reality, the flyout object may need to be a subclass of UI::Command
as the iterator method for toolbar objects could stumble (and crash SketchUp) if it encounters objects that it cannot handle.