Neither of them "are" GTK. Both can use multiple toolkits to render their widgets. One of these is GTK.
>> 9. Konqueror and KHTML, without WebKit, is hobbled by severe rendering and JavaScript bugs
And this has to do with GTK how?
>> 8. GIMP is GTK+
Great. Haven't used it in years. Most people are far better served with a photo manager that does some light editing than a full image processing app. Especially on a mobile device I really doubt anyone is seriously using the GIMP.
>> 7. The OOo KDE integration, last I checked anyway, was nowhere near as good as the GNOME integration.
Works fine here. Without specifics it's hard to tell what you're talking about.
>> 6. Pidgin is GTK+ and Kopete is still very immature compared to it.
Subjective. I don't see anything mind-blowing about Pidgin when I used it. Amsn does a better job than both of them anyway (only the one network of course).
>> 5. Inkscape is a GTK+/GNOME app.
Scribus is a Qt app. Both of them are niche apps and really don't matter to mobile platforms.
>> 4. Audacity is GTK+
WxWidgets actually, as others have pointed out. And again, niche and not useful on mobile.
It's sold in litres, but in the UK, people still talk about fuel efficiency in terms of miles per gallon. Of course they are not using the US gallon for that comparison.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
Yeah I didn't have any problems with that. Hard to tell what was going on in your case though. I just put assistant.exe into the same directory as the app (program files/blah) and the appropriate qt libs and everything worked. Now I switched to my own custom help viewer written with QtHelp, so I don't have to distribute assistant.exe or individual html files (since it's now compressed)
Dual licensing GPL/Commercial is how they stayed in business. Licensing revenue was their primary income (you can check their financial statements) Having the GPL as the open source license forced commercial companies to pay them if they wanted to develop closed source programs using Qt. With LGPL licensing, that incentive is gone, so licensing revenue will likely drop hugely (I know that I probably won't bother renewing my commercial license after this announcement).
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:
>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.
Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.
>> Never missed this feature
Ah yes,the old "I don't use this feature therefore it's useless".
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
Sorry, my original comment was meant to be somewhat tongue in cheek. Of course you can write great applications with GTKMM. You can write great applications with any combination of language and toolkit. Great applications were written in assembly, even though we can now agree that using it for a new desktop application would be insanity. GTKMM is a decent choice, but it is my firm belief that it is not the best choice. And for me, I have only very limited time to devote to my side business, and Qt enables me to make a viable, successful product with those very limited resources. To me that is critical, to others it is not. Anyway, those projects you point out were written before this announcement. I can fully understand the attraction of using an LGPL/BSD toolkit instead of a GPL one, and how it can outweigh many other factors.
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
Yes I have. I'll tell you why it was so "unproductive" using my current project as an example. It's a small visio-like diagramming tool for a niche application that I sell. It comes in at a scant 7000loc, but does flowchart editing with various shapes, images in vector and raster formats and automatic connectors, manipulates SQL databases, autoupdates from the net, the canvas is zoomable, movable, undoable. Printing, spellchecking, exporting to PDFs and images, etc. All this with 7 delete statements and no memory leaks (since Qt manages most of the memory). All this with two dependencies (Qt and aspell). All this works on 3 platforms, with the only platform specific code related to handling aspell differences. Native look and feel on windows. And I mean really native, not "skin that looks like native". Build steps on each platform are "qmake make"
You just can't do that with GTK (mm or # or what have you). You will end up depending on many different little libraries, each one with a different build system and various levels of quality, documentation, maturity, and cross-platform issues. I do this as a side business, but I also do it for fun, and dealing with those kinds of hassles is not fun.
This one is true. I agree that in certain situations Qt should definitely add some exception support.
>>It is still featured in the wikipedia entry about QT, and therefore still seems to be valid.
Haha. Wikipedia says it so it must be true:)
>> And it seems to have appeared in QT 4.4 (please correct me if I am wrong)
Actually it was first an option in Qt 4.1. Not sure of the exact date, probably early 2006.
>> It basically a marketing page.
So.. what about the rest of the points on that page? Introspection and all that good stuff comes from moc. I sure appreciate it a lot more than that warm fuzzy feeling of being more pure to the C++ language.
Re:It's good news, but is it too late?
on
Qt Becomes LGPL
·
· Score: 1
>> Qt might be a good toolkit, but from the C++ point of view GTKMM is far better.
You're absolutely right. So if you are programming to write high quality programs in the least possible time for real world applications, chose Qt. If you are a language purist who values that more than productivity, chose GTKMM.
Re:Large uptick in Qt usage?
on
Qt Becomes LGPL
·
· Score: 1
Huh? I was using assistant as my help system on windows. No problems with spaces in paths.
And now they have the QtHelp system, which is even better.
>> You can safely assume that anyone who writes that today doesn't know C++.
Since I write C++ for a living, I have to ask, what's wrong with that line? Of course if possible I'd put it on the stack, but sometimes it can't be avoided..
>> So... how exception-safe is Qt these days? Can I safely use the STL or Boost and Qt in the same program?
Of course. We do.
>> I do realise that most Linux distros ship Qt with exception handling turned off, which is wrong on multiple levels, so obviously I'd have to compile it myself.
I don't think this is the case on newer distros. I think before GCC 4.0 exception support imposed a pretty big overhead so people left it out. I've never had a problem with exceptions in Qt-using code on any platform.
No, it is not. It uses its own toolkit, and you can optionally make it use one of several platform-specific frontends to render the widgets. One of those frontends uses GTK and tango icons, one of them uses Qt and crystal icons.. Openoffice does not require or depend on GTK or Qt though.
As commenters in that article also mention, the docs recommend (or at least did for a very long time) the event table approach. Not surprising that people are using it and not aware of an alternative.
What exactly is "the horror" of moc? In normal programming you will never be aware of its existence and it does a lot more than signal/slot connections for you (introspection for example). In many ways Qt brings the benefits of higher level languages like C#/Java to C++.
Signals and slots are also safer/easier than Connect, based on the last comment on that blog: "It should be noted that... you should always remember to disconnect the event handler in the event handler object's destructor, otherwise your application may crash if/when the handler is called after your event handler object is destroyed." That can never happen in Qt. If you delete an object it is automatically disconnected from any signals it may be connected to.
Re:ARGH! Just migrated to CMake + added Wx support
on
Qt Becomes LGPL
·
· Score: 1
Don't feel so bad, I just paid $1100 to renew my Qt commercial license:) That's ok though, it was worth it before, and they deserve the money for the kick ass product.
Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me. Same with lots of macros that needed to be there for certain automated tasks. The documentation isn't as solid as that of Qt, and I found a lot more bugs just playing with it than I ever found in writing serious code with Qt.
When Qt was expensive, wxWidgets was an option (even though I still elected to pay for Qt myself) but now I just can't see any reason why you would want to use it apart from legacy support.
>> Can anyone suggest any realistic situation where the LGPL would be undesirable for a commercial app?
One example and something that I do with Qt+commercial license is static linking to get the exe size down and contained within one executable with zero dependencies. I can't do that with LGPL Qt. Other than that there just isn't much point in getting the commercial license anymore. You'd be better off just buying support when you need it.
>> Still not quite natural-looking light despite improvements and claims that they are.
Bullshit. "Natural looking" is stupid anyway. What you mean is "incandescent looking".
>> Contain mercury.
Small amounts, trapped and recyclable. More mercury is produced from generating the extra power required by incandescents.
>> Still blow out (most I've seen last maybe 1 1/2 or so times the best incandescent bulb).
So lasting at least 50% longer than incandescents is a bad thing? Anyway most last much longer than that.
>> We seem to be abandoning the simple yet true adage of "if it ain't broke don't fix it" lately with a lot of things.
Firstly, it is broke since incandescents use way too much power. Secondly, if you don't want to replace working bulbs, just wait till your incandescents burn out (ie, break) and then replace them with the superior technology.
>> couldn't figure out why CFLs were lasting months rather than years in the bathroom
You bought crappy CFLs. CFL's don't have a problem with on/off as long as you're not running a disco or something. My 5 round CFL bulbs in the bathroom are going strong after 2 years. Same for everyone else in the family.
I agree that CFLs aren't for every possible use, but they are great for almost everything. The only thing they're not great for is decorative lamps (although you can get different shapes of CFLs) and outdoor lamps that aren't always on in cold environments (takes too long to warm up and produce full light).
As other's have mentioned, you must be fantastically unlucky to be getting those failure rates. I haven't had to replace a single one of the 10 bulbs I put in 2 years ago. Maybe your power is unstable? I've heard that CFLs tend to not like uneven power.
Also you mention rising electricity bills, but of course that has nothing to do with CFLs. They use less power, so you're doing something else to make up the difference. Not "probably" as you say, but absolutely certainly.
As for shipping, it's incredibly unlikely that the weight is a factor in comparing traditional bulbs to CFLs. Volume is going to be a limiting factor for both of them. No way would a cargo ship have to load fewer containers of CFLs because of some weight limitation. They ship containers of steel for crist's sake.
I think it's a matter of exposure. You say that most useful Linux progs are written with GTK, but really the only one that I use day to day that is Firefox, and that's not even a GTK app, it just happens to use some GTK widgets.
Once in a blue moon I fire up Inkscape, and that's about it. VLC is now Qt, Skype is Qt, Google Earth is Qt, Konversation for IRC, Okular for document viewing, OO has a version drawn with Qt widgets, k3b for burning discs, plenty of good qt music players, Krita and kolourpaint for image editing (really kolourpaint is enough for 90% of what I do), gwenview for image viewing, etc etc
Spoken like someone who hasn't used Qt (I don't know much about GTK so I can't speak to the subject). Qt is at least as productive and feature rich as Cocoa. And unlike Cocoa, you're not bound to one platform. So if you want to support Windows and MacOSX, Qt lets you do that with one codebase, while your cocoa app will need to be entirely rewritten.
Slashdot Mirror
>> Top 10 Reasons GNOME isn't going anywhere:
You're confusing GTK and GNOME.
>> 10. Firefox and Thunderbird are GTK+
Neither of them "are" GTK. Both can use multiple toolkits to render their widgets. One of these is GTK.
>> 9. Konqueror and KHTML, without WebKit, is hobbled by severe rendering and JavaScript bugs
And this has to do with GTK how?
>> 8. GIMP is GTK+
Great. Haven't used it in years. Most people are far better served with a photo manager that does some light editing than a full image processing app. Especially on a mobile device I really doubt anyone is seriously using the GIMP.
>> 7. The OOo KDE integration, last I checked anyway, was nowhere near as good as the GNOME integration.
Works fine here. Without specifics it's hard to tell what you're talking about.
>> 6. Pidgin is GTK+ and Kopete is still very immature compared to it.
Subjective. I don't see anything mind-blowing about Pidgin when I used it. Amsn does a better job than both of them anyway (only the one network of course).
>> 5. Inkscape is a GTK+/GNOME app.
Scribus is a Qt app. Both of them are niche apps and really don't matter to mobile platforms.
>> 4. Audacity is GTK+
WxWidgets actually, as others have pointed out. And again, niche and not useful on mobile.
>> 2. GNOME is easier to use than KDE
Riight.
>> My car gets 86mpg on the highway.
I call bullshit. What car? What circumstances?
One of the most fuel efficient cars in Europe is the VW Polo diesel, which gets 33/50 USMPG city/highway.
Then there's the VW Lupo 3L special edition, which gets 78MPG. So even with that you would have to do some hypermiling to get to 86.
It's sold in litres, but in the UK, people still talk about fuel efficiency in terms of miles per gallon. Of course they are not using the US gallon for that comparison.
Yeah I didn't have any problems with that. Hard to tell what was going on in your case though. I just put assistant.exe into the same directory as the app (program files/blah) and the appropriate qt libs and everything worked.
Now I switched to my own custom help viewer written with QtHelp, so I don't have to distribute assistant.exe or individual html files (since it's now compressed)
Dual licensing GPL/Commercial is how they stayed in business. Licensing revenue was their primary income (you can check their financial statements) Having the GPL as the open source license forced commercial companies to pay them if they wanted to develop closed source programs using Qt. With LGPL licensing, that incentive is gone, so licensing revenue will likely drop hugely (I know that I probably won't bother renewing my commercial license after this announcement).
>> You are really fun. It is true (at the end of the following page - and - hurray - its from trolltech): http://doc.trolltech.com/4.4/signalsandslots.html [trolltech.com]
Wrong. Just because it's mentioned on that page for the first time in 4.4 doesn't mean it was added in that version. It was added in 4.1 as shown in the release notes from Trolltech themselves:
http://www.qtsoftware.com/developer/changes/changes-4.1.0
>> Even that is not that long ago and more than 4 year after the outdated mailinglist post you criticized.
Why are you so obsessed with timing? Who cares whether it was a problem in the past? You complained about namespace pollution, it's no longer an issue. Period.
>> Never missed this feature
Ah yes,the old "I don't use this feature therefore it's useless".
Sorry, my original comment was meant to be somewhat tongue in cheek. Of course you can write great applications with GTKMM. You can write great applications with any combination of language and toolkit. Great applications were written in assembly, even though we can now agree that using it for a new desktop application would be insanity. GTKMM is a decent choice, but it is my firm belief that it is not the best choice. And for me, I have only very limited time to devote to my side business, and Qt enables me to make a viable, successful product with those very limited resources. To me that is critical, to others it is not. Anyway, those projects you point out were written before this announcement. I can fully understand the attraction of using an LGPL/BSD toolkit instead of a GPL one, and how it can outweigh many other factors.
Yes I have.
I'll tell you why it was so "unproductive" using my current project as an example. It's a small visio-like diagramming tool for a niche application that I sell. It comes in at a scant 7000loc, but does flowchart editing with various shapes, images in vector and raster formats and automatic connectors, manipulates SQL databases, autoupdates from the net, the canvas is zoomable, movable, undoable. Printing, spellchecking, exporting to PDFs and images, etc.
All this with 7 delete statements and no memory leaks (since Qt manages most of the memory).
All this with two dependencies (Qt and aspell).
All this works on 3 platforms, with the only platform specific code related to handling aspell differences.
Native look and feel on windows. And I mean really native, not "skin that looks like native".
Build steps on each platform are "qmake make"
You just can't do that with GTK (mm or # or what have you). You will end up depending on many different little libraries, each one with a different build system and various levels of quality, documentation, maturity, and cross-platform issues. I do this as a side business, but I also do it for fun, and dealing with those kinds of hassles is not fun.
That's stupid. If Qt was LGPL'd 15 years ago, Trolltech would have gone out of business 14 years ago, and Qt wouldn't exist.
>> Does it use templates - no
Sure it does, all the collection classes are templated.
>> Does it use standard collections & iterators - no
True, although I like the api of the Qt collections much better than the std ones.
>> The standard C++ string?
The standard C++ string class is horrible for GUI applications. It just sucks. No convenience functions, no unicode. Blah. Thank god for QString.
>> you cannot even construct a QString from a std::string without using c-strings
Sure you can:
QString QString::fromStdString ( const std::string & str )
>> Qt hardly uses any exceptions
This one is true. I agree that in certain situations Qt should definitely add some exception support.
>>It is still featured in the wikipedia entry about QT, and therefore still seems to be valid.
Haha. Wikipedia says it so it must be true :)
>> And it seems to have appeared in QT 4.4 (please correct me if I am wrong)
Actually it was first an option in Qt 4.1. Not sure of the exact date, probably early 2006.
>> It basically a marketing page.
So.. what about the rest of the points on that page? Introspection and all that good stuff comes from moc. I sure appreciate it a lot more than that warm fuzzy feeling of being more pure to the C++ language.
>> Qt might be a good toolkit, but from the C++ point of view GTKMM is far better.
You're absolutely right. So if you are programming to write high quality programs in the least possible time for real world applications, chose Qt. If you are a language purist who values that more than productivity, chose GTKMM.
Huh? I was using assistant as my help system on windows. No problems with spaces in paths.
And now they have the QtHelp system, which is even better.
>> You can safely assume that anyone who writes that today doesn't know C++.
Since I write C++ for a living, I have to ask, what's wrong with that line? Of course if possible I'd put it on the stack, but sometimes it can't be avoided..
>> So... how exception-safe is Qt these days? Can I safely use the STL or Boost and Qt in the same program?
Of course. We do.
>> I do realise that most Linux distros ship Qt with exception handling turned off, which is wrong on multiple levels, so obviously I'd have to compile it myself.
I don't think this is the case on newer distros. I think before GCC 4.0 exception support imposed a pretty big overhead so people left it out. I've never had a problem with exceptions in Qt-using code on any platform.
No, it is not. It uses its own toolkit, and you can optionally make it use one of several platform-specific frontends to render the widgets. One of those frontends uses GTK and tango icons, one of them uses Qt and crystal icons.. Openoffice does not require or depend on GTK or Qt though.
As commenters in that article also mention, the docs recommend (or at least did for a very long time) the event table approach. Not surprising that people are using it and not aware of an alternative.
What exactly is "the horror" of moc? In normal programming you will never be aware of its existence and it does a lot more than signal/slot connections for you (introspection for example).
In many ways Qt brings the benefits of higher level languages like C#/Java to C++.
Signals and slots are also safer/easier than Connect, based on the last comment on that blog: "It should be noted that ... you should always remember to disconnect the event handler in the event handler object's destructor, otherwise your application may crash if/when the handler is called after your event handler object is destroyed."
That can never happen in Qt. If you delete an object it is automatically disconnected from any signals it may be connected to.
Don't feel so bad, I just paid $1100 to renew my Qt commercial license :) That's ok though, it was worth it before, and they deserve the money for the kick ass product.
Yep, I spent a few months using wxWidgets a couple years ago. I just didn't like it. Obtuse MFC style message maps just screamed ugly at me. Same with lots of macros that needed to be there for certain automated tasks. The documentation isn't as solid as that of Qt, and I found a lot more bugs just playing with it than I ever found in writing serious code with Qt.
When Qt was expensive, wxWidgets was an option (even though I still elected to pay for Qt myself) but now I just can't see any reason why you would want to use it apart from legacy support.
Huh, I've always gotten great support through their commercial support. Usually things were fixed ASAP. But I guess it depends on the issue.
>> Can anyone suggest any realistic situation where the LGPL would be undesirable for a commercial app?
One example and something that I do with Qt+commercial license is static linking to get the exe size down and contained within one executable with zero dependencies. I can't do that with LGPL Qt. Other than that there just isn't much point in getting the commercial license anymore. You'd be better off just buying support when you need it.
>> Annoying hums
Bullshit. Flourescent tubes hum, CFLs don't.
>> Still not quite natural-looking light despite improvements and claims that they are.
Bullshit. "Natural looking" is stupid anyway. What you mean is "incandescent looking".
>> Contain mercury.
Small amounts, trapped and recyclable. More mercury is produced from generating the extra power required by incandescents.
>> Still blow out (most I've seen last maybe 1 1/2 or so times the best incandescent bulb).
So lasting at least 50% longer than incandescents is a bad thing? Anyway most last much longer than that.
>> We seem to be abandoning the simple yet true adage of "if it ain't broke don't fix it" lately with a lot of things.
Firstly, it is broke since incandescents use way too much power. Secondly, if you don't want to replace working bulbs, just wait till your incandescents burn out (ie, break) and then replace them with the superior technology.
>> couldn't figure out why CFLs were lasting months rather than years in the bathroom
You bought crappy CFLs. CFL's don't have a problem with on/off as long as you're not running a disco or something. My 5 round CFL bulbs in the bathroom are going strong after 2 years. Same for everyone else in the family.
I agree that CFLs aren't for every possible use, but they are great for almost everything. The only thing they're not great for is decorative lamps (although you can get different shapes of CFLs) and outdoor lamps that aren't always on in cold environments (takes too long to warm up and produce full light).
As other's have mentioned, you must be fantastically unlucky to be getting those failure rates. I haven't had to replace a single one of the 10 bulbs I put in 2 years ago. Maybe your power is unstable? I've heard that CFLs tend to not like uneven power.
Also you mention rising electricity bills, but of course that has nothing to do with CFLs. They use less power, so you're doing something else to make up the difference. Not "probably" as you say, but absolutely certainly.
As for shipping, it's incredibly unlikely that the weight is a factor in comparing traditional bulbs to CFLs. Volume is going to be a limiting factor for both of them. No way would a cargo ship have to load fewer containers of CFLs because of some weight limitation. They ship containers of steel for crist's sake.
I think it's a matter of exposure. You say that most useful Linux progs are written with GTK, but really the only one that I use day to day that is Firefox, and that's not even a GTK app, it just happens to use some GTK widgets.
Once in a blue moon I fire up Inkscape, and that's about it. VLC is now Qt, Skype is Qt, Google Earth is Qt, Konversation for IRC, Okular for document viewing, OO has a version drawn with Qt widgets, k3b for burning discs, plenty of good qt music players, Krita and kolourpaint for image editing (really kolourpaint is enough for 90% of what I do), gwenview for image viewing, etc etc
Spoken like someone who hasn't used Qt (I don't know much about GTK so I can't speak to the subject). Qt is at least as productive and feature rich as Cocoa. And unlike Cocoa, you're not bound to one platform. So if you want to support Windows and MacOSX, Qt lets you do that with one codebase, while your cocoa app will need to be entirely rewritten.
Uhh.. No. Drive from Vancouver to Halifax, you're in the car for a few days. Fly that distance and it's a few hours.
Risk/hour is completely irrelevant when comparing the safety of airplanes to cars. When was the last time you took a week long plane trip?