Admittedly, it is all compile-time, but that doesnt mean its not dynamic --------- If its compile-time, then its *not* dynamic. C++ has very limited support for any sort of dynamism, and the STL and libsigc++ continue that tradition. Like I said, I'm a fan of "modern" C++, but I have to admit that its static nature isn't great for GUIs.
The MOC isnt going to make C++ into an interpreted language or anything. ----------- Since when do you need an interpreted language to have dynamism? Smalltalk and Lisp are among the most highly dynamic languages out there, yet have the most advanced native-code compilers available.
that the code size tends to be small, and the executables tend to be fast. ---------- In my experience, Qt is a lot faster than GTK+. GTK+ is really glacial for redraws (especially resizing) and certain things like GtkListView and Pango are quite slow. It doesn't really matter if the language binding is faster if the underlying toolkit is slower.
Get over yourself. Its not perfect Linux support, but its good enough in my book. I'd be more willing to support the OSS-hardliner position on this one if there were OSS 3D drivers that didn't suck, but there aren't, so I'm not.
And the majority of people who care about 3D on Linux aren't gamers anyway. NVIDIA supports 3D on Linux the way they do because the professional 3D workstation market (eg: ILM, etc) finds Linux + Intel + NVIDIA a very attractive value proposition.
Well, that's what Linux uses. There is a little bit of code (source-available) that encapsulates all the kernel-level differences between Linux kernel versions, BSD, and Linux.
NVIDIA cards, anyway, have excellent Linux support. Thanks to the fact that the NVIDIA drivers use a portable core anyway, they seem to be having no problem keeping up with the kernel.
GNOME is C written in a OO style, while C++ is, of course, very similar to C but with OO features. -------- Its not just a matter of language. Its a matter of the fundemental structure of the code.
a lot of the foundation code in both systems isn't GUI dependent and could migrate a lot easier I believe than you think. --------- I am reasonably familier with the KDE architecture and parts of the KDE code, and I can tell you that nearly everything is fundementally tied to Qt. Even non-GUI stuff like kio and dcop are dependent on Qt. Unless GNOME is willing to adopt a Qt dependency (never going to happen) that code cannot be integrated. In the other direction, a lot of GNOME code has dependencies on glib and GTK+. There is no way in hell that KDE will adopt a GTK+ dependency, but it is porting some of the glib-dependent parts over. However, that is not terribly useful, because GNOME really has few non-GUI things that are worth porting.
You know, call me crazy, but I just don't believe this. Think of the apps out there that have an "advanced interface" button. ----------- HIG research shows that such interfaces do not work. People overestimate their capabilities and try to use the advanced mode when they shouldn't, or need to use it the minute they need even one thing not in the default interface.
I don't buy the argument that a feature from KDE couldn't be ported to GNOME or vice versa ------------ The KDE code and GNOME code are completely different. It would be easier to just rewrite all of KDE's features than to port them to GNOME. The license and language issues do play a role, but the simple fact is that KDE and GNOME are very different, not just in the code, but in the developer and user communities.
Having a default KISS interface that can morph into a power user's interface in the same DE is not some technically impossible challenge ------------- I'd say its a damn hard technical challenge. Certainly, I can't think of a mainstream app that has accomplished such a feat. Look at all the popular apps: Microsoft Office, Photoshop, etc, are very powerful, but have very complex interfaces. iMovie, iPhoto, etc, are very simple, but limited in power. Now, if you've got a great idea on how to accomplish this, when so many others have failed, I'm willing to listen!
Qt and the STL are not at odds. They are two different approaches for two different problems. The STL is a general-purpose container library. Its not at all object-oriented, and aggressively static.
Meanwhile, Qt is specialized for GUI programming, and moc and the Qt container library fit that very well. Both allow for much more dynamic code, and in my experience, GUIs are extremely well-suited to dynamism in the language. After all, two of the best GUI languages ever (Smalltalk and Objective C) were of the dynamic/object-oriented variety.
I'm a C++ coder too, and also love the STL. However, I've spent a bit of time doing Qt programming, and really do agree that a more dynamic approach is better suited for GUIs.
He was wondering why we still have to keep installing two different collections of libraries and packages so we can run each other's apps. ----------- Why does Explorer, MS Office, and Visual Studio on Windows all use different toolkits and underlying lbrares? Because things historically just don't work out the way you always want it to, and if "integration" is good enough, than it doesn't matter that its not a perfect solution.
Why the hell aren't they one desktop project that is both uber-customizable yet focusing on KISS usability issues? ----------- Are you dense? The two approaches are completely contridictory! GNOME follows the idea that "less is more." KDE follows the idea that "more is more." You can either have less or more --- you can't combine them.
KDE is whatever you want it to be. I've got mine set up like OS X --- menubar at top, panel at bottom, toolbars and menus simplified. Out of box, its pretty Windows-y, but I'd wager most KDE users don't use the desktop the way it comes out of box.
1) GNOME apps work just fine in KDE, and KDE apps work just fine in GNOME. Indeed, the integration between GNOME and KDE apps is much gerater than between either desktop and Mozilla/OO.o/Motif/Xaw apps.
2) GNOME and KDE have adopted quite different philosophies. The GNOME folks have thrown a lot of effort into polishing the UI, and the KDE folks have spent a lot of effort on the underlying technology. GNOME goes with a "simpler is better" philosophy, while KDE goes with "users like features and power." GNOME tries to define one "right" configuration, while KDE allows you to individualize your setup for efficiency. As such, t would be nearly impossible to define a common framework for both desktops.
Right now, the best thing to do is push for greater integration. People who actually use KDE and GNOME find themselves mostly using apps from one desktop. Using apps from the other desktop is an exception, not the rule. As long as the integration is good, than this isn't a problem. Windows users seem to deal with apps that use a different toolkit (Visual Studio, MS Office, etc) just fine.
The fact that tons of clueless Mac people believe that Quartz Extreme is actual hardware acceleration (like Longhorn's) instead of just acceleration for window compositing. Ie: When you draw a gradient triangle using Quartz2D, its done via the CPU, not the graphics card.
Supercomputers run computation-intensive programs. They spend most of their time running their own code, not running OS code. The only places where OS performance is really involved is for I/O.
Precisely. I don't see why everyone is getting their panties in a bunch. So OS X's UNIX guts are old. Does the average Mac users really care about unixbench scores? Even those doing performance-intensive work with their Macs usually aren't doing something that where kernel performance is heavily involved.
I'm curious --- who were these people that you surveyed? Were they in the US, or worldwide? Does the fact that you conduct online surveys make the user pool somewhat self-selecting? What makes your research methods better than IDC's, anyway?
I definitely think your research should have made Slashdot, but at the same time, I see no compelling reason to believe that your results are more accurate than those of other companies.
You know, with languages like Haskell and Clean, where you have tools that can run proofs on the code, you could eliminate many programming errors automatically, and then devote your testing time to other areas.
But people are *entitled* to do what they love and make a great living off it! I mean, they tell us the procedure to follow (high-school, college, graduate-school) and that's supposed to *guarantee* that our life will be exactly the way we want it in the future! I mean, why would they lie to us about us all being special and *entitled* to anything we want?
Yesh. What has our generation come too? I beginning to sound far too conservative for my taste, but this outsourcing thing is really getting ridiculous...
See: Lisp, Dylan, Scheme, Ruby, Python, Smalltalk, among others. These languages are all "objects all the way down" though Dylan, Ruby, and Python are more-so than Lisp and Scheme.
Those make perfect sense. There was a IE port to Solaris (mlhtml...unix) and Windows did (probably still does, just not publically) run on PPC, MIPS, and Alpha in addition to x86.
Slashdot Mirror
Its not a matter of me thinking so. It was in the presentation Apple gave at Siggraph.
Admittedly, it is all compile-time, but that doesnt mean its not dynamic
---------
If its compile-time, then its *not* dynamic. C++ has very limited support for any sort of dynamism, and the STL and libsigc++ continue that tradition. Like I said, I'm a fan of "modern" C++, but I have to admit that its static nature isn't great for GUIs.
The MOC isnt going to make C++ into an interpreted language or anything.
-----------
Since when do you need an interpreted language to have dynamism? Smalltalk and Lisp are among the most highly dynamic languages out there, yet have the most advanced native-code compilers available.
that the code size tends to be small, and the executables tend to be fast.
----------
In my experience, Qt is a lot faster than GTK+. GTK+ is really glacial for redraws (especially resizing) and certain things like GtkListView and Pango are quite slow. It doesn't really matter if the language binding is faster if the underlying toolkit is slower.
Get over yourself. Its not perfect Linux support, but its good enough in my book. I'd be more willing to support the OSS-hardliner position on this one if there were OSS 3D drivers that didn't suck, but there aren't, so I'm not.
And the majority of people who care about 3D on Linux aren't gamers anyway. NVIDIA supports 3D on Linux the way they do because the professional 3D workstation market (eg: ILM, etc) finds Linux + Intel + NVIDIA a very attractive value proposition.
Well, that's what Linux uses. There is a little bit of code (source-available) that encapsulates all the kernel-level differences between Linux kernel versions, BSD, and Linux.
NVIDIA cards, anyway, have excellent Linux support. Thanks to the fact that the NVIDIA drivers use a portable core anyway, they seem to be having no problem keeping up with the kernel.
GNOME is C written in a OO style, while C++ is, of course, very similar to C but with OO features.
--------
Its not just a matter of language. Its a matter of the fundemental structure of the code.
a lot of the foundation code in both systems isn't GUI dependent and could migrate a lot easier I believe than you think.
---------
I am reasonably familier with the KDE architecture and parts of the KDE code, and I can tell you that nearly everything is fundementally tied to Qt. Even non-GUI stuff like kio and dcop are dependent on Qt. Unless GNOME is willing to adopt a Qt dependency (never going to happen) that code cannot be integrated. In the other direction, a lot of GNOME code has dependencies on glib and GTK+. There is no way in hell that KDE will adopt a GTK+ dependency, but it is porting some of the glib-dependent parts over. However, that is not terribly useful, because GNOME really has few non-GUI things that are worth porting.
You know, call me crazy, but I just don't believe this. Think of the apps out there that have an "advanced interface" button.
-----------
HIG research shows that such interfaces do not work. People overestimate their capabilities and try to use the advanced mode when they shouldn't, or need to use it the minute they need even one thing not in the default interface.
I don't buy the argument that a feature from KDE couldn't be ported to GNOME or vice versa
------------
The KDE code and GNOME code are completely different. It would be easier to just rewrite all of KDE's features than to port them to GNOME. The license and language issues do play a role, but the simple fact is that KDE and GNOME are very different, not just in the code, but in the developer and user communities.
Having a default KISS interface that can morph into a power user's interface in the same DE is not some technically impossible challenge
-------------
I'd say its a damn hard technical challenge. Certainly, I can't think of a mainstream app that has accomplished such a feat. Look at all the popular apps: Microsoft Office, Photoshop, etc, are very powerful, but have very complex interfaces. iMovie, iPhoto, etc, are very simple, but limited in power. Now, if you've got a great idea on how to accomplish this, when so many others have failed, I'm willing to listen!
Qt and the STL are not at odds. They are two different approaches for two different problems. The STL is a general-purpose container library. Its not at all object-oriented, and aggressively static.
Meanwhile, Qt is specialized for GUI programming, and moc and the Qt container library fit that very well. Both allow for much more dynamic code, and in my experience, GUIs are extremely well-suited to dynamism in the language. After all, two of the best GUI languages ever (Smalltalk and Objective C) were of the dynamic/object-oriented variety.
I'm a C++ coder too, and also love the STL. However, I've spent a bit of time doing Qt programming, and really do agree that a more dynamic approach is better suited for GUIs.
It depends on where your priorities are. Yeah, OS X is more polished and more pretty, but KDE is a whole lot more flexible and powerful.
He was wondering why we still have to keep installing two different collections of libraries and packages so we can run each other's apps.
-----------
Why does Explorer, MS Office, and Visual Studio on Windows all use different toolkits and underlying lbrares? Because things historically just don't work out the way you always want it to, and if "integration" is good enough, than it doesn't matter that its not a perfect solution.
Why the hell aren't they one desktop project that is both uber-customizable yet focusing on KISS usability issues?
-----------
Are you dense? The two approaches are completely contridictory! GNOME follows the idea that "less is more." KDE follows the idea that "more is more." You can either have less or more --- you can't combine them.
KDE is whatever you want it to be. I've got mine set up like OS X --- menubar at top, panel at bottom, toolbars and menus simplified. Out of box, its pretty Windows-y, but I'd wager most KDE users don't use the desktop the way it comes out of box.
1) GNOME apps work just fine in KDE, and KDE apps work just fine in GNOME. Indeed, the integration between GNOME and KDE apps is much gerater than between either desktop and Mozilla/OO.o/Motif/Xaw apps.
2) GNOME and KDE have adopted quite different philosophies. The GNOME folks have thrown a lot of effort into polishing the UI, and the KDE folks have spent a lot of effort on the underlying technology. GNOME goes with a "simpler is better" philosophy, while KDE goes with "users like features and power." GNOME tries to define one "right" configuration, while KDE allows you to individualize your setup for efficiency. As such, t would be nearly impossible to define a common framework for both desktops.
Right now, the best thing to do is push for greater integration. People who actually use KDE and GNOME find themselves mostly using apps from one desktop. Using apps from the other desktop is an exception, not the rule. As long as the integration is good, than this isn't a problem. Windows users seem to deal with apps that use a different toolkit (Visual Studio, MS Office, etc) just fine.
The fact that tons of clueless Mac people believe that Quartz Extreme is actual hardware acceleration (like Longhorn's) instead of just acceleration for window compositing. Ie: When you draw a gradient triangle using Quartz2D, its done via the CPU, not the graphics card.
Supercomputers run computation-intensive programs. They spend most of their time running their own code, not running OS code. The only places where OS performance is really involved is for I/O.
Precisely. I don't see why everyone is getting their panties in a bunch. So OS X's UNIX guts are old. Does the average Mac users really care about unixbench scores? Even those doing performance-intensive work with their Macs usually aren't doing something that where kernel performance is heavily involved.
That's right. Jupiter was never a star. Its its hottest, its core temperature never got above about 1/3 what was necessary for fusion to occur.
Actually, its more like saying that the sale of Ferrari's outstripped that of Bentleys. Completely different target markets...
I'm curious --- who were these people that you surveyed? Were they in the US, or worldwide? Does the fact that you conduct online surveys make the user pool somewhat self-selecting? What makes your research methods better than IDC's, anyway?
I definitely think your research should have made Slashdot, but at the same time, I see no compelling reason to believe that your results are more accurate than those of other companies.
This is insightful? What do you think they base their studies on, if not data?
FYI: There are tons of Linux desktop machines around my campus. What does that mean? Absolutely nothing, just like your story.
Its not based on FreeBSD. It uses parts of FreeBSD, but the bulk of the code is derived from Mach 3.x and 4.4BSD-Lite2.
This and the Quartz "Extreme" bullshit are perhaps my biggest peeves...
You know, with languages like Haskell and Clean, where you have tools that can run proofs on the code, you could eliminate many programming errors automatically, and then devote your testing time to other areas.
But people are *entitled* to do what they love and make a great living off it! I mean, they tell us the procedure to follow (high-school, college, graduate-school) and that's supposed to *guarantee* that our life will be exactly the way we want it in the future! I mean, why would they lie to us about us all being special and *entitled* to anything we want?
Yesh. What has our generation come too? I beginning to sound far too conservative for my taste, but this outsourcing thing is really getting ridiculous...
See: Lisp, Dylan, Scheme, Ruby, Python, Smalltalk, among others. These languages are all "objects all the way down" though Dylan, Ruby, and Python are more-so than Lisp and Scheme.
Those make perfect sense. There was a IE port to Solaris (mlhtml...unix) and Windows did (probably still does, just not publically) run on PPC, MIPS, and Alpha in addition to x86.
Sports programs are largely self-sustaining. Between ticket sales and TV deals and donations and whatnot, they make out pretty well.