On Saturday 28 July 2007 01:04, M. Donalies wrote: > In NotationProperties, the following are defined globally (same > across notation views): > HEIGHT_ON_STAFF; > NOTE_STYLE; > BEAMED; > BEAM_ABOVE; > SLASHES; > STEM_UP; > USE_CAUTIONARY_ACCIDENTAL; > OTTAVA_SHIFT; > SLUR_ABOVE;
In my previous email I said that making HEIGHT_ON_STAFF view-local should be fine. The reason for that is that HEIGHT_ON_STAFF is always computed -- you never supply the value for it yourself. The worst that should happen if you made it view-local would be that Rosegarden ended up computing the same value more than once. That is the case for all of the view-local NotationProperties properties. However, not all the properties in the list above are purely computed -- some of them can be set or overridden by the user. For example, STEM_UP is usually computed and set by Rosegarden as a non-persistent property, but the user can override it with a persistent property through ChangeStemsCommand. That wouldn't be possible if the property was local to the view (see VIEW_LOCAL_STEM_UP, a view-local property derived from the current value of STEM_UP and adjusted according to the view's layout). I think SLASHES, NOTE_STYLE, USE_CAUTIONARY_ACCIDENTAL and OTTAVA_SHIFT can currently only be set by the user; SLUR_ABOVE and STEM_UP are normally computed but can be overridden by the user; BEAM_ABOVE is computed and can in principle be overridden, but never actually is (the overridden value is set by STEM_UP and deduced from that instead); and HEIGHT_ON_STAFF and BEAMED are only ever computed. > Would it be possible to attach these properties to a Track or a > NotationStaff? Some of these are very problematic for the reason above. OTTAVA_SHIFT is a great example of why it's such a fundamental problem, and also maybe a hint about a possible solution. The user is setting a property that is in fact only "staff"-local (you don't necessarily want an ottava in all types of staff, and it depends on the clef in force), but they have to do it in a global way because all properties the user can set have to be global. So a property like that really wants to be local not to the view, nor to the specific instance of a staff, but to the "type" or configuration of the staff, so that the user can set them in one view and have them apply to all views in which the same segment is shown in a similar type of staff. But that doesn't apply to all the view-local properties -- many of them hold things like pixel values, and those depend on the font size in the current view and similar settings, and so have to be local to a view, or to something like a staff within that view. > noteheads (numbers displayed as text) I switched to an ordinary text > font (same one that's used for fingering). I don't seem to be able to > place it correctly, though. When drawing text, the origin for coordinates is x = the left extent of the first character, y = the baseline of the first character. If you want something else, you have to do the sums. Numbers have no descenders, so the effective origin for a numerical string is the bottom-left of the first character in your string (the exact bottom-left, with none of the usual between-character spacing). Chris ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
