<-----Ursprungligt Meddelande----->
From: Henrik Andersson [EMAIL PROTECTED]
Sent: 11/11/2008 11:07:41 AM
To: [EMAIL PROTECTED]
Subject: Re: [Rosegarden-devel] Question concerning rev. 9523
Hi, those change's is a small change in the line for my implementation
of drawtools
to the ControlRuler, the actual change was to show the actual event
duration of a CC
and not the hardcoded width of an event.
But as mention by Chris im apperently uses the wrong methods for getting
the actual width
and i will update the code to suggested method.
Thats all for that change, the tool works as before until i have worked
out the DrawTools as mention below.
Here's a roundup for what im working on:
The draw line tool today is ugly integrated into the
ControllerEventRuler which i have removed
and implemented a new baseclass DrawTool which is used for implementing
tools like drawline/freehand draw in the ControlRuler.
The tools im working on will insert events @ each quanted time selected
in Quantization combobox, and will have the duration matching the quant
so no visual overlaps och eventrepresentation will occur.
/Henrik
<-----Ursprungligt Meddelande----->
From: Chris Cannam [EMAIL PROTECTED]
Sent: 11/11/2008 10:30:31 AM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Rosegarden-devel] Question concerning rev. 9523
I haven't tested this patch yet and I don't want to distract anyone
from answering Julie's query, but I would like to comment on one thing
in the patch:
int width=m_rulerScale->getXForTime(e->getDuration());
The mapping from time to pixel position provided by a RulerScale is
not necessarily linear. You can't just call getXForTime with a
duration and expect to get the right pixel width back -- the pixel
width corresponding to a given duration may vary depending on where in
the timeline that duration begins.
Always use RulerScale::getWidthForDuration(timeT startTime, timeT
duration) when you want to map from duration to pixel width.
In a perfect world, "time" and "duration" would have different data
types, and this sort of confusion would be prevented by the compiler.
In hindsight, I really wish we had done that in Rosegarden.
(Of course, calling getXForTime will work by accident much of the
time. In the matrix, the mapping _is_ linear. But it's a pattern
that it pays to get right, as there are plenty of places in Rosegarden
where this kind of mix-up can lead to serious consequences -- most
notably when using the conceptually similar conversions between
musical time and real-time in Composition.h, where mixing up time and
duration will give you the wrong result as soon as you hit a tempo
change.)
Chris
------------------------------------------------------------------------
-
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
.
-------------------------------------------------------------------------
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
