« Return to Thread: Ruler comments
Re: Ruler comments
by Chris Fryer
::
Rate this Message:
On Sun, 2009-07-05 at 17:08 -0400, D. Michael McIntyre wrote:
> The only lingering thing I'd grouse about there is the way a bar
> will grow so tall that the top of its border is cut off when it hits the
> upper limit.
Yep. That's on my fictional list, quite near the back because the list
is dominated by implementing a ControlTool mechanism based on BaseTool
whilst fighting off the temptation to just process everything in widget
mouse event handlers.
> A few of the velocities I picked at random, the colors didn't lighten so well.
> At a certain range, you're getting into dark yellows that become bright
> yellows, and then revert back to dark yellows when unselected. It looks a
> bit strange. A good idea, just with a bit more tweaking indicated I think.
I've not looked at that yet. Maybe, as I said before, looking at saturation will
be the answer.
This behaviour is particularly relevant because you can't (now) use the control
ruler to change selection. I think this is logical given the ambiguity of notes in
chords but wanted to raise the fact at this early stage.
> Also, we really need some kind of alpha in here too, as a way to help deal
> with overlapping velocities. A chord with a different velocity in each note,
> the note with the highest velocity obscures everything else. I think the
> event rectangles on the matrix grid are already only 80% opaque (I have no
> idea what the real figure is) to show up overlapping events more easily. We
> could just find wherever that is and apply it in the ruler too.
Good point. I'll look into it.
> I'd almost vote for that after I just worked on a chunk of code with QColor
> here, Colour from one of our classes there, and Color from another one of our
> classes spread around in the middle. I used Colour in the new code as a nod
> to the Chrisses, but a good case could have been made to use Color instead.
> Kuller doesn't actually seem like such a ludicrous idea, but only if we can
> have QKuller too.
>
> (As far as that goes though, in the 18th century we changed "colour"
> into "color" and you changed "curb" into "kerb." At least "color"
> and "colour" are mutually intelligible. I had to encounter "kerb" about ten
> times before I realized it was a real word with a long history, and not some
> cute online gamer spelling like "teh" or "moar.")All we need is a half decent IDE that can translate for us. BTW I'm very
happy using eclipse now and recommend it strongly - I've got effective
debugging and everything. Now, if I could find the time to write some
"pedantic/pathetic/patriotic" plug-in that would offer "How do you want
to spell colour/color?"
------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
> The only lingering thing I'd grouse about there is the way a bar
> will grow so tall that the top of its border is cut off when it hits the
> upper limit.
Yep. That's on my fictional list, quite near the back because the list
is dominated by implementing a ControlTool mechanism based on BaseTool
whilst fighting off the temptation to just process everything in widget
mouse event handlers.
> A few of the velocities I picked at random, the colors didn't lighten so well.
> At a certain range, you're getting into dark yellows that become bright
> yellows, and then revert back to dark yellows when unselected. It looks a
> bit strange. A good idea, just with a bit more tweaking indicated I think.
I've not looked at that yet. Maybe, as I said before, looking at saturation will
be the answer.
This behaviour is particularly relevant because you can't (now) use the control
ruler to change selection. I think this is logical given the ambiguity of notes in
chords but wanted to raise the fact at this early stage.
> Also, we really need some kind of alpha in here too, as a way to help deal
> with overlapping velocities. A chord with a different velocity in each note,
> the note with the highest velocity obscures everything else. I think the
> event rectangles on the matrix grid are already only 80% opaque (I have no
> idea what the real figure is) to show up overlapping events more easily. We
> could just find wherever that is and apply it in the ruler too.
Good point. I'll look into it.
> I'd almost vote for that after I just worked on a chunk of code with QColor
> here, Colour from one of our classes there, and Color from another one of our
> classes spread around in the middle. I used Colour in the new code as a nod
> to the Chrisses, but a good case could have been made to use Color instead.
> Kuller doesn't actually seem like such a ludicrous idea, but only if we can
> have QKuller too.
>
> (As far as that goes though, in the 18th century we changed "colour"
> into "color" and you changed "curb" into "kerb." At least "color"
> and "colour" are mutually intelligible. I had to encounter "kerb" about ten
> times before I realized it was a real word with a long history, and not some
> cute online gamer spelling like "teh" or "moar.")
happy using eclipse now and recommend it strongly - I've got effective
debugging and everything. Now, if I could find the time to write some
"pedantic/pathetic/patriotic" plug-in that would offer "How do you want
to spell colour/color?"
------------------------------------------------------------------------------
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
« Return to Thread: Ruler comments
| Free embeddable forum powered by Nabble | Forum Help |
