They're complete application frameworks. They provide numerous APIs to applications in an easy to use manner for things like networking, XML parsing, inter-app communication, etc. At the user level, you get (KDE 3.2-biased, because I'm a KDE user):
- Integration: System-wide spellechecking, system-wide password handling, system-wide toolbar and menu customization, system-wide preferences handling, system-wide contacts management, etc.
- Consistency: KDevelop (a full IDE), Kate (a programmer's editor like BBEdit), and KWrite (a notepad replacement) all use the same editor widget, so you only have to learn one. Any app can embed KHTML with a few lines of code, so all apps that need to display HTML (say KMail) use the same renderer. All apps look and behave the same, and respond to the same shortcuts.
- Shared power: All KDE apps can access remote resources through KIO. Can save and load files from a remote SSH server, for example, even through a simple app like KSnapshot. All KDE apps can use mouse gestures. All KDE apps apps can be scripted with the same language. Scripting languages like Python and Javascript can access the entire KDE framework and all its modules. This means that any KDE app can easily embed a scripting program to provide more functionality.
Like I said, I don't think that ATK was a bad choice, since it was clearly the superior and most widely support technology in this case.
However, while D-BUS is modeled on KDE, its still a different technology and the KDE folks will have to go to a lot of work to integrate it. For GNOME, ATK was already integrated.
Of course, Qt-core (like glib) is being split-out in Qt4. If I don't see a Qt-core dependency in GNOME at that time, I'm going to be a pissed-off KDE user.
How does working for an outsourcing company violate this guy's morals? Not all outsourcing companies pull tricks like this to get work. On the otherhand, if your morals are "outsourcing is wrong," you have a stupid moral and should reevaluate it.
When their code stops working well, then customers will complain. Then Dell will lose sales and their management will reevaluate their policies. If they don't, they'll lose more money until a competitor figures out the problem and offers superior products.
Yes, because we'll think of something else to work on! We've done it without fail for decades now, and we can keep it up. And if we can't and other countries out-innovate us, then we deserved it.
The sad truth is that, these days, companies are run by accountants and lawyers. These are exactly the people who look at what the money does, and NOT at what happens to the world around. Nobody seems to care about 10, or 20 years down the road. As long as the cash is on the table NOW, and LOTS of it, all is good. >>>>>>>>>>> That's how capitalism works! The only thing a capitalist assumes is that corporations are motivated by profit.
Its also another example of the KDE side having to wrap GNOME C APIs because the technology transfer is going GNOME -> KDE rather than the other way around. In this case, its perfectly fine (since ATK is superior to anything KDE had), but hopefully, a lot of the superior technology of KDE will make it into GNOME. My biggest fear is that the fact that GNOME is C and C is easier to wrap will make GNOME technologies more prevalent in standards even when the KDE versions are greatly superior.
I second that. It took me a year to trudge through Fellowship, because I couldn't stand to read more than a few pages at a time. But the movies were really good.
What you are saying is happening but not the way you imagine... they got other jobs (often in the service industry) which were FAR worse (in terms of pay). >>>>>>>>>>>>>> That's not what happened here in the US. In the 1900's, most Americans worked on a farm. When the industrial revolution made farming unprofitable, those workers got better jobs in industry. When industrial jobs got shipped overseas, those people got better jobs in the services industry.
If countries A and B are trading, A can get all the benefit, or B can, or they can share it in some manner. >>>>>>>>>>> No it can't. Its a product of the mathematical model describing trade. There is no such thing as uneven trade.
Unfortunately for the poorer countries, the benefit accrues to rich countries. >>>>>>>>>>> Its not a factor of trade benifeting richer countries more than poorer countries, but growth being a function of the amount of capital, and richer countries having more capital to begin with.
The problem with the United States is not the capitalist system, but the fact that the government does not do enough income redistribution. 70% of economists believe that the government has a legitimate role in redistributing income, and that the current US imbalance needs to be fixed. Those same economists realize that international trade benifets everyone involved.
Let's try that again. Its not the CEO's who lose the $202,000, its workers in other industries that are either making lower wages or not getting hired at all. Most importantly, its an overall loss to the US GDP.
Interesting you should mention Thailand. I was actually born in Bangkok (my parents were living there at the time), and have been back many times since. You're absolutely right about the cost of living. At first, I was embarrassed about giving the bellboy a $0.50 tip, until I realized how cheap everything there was. The quality of life there certainly isn't as high as it is here, for the professional class (which anybody contracted to an American company would be a part of) in Bangkok its not that much different from parts of urban Europe. European standards of living might seem very low to Americans (most households only have a single TV!) but its an entirely livable lifestyle.
Now, as for how the United States can compete with the price of living in other countries, the simple fact is that it doesn't need to. If the cost of living in Thailand is much lower than the US, than jobs that can be exported are exported. So the US does lose hi-tech jobs. On the other hand, that creates a demand for other types of jobs in the US. For example, you'll need new people to handle the communications between the company and teams located in other countries. Its a basic economic principle that the number of jobs lost because of such events is less than the number of jobs gained. Also, remember that Thailand and a number of other asian countries have very quickly growing economies. As an economy grows, the cost of living rises. Eventually, the economy will hit a state where it is no longer profitable to export jobs to the country, because the cost of living is so high. This happened, for example, with Hong Kong, where the per-capita GDP has approached 80% of that of the United States.
Consider a real-world example (that I ripped from an economics text:) The United States has an international agreement to protect textile jobs in the United States. So far, it has saved about 79,000 textile jobs. However, adhering to that agreement costs the country about $16 billion dollars a year in lost revenue in other industries. That means for each job saved, it is costing the US economy $202,000 a year. Also consider NAFTA. When NAFTA was created, there were numerous complaints that it would destroy the US economy, because jobs would be sucked over to Mexico. While many jobs were indeed sucked over to Mexico, many new jobs were created here for Americans.
Pick up a basic economics book to realize why you're full of shit. There are few things economists agree on, or are willing to make definitive statements on, but the "exporting jobs to furriners" is one of them.
Qt is a 7MB library. Hardly megabloat. And you can make it a lot smaller than that (think Qt-Embedded). And its got three components:
1) A GUI toolkit, which don't come built into Linux and which you're going to need anyway;
2) Framework libraries and utility routines, which don't come built into Linux and which you're going to need anyway;
3) A thin C++ API over features that do come built into Linux.
So the only "bloat" there is the C++ wrapper over the features built-into Linux, which doesn't account for a huge portion of the library, and which you'll need anyway if you want a C++ interface rather than a C one.
I don't understand- do you not believe me or something? >>>>>>>>>>>>>>>&g t; No, its just that what you're saying is non-sensical.
I dunno man- addressing your comments directly, AFAIK *nothing* uses GNOME-VFS yet (and I suspect it may die a horrid sudden death). And yeah, nothing uses GConf either (registry)- but really- those ideas are ahead of their time. >>>>>>>>>>>> Not on KDE. Every app uses KConfig and every app uses KIO. KDE users use these features daily. For example, if I need to submit a big document to our central printer, I just save it directly from my program using ssh over KIO.
Those things make sense in *huge* integrated environments- sure they seem unwieldy and unneeded now >>>>>>>>>>>> KDE is a highly integrated environment, GNOME is not. That's why they are different! And KDE is not at all unwieldy or unneeded.
, but the principles they implement make sense. As for bonobo, I don't know what you're talking about. >>>>>>>>>>>>&g t; Bonobo is GNOME's answer to KParts, based on CORBA. Its over-engineered and very few apps use it because its hard to use. In contrast, tons of KDE apps use KParts because it is easy.
KDE has some of the same structures, (of those specifically, DCOP acting like Bonobo), but it just all *seems* more hacked together in a mishmash sort of way- >>>>>>>>>>>>>>>>> How is any of it hacked together? KDE is probably the *least* hacked-together desktop in existence. The UI polish is low, but that's a design factor, not a technology factor.
Like I said- I don't really see any *major* differences under the hood- the GNOME components just mentioned are (again) ahead of their time, and dont really contribute much at the moment- so things are basically in the same spot. ---------------- That's the essential difference. Those things might be ahead of their time on GNOME, but not on KDE. You're basically saying that if you ignore all the differences, GNOME and KDE are the same. Well, by your logic, MacOS X and WinXP are the same!
Menu at bottom, taskbar at bottom, quicklauch at top etc etc. >>>>>>>>>>>>>> I've got my taskbar and panel at 75% size along the bottom. I've got the application main menu, clock, and system tray at the top of the screen (like MacOS) in a panel. I've got it set to allow applications to cover the main menu or panel unless I move my mouse to a specific location (like NeXT). This buys me tons of screen real-estate, doesn't require fast reflexes like auto-hide, and still gives me fast acess to the menus. There is just no way to do this in GNOME!
Anyway- I'm not trying to start desktop enviroment war I just hink that KDE is on its way out because of the Novell+Ximian+SUSE thing, and that it's a *good* thing- because those things that are *good* about KDE will now get put in to GNOME and the "Unified U*IX Desktop" will become a feasible reality:) >>>>>>>>>>>> Screw a unified *NIX desktop. There is no way I'm giving up KDE's 21st-century features to live in GNOME's 20th century crap-hole. And I'd be surprised if any cool KDE features make it into GNOME in the next decade. The GNOME developers have basically given a "screw-you" to power users, and decided that anything that might confuse a 80-year-old grandma shouldn't be in the system.
How? There is a difference between tight coupling and tight integration. KDE apps are very loosly coupled, but tightly integrated, because they do all their communication via DCOP.
Unixware is basically the same thing as Solaris. >>>>>>>>>>> No, it isn't. They're both derived from SVR4, but all the performance insanity that Sun put into Solaris went in *after* the split.
Don't give me that crap- I've extensively used both- >>>>>>>>>>>> Keyword: "extensively." I use Linux as my only desktop OS. While KDE is my primary desktop, I try the latest GNOME every time a new one is released.
I don't think anything is particularly "killer" under KDE's hood contrasted to GNOME- >>>>>>>> KIO, DCOP, KParts, KConfig, XML-GUI, etc. While there are counterparts to most of those in GNOME, they're not really leveraged across the desktop. Its hard to find apps, for example, that really use Bonobo. Abiword-GNOME apparently doesn't use Gnome-VFS. Not many apps use GConf yet, etc. On top of that, the KDE framework libraries are tightly integrated and very powerful. The reason so many KDE apps have advanced features built-in is because it either comes free via the framework (KIO, XML-GUI), or is ridiculously easy to use (KParts, DCOP). Try developing on both systems and see what I mean.
and "default look" is a pretty weak measure of each package as a whole. >>>>>>>>>>> You just can't get KDE to look like GNOME. Take something simple like "text next to icons." KDE has an option for it, but KDE apps have so many icons that it makes the toolbar enormous. Same thing for context menus. Much longer in KDE than in GNOME. I mean, you could go and edit all the toolbars and context menus in every KDE app (because configurable KAction holders are built into the framework), but that'd be a development project in and of itself.
And I don't see how you can say they're "completely different"- each of them has a "default layout"- and each can be customized to act roughly equivalent to each other's default layouts- >>>>>>>>>> No they can't. Unless you whip up a ton of code and add-back all the features they removed in GNOME 2.x, or heavily refactor all the panel, toolbar, and menu layouts in KDE, they can't.
In my mind they're roughly equivalent in all areas, sure, KDE might do this and that better, and GNOME might do this and that better, but its all details. >>>>>>>>>> Let me guess --- you don't use either on a regular basis, right?
Slashdot Mirror
They're complete application frameworks. They provide numerous APIs to applications in an easy to use manner for things like networking, XML parsing, inter-app communication, etc. At the user level, you get (KDE 3.2-biased, because I'm a KDE user):
- Integration: System-wide spellechecking, system-wide password handling, system-wide toolbar and menu customization, system-wide preferences handling, system-wide contacts management, etc.
- Consistency: KDevelop (a full IDE), Kate (a programmer's editor like BBEdit), and KWrite (a notepad replacement) all use the same editor widget, so you only have to learn one. Any app can embed KHTML with a few lines of code, so all apps that need to display HTML (say KMail) use the same renderer. All apps look and behave the same, and respond to the same shortcuts.
- Shared power: All KDE apps can access remote resources through KIO. Can save and load files from a remote SSH server, for example, even through a simple app like KSnapshot. All KDE apps can use mouse gestures. All KDE apps apps can be scripted with the same language. Scripting languages like Python and Javascript can access the entire KDE framework and all its modules. This means that any KDE app can easily embed a scripting program to provide more functionality.
Read DeTocqueville's Democracy in America chapter 15, subsection titled "Tyranny of the Majority."
Like I said, I don't think that ATK was a bad choice, since it was clearly the superior and most widely support technology in this case.
However, while D-BUS is modeled on KDE, its still a different technology and the KDE folks will have to go to a lot of work to integrate it. For GNOME, ATK was already integrated.
Of course, Qt-core (like glib) is being split-out in Qt4. If I don't see a Qt-core dependency in GNOME at that time, I'm going to be a pissed-off KDE user.
How does working for an outsourcing company violate this guy's morals? Not all outsourcing companies pull tricks like this to get work. On the otherhand, if your morals are "outsourcing is wrong," you have a stupid moral and should reevaluate it.
When their code stops working well, then customers will complain. Then Dell will lose sales and their management will reevaluate their policies. If they don't, they'll lose more money until a competitor figures out the problem and offers superior products.
Welcome to the free market!
Yes, because we'll think of something else to work on! We've done it without fail for decades now, and we can keep it up. And if we can't and other countries out-innovate us, then we deserved it.
The sad truth is that, these days, companies are run by accountants and lawyers. These are exactly the people who look at what the money does, and NOT at what happens to the world around. Nobody seems to care about 10, or 20 years down the road. As long as the cash is on the table NOW, and LOTS of it, all is good.
>>>>>>>>>>>
That's how capitalism works! The only thing a capitalist assumes is that corporations are motivated by profit.
Its also another example of the KDE side having to wrap GNOME C APIs because the technology transfer is going GNOME -> KDE rather than the other way around. In this case, its perfectly fine (since ATK is superior to anything KDE had), but hopefully, a lot of the superior technology of KDE will make it into GNOME. My biggest fear is that the fact that GNOME is C and C is easier to wrap will make GNOME technologies more prevalent in standards even when the KDE versions are greatly superior.
Accessibility is a huge issue. Without it, KDE cannot be used for many government purposes.
I second that. It took me a year to trudge through Fellowship, because I couldn't stand to read more than a few pages at a time. But the movies were really good.
What you are saying is happening but not the way you imagine... they got other jobs (often in the service industry) which were FAR worse (in terms of pay).
>>>>>>>>>>>>>>
That's not what happened here in the US. In the 1900's, most Americans worked on a farm. When the industrial revolution made farming unprofitable, those workers got better jobs in industry. When industrial jobs got shipped overseas, those people got better jobs in the services industry.
If countries A and B are trading, A can get all the benefit, or B can, or they can share it in some manner.
>>>>>>>>>>>
No it can't. Its a product of the mathematical model describing trade. There is no such thing as uneven trade.
Unfortunately for the poorer countries, the benefit accrues to rich countries.
>>>>>>>>>>>
Its not a factor of trade benifeting richer countries more than poorer countries, but growth being a function of the amount of capital, and richer countries having more capital to begin with.
The problem with the United States is not the capitalist system, but the fact that the government does not do enough income redistribution. 70% of economists believe that the government has a legitimate role in redistributing income, and that the current US imbalance needs to be fixed. Those same economists realize that international trade benifets everyone involved.
They put POSIX into NT to satisfy government requirements, but its not usable. It has no networking, no mmap'ed files, no modern features at all.
2k was solid, but XP is pretty flaky. NT-based kernels have stopped crashing, but I can make Explorer crash just trying to view a CIFS share.
Let's try that again. Its not the CEO's who lose the $202,000, its workers in other industries that are either making lower wages or not getting hired at all. Most importantly, its an overall loss to the US GDP.
Its not the CEO's making that extra $202,000. Its workers in other industries that either are making lower wages or not getting hired at all.
Interesting you should mention Thailand. I was actually born in Bangkok (my parents were living there at the time), and have been back many times since. You're absolutely right about the cost of living. At first, I was embarrassed about giving the bellboy a $0.50 tip, until I realized how cheap everything there was. The quality of life there certainly isn't as high as it is here, for the professional class (which anybody contracted to an American company would be a part of) in Bangkok its not that much different from parts of urban Europe. European standards of living might seem very low to Americans (most households only have a single TV!) but its an entirely livable lifestyle.
:) The United States has an international agreement to protect textile jobs in the United States. So far, it has saved about 79,000 textile jobs. However, adhering to that agreement costs the country about $16 billion dollars a year in lost revenue in other industries. That means for each job saved, it is costing the US economy $202,000 a year. Also consider NAFTA. When NAFTA was created, there were numerous complaints that it would destroy the US economy, because jobs would be sucked over to Mexico. While many jobs were indeed sucked over to Mexico, many new jobs were created here for Americans.
Now, as for how the United States can compete with the price of living in other countries, the simple fact is that it doesn't need to. If the cost of living in Thailand is much lower than the US, than jobs that can be exported are exported. So the US does lose hi-tech jobs. On the other hand, that creates a demand for other types of jobs in the US. For example, you'll need new people to handle the communications between the company and teams located in other countries. Its a basic economic principle that the number of jobs lost because of such events is less than the number of jobs gained. Also, remember that Thailand and a number of other asian countries have very quickly growing economies. As an economy grows, the cost of living rises. Eventually, the economy will hit a state where it is no longer profitable to export jobs to the country, because the cost of living is so high. This happened, for example, with Hong Kong, where the per-capita GDP has approached 80% of that of the United States.
Consider a real-world example (that I ripped from an economics text
Pick up a basic economics book to realize why you're full of shit. There are few things economists agree on, or are willing to make definitive statements on, but the "exporting jobs to furriners" is one of them.
The Samsung SCH i519 runs Qt/Embedded on Linux, and the official SDK is a Linux machine running KDevelop :)
w00t!
Qt is a 7MB library. Hardly megabloat. And you can make it a lot smaller than that (think Qt-Embedded). And its got three components:
1) A GUI toolkit, which don't come built into Linux and which you're going to need anyway;
2) Framework libraries and utility routines, which don't come built into Linux and which you're going to need anyway;
3) A thin C++ API over features that do come built into Linux.
So the only "bloat" there is the C++ wrapper over the features built-into Linux, which doesn't account for a huge portion of the library, and which you'll need anyway if you want a C++ interface rather than a C one.
I don't understand- do you not believe me or something?
:)
>>>>>>>>>>>>>>>&g t;
No, its just that what you're saying is non-sensical.
I dunno man- addressing your comments directly, AFAIK *nothing* uses GNOME-VFS yet (and I suspect it may die a horrid sudden death). And yeah, nothing uses GConf either (registry)- but really- those ideas are ahead of their time.
>>>>>>>>>>>>
Not on KDE. Every app uses KConfig and every app uses KIO. KDE users use these features daily. For example, if I need to submit a big document to our central printer, I just save it directly from my program using ssh over KIO.
Those things make sense in *huge* integrated environments- sure they seem unwieldy and unneeded now
>>>>>>>>>>>>
KDE is a highly integrated environment, GNOME is not. That's why they are different! And KDE is not at all unwieldy or unneeded.
, but the principles they implement make sense. As for bonobo, I don't know what you're talking about.
>>>>>>>>>>>>&g t;
Bonobo is GNOME's answer to KParts, based on CORBA. Its over-engineered and very few apps use it because its hard to use. In contrast, tons of KDE apps use KParts because it is easy.
KDE has some of the same structures, (of those specifically, DCOP acting like Bonobo), but it just all *seems* more hacked together in a mishmash sort of way-
>>>>>>>>>>>>>>>>>
How is any of it hacked together? KDE is probably the *least* hacked-together desktop in existence. The UI polish is low, but that's a design factor, not a technology factor.
Like I said- I don't really see any *major* differences under the hood- the GNOME components just mentioned are (again) ahead of their time, and dont really contribute much at the moment- so things are basically in the same spot.
----------------
That's the essential difference. Those things might be ahead of their time on GNOME, but not on KDE. You're basically saying that if you ignore all the differences, GNOME and KDE are the same. Well, by your logic, MacOS X and WinXP are the same!
Menu at bottom, taskbar at bottom, quicklauch at top etc etc.
>>>>>>>>>>>>>>
I've got my taskbar and panel at 75% size along the bottom. I've got the application main menu, clock, and system tray at the top of the screen (like MacOS) in a panel. I've got it set to allow applications to cover the main menu or panel unless I move my mouse to a specific location (like NeXT). This buys me tons of screen real-estate, doesn't require fast reflexes like auto-hide, and still gives me fast acess to the menus. There is just no way to do this in GNOME!
Anyway- I'm not trying to start desktop enviroment war I just hink that KDE is on its way out because of the Novell+Ximian+SUSE thing, and that it's a *good* thing- because those things that are *good* about KDE will now get put in to GNOME and the "Unified U*IX Desktop" will become a feasible reality
>>>>>>>>>>>>
Screw a unified *NIX desktop. There is no way I'm giving up KDE's 21st-century features to live in GNOME's 20th century crap-hole. And I'd be surprised if any cool KDE features make it into GNOME in the next decade. The GNOME developers have basically given a "screw-you" to power users, and decided that anything that might confuse a 80-year-old grandma shouldn't be in the system.
How? There is a difference between tight coupling and tight integration. KDE apps are very loosly coupled, but tightly integrated, because they do all their communication via DCOP.
Are you joking me about those differential equations? None of the people involved know any math! They all majored in a liberal art in college :)
The sad thing that its not even his post... It's an old troll from dot.kde.org that's been recycled a few times over there too.
Unixware is basically the same thing as Solaris.
>>>>>>>>>>>
No, it isn't. They're both derived from SVR4, but all the performance insanity that Sun put into Solaris went in *after* the split.
Don't give me that crap- I've extensively used both-
>>>>>>>>>>>>
Keyword: "extensively." I use Linux as my only desktop OS. While KDE is my primary desktop, I try the latest GNOME every time a new one is released.
I don't think anything is particularly "killer" under KDE's hood contrasted to GNOME-
>>>>>>>>
KIO, DCOP, KParts, KConfig, XML-GUI, etc. While there are counterparts to most of those in GNOME, they're not really leveraged across the desktop. Its hard to find apps, for example, that really use Bonobo. Abiword-GNOME apparently doesn't use Gnome-VFS. Not many apps use GConf yet, etc. On top of that, the KDE framework libraries are tightly integrated and very powerful. The reason so many KDE apps have advanced features built-in is because it either comes free via the framework (KIO, XML-GUI), or is ridiculously easy to use (KParts, DCOP). Try developing on both systems and see what I mean.
and "default look" is a pretty weak measure of each package as a whole.
>>>>>>>>>>>
You just can't get KDE to look like GNOME. Take something simple like "text next to icons." KDE has an option for it, but KDE apps have so many icons that it makes the toolbar enormous. Same thing for context menus. Much longer in KDE than in GNOME. I mean, you could go and edit all the toolbars and context menus in every KDE app (because configurable KAction holders are built into the framework), but that'd be a development project in and of itself.
And I don't see how you can say they're "completely different"- each of them has a "default layout"- and each can be customized to act roughly equivalent to each other's default layouts-
>>>>>>>>>>
No they can't. Unless you whip up a ton of code and add-back all the features they removed in GNOME 2.x, or heavily refactor all the panel, toolbar, and menu layouts in KDE, they can't.
In my mind they're roughly equivalent in all areas, sure, KDE might do this and that better, and GNOME might do this and that better, but its all details.
>>>>>>>>>>
Let me guess --- you don't use either on a regular basis, right?