On Wednesday 02 August 2006 3:29 pm, Chris Cannam wrote: > Just tried it out -- very nice! What a great little dialog.
Why thank you! > Of course > I can now visualise all sorts of enhancements (e.g. a pitch range > preview illustration on the dialog), but I should probably shut up > about those unless and until I'm actually going to implement them > myself. You think just pitch range? That might be a reasonable compromise between what I was thinking about, and what I did. Namely, what I did was nothing. I was thinking about some dummy widgets to preview the contents of all the fields you were about to buy, but then it seemed like another kind of slippery slope, as you alluded to, whereby people would want to edit these values in situ and save their own copy. I'm not averse to making it possible for the user to edit their own userspace version of the database, but there are several problems to solve, and a lot of additional work. Couple that with the gigantic database Magnus provided (*), and I just don't see a lot of need. I think I'll leave it up to a user referendum. If a lot of people say "Wow, this is cool, but why can't I save my own presets?" then that's an indication it's worth the trouble to go the extra mile. It would be an extra mile. Some way to juggle the appdata global vs. local thing, and code to write the database in RAM back out to a file. A decision to be made whether to maintain user custom settings and global settings in the same file, in the style of many other things (eg. autoload.rg), or to create a new instance of PresetGroup that populates itself from a different file (the file is currently hard coded to our installed presets.xml, but I could easily pass in a filename in the ctor to make each instance read a different one, perhaps even an arbitrary one from a KFileDialog.) The way that structure is built, it would be trivial to put in a fourth combo that selects between Factory and User presets, and then re-populates all the dependent widgets from the respective database. There could even be more than one collection of user presets loaded at the same time, each PresetGroup from a different file. I think that was a rather elegant design, and it seems something of a pity not to make some use of the self-contained nature of each database. Anyway, there are a lot of different ways to go with all of that, a lot of decisions to make, many things that would do, but finding the best way is a good bit to think about. I just see all of that as a potential future enhancement for 2.0. No use doing everything on the first release, is there? I'll bet commercial software holds back potential extensions of things like this on purpose. > to edit the preset name to wanting to save a new preset, so maybe it > should just blank out the preset name when you modify one of its > properties? Indeed, I intended to do that already, and overlooked it. Change it to something like "<user>" maybe. > Another thing -- it'd be nice if the dialog remembered your last > selection. The coolest way to do this would be using KConfig, as then > it could remember the selection from one run to the next. I have a feature request reminding myself to do this, and there's already a slotOK() stub in the code as a place to write out the config. The problem I have to chew on is what to do about the Instrument combo. Of course its indices are totally dependent on whatever was in the Category combo. I need to make sure nothing evil can happen if I load some indices from KConfig that refer to combo items that no longer exist. (*) The clef thing. I also need to figure out what to do with the clefs. Maybe add Soprano, which looks easy, but we really can't handle any of the stuff that depends on the two-bar percussion clef yet. I've about concluded it's better to avoid exposing those to the user than to create them with the wrong clef. Not such a big deal, but it eliminates a huge chunk of Magnus's database for the time being. Figuring out a true percussion clef is something we really ought to think about, but I don't guess there's any hope of sneaking it in before 1.3. It's certain I won't have time to think about it. I'm more ambitious lately, but not *that* ambitious. > > (I *do* hope it goes into 1.3. > > Oh yeah, it definitely will. Excellent. I'm going to continue working like a dog to get this finished ASAP. I've gotten word I start the new job in two to three weeks, depending on whether my replacement sticks or not. The future beyond the job change is completely nebulous, but there are surely rocky times ahead. I hate changing jobs. Inertia is the main reason I'm still driving a truck nine years later. This is no easy thing I'm doing here, trading the mixed comfort of knowing just where the thorns in my back are stuck for a completely unknown quantity. I'm gambling there will be fewer thorns, further between, but I could be jumping out of the frying pan and straight into the fire. "Looking at the cake is like looking at the future, until you've tasted it what do you really know? And then, of course, it's too late." --Merlin -- D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
