Emanuel proposes: > slot-name: slot_filter_selection > action-name: filter_selection > icon-name: filter_selection
No. We're definitely not going to have slots with names like this, so the only way to make any change would be to change the other strings to use lowerCamelCase notation as well, like filterSelection and so on. There's some room to debate that. I think I've used lowerCamelCase in other contexts. In the XML, I think. highestPlayable, lowestPlayable, and so forth. Yes, we use this (a bit inconsistently) in our .rg files. A random sampling: defaultTempo="120.0000" compositionDefaultTempo="12000000" startMarker="-7680" endMarker="384000" defaultClef="0" defaultTranspose="0" I think it would probably be best just to leave well enough alone though. Julie S wrote: > I like the idea of an external file. Emanuel mentioned JSON files which > are very human readable. My reservation is that we have traditionally used > XML for reading things, and I'd hate to add another file type to the mix. If we use external files, we'll use XML. We use XML everywhere. The guitar chord dictionary, the instrument parameter presets, our own native .rg and .rgd files. Adding some new format is nonsense. No. Chris talks about whether to use external files or hard code: My arguments for external files... * Some users like to rearrange their menus and toolbars by hacking their .rc files. If we continue to use something like this, they can continue to do that. * We should consider users who like to rearrange their toolbars through the GUI, doing their own action mappings. I'm not sure if Qt has an analog for Settings -> Configure Toolbars anyway, but I'm betting if we hard code we're eliminating any possibility of adding that functionality in any form. * It seems like it would be easier to get an overview of, and occasionally rearrange, the complicated menu structure if it continued to be stored in external files (We'd like to think we've got it right this time, but we've shuffled all of this around at least three times now.) Arguments for hard coding... * We have a lot of actions with weird names that bear no resemblance to their end-user readable GUI counterparts. "decounterpoint" is "Split and Tie Overlapping Notes" I think, for example. This kind of nonsense has caused me misery on numerous occasions, trying to figure out what connected with what to do what. It is often very unclear just what which action is supposed to do, when looking at the existing rc files. It seems like hard coding could do some good here in terms of bringing order to that chaos. (We also have a lot of legacy crap, still, with hard-coded references to an obsolete and long-forgotten menu structure. Lots of icon names come right to mind. I had trouble finding a number of icons without grep when I set about remaking all the notation editor icons.) (Which reminds me I still need to redo the crescendo and 8va icons, which look like crap.) -- D. Michael McIntyre ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
