From: Julie S <msj...@ya...> - 2009-07-22 11:34:03
|
DEar Michael, In the commit of 10543 I found: > NewNotationView::~NewNotationView() > { > + //!!! Odd that the window geometry save bit > didn't work in here. The little > + // message printed to std::cerr didn't fire, > so unless I'm just really > + // obtuse and illiterate about something, I > don't think this dtor ever fires > + // and we probably have a memory leak. I was under the impression that the destructor was only called when we closed RG. I thought we just hid the window when people pressed the close button. I didn't scour the code looking at the implementation, so maybe some who know the code better can correct me. But assuming I'm correct, then the std::cerr message if placed in the destructor for this window would have fired near the exit of RG not on closing the notation view window. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-08-15 20:47:03
|
On Saturday 15 August 2009, ygu...@us... wrote: > - Fix most of the staff headers width problems. > - Use segment color as header background. Oh, splendid! You even dealt with the problem of what to do with light and dark segment colors. In fact, that's a really clean, high quality solution to that problem. Nice work! Nice work from Jani, Heikki and Thorsten today too. It's great to see so many things getting done! -- D. Michael McIntyre |
From: Jani F. <j.f...@gm...> - 2009-08-15 20:50:26
|
2009/8/15 D. Michael McIntyre <mic...@ro...> > > Nice work from Jani, Heikki and Thorsten today too. It's great to see so > many > things getting done! We seem to have a competition going on :) -Jani |
From: D. M. M. <mic...@ro...> - 2009-09-13 19:36:17
|
On Sunday 13 September 2009, ja...@us... wrote: > Quick hack to port step recording in notation. Works! Only a quick rudimentary test though. Thanks. -- D. Michael McIntyre |
From: Yves G. <yc....@wa...> - 2009-11-14 22:58:50
|
Le samedi 14 novembre 2009 22:31:03, dmm...@us... a écrit : > Revision: 11262 > > http://rosegarden.svn.sourceforge.net/rosegarden/?rev=11262&view=rev > Author: dmmcintyr > Date: 2009-11-14 21:31:03 +0000 (Sat, 14 Nov 2009) > > Log Message: > ----------- > A real solution, or merely a bandaid? I leave it up to someone else to > untangle the web of interconnections and make that determination. In the > meantime, we trap a race condition and avoid crashing when trying to edit > notation in a smaller than default window. > Another working solution is to never call ensureVisible() (from Panned::ensureVisiblePointerInView()) on a rectangle taller than the view (ie to reduce the height of that rectangle when necessary). When the rectangle doesn't fit inside the view, a mouseMoveEvent() is trigged inside the scene, setCurrentStaff() is called, currentStaffChanged signal is emited etc... and we get a vertical oscillation of the view position. Nevertheless, I'm not sure my solution is better than yours as I don't totally understand the whole processing chain so I will not commit it. Yves |
From: Chris C. <ca...@al...> - 2009-11-14 23:04:50
|
On Sat, Nov 14, 2009 at 10:57 PM, Yves Guillemot <yc....@wa...> wrote: > Another working solution is to never call ensureVisible() (from > Panned::ensureVisiblePointerInView()) on a rectangle taller than the view > (ie to reduce the height of that rectangle when necessary). > > When the rectangle doesn't fit inside the view, a mouseMoveEvent() is trigged > inside the scene, setCurrentStaff() is called, currentStaffChanged signal is > emited etc... and we get a vertical oscillation of the view position. > > Nevertheless, I'm not sure my solution is better than yours as I don't totally > understand the whole processing chain so I will not commit it. I don't totally understand the whole processing chain either (oops) but that sounds like a very plausible reading of it so far. Chris |
From: D. M. M. <mic...@ro...> - 2009-11-16 06:19:22
|
On Saturday 14 November 2009, ygu...@us... wrote: > - Draw again a colored rectangle around the header to show the current > staff. - Add a separation line between headers. We used to have a rectangle around the header to show the current staff? This seems new to me. Anyway, it's a very good idea, and it's currently a lot more reliable an indicator of what the current staff is than the edit/playback cursor. I like this! I wonder if you mean for it to be a three-quarters box like ================ | | | | | | | | ================= I'm having trouble deciding if I like that. On the one hand, it seems to make a kind of sense being open to the right, because all of that stuff off to the right is now the area of focus. On the other, we have so many random +1 and -1 drawing problems that the whole thing also looks like it could simply be a drawing mistake. I am less sure about the little yellow lines separating these segments. Although I just now tried adding some color to the segments and I seem to like the effect better when there are different colors. It seems consistent enough, and will probably work. Incidentally (not at all related to your work) I notice changing the color of a segment by rolling through the color combo box with my mouse wheel seems to be a really expensive operation that bogs down the entire user interface for orders of magnitude longer than I would expect for such a simple operation. Something feels wrong there. -- D. Michael McIntyre |
From: Yves G. <yc....@wa...> - 2009-11-16 21:30:13
|
Le lundi 16 novembre 2009 07:15:23, D. Michael McIntyre a écrit : > We used to have a rectangle around the header to show the current staff? We had it in 1.7.3 already. > I wonder if you mean for it to be a three-quarters box like > No I don't. This is a bug I still don't understand but that I have to fix. The rectangle is fully visible at very hight zoom levels. > > I am less sure about the little yellow lines separating these segments. > Although I just now tried adding some color to the segments and I seem to > like the effect better when there are different colors. It seems > consistent enough, and will probably work. The line should be of the segment color and not always yellow. > > Incidentally (not at all related to your work) I notice changing the color > of a segment by rolling through the color combo box with my mouse wheel > seems to be a really expensive operation that bogs down the entire user > interface for orders of magnitude longer than I would expect for such a > simple operation. Something feels wrong there. The response time from the wheel move to the new color being visible is roughly half a second here (on a rather fast machine). Probably it's long for such an operation, but it seems usable still as time is needed to look at the colors. Yves |
From: D. M. M. <mic...@ro...> - 2009-07-23 00:56:26
|
On Wednesday 22 July 2009, Julie S wrote: > I was under the impression that the destructor was only called when we > closed RG. I thought we just hid the window when people pressed the close > button. I don't know if that's true or not, but if so, it seems like it could get expensive keeping all those defunct NewNotationView objects in memory. Hundreds of them, potentially. The RosegardenMainWindow dtor doesn't fire either, even when I put a std::cerr in there to bypass any problems with RG_DEBUG. If that's also true, that's probably a gigantic glob of memory leaked out. Surely it can't really be true, but it damn sure looks that way. I wonder if we have to call the dtor manually from closeEvent() or something? -- D. Michael McIntyre |