Removing Drawable::createFromValueTree methods


#1

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!


#2

Bump. Just sayin’ that we’ll delete this stuff pretty soon unless there’s a huge outcry.


#3

(while at it, perhaps rework/implement another Drawable that’s not a Component anymore?)


#4

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


#5

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…


#6

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.