On Tuesday 15 August 2006 5:29 pm, Chris Cannam wrote: > I don't find them comfortable, I don't use them, and I > probably never will - although I do kind of like them in > theory, and would understand if others did in > practice.
I'd probably never use them either if it weren't necessary to do so in order to get to my new additions. I quite agree with what you expressed so well, "The track is becoming less like an arbitrary y coordinate for the segment, and more like an object that the user will want to tweak to their requirements." I think this is a good direction in which to move. I also made an attempt to have new segments take their name from a loaded preset. I don't remember if I tested whether it worked. What I'm after with that is trying to establish a loose but real connection between a segment and where it came from originally. You can move them, sure, but I want to try to make it obvious to people that a trumpet segment created on a trumpet track does not become a flute segment that magically transposes itself if you drop it on a flute track. This is the same thing I was trying to achieve when I created a new, different default color for audio segments. In the case of the presets, I decided not to make color a part of this, because it's the one thing that would have made it absolutely mandatory to offer users some friendly GUI mechanism for customizing their personal preferences, and I'm deferring that for some boring day in the future. Which, incidentally, suggests we might want to change the default MIDI segment color after all. When last I spoke on that, I was thinking that my presets would, in fact, have colors. (That was before I saw the 300+ entries Magnus came up with too. I think perhaps if we ever do have color as part of this, it should be on a per category basis.) If we do change the default, why not handle it the same way I did audio? It's not a real hard coded default, but only a hard coded index referring to the user-editable colourmap, and it won't come out right on studios that aren't derived from the autoload that shipped at that time. It's index 1 I think, a named constant somewhere, and the index 0 is reserved for our default. We could have a default default failsafe in code, but switch things a bit to allow index 0 to be edited. Then we can change the color, and if people hate it, then they can change their own default, as well as their own audio default. Actually, hell, I never tried that. I already *can* change the "Rosegarden green" default. The color applies to segments after they're drawn, but the segment in progress is drawn using what must be some incorrectly hard-coded reference to the default default color. Anyway, I'm getting completely off the subject here. > the omission > of the extended track properties in stacked mode is > a serious showstopper in my book (i.e. I don't see > tabs as a good enough answer). We probably need > a quick open/close toggle for the extra properties in > each box, or something similarly unwieldy. And then, > yes, a vertical scrollbar for the whole area. Damn it. I'm afraid I agree that tabs aren't good enough. I say continue to offer that if anyone cares to use it, but we really must find some other way as well. I'm leery of another "flap" implementation, because the damn flap on the transport is always forgetting its settings at random, for no discernible reason. I hate the flap, and would probably delight in just showing all the controls, and abolishing the flap. I have real doubts about a "show extra controls" implementation that wouldn't piss me off. As I said when this came up the first time, I could live with a GIMP-style scrollbar for each section of the panel, which I could use to position the controls I'm interested in at this moment where they are at hand. Then, yes, we'd probably have to have a scrollbar for the whole thing as well, for short displays. If the notion of a scroll for each PB and an overall scroll just makes you want to vomit, then is there some way we could put toggles on groups of controls without eating too much space? The problem I see, in addition to the whole KConfig amnesia problem that refuses to die, is that we might well all have different ideas about which controls are the "extra" ones. > I did find myself agreeing > with much of your email just now. Well, that's encouraging. One of the biggest obstacles to progress around here has always been our failure to be able to come to an agreement as to just what should be done. Too many flexible people, not enough assertive people. Plus there's always the siren song of the easier solution over the best solution. -- 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/ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
