I had the idea to use JUCE' Component's neat setTranform() to implement a quick and dirty resize feature inside my audio plug-ins.
Inside the plugin editor, I do the following...
if( mode == 0 ) // normal size { setSize ( originalWidth, originalHeight ); setTransform( AffineTransform::identity ); } else // double size { setSize ( originalWidth * 2, originalHeight * 2 ); setTransform( AffineTransform::scale( 2.0f ) ); }
...which - to my surprise, works great. All fonts, hand-drawn elements, as well as bitmaps scale perfectly (at least for my purpose).
The only problem is the fact that PopupMenus aren't derived from Component and thus do not support tranforms at all. I searched throught the documentation and found this:
"Currently, transforms are not supported for desktop windows, so the transform will be ignored if you put a component on the desktop."
Ok. But as far as I can see, this implies that Comboboxes, even if they formaly support transforms, are not cappable to draw their own PopupMenu element properly?
The only fix I found is awkward (tricking the component to think that the original component has say, the double size than it really has; after hours of hacky jedi trickery). The tooltips on the other hand need a specific lookandfeel class for every possible size.
Now my question is simple: Why can't JUCE just derive anything "Popup" from Component (which would perfectly fine from the oop point of view)?
...or is there another way to achieve the same with the latest JUCE version? (maybe a mysterious setting telling JUCE that I don't want to draw my popupmenus on the desktop anyway?) The transforms seem to be the perfect tool for user controlled UI resizing. But the popup problem is truly a show-stopper for me. I really don't want to write my own elementary UI classes from scratch just because of that minuscule "missing feature" (which in the case of comboboxes smells more like a bug to me ;)).