Now that all components can be scaled arbitrarily, I’m thinking of getting rid of the MagnifyingComponent, which was really only created as a temporary hack to allow zooming in the old jucer, and which has some unfixable problems due to the way that the new mouse input classes work… Would its demise upset anybody?
I think it’s still useful for some particular scenarios, so you probably need to keep it.
For instance, I plan to make a app to help the old people to surf in the internet, so the key functionality is make the app gui much visible for them.
It maybe need zoom out the text on the window box, so the magnifyingcompont will help with this.
If my requirment is resonable, please fix the defects and keep it:)
Zooming in can be done in a much, much better (and easier) way now by simply using a transform. The only difference with a magnifyingcomponent is it scales things up using a bitmap, so that when you zoom in, everything will be blocky. If you’re trying to make things easier to read, you definitely don’t want the magnifyingcomponent!
Great suggestion. Thanks Jules.
BTW, I try to create a tiny Squirrel script edit tool, called as a nice name “SquirrelStudio” these days, I don’t think it’s easy to implement a multi-docment window using Juce, e.g, implementing the float window. The final demo should like visual studio8.
It’s reasonable, due to juce is young library and maybe need much work to do, moreover, I find it’s very esay to create personalized customization ui, likes msn, icq ui.
What’s your opinion about this?
It’s just one of a million things I need to do…!
AffineTransform class can accomplish the same thing? How to use it?
I have read API documentation, but don’t understand.
This method is much better than MagnifyingComponent. Very clear!
MagnifyingComponent zoom in component are not clear.
scoreRongqi-> setTransform (AffineTransform:: scale (float (biliSlider-> getValue () / 100), float (biliSlider-> getValue () / 100), float (getWidth () / 2), float (getHeight () / 2 )));
Happy new year to all 8)
Is it possible to scale a component via the new transform methods in a viewport with correct scrollbar behaviour?
How does the viewport calc the size, when the content is rotated?
Yeah… a sort of zoomable viewport would be great.
I agree with that!
At the moment the viewport won’t cope with transforms, but you can always put your transformed comp inside another normal one and put that in the viewer.