I’m planning on killing off the Drawable::createFromValueTree and Drawable::createValueTree methods, and simplifying the Drawable classes to use simple coords rather than the RelativeCoordinate classes (which will eventually also be removed).
I suspect that nobody will notice this, since I doubt if anyone is actively loading/saving Drawables, but if you do rely on this, please speak now!
Bump. Just sayin’ that we’ll delete this stuff pretty soon unless there’s a huge outcry.
(while at it, perhaps rework/implement another Drawable that’s not a Component anymore?)
Yes, something I’d quite like to do would be some classes that actually represent SVG elements, which would be a nice standards-compliant way to do the same thing
But the drawables, that are Components, would be nice, if they could be placed using setBounds()…
If I use setBounds for DrawableText, it always goes amiss…
Speaking of ComponentBuilder, will the whole ComponentBuilder be removed?
Is a replacement planned?
What stopped me from using the ComponentBuilder in the past was the missing documentation of the needed properties of the ValueTree for each Component…
The confusing thing about Drawables is that setBounds makes no sense when you’re talking about a path or transformed shape. I think a better replacement would be some SVG classes that don’t have any concept of a bounding box.
Yes, ComponentBuilder was a bad design and is on the hit-list for deletion, though it’s very hard to judge how many people that’d affect (if any!)
A good replacement system for making UI development easier is something that’s a high priority feature for us, but we’ve not figured out exactly what form it’ll take yet.
