From: Heinz W. <HMW...@li...> - 2009-12-26 13:02:16
|
On Friday 25 December 2009 06:35:43 D. Michael McIntyre wrote: > ====== ROSEGARDEN 10.02, codename "Thorn" BETA RELEASED ====== > > The Rosegarden team is proud to announce the BETA release of version 10.02 > of Rosegarden, an audio and MIDI sequencer and musical notation editor for > Linux. The beta period will run from now to the end of January, 2010, and > the final release of "Thorn" will occur on 14th February, 2010, marking > five years to the day since the release of 1.0 (which would be be called > 05.02 using our current numbering scheme). Very nice! I had a go at building the beta on Slackware and it was no problem at all. Thumbs up! :) I have a few bugs though. It seems that the editing area of the notation view is limited to a fixed size. Everything below a certain point is black. (screenshot here: http://www.liwjatan.at/files/screenshots/rosegarden-notation-view.png) Also there's a rendering issue when I maximize the main window after a fresh start. It works fine if I drag the lower edge of the window manually, but if I click on the maximize icon in the window decoration it leaves garbage. (screenshot here: http://www.liwjatan.at/files/screenshots/rosegarden-main- window.png) Last is a package issue. "make install" runs update-mime-database at the end. For packaging rosegarden I would need to patch the Makefile to remove that command, because update-mime-database should be called on installation of the package, and not at the end of "make install". I can't really think of a better solution than patching right now, but maybe someone else has a good idea on how we can avoid that. Here's my facts: Slackware64 13.0, gcc 4.3.3, glibc 2.10, qt-4.5.2. Tested in kde 4.3.1 I can also open reports in the bugtracker if it's better located there. Lastly, out of curiosity, I recognized the cmake build system is gone. Will it come back at some point or will you stay with autotools? Grs, Heinz (I sent this mail once before with the screenshots attached. It currently awaits moderator approval. Just disregard that mail.) |
From: D. M. M. <mic...@ro...> - 2009-12-26 15:57:49
|
On Saturday 26 December 2009, Heinz Wiesinger wrote: > Very nice! > I had a go at building the beta on Slackware and it was no problem at all. > Thumbs up! :) Good stuff! > It seems that the editing area of the notation view is limited to a fixed > size. Everything below a certain point is black. (screenshot here: > http://www.liwjatan.at/files/screenshots/rosegarden-notation-view.png) I forgot about trying to do something with that one. It doesn't react to resizing in the vertical axis well, or at all. Thanks for the reminder. > Also there's a rendering issue when I maximize the main window after a > fresh start. It works fine if I drag the lower edge of the window > manually, but if I click on the maximize icon in the window decoration it > leaves garbage. (screenshot here: > http://www.liwjatan.at/files/screenshots/rosegarden-main- window.png) That one I can't repeat, and your setup is quite similar to mine apart from the gcc version. That doesn't give me anything I could compile and test against, so I don't have much hope of sorting that out. I'm left having to hope that you can get around that problem using the native graphics system. Try: ./rosegarden -graphicssystem native If that works, I'm going to have to revisit the idea of making the graphics system configurable through the preferences interface. That particular detail can't be stored in QSettings, so I'll have to come up with some workaround. > Last is a package issue. "make install" runs update-mime-database at the > end. For packaging rosegarden I would need to patch the Makefile to remove > that command, because update-mime-database should be called on > installation of the package, and not at the end of "make install". I can't > really think of a better solution than patching right now, but maybe > someone else has a good idea on how we can avoid that. Is running update-mime-database out of an install target abnormal and wrong for every distro? I don't think I'd ever written an install target from scratch, and it's entirely possible that was just a stupid thing to do. I don't remember if our old build system used to do that at some point or not. I'll be happy to honor whatever the best standard practice is. I'm not trying to make life hard for maintainers. > I can also open reports in the bugtracker if it's better located there. It isn't necessary to open bugs on the tracker, but I think we're at a point where it's OK to go ahead and start using it again, and I removed the "don't use the tracker yet" instructions from the latest round of texts I published. At this point the main thing I care about is reporting the bugs *somewhere* I can see them, and this was just fine. Thank you for the reports! > Lastly, out of curiosity, I recognized the cmake build system is gone. Will > it come back at some point or will you stay with autotools? We were all building with some static hand-written makefile for months in preference to anybody trying to get CMake working again. It fell on my shoulders to get it to go, and I was just not able to do so. Chris had an alternate plan for doing up a simple Autotools based build system, and we went with that and got it to work. I'm not strongly opposed to going back to CMake, but I am strongly opposed to having a build system that's dependent on one single individual to maintain. People lose interest and move away sometimes. If Chris or I lose interest and move away, the project is most likely dead, so if we have a build system both Chris and I can maintain ourselves, that's as close as we can come to guaranteeing somebody will always be around who knows how to maintain it. So I think we're probably sticking with Autotools, with some sad regret about having to dump such a nice thing as we had, and some relief about maintainability over time mixed in as well. After all, we're here to write software first, not build systems. If the thing compiles, it gets the job done. -- D. Michael McIntyre |
From: Dave P. <dp...@we...> - 2009-12-27 10:05:05
|
On 12/26/2009 05:57 PM, D. Michael McIntyre wrote: > On Saturday 26 December 2009, Heinz Wiesinger wrote: > > > >> Last is a package issue. "make install" runs update-mime-database at the >> end. For packaging rosegarden I would need to patch the Makefile to remove >> that command, because update-mime-database should be called on >> installation of the package, and not at the end of "make install". I can't >> really think of a better solution than patching right now, but maybe >> someone else has a good idea on how we can avoid that. >> > Is running update-mime-database out of an install target abnormal and wrong > for every distro? I don't think I'd ever written an install target from > scratch, and it's entirely possible that was just a stupid thing to do. I > don't remember if our old build system used to do that at some point or not. > > I'll be happy to honor whatever the best standard practice is. I'm not trying > to make life hard for maintainers. > > > I've patched out the "update-mime-database" in Makefile.in but if it's normal practice for it to run on make install and make uninstall when somebody installs from source then I'm fine with that. For rpm packaging it should be run in the %post and %postun sections and openSUSE build service doesn't like it to be run in the %install section. Regards Dave P |
From: Heinz W. <HMW...@li...> - 2009-12-26 16:44:46
|
On Saturday 26 December 2009 16:57:33 D. Michael McIntyre wrote: > On Saturday 26 December 2009, Heinz Wiesinger wrote: > > Also there's a rendering issue when I maximize the main window after a > > fresh start. It works fine if I drag the lower edge of the window > > manually, but if I click on the maximize icon in the window decoration > > it leaves garbage. (screenshot here: > > http://www.liwjatan.at/files/screenshots/rosegarden-main- window.png) > > That one I can't repeat, and your setup is quite similar to mine apart from > the gcc version. That doesn't give me anything I could compile and test > against, so I don't have much hope of sorting that out. > > I'm left having to hope that you can get around that problem using the > native graphics system. Try: > > ./rosegarden -graphicssystem native > > If that works, I'm going to have to revisit the idea of making the graphics > system configurable through the preferences interface. That particular > detail can't be stored in QSettings, so I'll have to come up with some > workaround. Indeed that works, as does -graphicssystem opengl. -graphicssystem raster fails as well (which is probably the standard anyway) > > Last is a package issue. "make install" runs update-mime-database at the > > end. For packaging rosegarden I would need to patch the Makefile to > > remove that command, because update-mime-database should be called on > > installation of the package, and not at the end of "make install". I > > can't really think of a better solution than patching right now, but > > maybe someone else has a good idea on how we can avoid that. > > Is running update-mime-database out of an install target abnormal and wrong > for every distro? I don't think I'd ever written an install target from > scratch, and it's entirely possible that was just a stupid thing to do. I > don't remember if our old build system used to do that at some point or > not. > > I'll be happy to honor whatever the best standard practice is. I'm not > trying to make life hard for maintainers. I know two other apps that do this. One is ardour, which did this to actually make the life of packagers easier (*cough*). I filed a bug for that aeons ago, still open. The other is google-gadgets, but they offer the possibility to turn it off with "--disable-update-mime-database" as a configure parameter. Maybe that would be a good option. Either way, if you run update-mime-database running update-desktop-database might be a good idea as well. > > I can also open reports in the bugtracker if it's better located there. > > It isn't necessary to open bugs on the tracker, but I think we're at a > point where it's OK to go ahead and start using it again, and I removed > the "don't use the tracker yet" instructions from the latest round of > texts I published. At this point the main thing I care about is reporting > the bugs *somewhere* I can see them, and this was just fine. Thank you > for the reports! No problem :) > > Lastly, out of curiosity, I recognized the cmake build system is gone. > > Will it come back at some point or will you stay with autotools? > > We were all building with some static hand-written makefile for months in > preference to anybody trying to get CMake working again. It fell on my > shoulders to get it to go, and I was just not able to do so. Chris had an > alternate plan for doing up a simple Autotools based build system, and we > went with that and got it to work. > > I'm not strongly opposed to going back to CMake, but I am strongly opposed > to having a build system that's dependent on one single individual to > maintain. People lose interest and move away sometimes. If Chris or I > lose interest and move away, the project is most likely dead, so if we > have a build system both Chris and I can maintain ourselves, that's as > close as we can come to guaranteeing somebody will always be around who > knows how to maintain it. > > So I think we're probably sticking with Autotools, with some sad regret > about having to dump such a nice thing as we had, and some relief about > maintainability over time mixed in as well. After all, we're here to write > software first, not build systems. If the thing compiles, it gets the job > done. Heh, this is actually the first time I heard someone saying autotools is easier than cmake ;) As said, I was just curious. As long as it works for you it's fine for me as well. The only build system I hold a grudge against is waf. I really don't understand why ardour and jack are moving that way.... Thanks for the comments! Grs, Heinz |
From: D. M. M. <mic...@ro...> - 2009-12-27 04:34:42
|
On Saturday 26 December 2009, Heinz Wiesinger wrote: > Indeed that works, as does -graphicssystem opengl. -graphicssystem raster > fails as well (which is probably the standard anyway) Right, we default to raster. The opengl doesn't work for me here. It's fast, but there are hundreds of horrible artifacts everywhere, and it's not usable at all. This one is getting harder to call. We're trying to default to the raster graphics system due to it being several times faster than the native, but there have been a lot of problems for remote users that are almost impossible to diagnose and correct from here. I really don't know where to start on the phenomenon you're experiencing. Another guy had Rosegarden crashing in Qt drawing code in a Qt stock dialog with the raster graphics system. I think I'd rather advise people to change a configuration option than advise them to add command line parameters to however they run Rosegarden, so I think that settles this matter, and I've just got to suck it up and work out some way to make this configurable from inside Rosegarden. > I know two other apps that do this. One is ardour > The other is google-gadgets Sounds to me like the most standard thing to do would be to just yank all of that out and leave it to maintainers to deal with. OK, I did that, and I dug up my patch for the graphics system changer and ironed it out and committed that as well. -- D. Michael McIntyre |