I really like the mouse behaviour of PopupMenu. You can mouse down on a button and then while holding the mouse down drag and release to select a a menu item with all the mouse over highlights working.
I had a dig in PopupMenu to try and figure out what’s going on, but the mouse handling is kind of crazy, basically seems to be running a timer and grabbing the current mouse position, checking for mouse button events and then making it work from there by being as non-standard as possible
Would be nice if there was a standard way of doing this for any components? Maybe something baked into ComponentPeer so the behaviour looked completely standard for the client components?
Or failing that the logic in PopupMenu could be factored out into a reusable class with some custom callbacks so it’s possible to write arbitrary PopupMenu style widgets?
Actually what you’re observing there, is the behaviour modifications required to make a JUCE UI behave acceptably-well on Touchscreen-based devices, such as iOS/Android tablets.
As far as extending PopupMenu, I believe that the future of sub-windows that are a child of a main window is going to be somewhat limited - this is because, with new plugin formats (AUv3), the ability for child windows to attach to parent windows after-the-fact of loading, is going away. Sandbox’ing being what it is, this inter-window context relationship is becoming less and less relevant. So for example, in my plugins, I have removed all subwindow-style popups, such as PopupMenu, and replaced them with dynamic components which slide in/out in the context of the main Component. This works great on Windows, MacOS and Linux, and of course is simply TheWayForward™ on touch-based interfaces.
That said, you can still achieve what you want by replacing sub-windows with ‘smart Components’ …
