shadowphiar wrote > My CapoText object is derived from Text, which is derived from Element. (I > wondered if under some circumstances people may want to edit the text > which is displayed? Not really sure if I can come up with a concrete use > case for that, but I couldn't rule it out either).
Well, I haven't your current code under my eyes right now, but maybe the text it creates is geared toward English. Users using other languages (not necessarily their *system* language) may need different texts. But I wouldn't tie the object to its textual functionality only: its numeric data can be used by other objects as well. So, perhaps, it is better to name it simply "Capo" (of which the text would be one property) rather than "CapoText"? > At the moment, it's going into the same Segment as the chord it is > attached to (like Tempo does). Is this a problem? Quite probably, no, it isn't a problem: if Tempo's are in chord/rest segments as well, evidently it works. It is in the Segment annotations? > I will have a look at Staff, and at TempoMap which was mentioned earlier > in the thread; and either extend one of them to hold more generic > information or implement a new similar mechanism, depending on what seems > most sensible. This is a very personal suggestion: once the Capo object is in place and more or less complete (with an eye toward a flexible usage), what about limiting in the UI -- at leat for the moment being -- its use to the score first chord/rest only (if it remains attached to chord/rest segments). This could do without having to implement a mapping/listing/... mechanism: testing the new object and its accessibility and usability from, say, tabs wold be simpler and quicker. Also the maps already existing are probably going to be worked on (and there is a shift from Qt containers to STL containers). Once all of this will be reasonably stable, the functionality (and the UI) of the Capo object could be extended more easily. But, as I said, this is a personal opinion. > Yes, I am working on the assumption that there will be a text style > associated with the element. (Equally though, happy to use an existing > style if it is considered that the user is getting overloaded with > numerous text styles for infrequently-used elements). I personally do not see this as a problem: text styles are never enough! I use the "New text style" feature quite frequently to define special styles maybe needed only occasionally. As Leon volunteered to take care of the MusicXML I/O, I can take care of the interaction with TAB's, if it is OK. Thanks, Maurizio -- View this message in context: http://dev-list.musescore.org/Capo-support-in-tablature-tp7577937p7577974.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
