From: Julie S <msj...@ya...> - 2009-08-30 18:57:45
|
Dear Heikki, from your last commit: > Log Message: > ----------- > Function size() returns size_t when std::vector is used. > > I am thinking what would happe in std::vector would be > replaced with QVector, > and std::string with QString? Their size() function return > int, and then > there would be less to think about unsigned int vs. signed > conversions. Everytime, I talk of moving a Qt class to base, it spurs a discussion about the long standing tradition of keeping base toolkit free. That is why we have some classes that act as liaisons in the misc/ directory. They handle the dirty work of talking to base in its language. Without Chris around to weigh in on it, I suggest we hold off. I don't think he is outright opposed to it. Maybe if enough of these instances appear, then there could be a strong case made to push QString, and QVector, etc to base. Historically, these talks end in leaving base alone. Not to shut the discussion down, but just to say, we've been there before and this is what happened. I'm not taking sides just asking the decision to wait until Chris resurfaces. Sincerely, Julie S. PS -- Great work cleaning up trunk/ ! Thank you. --- On Sun, 8/30/09, hj...@us... <hj...@us...> wrote: > From: hj...@us... <hj...@us...> > Subject: [Rosegarden-bugs] SF.net SVN: rosegarden:[10791] trunk/rosegarden/src/base/Studio.cpp > To: ros...@li... > Date: Sunday, August 30, 2009, 2:47 PM > Revision: 10791 > http://rosegarden.svn.sourceforge.net/rosegarden/?rev=10791&view=rev > Author: hjunes > Date: 2009-08-30 18:47:17 +0000 > (Sun, 30 Aug 2009) > > Log Message: > ----------- > Function size() returns size_t when std::vector is used. > > I am thinking what would happe in std::vector would be > replaced with QVector, > and std::string with QString? Their size() function return > int, and then > there would be less to think about unsigned int vs. signed > conversions. > > Modified Paths: > -------------- > trunk/rosegarden/src/base/Studio.cpp > > Modified: trunk/rosegarden/src/base/Studio.cpp > =================================================================== > --- trunk/rosegarden/src/base/Studio.cpp > 2009-08-30 18:31:29 UTC (rev 10790) > +++ trunk/rosegarden/src/base/Studio.cpp > 2009-08-30 18:47:17 UTC (rev 10791) > @@ -157,7 +157,7 @@ > ids.insert((*it)->getId()); > if ((*it)->getType() == > Device::Midi) { > InstrumentList il = > (*it)->getAllInstruments(); > - for (int i = 0; i < > il.size(); ++i) { > + for (size_t i = 0; i < > il.size(); ++i) { > if > (il[i]->getId() > highestMidiInstrumentId) { > > highestMidiInstrumentId = il[i]->getId(); > > foundInstrument = true; > > > This was sent by the SourceForge.net collaborative > development platform, the world's largest Open Source > development site. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rosegarden-bugs mailing list > Ros...@li... > - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-bugs > |
From: Heikki J. J. <hj...@gm...> - 2009-08-30 19:29:29
|
2009/8/30 Julie S <msj...@ya...> > Dear Heikki, > > from your last commit: > > Log Message: > > ----------- > > Function size() returns size_t when std::vector is used. > > > > I am thinking what would happe in std::vector would be > > replaced with QVector, > > and std::string with QString? Their size() function return > > int, and then > > there would be less to think about unsigned int vs. signed > > conversions. > > Everytime, I talk of moving a Qt class to base, it spurs a discussion about > the long standing tradition of keeping base toolkit free. That is why we > have some classes that act as liaisons in the misc/ directory. They handle > the dirty work of talking to base in its language. > There are currently three lisences for Qt 4.5: Commercial, GNU LGPL v. 2.1 and, GNU GPL v. 3.0 http://qt.nokia.com/products/licensing > Without Chris around to weigh in on it, I suggest we hold off. I don't > think he is outright opposed to it. Maybe if enough of these instances > appear, then there could be a strong case made to push QString, and QVector, > etc to base. > I was thinking this purely for technical reasons. Chris expressed his preference to use purely int types and I was trying to figure out what that would mean in coding. > > Historically, these talks end in leaving base alone. > > Not to shut the discussion down, but just to say, we've been there before > and this is what happened. > The licensing of Qt has been changing with time, therefore the "free" argument could be reconsidered now that GPL lisencing is available. > > I'm not taking sides just asking the decision to wait until Chris > resurfaces. Chris is the person who makes the technical decision. I am the person who generates sparkles, but Chris is the person who has the fuel and who desides when to light the fire. -- Heikki |
From: Julie S <msj...@ya...> - 2009-08-30 19:34:57
|
Dear Heikki, Sounds like you've given it some thought. Chris should be back soon enough. Chris can speak for himself on this issue. I just wanted to allow him the courtesy. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-08-31 03:37:50
|
On Sunday 30 August 2009, Heikki Johannes Junes wrote: > > They handle the dirty work of talking to base in its language. > > There are currently three lisences for Qt 4.5: Right, licensing was never the issue here. Rosegarden had already been through two rewrites before the current version was born, and when they designed this Rosegarden, they wanted to set the core data structures and other underpinnings of the application apart from the toolkit, so as to make it easier to change toolkits again in the future, and build a different GUI on top of the same foundation. That's the historical reason why Qt was never allowed in base/. In practice, over the years, most of what Rosegarden has become isn't in base/ anyway, and we're married to Qt. I think we decided it would be OK to use QString in base/ when that was the most reasonable way to solve a problem, but we should continue to avoid it in general. I'm not sure why. It may be due to nothing more than the scale of the problem changing around all the existing code that is already written to work this way. Between qstrtostr() and strtoqstr() we have around 700 of these to sort out (not counting alternative methods like using QString.toLocal8Bit() and maybe half a dozen other QString.toSomething() methods). Then there are probably hundreds (about 1300, actually) of QStrings outside of base/ that exist to communicate with base/ and would need to be changed out. And then in the middle of this there are some number of std::strings that must remain such for technical reasons. Maybe these want to stay std::strings, or maybe they want to be QStrings that get converted appropriately for whatever technical use requires them. All in all it's about 2,000 lines to sort out to accomplish a string changeover, and that's not considering any surrounding code that might need to be rewritten as well. I think it's very reasonable to say we should talk about all of this again after getting the release out the door. It would be really crazy to try to sort all of this out in time for a release, and we have an alpha coming up soon. -- D. Michael McIntyre |
From: Heikki J. J. <hj...@gm...> - 2009-08-31 05:35:53
|
2009/8/31 D. Michael McIntyre <mic...@ro...> > On Sunday 30 August 2009, Heikki Johannes Junes wrote: > > > They handle the dirty work of talking to base in its language. > > > > There are currently three lisences for Qt 4.5: > > I think it's very reasonable to say we should talk about all of this again > after getting the release out the door. It would be really crazy to try to > sort all of this out in time for a release, and we have an alpha coming up > soon. That was a very valuable comment from the Release Manager! -- Heikki |