> >Qt lacks gtk's incredibly useful dynamic keybinding features
> That has disappeared in GNOME 2.
And besides that, it DOES have dynamic keybinding, or at least it did in version 2.3. Haven't played with it recently. But I'm personally of the opinion that dynamic keybinding is a really bad idea. It's not at all intuitive to newbies, and even for experts, there's no feedback at all given as to what's happening, and there's no conflict resolution policy. Shouldn't I be *asked* first if I try to reassign Ctrl-C from "copy" to "close window" or something?
I don't know if Qt still has dynamic keybinding, but I hope they got wise and removed it, as it sounds like Gnome is doing as well.
I was assuming they meant "perfect store" from the business perspective. They offer a huge selection of merchandise without having to ever buy or warehouse any of it. Really, they're selling raw commerce itself. Great for them. But definitely not the best deal for the consumer.
Your comment points to what I think is THE major downside to STL: debugging.
If something's not compiling that you think should, you end up wading through the mile-long error messages. If it does compile but doesn't work right, you're going to find yourself in the debugger trying to step through some of that crazy obscure STL C++ code to try to figure out what the heck is going wrong. Neither is much fun.
But when it does compile and run correctly STL is pretty nice!
I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.
Basically people have realized that templates can can be used to create programs that run at compile time to do some very clever optimizations (template meta-programming is what they call it see http://www.boost.org for one implementation. Blitz++ is the big example use of the stuff that everyone points too). But the code to make this stuff happen is ATROCIOUS!
Yeh, you can make a template meta-program to calculate factorials at compile-time. Great! That sort of thing can come in handy. You can even write template meta-code that basically generates code at compile time. That's cool too! But the code to do it looks NOTHING at all like the equivalent run-time code. Why does it have to be that way? Why does compile-time code have to look SO different from run-time code, at at the same time look SO horrific?
I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax. Then you could just, say, change one line to turn some run-time code into compile-time code (only when there's no dependence on run-time data, naturally). But it doesn't necessarily make sense to put all the run-time efficiency restrictions on the compile-time language. Dynamic function lookup by strings is a pretty big run-time hit, for example, but you wouldn't care as much if it were used for compile-time function lookup.
In general, the meta-programs seem work a lot more like functional languages -- so fine, I'd be willing to settle for at least a clean syntax for the compile-time language, say something Lisp-like, even if it looks different from the run time language. ANYTHING, as long as the syntax is clean and readable, would be better than the current situation of trying to do meta-programming in C++.
I think the situation C++ is in today with respect to generic programming and meta-programming is a lot like where C was when OOP started to become big. People realized that, yeh, C can do OOP, but it doesn't really support it. C allows OOP, but it offers nothing really to facilitate its use. I think Stroustrup makes that argument in his C++ book. So Stroustrup created C++ as a language that would support OOP, not just allow it.
Well folks, now we've got this handy meta-programming stuff, and yeh you can do it in C++, but it is not pretty. It's downright painful. Writing it is hard. Debugging it is hard. Testing it is hard. Reading it a week after you write it is even hard. Sounds to me like it's time for some new language stud to come and save us.
The reason people shout into cell phones isn't that the phones don't pick up sound well enough. They do. It's that people don't *THINK* they pick up sound well enough because the phones don't give you any feedback in your own ear. Normal phones do give feedback and people are used to that. When you hear no feedback, you think "hey this phone must not be picking me up very well".
It may be a neat bit of technology they've come up with, but people won't stop shouting into their phones until they get feedback.
Quote from the mousedriver.com web page: "WE WILL NOT SELL DIRECTLY TO CUSTOMERS OR DISTRIBUTORS!!!" Doesn't that cut out just about anybody who'd want to buy it?
Seriously, though, if they're going to go to the trouble of making such a web site for their company, they should at least let people buy them on line. What's the point in making the product so hard for WebSurfin' Joe to get his hands on?
I'm not an expert on all the ins and outs, but I had to do some large image editing recently, and Photoshop's memory handling is VASTLY superior to the GIMPs. The GIMP was just barely able to do anything to this 500MB image without crashing, while it was pretty easy and snappy to do with Photoshop.
The other thing I was doing was trying to add some VERY LARGE TEXT, and as far as I could tell GIMP doesn't have any way of handling outline fonts and rendering them at very high resolutions. It turned the text into a very jaggy bitmap no matter what I tried. This was the PC port of the GIMP, though. The Unix version might be better. The PC version will only let you create text at 72 points max.
What journal is going to accept a paper on an "CGI ranking system for online games"? Come on, even the lamest journals would surely laugh at such a thing. Only the US Patent office is silly enough to think such a pile of old ideas is "innovative".
But still, your point is valid. If all they want is to make sure no one else can claim it they just have to make it public. Web pages count as public disclosures too, so no journal pub is necessary.
But even an altruistic company has incentive to patent everything under the sun. As someone mentioned they look good in reports to investors, and also they serve as leverage when you get sued. Recall not too long ago when there were law suits flaring up between SGI and NVIDIA, and in the end they were able to resolve things amicably in part by patent swap agreements. That probably wouldn't have gone so well for NVIDIA if all they had to swap with was ideas they gave to the public domain.
Actually there would not be much of a paper in exposing the flaws in the CIE's L*a*b "perceptually uniform" color space. The limitations were known to the folks who designed it. It was intended to be a color space which was *nearly* perceptually uniform, but at the same time computationally efficient to transform into and out of on whatever hardware they had back when it was defined. They had to cut corners to come up with something that didn't require a supercomputer (of that era) to put to practical use. So yes there are regions where it strays pretty far from the ideal of perceptually uniform.
They get away with all of this for one big reason; the stuff is good quality.
The amusing thing is that they have exactly the opposite reputation in their home country. I don't know why, but for some reason it seems that Japanese folks tend to think of Sony as synonymous with shoddy workmanship. Maybe they have a history of releasing a lot of duds in Japan that they just don't bother trying to export, so we only see the good stuff over here. Anybody know more about why that is?
Well if you compare this to SHARP's previous policies concerning PDAs, this is a hell of a lot more open. Their previous ZAURUS PDAs (mostly only released in Japan) were completely closed. Only SHARP could develop new apps for them.
At least now they've seen the light and realize that it might not be such a bad idea to allow other people to make apps for their hand helds.
Incidentially I almost bought one of these new SHARPs over the summer when I saw it in Japan -- it's a beautiful little handheld -- then I found out it wasn't running CE.
Re:Have you tried FLTK ??
on
GTK-- vs. QT
·
· Score: 1
Well it is fast and light, but it is also seriously lacking in features and flexibility. I tried using it about a year ago, got frustrated trying to make a window lay out the way I wanted it to, and gave up eventually.
In contrast, I tried out Qt over the summer, worked through all the excellent documentation and tutorials, and have had basically nothing but pleasant surprises the whole way. It's not a perfect toolkit, but it's a whole heck of a lot closer than anything else I've tried, including FLTK.
It sounds to me like the way that X-Servers on Windows work. (Like eXceed and XWin-32). Probably works that way on Mac OSX too.
That lets you open a remote X program on your DirectFB desktop, but I don't think that solves the problem in the other direction.
Seems to me like a reasonable solution would be to still ship all the non-whizbang apps linked against X so they can be run over the net, and just use DirectFB for games and video apps that don't really need to be run remotely.
Hellooo? Who is it complaining about the $1500 fee? I think you'll find that it's not people in a commercial software development setting. It's hobbyists, academics, and small-time shareware authors. We want a license that makes sense for us. I can't afford to pay for a Qt licence, so I'm very grateful for the current free licensing schemes they've added, but they've got some problems.
Namely, I would really appreciate it if I were at least allowed to work on my own apps under the non-commercial licencse, and then later -- if they turn out to be commercializable -- switch to the commercial license.
But check out this language from Trolltech.com's FAQ:
Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software
Frankly, I'm dubious as to whether they can even make that restriction, legally. Does that apply to ALL the code I write as part of a Qt non-commercial application? What if some particular source_file.cpp I write has *nothing* to do with Qt? I.e. includes no Qt headers and uses no Qt classes. I try to keep my UI code separate from my app code, so that situation is not uncommon. What about source files in libraries I wrote before I even started using Qt? I didn't have a Professional License when I wrote it, so does using those files in my current Qt project suddenly make them ineligible for inclusion in a commercial Qt app for all time? Everyone has their own little set of utility libraries they reuse from project to project. You hardly ever start completely from scratch. Surely those would have to be exempt from the above. I think the terms above are way too ambiguous to be binding.
I can certainly understand why they want this clause -- too many software companies go belly up before actually shipping product, so you have to get them to pay for the commercial license up front. But what about the lone coder working on something (again in an academic setting, or as a hobby) that turns out to be sellable. That guy shouldn't be prevented from buying a commercial Qt license and selling his code, just because he started out using the free version of Qt. That seems like bad strategy on Trolltech's part. If they can turn a free user into a paying user, they should be excited about that. Instead they've set up what amounts to a disincentive to use the library for users just tinkering around, but with vague commercial aspirations.
I guess my point is that I don't have any plans to write commercial apps, but I *am* doing development. If something turns out to be worth commercializing, Trolltech is telling me that they won't just sell me a commercial license to release the program under, instead they want me to buy the license and then *rewrite* everything.
I must have thought that that FAQ link was to an external site when I first looked because it appears in the "Other Options" section after "AvantGo". Not where I would expect to find the only information on what the site is about. How about making an "About Us" link like 2nd in the main menu? Geez, they spend all that time making a slick looking site, you'd think they could organize the actual information a little better.
I went to eggforge.net and wasted about 5 minutes clicking around and reading things in a vain attempt to figure out what on earth Eggplant is, other than a vegetable that tastes good parmesian style. I still haven't a clue. All I did find was a comment posted by the same Ace905. Apparently she or he is somewhat involved in this eggplant thing, and trying to use slashdot to let us know how impressed he is with himself.
Well, here's some advice: if you're going to go posting your url all over the place, try to put some information up that actually explains what the damn project is about.
I tried wxWindows for a while, but just found it really hard to use. I think perhaps the biggest problem was just that the documentation for wxWindows is no where near as good as Trolltech's documentation for Qt.
That and nothing in wxWindows behaved the way I expected it too. And it all looks way too much like MFC with all those message map macros.
In contrast, for whatever reason, Qt just works the way I expect it to. And whenever it doesn't it only takes a few seconds to bring up the appropriate page of documentation that explains where I went awry.
But, yes, wxWindows has got Qt beat hands-down on the licensing front. I feel like I have to hire a lawyer just to use the darned Qt library.
What's your source? I've been in search of some confirmation that the Trolls will be releasing a 3.0 NonCommercial version for Windows for a while, with no luck.
That's not quite correct. You can use the OpenGL API all you want for free. What's not free is re-implementing the OpenGL API yourself and actually *calling* it OpenGL. That's why we have a library from Brian Paul called MesaGL and not Mesa OpenGL.
But you're free to make and sell as many OpenGL-based games and apps you want without paying royalties to SGI.
Oh, my bad. I had a feeling "habitat destruction" was a little too recent an environmentalist warcry to be relavent to the dodo... But about the second, I sure don't miss the dodo, but if they were hunted out of existence, I'd guess those who used to hunt them do.
Slashdot Mirror
> >Qt lacks gtk's incredibly useful dynamic keybinding features
> That has disappeared in GNOME 2.
And besides that, it DOES have dynamic keybinding, or at least it did in version 2.3. Haven't played with it recently. But I'm personally of the opinion that dynamic keybinding is a really bad idea. It's not at all intuitive to newbies, and even for experts, there's no feedback at all given as to what's happening, and there's no conflict resolution policy. Shouldn't I be *asked* first if I try to reassign Ctrl-C from "copy" to "close window" or something?
I don't know if Qt still has dynamic keybinding, but I hope they got wise and removed it, as it sounds like Gnome is doing as well.
I was assuming they meant "perfect store" from the business perspective. They offer a huge selection of merchandise without having to ever buy or warehouse any of it. Really, they're selling raw commerce itself. Great for them. But definitely not the best deal for the consumer.
Your comment points to what I think is THE major downside to STL: debugging.
If something's not compiling that you think should, you end up wading through the mile-long error messages. If it does compile but doesn't work right, you're going to find yourself in the debugger trying to step through some of that crazy obscure STL C++ code to try to figure out what the heck is going wrong. Neither is much fun.
But when it does compile and run correctly STL is pretty nice!
I'm looking forward to somebody starting over some day and coming up with a language that supports generic programming as well as C++, but which doesn't have the terrible syntax of C++ templates. It must be possible.
Basically people have realized that templates can can be used to create programs that run at compile time to do some very clever optimizations (template meta-programming is what they call it see http://www.boost.org for one implementation. Blitz++ is the big example use of the stuff that everyone points too). But the code to make this stuff happen is ATROCIOUS!
Yeh, you can make a template meta-program to calculate factorials at compile-time. Great! That sort of thing can come in handy. You can even write template meta-code that basically generates code at compile time. That's cool too! But the code to do it looks NOTHING at all like the equivalent run-time code. Why does it have to be that way? Why does compile-time code have to look SO different from run-time code, at at the same time look SO horrific?
I think what is needed is a new language that will put compile-time and run-time code on equal footing. It would be great if they had the same syntax. Then you could just, say, change one line to turn some run-time code into compile-time code (only when there's no dependence on run-time data, naturally). But it doesn't necessarily make sense to put all the run-time efficiency restrictions on the compile-time language. Dynamic function lookup by strings is a pretty big run-time hit, for example, but you wouldn't care as much if it were used for compile-time function lookup.
In general, the meta-programs seem work a lot more like functional languages -- so fine, I'd be willing to settle for at least a clean syntax for the compile-time language, say something Lisp-like, even if it looks different from the run time language. ANYTHING, as long as the syntax is clean and readable, would be better than the current situation of trying to do meta-programming in C++.
I think the situation C++ is in today with respect to generic programming and meta-programming is a lot like where C was when OOP started to become big. People realized that, yeh, C can do OOP, but it doesn't really support it. C allows OOP, but it offers nothing really to facilitate its use. I think Stroustrup makes that argument in his C++ book. So Stroustrup created C++ as a language that would support OOP, not just allow it.
Well folks, now we've got this handy meta-programming stuff, and yeh you can do it in C++, but it is not pretty. It's downright painful. Writing it is hard. Debugging it is hard. Testing it is hard. Reading it a week after you write it is even hard. Sounds to me like it's time for some new language stud to come and save us.
The reason people shout into cell phones isn't that the phones don't pick up sound well enough. They do. It's that people don't *THINK* they pick up sound well enough because the phones don't give you any feedback in your own ear. Normal phones do give feedback and people are used to that. When you hear no feedback, you think "hey this phone must not be picking me up very well".
It may be a neat bit of technology they've come up with, but people won't stop shouting into their phones until they get feedback.
Quote from the mousedriver.com web page: "WE WILL NOT SELL DIRECTLY TO CUSTOMERS OR DISTRIBUTORS!!!" Doesn't that cut out just about anybody who'd want to buy it?
Seriously, though, if they're going to go to the trouble of making such a web site for their company, they should at least let people buy them on line. What's the point in making the product so hard for WebSurfin' Joe to get his hands on?
Ok. That's good to know. Next time I want to try GIMP I'll look for a Linux box.
I'm not an expert on all the ins and outs, but I had to do some large image editing recently, and Photoshop's memory handling is VASTLY superior to the GIMPs. The GIMP was just barely able to do anything to this 500MB image without crashing, while it was pretty easy and snappy to do with Photoshop.
The other thing I was doing was trying to add some VERY LARGE TEXT, and as far as I could tell GIMP doesn't have any way of handling outline fonts and rendering them at very high resolutions. It turned the text into a very jaggy bitmap no matter what I tried. This was the PC port of the GIMP, though. The Unix version might be better. The PC version will only let you create text at 72 points max.
What journal is going to accept a paper on an "CGI ranking system for online games"? Come on, even the lamest journals would surely laugh at such a thing. Only the US Patent office is silly enough to think such a pile of old ideas is "innovative".
But still, your point is valid. If all they want is to make sure no one else can claim it they just have to make it public. Web pages count as public disclosures too, so no journal pub is necessary.
But even an altruistic company has incentive to patent everything under the sun. As someone mentioned they look good in reports to investors, and also they serve as leverage when you get sued. Recall not too long ago when there were law suits flaring up between SGI and NVIDIA, and in the end they were able to resolve things amicably in part by patent swap agreements. That probably wouldn't have gone so well for NVIDIA if all they had to swap with was ideas they gave to the public domain.
That is, until it stops because of a hardware failure, and a nice little hole is burned into your fovea.
Actually there would not be much of a paper in exposing the flaws in the CIE's L*a*b "perceptually uniform" color space. The limitations were known to the folks who designed it. It was intended to be a color space which was *nearly* perceptually uniform, but at the same time computationally efficient to transform into and out of on whatever hardware they had back when it was defined. They had to cut corners to come up with something that didn't require a supercomputer (of that era) to put to practical use. So yes there are regions where it strays pretty far from the ideal of perceptually uniform.
The amusing thing is that they have exactly the opposite reputation in their home country. I don't know why, but for some reason it seems that Japanese folks tend to think of Sony as synonymous with shoddy workmanship. Maybe they have a history of releasing a lot of duds in Japan that they just don't bother trying to export, so we only see the good stuff over here. Anybody know more about why that is?
Looks like CNN took you up on your challenge, Michael. And they cite Slashdot as the source of their new-found skepticism! Too funny!
Well if you compare this to SHARP's previous policies concerning PDAs, this is a hell of a lot more open. Their previous ZAURUS PDAs (mostly only released in Japan) were completely closed. Only SHARP could develop new apps for them.
At least now they've seen the light and realize that it might not be such a bad idea to allow other people to make apps for their hand helds.
Incidentially I almost bought one of these new SHARPs over the summer when I saw it in Japan -- it's a beautiful little handheld -- then I found out it wasn't running CE.
Well it is fast and light, but it is also seriously lacking in features and flexibility. I tried using it about a year ago, got frustrated trying to make a window lay out the way I wanted it to, and gave up eventually.
In contrast, I tried out Qt over the summer, worked through all the excellent documentation and tutorials, and have had basically nothing but pleasant surprises the whole way. It's not a perfect toolkit, but it's a whole heck of a lot closer than anything else I've tried, including FLTK.
Says who? Do you have some links to reviews or benchmarks that back that up?
It sounds to me like the way that X-Servers on Windows work. (Like eXceed and XWin-32). Probably works that way on Mac OSX too.
That lets you open a remote X program on your DirectFB desktop, but I don't think that solves the problem in the other direction.
Seems to me like a reasonable solution would be to still ship all the non-whizbang apps linked against X so they can be run over the net, and just use DirectFB for games and video apps that don't really need to be run remotely.
Hellooo? Who is it complaining about the $1500 fee? I think you'll find that it's not people in a commercial software development setting. It's hobbyists, academics, and small-time shareware authors. We want a license that makes sense for us. I can't afford to pay for a Qt licence, so I'm very grateful for the current free licensing schemes they've added, but they've got some problems.
Namely, I would really appreciate it if I were at least allowed to work on my own apps under the non-commercial licencse, and then later -- if they turn out to be commercializable -- switch to the commercial license.
But check out this language from Trolltech.com's FAQ:
Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software
Frankly, I'm dubious as to whether they can even make that restriction, legally. Does that apply to ALL the code I write as part of a Qt non-commercial application? What if some particular source_file.cpp I write has *nothing* to do with Qt? I.e. includes no Qt headers and uses no Qt classes. I try to keep my UI code separate from my app code, so that situation is not uncommon. What about source files in libraries I wrote before I even started using Qt? I didn't have a Professional License when I wrote it, so does using those files in my current Qt project suddenly make them ineligible for inclusion in a commercial Qt app for all time? Everyone has their own little set of utility libraries they reuse from project to project. You hardly ever start completely from scratch. Surely those would have to be exempt from the above. I think the terms above are way too ambiguous to be binding.
I can certainly understand why they want this clause -- too many software companies go belly up before actually shipping product, so you have to get them to pay for the commercial license up front. But what about the lone coder working on something (again in an academic setting, or as a hobby) that turns out to be sellable. That guy shouldn't be prevented from buying a commercial Qt license and selling his code, just because he started out using the free version of Qt. That seems like bad strategy on Trolltech's part. If they can turn a free user into a paying user, they should be excited about that. Instead they've set up what amounts to a disincentive to use the library for users just tinkering around, but with vague commercial aspirations.
I guess my point is that I don't have any plans to write commercial apps, but I *am* doing development. If something turns out to be worth commercializing, Trolltech is telling me that they won't just sell me a commercial license to release the program under, instead they want me to buy the license and then *rewrite* everything.
Oh oh! I found the FAQ. Ok. I get it now.
I must have thought that that FAQ link was to an external site when I first looked because it appears in the "Other Options" section after "AvantGo". Not where I would expect to find the only information on what the site is about. How about making an "About Us" link like 2nd in the main menu? Geez, they spend all that time making a slick looking site, you'd think they could organize the actual information a little better.
I went to eggforge.net and wasted about 5 minutes clicking around and reading things in a vain attempt to figure out what on earth Eggplant is, other than a vegetable that tastes good parmesian style. I still haven't a clue. All I did find was a comment posted by the same Ace905. Apparently she or he is somewhat involved in this eggplant thing, and trying to use slashdot to let us know how impressed he is with himself.
Well, here's some advice: if you're going to go posting your url all over the place, try to put some information up that actually explains what the damn project is about.
I tried wxWindows for a while, but just found it really hard to use. I think perhaps the biggest problem was just that the documentation for wxWindows is no where near as good as Trolltech's documentation for Qt.
That and nothing in wxWindows behaved the way I expected it too. And it all looks way too much like MFC with all those message map macros.
In contrast, for whatever reason, Qt just works the way I expect it to. And whenever it doesn't it only takes a few seconds to bring up the appropriate page of documentation that explains where I went awry.
But, yes, wxWindows has got Qt beat hands-down on the licensing front. I feel like I have to hire a lawyer just to use the darned Qt library.
What's your source? I've been in search of some confirmation that the Trolls will be releasing a 3.0 NonCommercial version for Windows for a while, with no luck.
That should be "nanotube-dick".
Actually I think it's one of those e^n problems. It's exponential, not polynomial.
But you're free to make and sell as many OpenGL-based games and apps you want without paying royalties to SGI.
Oh, my bad. I had a feeling "habitat destruction" was a little too recent an environmentalist warcry to be relavent to the dodo... But about the second, I sure don't miss the dodo, but if they were hunted out of existence, I'd guess those who used to hunt them do.