pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Data, Components and Skins
Date Thu, 30 Sep 2010 13:36:34 GMT
> The data model for a score contains one or more StaffComponents which in turn each reference
a StaffComponentModel object that wraps a [collection] which contains Chord objects which
also have a [collection] which contains Note objects. Having the ability to declare the object
graph for a whole score or just a staff in BXML is important and it also looks like what type
of Pivot collection to use in place of the generic placeholder [collection] used by the StaffComponentModel
and Chord objects is important for binding.

You'll most likely want to use a "read-only sequence". The WTKX Primer section of the tutorial
talks about this - I'm currently in the process of updating it to cover BXML, but many of
the concepts still apply in the earlier version.

> What I am thinking of is having a StaffComponent, StaffComponentModel (also known as
a Part in music) and StaffComponentSkin. There is only one type of StaffComponent that is
created for each score staff desired. A StaffComponent will then reference one of the StaffComponentModel
instances that are stored in a separate map outside of the score. A StaffComponent will also
have a StaffComponentSkin which will be able to layout and paint the music data in the StaffComponentModel
referenced by a StaffComponent in any possible way.

Makes sense.

> The StaffComponentSkin should be able to dynamically load JSON resource files to provide
user/style properties (to load into it dictionaries) which will be recipes for different notation
types (there are many types of proposed notations besides the standard notation we all know).
Is it possible to use the same resource file mechanism that localization does for this?

Yes, you could certainly do that. But it might be more consistent with Pivot design to define
"styles" in your skin class that allow the caller to customize its appearance/behavior. Styles
are simply bean properties defined by your skin class. They can be accessed by the Component's
style dictionary and set either programmatically in code or declaratively in BXML (using either

> is it possible to dynamically load/store notation resource files for a StaffComponentSkin
so the LNF for a staff can be changed at any time and be completely pluggable (as in PLNF)?

Pivot doesn't support runtime replacement of the entire L&F like Swing does. However,
you can dynamically change styles at runtime, which may be sufficient. If you find that providing
multiple skins makes development easier, you could simply re-instantiate the component using
a specific skin and re-attach it to your model. This would allow you to swap out the L&F
for an individual component, at least.

> There are also Renderer objects and Decorator objects to consider as extensions to the
StaffComponentSkin. With the StaffComponentSkin responsible for the layout and painting of
the data in the staff's StaffComponentModel how would Renderer and Decorator objects be best

Components represent the "controller" in Pivot's MVC implementation, and skins represent the
"view". A skin defines the overall L&F of a component, but it doesn't define how the component's
content is painted. That's where renderers come in. However, based on my understanding of
your app's requirements, I'm not sure you would need to support a renderer (not all skins

Decorators are used to augment a component's default paint behavior. They allow a caller to
hook into the paint process before and after a component is painted. Skins often take advantage
of them, but they don't necessarily have to. In other words, there's no need to use a decorator
if you can implement the behavior you need within the skin's paint() method.


View raw message