Code infrastructure for accessing different properties of multiple elements (vector graphics editor)

Question

Hi everybody,

I am currently working on a small vector graphics editor (sort of) and facing a code design question, wondering how it would be solved in an elegant and straightforward manner.

If anyone has a good idea how to solve this, or knows a good link or a piece of open source code dealing with a similar setup, I would be really happy.

Basically, the status quo is as follows

• a stage holding all elements, knowing which elements are selected
• it is possible to select multiple elements
• each element may have child elements (which cannot be selected separately but may have their own properties)

What I want to do implement is a property toolbar which allows changing properties of selected elements.

Of course, different element types have different properties - the toolbar should display the intersection of selected element types.

I have spent a lot of time thinking about this and thought about several approaches, none of which seems to be really elegant/straigtforward. I thought about using maps or reflection, but would prefer to have a typesafe solution without casts. I suspect I might be missing an obvious solution here or a cool pattern I do not know... At first go, what would be your idea for approaching this?

Thank you very much for any inspiration with this.

Answer 1

There's a property dialog, that will allow you to show properties of objects, and allow you to change them.

It is, however, not a toolbar, as what you want.

Answer 2

In the real world apps like vector graphics editors typically have a higher-level pseudo-object system of their own that implements document-object-level ‘properties’ as entities of their own, with features like group setting, change history and so one that the language's own object system cannot provide.

Could this be done using just reflection and the built-in object model? Maybe, depending on what language you're using. But certainly in C++ it would be an enormous pain in the face which I wouldn't attempt. With more dynamic languages you'd have a better chance, but you'd still need a way to distinguish user-interactable properties from anything else provided by the object, and I'd tend to do that with meta-object overhead like an ordered list of user-visible property names and their corresponding datatypes, defined on the document-object base-class, rather than totally relying on reflection.