>> Basically, the problem is: if it's working fine, why change? For instance, I'm still using the KDE-classic icon set because I see no reason to get glossier icons, I recognize instantly the old icons and that's what matters.
Familiarity is nice to avoid retraining, but you won't be attracting any new users/devs with ugly interfaces. Sounds shallow but its a fact of life. Aesthetics matter.
>> The big point about KDE has always been its capability for personal configuration. I prefer to use just one desktop, so I don't have a desktop selector applet in my taskbar. I prefer not to put icons on my desktop, since the desktop is always covered by the windows I'm using, so I have my favorite apps icons in my taskbar and use konqueror in the file management mode to open documents.
All of those things are possible in KDE 4 (at least the version I'm using, perhaps even in 4.0.x).
I think the configuration culture hasn't gone, but there does have to be a better reason to add an option now. Some options are simply missing because they haven't been added back, but will be as soon as possible.
You misread that quote. They are saying the libraries will remain stable until KDE 5.. That means kdelibs and such. Then they go on to say, since the libraries are stable, they should release to benefit the relatively complete applications that have built on these libraries (like Dolphin).
They're not saying Dolphin won't change. Just the underlying libraries.
Binary compatibility means nothing when talking about programs. You can only apply the term to libraries. (And even then it doesn't mean that the library "remains static", just that no features are removed or changed such that it would break existing programs that rely on them).
Yeah the video is hard to believe. I've done lots of work with image processing using webcams and they're usually pretty crap. You can get 30fps max, and then usually only at 320x240. If the lighting conditions aren't good, your framerate will drop (or everything goes unusably dark if you disable the automatic aperture adjustment).
They show some latency, but overall the motion is incredibly smooth. Based on my experience that's impossible, but I'd love to be proven wrong. Gotta try that out.
Of course, everything is possible to do with other tools. It's just harder. Anything I can write in Qt I can also write in pure assembly, but it'd be terribly inconvenient.
Same goes for the other toolkits. Yes I can use GTK for the ui, some other lib for network access, something else for XML parsing, something else for webkit integration, etc etc.. All of those libs will have different build systems, different levels of maturity, different levels of cross platform support, different API styles, different places to get support, and different levels of documentation (mostly poor).
Or I can use Qt, get all those things from one place (but still modular), with high quality documentation, a consistent and intuitive API, and a consistent cross platform performance.
Not a hard choice for me. Save me a ton of time. My one man business would not be possible without Qt.
>> If QT goes that route then we do have wxWidgets as you mentioned (which is a toolkit that I REALLY like - you mentioned Linux and Windows but the code also ports over to MacOS as well)
And works equally badly on all those platforms. I've used wxWidgets, and it's not anywhere close to Qt for a cross platform toolkit. I can develop in Qt in Linux and test my app, then build the installer in Windows and ship it to clients. Never had even a single problem that only showed up on Windows. That's quality cross platform.
>> , or the obvious choice of GTK.
Which is not even remotely the same thing. GTK is GUI only, not any of the other stuff Qt (and to a lesser extent, wxWidgets) provides.
Ha. Obviously you've never used the alternatives. They are far inferior to Qt. There are no other FOSS cross-platform toolkits anywhere near the level of Qt, for the simple reason that Qt has had lots of dedicated resources for quite a few years now, whereas no other toolkit has the same (aside from some proprietary MS stuff that can't really be called cross-platform).
And yet after that long post trying to discount peak oil, just look at the data. Look at how we've been on a plateau since late 2005. Look at how even though prices have gone through the roof, production hasn't increased, even though all the incentives are there for it to do so.
Sorry but that's bull. I read the kde dev blogs, I use KDE 4.1 packages, and I love KDE, but the release was certainly not advertised as unstable nearly enough.
Have a look at the official release announcement. Not a word that it's not actually meant for users. http://kde.org/announcements/4.0/
I love KDE, but that release was a bad move. Luckily KDE 4.1 will actually be pretty good for users, so it won't be repeated.
>> My biggest gripe is the volume control -- it's really hard to fine tune it.
This is fixed in the current SVN (which will become 0.9)
>> The UI has a LOT of room for improvement, and I've never found a skin for it that actually works properly.
Yep. Luckily VLC decided to drop wxWidgets entirely (which they say was causing a lot of issues) and rewrite the UI in Qt4 for the upcoming version. It's not perfect, but it's already a big step up.
If you had stuck with windows, how much of your time would it take to clean the crapware off the machine? How much time did it take to put all the software on that you use? How much time will it take in the future to keep the various virus/spyware/malware stuff up to date and clean up the mess? So even if you spend a day setting up Linux there's still no way of knowing if that's more or less than it would have taken to set up windows.
It's art. Do you find it sexually attractive? I don't. It's normal to see a naked child and not be aroused, that's one reason adults look different to children. Sorry, if you don't understand the difference between a naked child and a child posed in a sexually suggestive manner, I can't help you.
I have no problems with naked children running around the beach like is common in Europe. There is nothing sexual there, and the paranoia about that in north america is ridiculous.
This cover is not innocent nakedness. It's obviously meant to be a suggestive pose, and I don't think that's ok.
Remember Nevermind, by Nirvana? It has a picture of a baby boy, you can see his penis. The fact that you're comparing those two pictures shows you don't understand the difference at all. That picture is just a picture. There is no deliberate sexual pose involved. It's basically just a picture of a child at play. The issue is not black and white like you are portraying it.
Whatever your large project is, I'm willing to bet it's nowhere near as complex as the kernel. Whenever you get the feeling that they must have missed something that seems obvious, you're probably the one that's wrong. No offense, but they have a lot more experience dealing with unique kernel issues than you do.
You talk about unit testing, but how exactly are you going to unit test multi-threading issues? This is not some simple problem that you can run a test/fail test against. These kinds of things can really only be tested by analysis to prove it can't fail, or extensive fuzz testing to get it "good enough"..
You need to be more flexible with changes. Users like you are the hardest to please (using FF for almost 10 years == huge resistance to change).
Extensions will be updated when it's properly released.
Use the browser for a while and that "intelligent bar" as you call it will eventually give you the results you want, and should be better than the old bar even. It takes a couple days to learn the sites I go to often, but now I can't live without it. Open your mind a bit and give things a chance, instead of just rejecting them outright.
You complain about memory use, but then outright reject a browser which has solved this problem to a large extent. Completely silly. You think IE8 will be any good? Judging from the piss-poor IE7, I don't hold out much hope.
You're confusing two issues. Whether a website works or not is completely different than whether it crashes the browser.
If a website crashes the browser it is always the browser's problem. NO EXCEPTIONS. Nothing a website can do should crash the browser. If it does the browser is broken.
If a website doesn't work correctly, then it could be either the browser or the website's fault, depending on the website's code.
>> With Qt 3 (I have no knowledge of Qt 4), you have to write adaptor classes that monitor the data model and affect the UI and vice versa, because Qt 3 does not support the MVC pattern.
I started on Qt4, which uses MVC extensively. I've never had to do that so I can't comment.
>> When the bus or the shared cache is locked, there are stalls in all the parts of the system that wish to access those resources, by the very definition of the operation: locking means some part of the system will have to wait.
Of course, but that still gives you almost no information about overall performance. You don't know what the tradeoff is. With a garbage collector you lose the predictability. Last thing I want is the collector running at random times when my application is time-sensitive.
Right now in about 10kloc I have a grand total of 7 delete statements. All my other memory is handled by Qt. Yes that's a small app (I'm the sole dev) but for stuff like that I really have no need for a GC.
Re:But does it work with Visual C++ Express?
on
In-Depth With Qt 4.4
·
· Score: 1
Two answers. Yes Qt works with the compilers in visual studio express. You can just download the source and recompile it with those compilers, then compile your programs against that. You need to download the platform SDK separately though, since the express editions don't come with it.
There is no built in VS integration in the free version, you have to buy a license for that.
It's definitely much easier to use mingw, since everything comes pre-compiled for you. Then use something like QDevelop or the Eclipse Qt integration as an IDE.
>> A real example is a widget tree: a widget contains pointers to children and a pointer to the parent.
Exactly the sort of thing that Qt will handle for you, and as an application developer I never have to worry about.
>> This overhead is not significant if your widgets are not many, but it becomes significant when you have memory constraints (e.g. on a hand-held device) or when you have a lot of objects organized in trees.
Assuming your calculation is correct on overhead, you're still missing the second part of the calculation. What's the overhead of the garbage collector? Both in terms of memory, CPU usage, and unpredictability. I highly doubt it will be less than the few bytes you're using to keep track of your objects.
>> In order to handle the reference counting from multiple threads, atomic increment and decrement instructions need to be used, and these instructions lock some aspect of the system (the bus, the cache, etc)
You're ok up to here...
>> and so the system becomes less responsive.
Until you make a huge leap to the conclusion where it all falls apart. System responsiveness is a massively complex issue, and you can't even begin to guess the tradeoff between reference counting and garbage collection without some real testing.
>> There is a philosophy in computer science that classes should be kept as simple as possible, and that utilities unrelated to the basic maintenance of the class should be relegated to separate functions.
In computer science? Not really. Anyway, defining "as simple as possible" is impossible.
>> I can do anything with an STL container that I can with a Qt container;
I can do anything with assembly that you can do with an STL container. That's not the point. The point is that things can be done more easily and in less lines of code with a more convenient API.
>> I just use free functions that can operate on any container rather than bloating the class with unnecessary functionality that then needs to be duplicated for other container types.
>> I appreciate Qt's motivation for creating their own containers but STL really is a more consistent and rigorously documented paradigm (try finding the timing constraints on any of their functions)
Overall I find that Qt's docs are much better organized than any stl source I've found. Hell there's a dedicated app to browse and search the Qt docs which is insanely useful. I agree that in some cases I would like more information about algorithmic complexity, but if you look at the sort functions on that QtAlgorithms page, it does tell you that where it's important.
Hmm, I never had a problem with the windows build environment. And I much prefer proper documentation and the best class library bar none to some sense of technical "correctness" that I would get with GTKMM. I would be embarrassed to give a GTK UI to a paying customer on Windows. It's great on Linux, but the cross platform support is pretty poor.
No, the answer is: gstreamer is effectively linux only. On Linux it makes sense to use gstreamer for the most part (lets not get into all the other equally capable frameworks like xine, mplayer, or vlc), but it would be stupid to use gstreamer on windows or mac, which all have their own native frameworks.
So in your narrow example, you considered Linux, but Qt runs on way more platforms than that.
>> On Linux the libraries are now so damn big that non-KDE users wont install them.
That's ridiculous. Only the hardcore GTK purists won't install qt libs. No one else will ever know or care. You can never please those fanatics. If you use GTK you will have the same problem with hardcore Qt purists. You can safely ignore those idiots.
>> On Windows the best development tools are moving away from C++.
As others have mentioned, that's not the case at all. Visual Studio has excellent C++ support in its latest versions, and there are lots of decent free alternatives (Eclipse CDT, dedicated stuff like QDevelop).
>> On Mac it's just plain ugly.
I can't say much about that since I don't use a mac, but some other people have mentioned that they didn't even notice the difference on some Qt using apps. Once again I doubt it's an issue for anyone except the hardcore purists.
And what's the alternative? Write a custom UI for each platform? Maybe if you have resources to burn, but these days it's just a huge waste.
>> Vista itself using the XAML aspects of these API throughout the OS, from the WDDM to the printing subsystem. These are very proven technologies, and work beyond what OS X can even do at this point.
And Vista has been such a success...:) You can't claim an API is successful based on the company that created it using it in their own products. If they didn't eat their own dogfood it would be pretty staggering.
>> (On OS X to get to the WPF levels of features, you literally have to create it yourself and drop to OpenGL.)
You probably know more about it than me, so I'll take your word for it. But at the end of the day what I care about as an application developer is what gives me real features that I can use and make my app better? So far I don't see WPF giving me any advantages. Yes it has all sorts of power to do crazy 3D stuff, but 90% of the time, that's not what I want at all. I want useful, practical APIs to perform the common tasks for today's desktop apps. WPF's success in that regard will be proven or disproven by its acceptance in the industry. For now it's a complete non-starter, because I have to still support at least Win98-Vista, let alone Linux, OSX, and embedded platforms. With WPF I would be limiting myself.
>> Actually video is from reserach team and Xerox
Yes, the _Microsoft_ research team. Yes the videos are interesting, but don't think they're not biased.
>> Do you have a point other than you don't like Vista? Vista is already supassed all Macs ever sold in the history of Apple, and you act like it is unproven crap? Strange...
I don't mind Vista. But its sales numbers have nothing to do with its quality. It's just about impossible to buy a new computer without it these days.
>> Hell let's even talk the WDDM in Vista, I can name 10 things it can do that no OTHER OS can do. From a shared 3D Surface texture composer, vector composer, to GPU RAM sharing, to even GPU multi-tasking, and multi-GPU threading...
Exactly the sort of thing I'm talking about. I don't care. That kind of thing is technical masturbation. Once I see the end-user benefit of those technical features, I will reconsider, but until then the capabilities of other platforms are just as good (since the result is indistinguishable).
>> Just because you don't know what this does, doesn't mean these are crap concepts or a highly advanced development platform that would take OS X to be re-engineered at the kernel level to attempt to implement because of the legacy BSD API kernel interfaces.
Well I'm not an expert in these technologies, but I understand the basics. I also understand (apparently you don't) that superior technical ability means nothing without meaningful applications of that ability. Also you obviously know little of kernel design, since you're mixing all sorts of concepts here. (re-engineered at the kernel level? who cares, happens all the time, also in windows)
>> I know this because I have worked in the UI research industry for many years. If you want innovative User Interaction, you look at what Microsoft Research is doing, not Apple.
If you really worked in the UI research area, you would know how ridiculous that is. Every company has some innovations there, and they all build on each other.
>> And an idiot that thinks giving an OS commands via a word list is 'graphical' or innovative is just damn funny.
And we devolve to name-calling:)
>> Besides, if you actually looked around, you would have noticed that there are more Vista x64bit applications than all the OS X applications ever developed.
Why bother making statements if you can't prove them? Most third party apps on windows are compiled for 32bit. The vast majority of Linux apps will be compiled for 64 bit. I don't know why you bother to argue.
>> Does this make Mac Zealots cry?
I dunno. I don't even use a Mac. I just smell radical windows supporter and had to inject some reality into the situation.
Slashdot Mirror
>> Basically, the problem is: if it's working fine, why change? For instance, I'm still using the KDE-classic icon set because I see no reason to get glossier icons, I recognize instantly the old icons and that's what matters.
Familiarity is nice to avoid retraining, but you won't be attracting any new users/devs with ugly interfaces. Sounds shallow but its a fact of life. Aesthetics matter.
>> The big point about KDE has always been its capability for personal configuration. I prefer to use just one desktop, so I don't have a desktop selector applet in my taskbar. I prefer not to put icons on my desktop, since the desktop is always covered by the windows I'm using, so I have my favorite apps icons in my taskbar and use konqueror in the file management mode to open documents.
All of those things are possible in KDE 4 (at least the version I'm using, perhaps even in 4.0.x).
I think the configuration culture hasn't gone, but there does have to be a better reason to add an option now. Some options are simply missing because they haven't been added back, but will be as soon as possible.
You misread that quote. They are saying the libraries will remain stable until KDE 5.. That means kdelibs and such. Then they go on to say, since the libraries are stable, they should release to benefit the relatively complete applications that have built on these libraries (like Dolphin).
They're not saying Dolphin won't change. Just the underlying libraries.
Binary compatibility means nothing when talking about programs. You can only apply the term to libraries. (And even then it doesn't mean that the library "remains static", just that no features are removed or changed such that it would break existing programs that rely on them).
Sort of like spelling...
Yeah the video is hard to believe. I've done lots of work with image processing using webcams and they're usually pretty crap. You can get 30fps max, and then usually only at 320x240. If the lighting conditions aren't good, your framerate will drop (or everything goes unusably dark if you disable the automatic aperture adjustment).
They show some latency, but overall the motion is incredibly smooth. Based on my experience that's impossible, but I'd love to be proven wrong. Gotta try that out.
Of course, everything is possible to do with other tools. It's just harder. Anything I can write in Qt I can also write in pure assembly, but it'd be terribly inconvenient.
Same goes for the other toolkits. Yes I can use GTK for the ui, some other lib for network access, something else for XML parsing, something else for webkit integration, etc etc.. All of those libs will have different build systems, different levels of maturity, different levels of cross platform support, different API styles, different places to get support, and different levels of documentation (mostly poor).
Or I can use Qt, get all those things from one place (but still modular), with high quality documentation, a consistent and intuitive API, and a consistent cross platform performance.
Not a hard choice for me. Save me a ton of time. My one man business would not be possible without Qt.
>> If QT goes that route then we do have wxWidgets as you mentioned (which is a toolkit that I REALLY like - you mentioned Linux and Windows but the code also ports over to MacOS as well)
And works equally badly on all those platforms. I've used wxWidgets, and it's not anywhere close to Qt for a cross platform toolkit. I can develop in Qt in Linux and test my app, then build the installer in Windows and ship it to clients. Never had even a single problem that only showed up on Windows. That's quality cross platform.
>> , or the obvious choice of GTK.
Which is not even remotely the same thing. GTK is GUI only, not any of the other stuff Qt (and to a lesser extent, wxWidgets) provides.
Qt gives me cross platform video/audio playing, cross platform webkit integration, network, sql, xml, xpath, threads, concurrent programming helpers, etc etc.
Sure we will suhvive as you say, but it will sure not be as much fun. Unless there's a decent fork or the FreeQt thing goes into effect.
Ha. Obviously you've never used the alternatives. They are far inferior to Qt. There are no other FOSS cross-platform toolkits anywhere near the level of Qt, for the simple reason that Qt has had lots of dedicated resources for quite a few years now, whereas no other toolkit has the same (aside from some proprietary MS stuff that can't really be called cross-platform).
And yet after that long post trying to discount peak oil, just look at the data. Look at how we've been on a plateau since late 2005.
Look at how even though prices have gone through the roof, production hasn't increased, even though all the incentives are there for it to do so.
People carriers are (mini)vans, not SUVs. Good clip though.
Sorry but that's bull. I read the kde dev blogs, I use KDE 4.1 packages, and I love KDE, but the release was certainly not advertised as unstable nearly enough.
Have a look at the official release announcement. Not a word that it's not actually meant for users. http://kde.org/announcements/4.0/
I love KDE, but that release was a bad move. Luckily KDE 4.1 will actually be pretty good for users, so it won't be repeated.
>> My biggest gripe is the volume control -- it's really hard to fine tune it.
This is fixed in the current SVN (which will become 0.9)
>> The UI has a LOT of room for improvement, and I've never found a skin for it that actually works properly.
Yep. Luckily VLC decided to drop wxWidgets entirely (which they say was causing a lot of issues) and rewrite the UI in Qt4 for the upcoming version. It's not perfect, but it's already a big step up.
If you had stuck with windows, how much of your time would it take to clean the crapware off the machine? How much time did it take to put all the software on that you use? How much time will it take in the future to keep the various virus/spyware/malware stuff up to date and clean up the mess? So even if you spend a day setting up Linux there's still no way of knowing if that's more or less than it would have taken to set up windows.
I have no problems with naked children running around the beach like is common in Europe. There is nothing sexual there, and the paranoia about that in north america is ridiculous.
This cover is not innocent nakedness. It's obviously meant to be a suggestive pose, and I don't think that's ok. Remember Nevermind, by Nirvana? It has a picture of a baby boy, you can see his penis. The fact that you're comparing those two pictures shows you don't understand the difference at all. That picture is just a picture. There is no deliberate sexual pose involved. It's basically just a picture of a child at play. The issue is not black and white like you are portraying it.
How was this ever allowed on an album cover?
Whatever your large project is, I'm willing to bet it's nowhere near as complex as the kernel. Whenever you get the feeling that they must have missed something that seems obvious, you're probably the one that's wrong. No offense, but they have a lot more experience dealing with unique kernel issues than you do.
You talk about unit testing, but how exactly are you going to unit test multi-threading issues? This is not some simple problem that you can run a test/fail test against. These kinds of things can really only be tested by analysis to prove it can't fail, or extensive fuzz testing to get it "good enough"..
You need to be more flexible with changes. Users like you are the hardest to please (using FF for almost 10 years == huge resistance to change).
Extensions will be updated when it's properly released.
Use the browser for a while and that "intelligent bar" as you call it will eventually give you the results you want, and should be better than the old bar even. It takes a couple days to learn the sites I go to often, but now I can't live without it. Open your mind a bit and give things a chance, instead of just rejecting them outright.
You complain about memory use, but then outright reject a browser which has solved this problem to a large extent. Completely silly. You think IE8 will be any good? Judging from the piss-poor IE7, I don't hold out much hope.
You're confusing two issues. Whether a website works or not is completely different than whether it crashes the browser.
If a website crashes the browser it is always the browser's problem. NO EXCEPTIONS. Nothing a website can do should crash the browser. If it does the browser is broken.
If a website doesn't work correctly, then it could be either the browser or the website's fault, depending on the website's code.
>> With Qt 3 (I have no knowledge of Qt 4), you have to write adaptor classes that monitor the data model and affect the UI and vice versa, because Qt 3 does not support the MVC pattern.
I started on Qt4, which uses MVC extensively. I've never had to do that so I can't comment.
>> When the bus or the shared cache is locked, there are stalls in all the parts of the system that wish to access those resources, by the very definition of the operation: locking means some part of the system will have to wait.
Of course, but that still gives you almost no information about overall performance. You don't know what the tradeoff is. With a garbage collector you lose the predictability. Last thing I want is the collector running at random times when my application is time-sensitive.
Right now in about 10kloc I have a grand total of 7 delete statements. All my other memory is handled by Qt. Yes that's a small app (I'm the sole dev) but for stuff like that I really have no need for a GC.
Two answers. Yes Qt works with the compilers in visual studio express. You can just download the source and recompile it with those compilers, then compile your programs against that. You need to download the platform SDK separately though, since the express editions don't come with it.
There is no built in VS integration in the free version, you have to buy a license for that.
It's definitely much easier to use mingw, since everything comes pre-compiled for you. Then use something like QDevelop or the Eclipse Qt integration as an IDE.
>> A real example is a widget tree: a widget contains pointers to children and a pointer to the parent.
Exactly the sort of thing that Qt will handle for you, and as an application developer I never have to worry about.
>> This overhead is not significant if your widgets are not many, but it becomes significant when you have memory constraints (e.g. on a hand-held device) or when you have a lot of objects organized in trees.
Assuming your calculation is correct on overhead, you're still missing the second part of the calculation. What's the overhead of the garbage collector? Both in terms of memory, CPU usage, and unpredictability. I highly doubt it will be less than the few bytes you're using to keep track of your objects.
>> In order to handle the reference counting from multiple threads, atomic increment and decrement instructions need to be used, and these instructions lock some aspect of the system (the bus, the cache, etc)
You're ok up to here...
>> and so the system becomes less responsive.
Until you make a huge leap to the conclusion where it all falls apart. System responsiveness is a massively complex issue, and you can't even begin to guess the tradeoff between reference counting and garbage collection without some real testing.
>> There is a philosophy in computer science that classes should be kept as simple as possible, and that utilities unrelated to the basic maintenance of the class should be relegated to separate functions.
In computer science? Not really. Anyway, defining "as simple as possible" is impossible.
>> I can do anything with an STL container that I can with a Qt container;
I can do anything with assembly that you can do with an STL container. That's not the point. The point is that things can be done more easily and in less lines of code with a more convenient API.
>> I just use free functions that can operate on any container rather than bloating the class with unnecessary functionality that then needs to be duplicated for other container types.
Qt containers are STL compatible, so you can use stl algorithms on them. Of course, there is a QtAlgorithms module which contains a lower_bound function. http://doc.trolltech.com/4.3/qtalgorithms.html#qLowerBound
>> I appreciate Qt's motivation for creating their own containers but STL really is a more consistent and rigorously documented paradigm (try finding the timing constraints on any of their functions)
Overall I find that Qt's docs are much better organized than any stl source I've found. Hell there's a dedicated app to browse and search the Qt docs which is insanely useful. I agree that in some cases I would like more information about algorithmic complexity, but if you look at the sort functions on that QtAlgorithms page, it does tell you that where it's important.
Also they have the information about the algorithmic complexity of the operations on Qt container classes.
http://doc.trolltech.com/4.3/containers.html#algorithmic-complexity
Hmm, I never had a problem with the windows build environment. And I much prefer proper documentation and the best class library bar none to some sense of technical "correctness" that I would get with GTKMM. I would be embarrassed to give a GTK UI to a paying customer on Windows. It's great on Linux, but the cross platform support is pretty poor.
No, the answer is: gstreamer is effectively linux only. On Linux it makes sense to use gstreamer for the most part (lets not get into all the other equally capable frameworks like xine, mplayer, or vlc), but it would be stupid to use gstreamer on windows or mac, which all have their own native frameworks.
So in your narrow example, you considered Linux, but Qt runs on way more platforms than that.
>> On Linux the libraries are now so damn big that non-KDE users wont install them.
That's ridiculous. Only the hardcore GTK purists won't install qt libs. No one else will ever know or care. You can never please those fanatics. If you use GTK you will have the same problem with hardcore Qt purists. You can safely ignore those idiots.
>> On Windows the best development tools are moving away from C++.
As others have mentioned, that's not the case at all. Visual Studio has excellent C++ support in its latest versions, and there are lots of decent free alternatives (Eclipse CDT, dedicated stuff like QDevelop).
>> On Mac it's just plain ugly.
I can't say much about that since I don't use a mac, but some other people have mentioned that they didn't even notice the difference on some Qt using apps. Once again I doubt it's an issue for anyone except the hardcore purists.
And what's the alternative? Write a custom UI for each platform? Maybe if you have resources to burn, but these days it's just a huge waste.
>> Vista itself using the XAML aspects of these API throughout the OS, from the WDDM to the printing subsystem. These are very proven technologies, and work beyond what OS X can even do at this point.
:)
:)
And Vista has been such a success...
You can't claim an API is successful based on the company that created it using it in their own products. If they didn't eat their own dogfood it would be pretty staggering.
>> (On OS X to get to the WPF levels of features, you literally have to create it yourself and drop to OpenGL.)
You probably know more about it than me, so I'll take your word for it. But at the end of the day what I care about as an application developer is what gives me real features that I can use and make my app better? So far I don't see WPF giving me any advantages. Yes it has all sorts of power to do crazy 3D stuff, but 90% of the time, that's not what I want at all. I want useful, practical APIs to perform the common tasks for today's desktop apps. WPF's success in that regard will be proven or disproven by its acceptance in the industry.
For now it's a complete non-starter, because I have to still support at least Win98-Vista, let alone Linux, OSX, and embedded platforms. With WPF I would be limiting myself.
>> Actually video is from reserach team and Xerox
Yes, the _Microsoft_ research team. Yes the videos are interesting, but don't think they're not biased.
>> Do you have a point other than you don't like Vista? Vista is already supassed all Macs ever sold in the history of Apple, and you act like it is unproven crap? Strange...
I don't mind Vista. But its sales numbers have nothing to do with its quality. It's just about impossible to buy a new computer without it these days.
>> Hell let's even talk the WDDM in Vista, I can name 10 things it can do that no OTHER OS can do. From a shared 3D Surface texture composer, vector composer, to GPU RAM sharing, to even GPU multi-tasking, and multi-GPU threading...
Exactly the sort of thing I'm talking about. I don't care. That kind of thing is technical masturbation. Once I see the end-user benefit of those technical features, I will reconsider, but until then the capabilities of other platforms are just as good (since the result is indistinguishable).
>> Just because you don't know what this does, doesn't mean these are crap concepts or a highly advanced development platform that would take OS X to be re-engineered at the kernel level to attempt to implement because of the legacy BSD API kernel interfaces.
Well I'm not an expert in these technologies, but I understand the basics. I also understand (apparently you don't) that superior technical ability means nothing without meaningful applications of that ability. Also you obviously know little of kernel design, since you're mixing all sorts of concepts here. (re-engineered at the kernel level? who cares, happens all the time, also in windows)
>> I know this because I have worked in the UI research industry for many years. If you want innovative User Interaction, you look at what Microsoft Research is doing, not Apple.
If you really worked in the UI research area, you would know how ridiculous that is. Every company has some innovations there, and they all build on each other.
>> And an idiot that thinks giving an OS commands via a word list is 'graphical' or innovative is just damn funny.
And we devolve to name-calling
>> Besides, if you actually looked around, you would have noticed that there are more Vista x64bit applications than all the OS X applications ever developed.
Why bother making statements if you can't prove them? Most third party apps on windows are compiled for 32bit. The vast majority of Linux apps will be compiled for 64 bit. I don't know why you bother to argue.
>> Does this make Mac Zealots cry?
I dunno. I don't even use a Mac. I just smell radical windows supporter and had to inject some reality into the situation.