Dear Chris,
You wrote:
> Note that you can use the mouse wheel over the blue area to
> zoom the
> main view in and out -- this probably needs to be mentioned
> in the
> status bar (sigh, another task there). To me, that
> also makes quite a
> big difference because it makes the blue box the place
> where pretty
> much all "large-scale" mouse navigation can be carried out
> very
> straightforwardly, without any annoying messing with
> scrollbars.
Yes, I see how the the mouse scroll wheel works with the blue area. But that
is an awfully big landing area for that feature.
The zoom widget Michael took from sonic visualizer is much more compact
horizontally and appears to accept mouse wheel events in the same fashion. But
I didn't look at the code, he may just be relaying these events to the blue
area widget for processing.
You wrote:
> Well, I implemented it and I like it a great deal. I
> think it makes a
> world of difference in terms of keeping a sense of where
> you are in a
> composition.
Well if you like it that is something then. I wasn't certain how people felt
about it--hence the inquiry. I didn't recall how it ended up in RG Thorn.
I can see where helping to navigate medium sized segments could be useful.
Specially in matrix view, percussion view, notation linear layout, or notation
multipage layout. But it is outright useless for many sizes segments for
notation continuous page layout. Continuous page layout really make the blue
area an ineffective information area, since continuous page layout is vertical
in nature and the blue area is a horizontal heavy feature.
One wild solution is re mount the blue area vertically along one of the sides
of the screen while in notation continuous page layout. But that sounds like a
lot of work indeed.
You wrote:
> I'd like to try to make some improvements to how it works
> with very
> long scenes, for example by squashing them a little less
> vertically
> than it does horizontally, but even without such things I'm
> pretty
> keen on it.
It definitely can use some tweaking, and some more bounds restrictions on the
white box. There is merit to the box, but I'm certainly not liking it a whole
lot right as it is.
I liked that in matrix view it appeared to show the non-active segment data in
a lighter color than the active segment. That was a nice touch.
I can see the appeal of centering the segment data in the blue area, but I find
that a bit inconsistent, though it is more aesthetically pleasing. Left
justify the data in the area perhaps?
Concerning the actual effective area of the blue box, I mentioned more
restrictions on the white view window box which would more accurately reflect
the segments limits under consideration. Maybe an additional step would be to
box and gray out (no necessarily gray) the unused area. In many cases this
would drastically reduce the brightness of the screen in that area and clearly
delineate the active region of the blue area. In large segments, the blue area
will be bigger, but the content in the active region will keep the brightness
in check.
Well, those are my thoughts on this.
Sincerely,
Julie S.
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
