>(*) Should pivot.wtk.Dimensions/Insets/CornerRadii/Bounds be final and >immutable?
This is a very good question, and could definitely generate a lot of discussion. Ideally, they would be implemented as structs, but Java doesn't have structs. >(*) What does HorizontalAlignment.JUSTIFY and VerticalAlignment.JUSTIFY >mean? It means stretch the contents to fill the available space. You are correct that it isn't relevant to all components. Components that don't support it should throw. >(*) Why does Renderer#getStyles not return a StyleDictionary? >seems like it would be nice if Style information was available in a >generic fashion. That would tie it tightly to Component, which we didn't want to do. >(*) TabPane would be more useful if I could set a component on the title >section of the tab, so I could draw whatever I wanted. This would probably be best implemented by providing a TabPane.TabRenderer interface, similar to what we do elsewhere. TabPane.TabPaneAttributes would change to define a single tabData property (as an Object) instead of separate icon and name properties. >(*) Component#StyleDictionary should expose methods for getting the >valid values of an enum property, >since some methods will take an enum, but will only be valid for some >subset of the values on that enum (e.g. usage of VerticalAlignment) Possibly, though this may be better served via documentation. A skin wouldn't be expected to programmatically provide info on the range of valid float values for a style property, for example. >(*) The Component#Attributes mechanism looks fragile. >What if I want to extend TabPane and add my own attributes? >It seems like this mechanism could be less fragile and more type-safe by >hand-coding Maps into the relevant sub-classes. I wouldn't characterize it as fragile - but it isn't all that pretty, I'll give you that. I'll have to give some thought to the subclassing question.
