Buttons with sub-buttons?

Disclaimer: Although I’m formally trained (4 year Bachelor’s degree) as a programmer, my college days predated (barely) the debut of OOP and all the ways of thinking OOP requires. And since then, I’ve not actually worked as a programmer (long story). While I’ve tried to keep abreast of modern programming concepts, please excuse my possible misuse of terms in the rest of this post. I just haven’t yet had a good reason to learn them!

OK, here’s my real topic:

I saw a topic: Show us the way you have Sketchup set up on your computer right now that blew me away with the (to my inexperienced mind) insane number of tools that some people keep instantly available in open toolbars! How the Aitch Eee Double Ell do they even remember which tool is which?!?

My first thought was that there MUST be a better way to organize your tools. And the first organization that popped into my mind was “Tool buttons under Tool buttons” much like menus have sub-menus.

My first question is: Has anyone done this yet? (I’m still a beginner when it comes to finding particular mousetraps that others have built).

My second question (assuming the answer to the first question is “no” or “not exactly”) is:

Should I choose to develop this myself, then in Ruby I would need to:

  • Create a new class of toolbar (as a derivative of the standard class) which can take both “standard” buttons and new …
  • super buttons which, instead of selecting a tool, pops up a sub toolbar containing standard buttons (and, recursively, more super buttons - perhaps!)
  • Create a user friendly interface for creation and maintenance of my new class of buttons and toolbars.
  • For extra credit, include “hooks” that other extension developers could include in their extensions in this order to allow my tool to include their tool’s button(s)

Have I am missed anything? Or displayed any misunderstandings that should be corrected?

Thanks in advance!

have a look at LaunchUp and Custom Toolbar threads at SketchUcation, you’ll see it’s a well trodden path and not easy with the ruby API…

A lot of us rely on keyboard shortcuts and avoid the need to display every tool under the sun…

for many of the ‘sets’ you can write simple one button loader that keep them at bay unless you need to use them…

on the journey it’s common to load everything you stumble upon and easy to loose track of those that aren’t used…

I had 1000+ at one stage myself, hence a rethink…

john

Many people, including me, have requested this before. In the SketchUp ‘getting started’ toolbar you see a nice example of some native tools that already have a flyout button. If that functionality would be available in the API every ruby developer would gladly use it (I would!).

Did you have a look at the developer page for the toolbar methods? http://www.sketchup.com/intl/en/developer/docs/ourdoc/toolbar
You will see there’s not much to work with do fulfill your request… Crossing fingers for V2017

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.