That RG crashes with a relatively high frequency indicates that strictness wrt what gets committed is far too lax.
I'm sorry but you have no clue on what you're talking about here. 90% of the crash reports we get are actually due to the sound libs we depend on (generally people using old version of Alsa). Lately we've received only 1 in several months. Please don't just blindly give stereotypical arguments which simply don't apply to our case.
There are only 3 developpers working on RG, these days more like 2 (Rich became a father recently). So while we do occasionnally use branches, having a 1.0/1.1 tree split is just not feasible.
As for SVN, yes, we'd like to use it, but sforge doesn't provide it yet (they announced it was scheduled for 2005).
Regarding outside patches being applied : we get less than a dozen per year, most of which are very simple and can't represent stability issues. We've never had a stability problem due to an external patch.
I actually wish your criticisms were true, it would mean much more activity on RG's code:-).
Actually, the text you're linking to is a bit misleading : no coding was ever actually done using plain GTK+, we never even considered that option. We went for gtk-- right away (or, if you prefer, we went for GTK+ as soon as we learned that C++ bindings were available).
We've discussed portaudio recently. Although we haven't seriously looked at it yet, it seems to be a very good candidate.
However, MacOS/X has Garage Band and Logic, Windows has Cubase, Cakewalk... I'm not sure how much of a "market share" Rosegarden could have on those platforms, where free software is less of an issue.
Er...maybe if they trained up some help, they'd have more time...
Gee, how come we never thought of this before.:-)
Honestly, if it were that simple do you really believe we wouldn't do it ? "Training" people through email just takes too long, and many contributors have just vanished after a couple of patches. We just can't afford to invest this kind of time into some guy whom we have no way to know if he'll stick around. All projects of this scale have the same kind of problem, there's no simple solution to it.
> Charlton Heston's tie changes colour in what is supposedly one speech
Er, yes, but who said it was supposed to be one speech ? When I saw the movie, I certainly didn't think it was, nor did any of the 5 or 6 friends I was with. The change of clothes and setting, not to mention the cut, made it obvious. No one would be stupid enough not to see it.
Seems to me the people blaming him for dishonesty on this part are actually blaming him for completely (or purposely) misunderstanding the movie.
Moore is certainly no saint, he generally will not show what won't fit his ideas, but if he didn't double-checked everything he says he'd been sued to kingdom come long ago.
They're just following the policy they've planned
on
Weapons in Space
·
· Score: 1
...developed a physics-defying substance called fire paste, which he claims eliminates the cross-transfer of heat and prevents anything coated in the substance from burning up.
Not only does the paste stop heat from getting through, it cools to the touch within 20 seconds of the fire source being removed.
When dry, the paste is non-toxic four times lighter than aluminum, more heat resistant than titanium, and costs only pennies to make
I can change the fact that you are required to pay money to distribute a proprietary application
Software companies generally don't mind paying licenses to distribute their products. That's regular business, and the licenses represent a fraction of the total cost of software development. And Qt is royalty-free, the license is for development only.
BTW, I work for a proprietary software editor, and over here the LGPL is considered highly suspect (GPL is out of the question of course). Between an LGPL lib and a proprietary licensed one, the choice will always be the latter.
Having a set of development libraries that are all cleared for producing and distributing proprietary applications would be least surprising.
Come on. There's much more to this than just licenses issues. Try developping with both platforms before making up your mind.
You can't have a full replacement of Qt's signals with a template-based framework : you lose introspection and "loose coupling" between emitter and receiver. Qt's containers are now STL compliant, so it doesn't make much of a difference if you use them or not (I generally don't).
But the main thing is that dependencies in development are not a pure benefit, they also drag their own problems. So until Qt integrates Boost (won't happen) or Boost is standard and widely spread, it doesn't really help. And by the time Boost is standard, I hope we have a better language than C++ for desktop app. development.
> Boost is portable to most of the C++ compilers that matter.
Yes, but this is not the issue. Think adding dependencies, API integration, this kind of stuff. Things you won't realize are crucial until you experience them directly.
I've had this debate dozens of time, it alwasy boils down to this : the person offering alternatives to Qt is just doing feature list matching, but has never actually tried using his solutions on a non-trivial project.
And no, I don't "believe in Qt". I'd take Cocoa over it any time if it were available on Linux. I even hope that Mono will be a viable option someday. But for the time being, it's by far the best existing option to develop desktop apps on Linux. Feel free to try to prove otherwise : take your own "better option", and port a Qt app to it. See how long it takes, how much less code you have to write, etc... or make your own app with it. Until someone does so, there's no point in arguing.
Incidently, Guillimue (I'm sure I mispelled his name) Laurent, one of the GTKmm designers, got fed up with how difficult it was to cleanly do a GNOME C++ API (unlike GTK), and ended up moving to Qt.
You indeed mispelled my name:-). You also totally misunderstood the reasons why I left gtkmm. They are explained here, and they have nothing to do with the difficulty of wrapping Gnome as opposed to GTK. Ask Murray Cumming if wrapping GTK+ is easy:-).
That said, I'm indeed extremely happy to have moved to KDE/Qt, even if that wasn't the reason why I left. Sooner or later, it would have been anyway.
I haven't looked at Rosegarden recently -- last I looked, it was based on Tk or something, and there was talk of using Qt but no code.
Er, when was the last time you looked, 3 years ago ? And the previous version was based on Athena. It did (optionally) linked with Tcl, but never used Tk.
Yes master, sorry master. Please explain again then. And, master, about those pointers to your valuable contributions to Gnome, so I can see how lousy a coder I am ? Please ?
Slashdot Mirror
That RG crashes with a relatively high frequency indicates that strictness wrt what gets committed is far too lax.
I'm sorry but you have no clue on what you're talking about here. 90% of the crash reports we get are actually due to the sound libs we depend on (generally people using old version of Alsa). Lately we've received only 1 in several months. Please don't just blindly give stereotypical arguments which simply don't apply to our case.
There are only 3 developpers working on RG, these days more like 2 (Rich became a father recently). So while we do occasionnally use branches, having a 1.0/1.1 tree split is just not feasible.
:-).
As for SVN, yes, we'd like to use it, but sforge doesn't provide it yet (they announced it was scheduled for 2005).
Regarding outside patches being applied : we get less than a dozen per year, most of which are very simple and can't represent stability issues. We've never had a stability problem due to an external patch.
I actually wish your criticisms were true, it would mean much more activity on RG's code
Actually, the text you're linking to is a bit misleading : no coding was ever actually done using plain GTK+, we never even considered that option. We went for gtk-- right away (or, if you prefer, we went for GTK+ as soon as we learned that C++ bindings were available).
We've discussed portaudio recently. Although we haven't seriously looked at it yet, it seems to be a very good candidate.
However, MacOS/X has Garage Band and Logic, Windows has Cubase, Cakewalk... I'm not sure how much of a "market share" Rosegarden could have on those platforms, where free software is less of an issue.
Er...maybe if they trained up some help, they'd have more time...
:-)
Gee, how come we never thought of this before.
Honestly, if it were that simple do you really believe we wouldn't do it ? "Training" people through email just takes too long, and many contributors have just vanished after a couple of patches. We just can't afford to invest this kind of time into some guy whom we have no way to know if he'll stick around. All projects of this scale have the same kind of problem, there's no simple solution to it.
Even worse, I live just a couple of miles away from the building in which Michael Moore was given his Palme d'Or. Imagine that. :-)
> Charlton Heston's tie changes colour in what is supposedly one speech
Er, yes, but who said it was supposed to be one speech ? When I saw the movie, I certainly didn't think it was, nor did any of the 5 or 6 friends I was with. The change of clothes and setting, not to mention the cut, made it obvious. No one would be stupid enough not to see it.
Seems to me the people blaming him for dishonesty on this part are actually blaming him for completely (or purposely) misunderstanding the movie.
Moore is certainly no saint, he generally will not show what won't fit his ideas, but if he didn't double-checked everything he says he'd been sued to kingdom come long ago.
It's all here : Rebuilding American's Defenses.
Pretty much echoes my feelings when I switched from Gnome/gtkmm to KDE/Qt back in 2000. Nice to see some things never change :-).
ESR has "astounding skills as a programmer". Yeah, that's amusing.
From the article
Not only does the paste stop heat from getting through, it cools to the touch within 20 seconds of the fire source being removed.
When dry, the paste is non-toxic four times lighter than aluminum, more heat resistant than titanium, and costs only pennies to make
I can change the fact that you are required to pay money to distribute a proprietary application
Software companies generally don't mind paying licenses to distribute their products. That's regular business, and the licenses represent a fraction of the total cost of software development. And Qt is royalty-free, the license is for development only.
BTW, I work for a proprietary software editor, and over here the LGPL is considered highly suspect (GPL is out of the question of course). Between an LGPL lib and a proprietary licensed one, the choice will always be the latter.
Having a set of development libraries that are all cleared for producing and distributing proprietary applications would be least surprising.
Come on. There's much more to this than just licenses issues. Try developping with both platforms before making up your mind.
Oh good one, I didn't know it. But you still want -n with X being a not-too-large int, though.
Sheesh : one useless antislash and one inefficient -exec :
find . -name \*.backup | xargs -n50 rm
Here is another rant on how the US should crush the muslim civilisation. Very tasty.
I used to have respect for him but reading his blog made me sick, not to mention the ones he links to.
You can't have a full replacement of Qt's signals with a template-based framework : you lose introspection and "loose coupling" between emitter and receiver. Qt's containers are now STL compliant, so it doesn't make much of a difference if you use them or not (I generally don't).
But the main thing is that dependencies in development are not a pure benefit, they also drag their own problems. So until Qt integrates Boost (won't happen) or Boost is standard and widely spread, it doesn't really help. And by the time Boost is standard, I hope we have a better language than C++ for desktop app. development.
> Boost is portable to most of the C++ compilers that matter.
Yes, but this is not the issue. Think adding dependencies, API integration, this kind of stuff. Things you won't realize are crucial until you experience them directly.
I've had this debate dozens of time, it alwasy boils down to this : the person offering alternatives to Qt is just doing feature list matching, but has never actually tried using his solutions on a non-trivial project.
And no, I don't "believe in Qt". I'd take Cocoa over it any time if it were available on Linux. I even hope that Mono will be a viable option someday. But for the time being, it's by far the best existing option to develop desktop apps on Linux. Feel free to try to prove otherwise : take your own "better option", and port a Qt app to it. See how long it takes, how much less code you have to write, etc... or make your own app with it. Until someone does so, there's no point in arguing.
> There are at least two free C++ signal-slot implementations out there
Please check your facts. moc does more than just signal/slots.
http://doc.trolltech.com/3.0/templates.html
> That's not a reason to pack the whole thing together.
Why not ? What's the point of having half a dozen lib instead of just one ? From a developpers standpoint, one lib is much more convenient.
> Boost. Boost. Can't say I find the API limited.
Have you actually used it on a real project, or are you just saying this looking at the pages on boost.org ?
Anyway, when it will be in all C++ compilers and as well documented as Qt, may be. Until then, Qt is the only practical solution.
Until C++ gets a more full-fledged object model, moc will remain a pretty good idea. In pratice it's simply just not a problem.
Or any of all those thing that have *zilch* to do with a GUI.
But plenty to do with developing a typical desktop application.
What's wrong with std::string?
No unicode support, no regexp support, fairly limited API.
Incidently, Guillimue (I'm sure I mispelled his name) Laurent, one of the GTKmm designers, got fed up with how difficult it was to cleanly do a GNOME C++ API (unlike GTK), and ended up moving to Qt.
:-). You also totally misunderstood the reasons why I left gtkmm. They are explained here, and they have nothing to do with the difficulty of wrapping Gnome as opposed to GTK. Ask Murray Cumming if wrapping GTK+ is easy :-).
You indeed mispelled my name
That said, I'm indeed extremely happy to have moved to KDE/Qt, even if that wasn't the reason why I left. Sooner or later, it would have been anyway.
Some people will tell you that GTK is harder to program for, but in reality that's not the case,
Have you really tried both toolkits extensively yourself, writing a significantly large app with both ?
if C++ is your thing then both Qt and GTKmm are excellent.
Same question.
I haven't looked at Rosegarden recently -- last I looked, it was based on Tk or something, and there was talk of using Qt but no code.
Er, when was the last time you looked, 3 years ago ? And the previous version was based on Athena. It did (optionally) linked with Tcl, but never used Tk.
I'll have to look at that.
Please do.
> In the 90's, we programmed in C++, and debugged with >>.
If you debug C++ with '>>', it's no wonder you have problems. Try '<<' next time. Works a lot better when applied to std::cout.
Yes. Could I have some examples of your code too ?
Yes master, sorry master. Please explain again then. And, master, about those pointers to your valuable contributions to Gnome, so I can see how lousy a coder I am ? Please ?