Nest attributes for layouted objects

[asinghvi17]

TODOS:

• [x] Nest axis attrs
• [ ] Change function defs to reflect this
• [x] Good schema for actions (pan, zoom, etc.)

[asinghvi17]

@SimonDanisch @jkrumbiegel is this appropriate? Would a better way be to replace tuples with x and y, like actions = (pan = (keys = (x = Keyboard.x, y = Keyboard.y)...))?

[jkrumbiegel]

Yeah I personally don't like the tuples, makes updating a component awkward. But bundling the attributes is a good idea per se. We should keep the x and y identifiers, because that's what people search for when they want to manipulate the elements

[asinghvi17]

I've implemented that nesting - now, things are nested as ticks.labels.font.x and so forth. We can also implement preprocessing of args / magic kwargs such that the longer names can be constructed from the default list of Attributes.

The only thing left is to agree on a common set of attributes for text, and to actually implement this API in constructors.

[jkrumbiegel]

hmm thinking more about this, why should x and y be the last factor, isn't it more logical to separate xaxis and yaxis and then both have the same attributes? because they are effectively duplicated anyway

like x.ticks.labels.font to keep it short

so this way it would go down the hierarchy, it would also be more in line with how people look for attributes, filtering all the way down

[jkrumbiegel]

also, do you know what's a good way to inherit these attributes from a scene if they're not overwritten? I haven't set it up that way right now, the LayoutedAxis has it's own full set of attributes

[asinghvi17]

I see your point - I can probably get that done pretty easily.

I was also going to change how Attributes work, to allow for "long keywords" as well as the current method of nesting. Essentially, you should be able to access nested attributes using a String, and we would store a lookup table along with the attributes. Since this will be primarily user facing, it shouldn't incur too much overhead.

To be honest, though, I probably still prefer the x and y at the end for programmatic use, since they are often used together - but that's a small gripe. I agree that for user facing interfaces the first separation being x and y makes sense.

[asinghvi17]

Edit: This isn't an issue if I split the pan attribute up, into a toplevel panbutton and an axis level pan.

An issue is the nested attributes which have things that are axis-dependent and axis-independent, pan for instance. It has keys for x and y, but also a button which is axis-independent. I think that we could special case this, and have it and zoom with x and y last?

[asinghvi17]

also, do you know what's a good way to inherit these attributes from a scene if they're not overwritten? I haven't set it up that way right now, the LayoutedAxis has it's own full set of attributes

You can do it on a per-scene basis, by attrs = merge(theme(scene), default_theme(LayoutedAxis))