From: Chris C. <ca...@al...> - 2007-03-27 09:46:57
|
On Tuesday 27 Mar 2007 10:03, gla...@us... wrote: > Changed build of TempoRuler RMB menu to use the parent window's > KXMLGUIFactory, like everwhere else Did you ever wonder _why_ the ruler wasn't using its parent's KXMLGUIFactory, like everywhere else? http://sourceforge.net/mailarchive/message.php?msg_id=36382774 So, please revert that one. I had already wasted quite a lot of time trying to find a better fix before I committed that. I do realise it's my fault that I didn't comment it properly. If you can find a better fix, go ahead, but I think it's easier and safer to just leave it the way it was working. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-27 10:23:01
|
On Tuesday 27 March 2007 11:49, Chris Cannam wrote: > On Tuesday 27 Mar 2007 10:03, gla...@us... wrote: > > Changed build of TempoRuler RMB menu to use the parent window's > > KXMLGUIFactory, like everwhere else > > Did you ever wonder _why_ the ruler wasn't using its parent's > KXMLGUIFactory, like everywhere else? > > http://sourceforge.net/mailarchive/message.php?msg_id=36382774 Yes, I recall that. However, I had just struggled quite a bit to get a KXMLGUIFactory built menu work for the MarkerRuler that I figured I could apply what I had just learned to the TempoRuler. In the mail linked above you mention the following problem : > The problem is that the second time a TempoRuler is > constructed, it fails to load the menu ("No menu TempoRuler in > temporuler.rc" from temporuler.cpp:151), and I can't immediately see why. I can't duplicate this problem after my changes. The menu appears and works correctly from the main window, and from any edit view created afterwards (even after closing/reopening edit views). BTW, a comment regarding that other part in your mail : > The segment tool's right-button menu does work even after it's destroyed > and recreated. That appears to be because it's extracting the menu from its > parent's rc file (rosegardenui.rc) instead of using its own. I also tried moving the menu into its own file for the sake of cleanness, but quickly realized that since the menu is actually made of actions from the main window, its definition has to be in the same rc file as the window. -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-27 10:31:31
|
On Tuesday 27 Mar 2007 11:23, Guillaume Laurent wrote: > In the mail linked above you mention the following problem : > > The problem is that the second time a TempoRuler is > > constructed, it fails to load the menu ("No menu TempoRuler in > > temporuler.rc" from temporuler.cpp:151), and I can't immediately > > see why. > > I can't duplicate this problem after my changes. The menu appears and > works correctly from the main window, and from any edit view created > afterwards (even after closing/reopening edit views). Follow the procedure Vladimir mentioned: open RG, right-click on tempo ruler, observe menu, use File -> New to create a new document, right-click on tempo ruler -- no menu. I seem to remember one of my intermediate attempts at a solution resulted in something that worked in the main window but not in edit views, but that isn't the particular problem that was being discussed there. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-27 10:35:49
|
On Tuesday 27 March 2007 12:34, Chris Cannam wrote: > > Follow the procedure Vladimir mentioned: open RG, right-click on tempo > ruler, observe menu, use File -> New to create a new document, > right-click on tempo ruler -- no menu. Indeed. There has to be a way to get this working... -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-27 10:42:05
|
On Tuesday 27 Mar 2007 11:36, Guillaume Laurent wrote: > On Tuesday 27 March 2007 12:34, Chris Cannam wrote: > > Follow the procedure Vladimir mentioned: open RG, right-click on > > tempo ruler, observe menu, use File -> New to create a new > > document, right-click on tempo ruler -- no menu. > > Indeed. There has to be a way to get this working... There was! Chris |
From: Guillaume L. <gla...@te...> - 2007-03-27 11:12:27
|
On Tuesday 27 March 2007 12:44, Chris Cannam wrote: > On Tuesday 27 Mar 2007 11:36, Guillaume Laurent wrote: > > On Tuesday 27 March 2007 12:34, Chris Cannam wrote: > > > Follow the procedure Vladimir mentioned: open RG, right-click on > > > tempo ruler, observe menu, use File -> New to create a new > > > document, right-click on tempo ruler -- no menu. > > > > Indeed. There has to be a way to get this working... > > There was! There is now. (I haven't spent half a day recompiling kdeui in debug mode after having added a bunch of traces in the kxml* code for nothing, dammit'. LD_PRELOAD is my friend.) -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-27 13:49:42
|
On Tuesday 27 Mar 2007 12:13, Guillaume Laurent wrote: > There is now. Hooray! Good work. The marker ruler menu doesn't appear to have benefited from this fix yet, I notice. A couple of other things I just noticed. Both these bugs are in 1.5.1 as well, so they're almost certainly my fault, but if you're looking: * the tempo ruler doesn't appear to resize when you change the zoom level in the matrix (it's fine in notation or segment views) * the tempo ruler menu's Delete Tempo option doesn't appear to work Chris |
From: Guillaume L. <gla...@te...> - 2007-03-27 14:25:02
|
On Tuesday 27 March 2007 15:51, Chris Cannam wrote: > > The marker ruler menu doesn't appear to have benefited from this fix > yet, I notice. Duh :-). So much for the triumphant feat. Thanks for reminding me, it's fixed now. > A couple of other things I just noticed. Both these bugs are in 1.5.1 > as well, so they're almost certainly my fault, but if you're looking: > > * the tempo ruler doesn't appear to resize when you change the zoom > level in the matrix (it's fine in notation or segment views) > > * the tempo ruler menu's Delete Tempo option doesn't appear to work OK, I'll take a look. -- Guillaume. http://telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2007-03-27 17:11:30
|
On Tuesday 27 March 2007 15:51, Chris Cannam wrote: > * the tempo ruler doesn't appear to resize when you change the zoom > level in the matrix (it's fine in notation or segment views) Did this use to work ? I'm probably missing something as I don't see any code to update the ruler when the zoom level is changed. -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-27 17:30:59
|
On Tuesday 27 Mar 2007 18:12, Guillaume Laurent wrote: > On Tuesday 27 March 2007 15:51, Chris Cannam wrote: > > =A0* the tempo ruler doesn't appear to resize when you change the > > zoom level in the matrix (it's fine in notation or segment views) > > Did this use to work ? It's quite possible it didn't. It's also possible it got lost in the=20 code reorganisation, I suppose, although I'm not sure how. I don't remember ever having explicitly tested it and found it to work. > I'm probably missing something as I don't see=20 > any code to update the ruler when the zoom level is changed. If nothing equivalent to whatever happens in the segment and notation=20 views isn't evidently present in matrix (or base class) at the=20 appropriate moment, then you're probably right. Chris |
From: Chris C. <ca...@al...> - 2007-03-27 17:33:29
|
On Tuesday 27 Mar 2007 18:33, Chris Cannam wrote: > If nothing equivalent to whatever happens in the segment and notation > views isn't evidently present in matrix (or base class) at the > appropriate moment [...] Ugh. Well, I hope you know what I meant. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-27 21:50:24
|
On Tuesday 27 March 2007 19:36, Chris Cannam wrote: > On Tuesday 27 Mar 2007 18:33, Chris Cannam wrote: > > If nothing equivalent to whatever happens in the segment and notation > > views isn't evidently present in matrix (or base class) at the > > appropriate moment [...] > > Ugh. Well, I hope you know what I meant. I'm not sure actually. Anyway, something strange is going on : it's more than a simple update() problem, triggering a repaint doesn't make any difference, yet paintEvent() does use a ruler scale to compute its positions. I'm trying to see if the ChordRuler exhibits the same problem, bit it seems to be broken altogether, not displaying anything at all. -- Guillaume. http://telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2007-03-28 09:12:49
|
On Tuesday 27 March 2007 23:51, Guillaume Laurent wrote: > On Tuesday 27 March 2007 19:36, Chris Cannam wrote: > > On Tuesday 27 Mar 2007 18:33, Chris Cannam wrote: > > > If nothing equivalent to whatever happens in the segment and notation > > > views isn't evidently present in matrix (or base class) at the > > > appropriate moment [...] > > > > Ugh. Well, I hope you know what I meant. > > I'm not sure actually. Anyway, something strange is going on : it's more > than a simple update() problem, triggering a repaint doesn't make any > difference, yet paintEvent() does use a ruler scale to compute its > positions. Upon further investigations, it's not that something is broken, it's that the code just isn't there : the ruler scale which the tempo ruler in the matrix view uses is the matrix horiz. layout, but there is no way to tell this layout that zoom has occurred (the zooming in the matrix view is done by changing the canvas' transform matrix). -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-28 09:56:19
|
On Wednesday 28 Mar 2007 10:13, Guillaume Laurent wrote: > Upon further investigations, it's not that something is broken, it's that > the code just isn't there : the ruler scale which the tempo ruler in the > matrix view uses is the matrix horiz. layout, but there is no way to tell > this layout that zoom has occurred (the zooming in the matrix view is done > by changing the canvas' transform matrix). Oh, of course -- that f*#*ing matrix. It's probably unwise to change the ruler scale anyway, because presumably that would mean the matrix itself ended up zooming twice over (I assume the matrix does use the ruler scale as well, and then just transforms that with the matrix transform afterwards). Which suggests two suitably nasty answers: have yet another scaling factor in the ruler itself that the matrix can set; or have a separate ruler scale for the rulers from the one used by the matrix. I see what you mean about the chord name ruler being broken. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-28 18:00:46
|
On Wednesday 28 March 2007 11:56, Chris Cannam wrote: > On Wednesday 28 Mar 2007 10:13, Guillaume Laurent wrote: > > Upon further investigations, it's not that something is broken, it's that > > the code just isn't there : the ruler scale which the tempo ruler in the > > matrix view uses is the matrix horiz. layout, but there is no way to tell > > this layout that zoom has occurred (the zooming in the matrix view is > > done by changing the canvas' transform matrix). > > Oh, of course -- that f*#*ing matrix. It's probably unwise to change the > ruler scale anyway, because presumably that would mean the matrix itself > ended up zooming twice over (I assume the matrix does use the ruler scale > as well, and then just transforms that with the matrix transform > afterwards). Yes, but we easily could disable the canvas transform of the matrix. That would also have the advantage that zooming would be done more centrally, rather than through a transform there and a QPainter scaling here. > Which suggests two suitably nasty answers: have yet another scaling factor > in the ruler itself that the matrix can set; or have a separate ruler scale > for the rulers from the one used by the matrix. The TempoRuler scales fine in the main view because it uses a SimpleRuler which knows how to scale, while the MatrixHLayout doesn't. IMHO it would make sense to change that. > I see what you mean about the chord name ruler being broken. Yup, seems completely dead to me. I tried adding a nice A7 chord following by a C7, it still wouldn't display anything. -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-28 18:54:57
|
On Wednesday 28 Mar 2007 19:01, Guillaume Laurent wrote: > Yes, but we easily could disable the canvas transform of the matrix. > That would also have the advantage that zooming would be done more > centrally, rather than through a transform there and a QPainter > scaling here. Aargh! Surely you haven't also forgotten why _you_ changed the matrix from using a scaling HLayout to using a matrix transform in the first place? I know it was over four years ago, but... Chris |
From: Guillaume L. <gla...@te...> - 2007-03-28 19:01:41
|
On Wednesday 28 March 2007 19:58, Chris Cannam wrote: > On Wednesday 28 Mar 2007 19:01, Guillaume Laurent wrote: > > Yes, but we easily could disable the canvas transform of the matrix. > > That would also have the advantage that zooming would be done more > > centrally, rather than through a transform there and a QPainter > > scaling here. > > Aargh! > > Surely you haven't also forgotten why _you_ changed the matrix from > using a scaling HLayout to using a matrix transform in the first place? Well, I have. > I know it was over four years ago, but... That's as good an excuse as any, no ? -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-28 19:14:39
|
On Wednesday 28 Mar 2007 20:02, Guillaume Laurent wrote: > On Wednesday 28 March 2007 19:58, Chris Cannam wrote: > > Surely you haven't also forgotten why _you_ changed the matrix from > > using a scaling HLayout to using a matrix transform in the first > > place? > > Well, I have. It was so that the objects on the matrix don't have to be recreated every time the zoom level changes. Initially we had a whole load of flicker when you moved the zoom slider, and it was bad enough to be worth a couple of months of fiddling about to fix it. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-28 19:49:12
|
On Wednesday 28 March 2007 21:18, Chris Cannam wrote: > On Wednesday 28 Mar 2007 20:02, Guillaume Laurent wrote: > > On Wednesday 28 March 2007 19:58, Chris Cannam wrote: > > > Surely you haven't also forgotten why _you_ changed the matrix from > > > using a scaling HLayout to using a matrix transform in the first > > > place? > > > > Well, I have. > > It was so that the objects on the matrix don't have to be recreated > every time the zoom level changes. Initially we had a whole load of > flicker when you moved the zoom slider, and it was bad enough to be > worth a couple of months of fiddling about to fix it. Ah, yes, well, making MatrixHLayout horizontal zoomable looks pretty bad here as well, so I guess I'll go for the TempoRuler-specific solution. -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-28 19:52:50
|
On Wednesday 28 Mar 2007 20:50, Guillaume Laurent wrote: > Ah, yes, well, making MatrixHLayout horizontal zoomable looks pretty > bad here as well, so I guess I'll go for the TempoRuler-specific > solution. I think maintaining a separate SimpleRulerScale in the matrix view that is only used for reference by the rulers is probably the nicer of the two approaches (the ones that I mentioned anyway). That way the ruler itself wouldn't have to change, a single fix would work for any and all rulers, and the hack would be localised to MatrixView which is where the other zoom hacks are already. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-28 22:42:44
|
On Wednesday 28 March 2007 21:56, Chris Cannam wrote: > On Wednesday 28 Mar 2007 20:50, Guillaume Laurent wrote: > > Ah, yes, well, making MatrixHLayout horizontal zoomable looks pretty > > bad here as well, so I guess I'll go for the TempoRuler-specific > > solution. > > I think maintaining a separate SimpleRulerScale in the matrix view that > is only used for reference by the rulers is probably the nicer of the > two approaches (the ones that I mentioned anyway). That way the ruler > itself wouldn't have to change, a single fix would work for any and all > rulers, and the hack would be localised to MatrixView which is where > the other zoom hacks are already. I got the principle ok, but I don't know what to feed to SimpleRulerScale::setUnitsPerPixel(). Giving it the value of the zoom slider as is done in the main view produces a hugely wide ruler. -- Guillaume. http://telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2007-03-28 23:00:00
|
On Thursday 29 March 2007 00:43, Guillaume Laurent wrote: > Giving it the value of the zoom slider > as is done in the main view produces a hugely wide ruler. Oh right, the value the zoom slider returns are settable. Well, I'll see about that tomorrow. -- Guillaume. http://telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2007-03-29 12:54:46
|
On Thursday 29 March 2007 01:01, Guillaume Laurent wrote: > On Thursday 29 March 2007 00:43, Guillaume Laurent wrote: > > Giving it the value of the zoom slider > > as is done in the main view produces a hugely wide ruler. > > Oh right, the value the zoom slider returns are settable. Well, I'll see > about that tomorrow. I'm stumped. AFAICT, the MatrixHLayout and the SimpleRulerScale have completely different implementations for getXForTime() (the MatrixHLayout is actually a RulerScale here), so fiddling with the values returned by the zoom slider won't help. I don't see how to make this work. -- Guillaume. http://telegraph-road.org |
From: Chris C. <ca...@al...> - 2007-03-29 19:40:26
|
On Thursday 29 Mar 2007 13:55, Guillaume Laurent wrote: > I'm stumped. AFAICT, the MatrixHLayout and the SimpleRulerScale have > completely different implementations for getXForTime() Right, the HLayout version inherits the default implementation in RulerScale, which assumes a subclass that knows where the barlines are but nothing else, and then interpolates linearly. (If you look at the notation view, you can see that the rulers are linear between the barlines even though the score is not, and that's the intentional result of doing the ruler scale this way.) SimpleRulerScale overrides that logic with a fixed-ratio scale throughout. So the idea is to introduce a new SimpleRulerScale and operate it quite independently of the hlayout. I've committed something of the sort. Chris |
From: Guillaume L. <gla...@te...> - 2007-03-29 21:43:03
|
On Thursday 29 March 2007 20:44, Chris Cannam wrote: > > So the idea is to introduce a new SimpleRulerScale and operate it quite > independently of the hlayout. I've committed something of the sort. Damn, I just had found what I think is a simpler fix, but had to leave taking pics of a friend's rock band. Anyway, my fix is to use the following as the RulerScale for the tempo and chord ruler : class ZoomableMatrixHLayoutRulerScale : public RulerScale, public HZoomable { public: ZoomableMatrixHLayoutRulerScale(MatrixHLayout& layout) : RulerScale(layout.getComposition()), m_referenceHLayout(layout) {}; virtual double getBarPosition(int n) const { return m_referenceHLayout.getBarPosition(n) * getHScaleFactor(); } virtual double getXForTime(timeT time) const { return m_referenceHLayout.getXForTime(time) * getHScaleFactor(); } virtual timeT getTimeForX(double x) const { return m_referenceHLayout.getTimeForX(x / getHScaleFactor()); } virtual double getBarWidth(int n) const { return m_referenceHLayout.getBarWidth(n) * getHScaleFactor(); } virtual int getLastVisibleBar() const { return m_referenceHLayout.getLastVisibleBar(); } protected: MatrixHLayout& m_referenceHLayout; }; Seems to work here. What do you think ? -- Guillaume. http://telegraph-road.org |