Jim Newton wrote > Hi Maurizio, Can you explain to me the relation between several classes. > I'm having some debugging problems and an overview of the intent might > help me. > > The class GlissandoSegment -> LineSegment -> SpannerSegment -> Element > Glissando -> SLine -> Spanner -> Element
In general: *Element*: all visible (and several non-visible) elements of a score derive ultimately from the class Element; we can think of this as a requirement of the MuseScore infrastructure. *Spanner*: it is a class for all the elements which may span across a time span: examples coming to my mind are: Volta, Slur, pedal indications and so on. IIRC, it is an abstract class. *SLine*: it is an implementation of Spanner for spanners with a visible line. *Glissando*: it sub-classes SLine and qualifies a glissando as a Spanner as, in general, a glissando may cover more than one system (for instance between the last note of a system and the first note of the next system). The other hierarchy is parallel but separate: *SpannerSegment*: it is one portion of a Spanner; a spanner covering more than one system is usually split in two (or more) segments, one for each system. Note that SpannerSegment's are the elements actually visible in a score. *LineSegment*: implements SpannerSegment for segments of an SLine. *GlissandoSegment*: sub-classes LineSegment for the individual segments of a glissando. > My situation is that I've added a new property the the Glissando (with a > QT interface to edit the property). > However, when I select a glissando in the score GUI, and change this > property, I see that the SpannerSegment::setProperty method is called, > which explicitly calls Element::setProperty. > This results in a qFatal being called in element.cpp inside > Element::setProperty(). Selection of Spanner's is tricky; it took me a while to understand all its implications. Basically, when you select (or believe to select) a Spanner, you actually select the SpannerSegment you physically clicked on. So, any property change is routed (by the Inspector framework) to the SpannerSegment class (or, in case, to a sub-class of it). If the property actually refers to the Spanner as whole, like for instance the STRAIGHT/WAVY property of a glissando, the relevant segment class (GlissandoSegment in this example) shall route the property change to the 'parent' Spanner class (or sub-class, Glissando in the above example). So, it mostly depends on the kind of property you added: if it is specific for each segment of the glissando, it should belong to GlissandoSegment and be managed by it; if it applies to the glissando as a whole, then the various methods of GlissandoSegment dealing with properties should route the relevant property get/set to the Glissando class. I do not have the code at hand right now, but I believe that, if you look at the GlissandoSegment::setProperty() and ::getProperty() functions, you should see some practical example of this. Hoping it may help, Maurizio -- View this message in context: http://dev-list.musescore.org/data-structure-for-glissando-tp7579311p7579330.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
