Trolltech had to recreate the Aqua look for Qt (the GUI toolkit, not QuickTime), since Qt emulates the look of the native system rather than wrapping. Like all other QStyles, there is probably close to no platform specific code in the engine. Unfortunately, only the Qt/Mac release will feature this style, as it apparently would go against "Apple rules" to distribute this into other Qt releases, like X11. So I guess it is ok to emulate the Aqua look as long as you are going to run on the Apple platform. That or Apple specifically granted Trolltech this permission, as Trolltech has mentioned they "coordinated with Apple" to make Qt/Mac.
While I have suspected Qt/Mac will not be GPL for other reasons, I believe this is a really strong reason as to why it won't be. If it were GPL, then any coder could just snag the style and compile with X11. Why mess with pixmap styles when you have close to the real-deal as a rendering engine?
Re:Last stable release until February
on
KDE 2.2.1 Up
·
· Score: 2
Hmm, don't "notorious" and "notoriety" (maybe I spelled that wrong) come from the same root? I actually did hesitate before posting, but then I remembered "notoriety" is a good thing.
Even though 0.1+ releases of KDE are more significant, the 0.0.1+ releases should not be ignored. They are the "clean up". There was 2.0, then 2.0.1, then 2.1, then 2.1.1, then 2.2, and now 2.2.1. There is always a follow-up 0.0.1 release, and if you use KDE you really should upgrade. The KDE team is good about fixing bugs.
Last stable release until February
on
KDE 2.2.1 Up
·
· Score: 5, Informative
According to this release plan, KDE 2.2.1 will be the last stable KDE release for quite some time. Planned for release in February is KDE3.0, which will essentially be the same 2.x architecture but based on Qt 3.0. They are going to call it KDE3.0 mainly because it will break binary compatibility with 2.x. It will not be a rewrite like KDE2 was.
Of course, KDE is notorious for frequent releases, so I would imagine there will be betas / release candidates every 6 weeks or so until the final 3.0.
I suppose I am, and I do use it. I am not afraid to learn something new, however. I am genuinely interested in what is good about GNUStep. My post had an argumentative tone (which now carried into your post) because the article mentioned its use as a cross-platform library. Not that there can't be more than one good cross-platform library, but I think Qt is probably the best choice at the moment. With 3.0, I think we'll begin to see major application providers (like perhaps Adobe) consider using it, even if they never intend on Linux ports.
I don't think I jumped the gun by saying Qt is viable for MacOS X development. It is already very good on Windows and X11. Trolltech has planned on 3.0 being "release quality" next month, and I don't doubt the Mac support will be very good considering their history.
Let me know when I can run your applications on my platform
I have good faith in Qt/Mac. If I actually had OS X, I would probably have grabbed the open beta. I do plan on porting one of my apps to OS X when I am ready.
Why would I want to develop crossplatform applications with GNUStep, when I can use Qt 3.0? Qt supports Windows, MacOS X, Unix/X11, and Embedded. Apps have the look and feel of the native platform (unlike GTK), and no power/speed is sacrificed because the look is emulated, not wrapped (unlike wxWindows). All this using the proven C++ language. This is not vaporware folks. Each supported platform is just that: fully supported and stable.
I can't compare it to the OS X API's, since I have never programmed for a Mac, but doing Qt programming has been easier than anything else I've tried. Check out this page, where customers, some from high-profile companies, sing praise about why they prefer Qt to other alternatives / native toolkits.
Besides the obvious cost of using Qt for commercial development (which should only be a financial issue for individual developers, not companies), what good reason is there to use anything else?
``Palm is going to be bringing out a new operating system... the belief is they'll have it done by the end of next year,'' he said. ``But it's hard to ship those things on time. It could take years, and Palm doesn't have years.''
Ok, so the trend is overpowerful PDAs to replace your desktop? If you want to use a PDA with desktop-like applications, why not use a Linux PDA with Qt Palmtop Environment? It's GPL and you can download it from the site. "Just add Linux and stir" it says on the page. Use Konq Embedded while you're at it, which is also complete. No vaporware here! Of course, you need a capable PDA to run these on. Hehe, are those available?:) Maybe iPAQ?
Oh and...
``The thing that impressed me the most is that it's a full Outlook client,'' he said, meaning the computer can have receive e-mail without relying on a desktop or laptop computer."
Golly gee. You could've received email with other PDAs for years too, like the Psions. Too bad they never got the recognition they deserve here in the states. At least with the built-in keyboard you could actually compose meaningful replies. Now that's power.
Developers who accept patches could just consider the patches as public domain contributions in order to avoid this problem.
For instance, if I ever got a patch from someone for one of my programs, I would only accept it under the condition that I gain ownership of the submitted code. No way am I losing my ownership over a 3 line patch. Only if the changes are huge would consider joint ownership of the program.
As another reply pointed out, OS/2 apparently doesn't run in VMWare. I really can't explain this because I don't use OS/2, but I would attempt to guess that OS/2 does some really wacky things. My PC's setup utility has an option that includes OS/2. It's the only OS-specific option in my entire BIOS menu! Can anyone shed some light on why OS/2 is "special" ?
Anyway, I would classify this as a hardware incompatibility, which is what I mentioned as a VMWare Con. And if OS/2 (or any similar non-working OS for VMWare) didn't exist, you could simply make a Linux bootdisk that crashes if USB is not found and call it an OS. Maybe I shouldn't have been so broad in a statement that could be voided so easily.
How about: VMWare will run anything x86 as long as it obeys VMWare's hardware/bios compatibilities.
It does not run in a self-contained window (whatever that means).
Funny how you should mention you don't know what I mean and yet still disagree with me at the same time. VMWare runs the VM session it its own window. Compared to WINE, this gives the effect of having your Windows applications self-contained in a single window.
Well you really have two approaches in the current crop of programs for "emulating Windows". I'll narrow them down to two applications: VMWare and WINE. VMWare can actually run any x86 OS, not just Windows, but for sake of argument we'll assume we're working with Windows.
VMWare Pros:
Emulates an x86 and much of its hardware
Zero software incompatibilities
VMWare Cons:
Slow
Some hardware incompatibilities (VMWare doesn't have 3D support, for instance)
Runs in a self-contained window
WINE Pros:
Fast
Lots of hardware support, including DirectX acceleration and 3D.
Applications run as native apps
WINE Cons:
Many software incompatibilities
So there you have it. Problems in one are generally made up in the other. This isn't to say that these programs will have such "Cons" for all time, but this is how it stands now. Ironically, VMWare does a simpler task (emulating x86 instead of emulating Windows directly) and winds up with more compatibility.
For me, I use VMWare to run any necessary Windows applications. I don't play games on my PC at all, so this works perfectly. There is absolutely no reason for me to ever dual boot. I can run IE, Media Player, etc. It all works without a hitch. Granted, VMWare is not free, but $100 wasn't much for me considering I haven't spent much on Linux software anyway.
The only odd-men-out are PC gamers. Damn games! Here's to hoping Loki can pull through.
Actually, if you have a GPS receiver you could contact your home government and give them your coordinates to within a meter. That's more information than most 911 operators have to go on. But would you stay alive long enough for help to arrive?
While you may not enjoy programming in your spare time, I do. For me, it's my way of recreation. So yes, I, and the many many others, will continue to "write that free software." We're not necessarily writing it for you in particular, but I hope you like it.
If software is to be free, then who can we expect to write it.
I dunno, me? I enjoy writing programs. I want to give them away for free. I enjoy this because free software helps the world.
You forget that some programmers enjoy programming as a hobby. I'm definitely not the only one. So who will write this free software? Everyone, of course. 99% of the free software out there is written by hobbyists.
Parsing XML isn't as bad as you think, especially with the availability of libraries. Understanding the protocol is loads easier when everything you get is plaintext XML. I think this is one of the positive sides to Jabber.
As an open source project, you should understand why it has taken them so long. Developing a client is one thing, but developing an IM system takes much more work. Compare it to writing the first mail server.
Anyway, it's much more mature today than ever. The main faults are: lack of good clients (which I am trying to fix), and transport instability. The instability generally comes from IP blocks by AOL to the jabber.org server. This can be solved by simply running your own server, which is the whole point of Jabber anyway.
At this point in time, my day-to-day IM consists of a private Jabber server, the AIM and ICQ transports, and the client I wrote. It's a proven system at this point. I say we run with it, rather than try to create something new again.
There's nothing particularly wrong with single-signon, just so as long it is done securely and the data of everyone on the planet isn't stored in one bank. Users are going to like the convience that Passport provides. Thus, we need a good alternative.
I found this, which discusses a way of doing a Passport-like identification over Jabber, dubbed "Jident". Maybe this, or something like it, could be implemented as a proper open-source/distributed counter to Passport.
Jabber is definitely what the world should be using instead of this new "Windows Messenger". Perhaps an alternative to Passport could be added/layered to it as well? Definitely check out that Jident page, especially the bottom where it lays out the pros and cons (and a neat scenario).
Maybe something like this will be discussed at JabberCon.
I probably worded the part about cell phones badly, but I believe if you reread the sentence you would still see what I meant: cell phone companies sell phones for a high price normally, but lower the price if you pay for service. Metricom doesn't do this. They don't offer the modems for full price. They offer the modems for a discounted price, assuming you will pay for service later. This is a much bigger risk because the modems are actually useful without service, while cell phone carriers know you can't really do anything until you come crawling to them for cell service.
The beef I have with Metricom is this:
a) I buy two modems
b) They work on their own just fine in non-Metricom territory.
c) They fail to operate in Metricom territory.
I don't even live in Metricom territory, but I am just close enough to a city that _is_ covered and so I am affected. If the Fry's I had purchased the modems from was just a few more miles away, I probably wouldn't have needed to write that web page.
I know Metricom has a business to run, but there are better ways to handle these situations. First of all, they could have just stopped building modems with peer-to-peer support (it was definitely an engineering decision to include it, not a management one). Instead, they try to block it via their network nameserver. As it stands, it almost looks like Metricom is sabotaging nearby P2P networks. It works fine in one area, but not another. Perhaps I should have built my own nameserver system for my modems to use. But what if Metricom subscribers near me started using my nameserver instead of Metricom's? Ick, what a situation that would be. And then who is right?
It's a range/speed tradeoff. Ricochet modems have been known to operate at least a mile in most cases. My own tests prove this true, and I can't get near that range with my 802.11 cards.
I've also heard stories (from Metricom representatives before they went anti-P2P) of cases where people have achieved up to 10 miles in areas with no obstructions; ie, when used over water, plains, or to link two tall buildings.
They both made a very critical mistake early on that falls along the lines of this statement:
"Lets build our desktop to look like Windows, because thats what people are used to."
Wrong. I can't speak for GNOME, but for KDE let me rephrase:
"Let's build the best desktop possible for developers (us) and users alike, modeled after both present functionality and new ideas."
it immediately commits you (and your project) to a life of constantly playing second fiddle..
Open source projects don't care about taking ideas. They take and they add. KDE has a launch button and task bar, made famous by Win95. It also has a desktop menubar, popularized by MacOS. Minimizing, shading, dockapp swallowing, system tray, desktop icons, multiple desktops. It's all there. Anything cool you've ever used, and then some, is there. Here's a recent scenario: a coder is sitting at his computer wishing he had a sidebar in Konqueror -- you know, something like what is in Internet Explorer 6 and Mozilla. Does he live the rest of his life without such a feature? Making some sort of sacrifice to use Linux? Of course not! He duplicates the feature in Konqueror. The point is that it doesn't matter where the idea comes from. If it is useful, it is added. That's how Open Source projects work.
Rather than try out new ideas, take a few risks here and there, and rethink the ways in which things have always been done, they both followed like puppy dogs into the same bloody mess. Now both are stuck. The defacto standard Linux GUI is now roughly equivalent to a Windows desktop from seven years ago. Clap at your leisure.
Right... and could you open a remote file from within the included Windows text editor 7 years ago? And would selecting the "save" option cause it to be uploaded back to the remote location? Did you have a command prompt that supported scrollback and multiple tabbed sessions? Could you disable popup windows, but keep the rest of Javascript in your web browser? Could you log your windowing events to stderr? Can you do any of this with even the latest version of Windows? I think not.
refine that departure into a stable, usable, likeable model. They didn't do that. Now they're paying the price, and have no one to blame but themselves.
The KDE libraries are a desktop perfection. I fail to see this price they are paying.
As a long-time unix developer, I love the command-line. But I also love KDE. No one says you can't use both at the same time. Konsole is one of the best applications that come with KDE.
While most of KDE is easy to use without touching the manual, it doesn't mean it is dumbed down. KDE 2.x stays true to its unix roots, and I would consider it essential software (ie a "major part") of any unix workstation.
Yes, the current system works, but it is not ideal. I don't hate Microsoft or AOL. They have done a great job in promoting IM. There's nothing wrong with using these systems either. The problem I have with their systems, as do all other Jabber developers, is that we think we can make a better one.
We don't consider Jabber a YAIMS (yet-another-IM-system). Odigo is YAIMS. What makes Jabber unique is the open/distributed nature. It's the only IM protocol that has a snowball's chance at being accepted as an RFC standard. Maybe one day in the future, ISP's will give you a free Jabber account along with your POP3 email. They can't do this with AIM or MSN or even ICQ, and none of these systems have such aspirations. We're trying to change the world here. It may be a longshot, but we can dream can't we?
Please don't discount Jabber just because it is not entirely ready for prime time. We're working on it!
Obviously you don't seem to have a problem with the fact that ICQ, MSN, and AIM are all closed systems with a central server. You can throw Odigo in there while you're at it. Each of these systems are against the original spirit of core Internet protocols, which is to be open and distributed.
Jabber is has created an open _decentralized_ standard, something you will never see coming from any of these other companies. Maybe you don't care that all of your conversation and personal data goes through these central systems? Maybe you don't mind the single point of failure in these systems? Will you be using MS Passport too?
It's all a matter of what you care about. A lot of people are content with "what works." For others, that's not enough.
Slashdot Mirror
Trolltech had to recreate the Aqua look for Qt (the GUI toolkit, not QuickTime), since Qt emulates the look of the native system rather than wrapping. Like all other QStyles, there is probably close to no platform specific code in the engine. Unfortunately, only the Qt/Mac release will feature this style, as it apparently would go against "Apple rules" to distribute this into other Qt releases, like X11. So I guess it is ok to emulate the Aqua look as long as you are going to run on the Apple platform. That or Apple specifically granted Trolltech this permission, as Trolltech has mentioned they "coordinated with Apple" to make Qt/Mac.
While I have suspected Qt/Mac will not be GPL for other reasons, I believe this is a really strong reason as to why it won't be. If it were GPL, then any coder could just snag the style and compile with X11. Why mess with pixmap styles when you have close to the real-deal as a rendering engine?
Hmm, don't "notorious" and "notoriety" (maybe I spelled that wrong) come from the same root? I actually did hesitate before posting, but then I remembered "notoriety" is a good thing.
Ah well =)
You're right, it's not the kernel. It's actually more important than the kernel.
Even though 0.1+ releases of KDE are more significant, the 0.0.1+ releases should not be ignored. They are the "clean up". There was 2.0, then 2.0.1, then 2.1, then 2.1.1, then 2.2, and now 2.2.1. There is always a follow-up 0.0.1 release, and if you use KDE you really should upgrade. The KDE team is good about fixing bugs.
According to this release plan, KDE 2.2.1 will be the last stable KDE release for quite some time. Planned for release in February is KDE3.0, which will essentially be the same 2.x architecture but based on Qt 3.0. They are going to call it KDE3.0 mainly because it will break binary compatibility with 2.x. It will not be a rewrite like KDE2 was.
Of course, KDE is notorious for frequent releases, so I would imagine there will be betas / release candidates every 6 weeks or so until the final 3.0.
Happy downloading/compiling/etc!
Why use anything? If you're ga-ga for Qt, use it.
I suppose I am, and I do use it. I am not afraid to learn something new, however. I am genuinely interested in what is good about GNUStep. My post had an argumentative tone (which now carried into your post) because the article mentioned its use as a cross-platform library. Not that there can't be more than one good cross-platform library, but I think Qt is probably the best choice at the moment. With 3.0, I think we'll begin to see major application providers (like perhaps Adobe) consider using it, even if they never intend on Linux ports.
I don't think I jumped the gun by saying Qt is viable for MacOS X development. It is already very good on Windows and X11. Trolltech has planned on 3.0 being "release quality" next month, and I don't doubt the Mac support will be very good considering their history.
Let me know when I can run your applications on my platform
I have good faith in Qt/Mac. If I actually had OS X, I would probably have grabbed the open beta. I do plan on porting one of my apps to OS X when I am ready.
Why would I want to develop crossplatform applications with GNUStep, when I can use Qt 3.0? Qt supports Windows, MacOS X, Unix/X11, and Embedded. Apps have the look and feel of the native platform (unlike GTK), and no power/speed is sacrificed because the look is emulated, not wrapped (unlike wxWindows). All this using the proven C++ language. This is not vaporware folks. Each supported platform is just that: fully supported and stable.
I can't compare it to the OS X API's, since I have never programmed for a Mac, but doing Qt programming has been easier than anything else I've tried. Check out this page, where customers, some from high-profile companies, sing praise about why they prefer Qt to other alternatives / native toolkits.
Besides the obvious cost of using Qt for commercial development (which should only be a financial issue for individual developers, not companies), what good reason is there to use anything else?
``Palm is going to be bringing out a new operating system ... the belief is they'll have it done by the end of next year,'' he said. ``But it's hard to ship those things on time. It could take years, and Palm doesn't have years.''
:) Maybe iPAQ?
Ok, so the trend is overpowerful PDAs to replace your desktop? If you want to use a PDA with desktop-like applications, why not use a Linux PDA with Qt Palmtop Environment? It's GPL and you can download it from the site. "Just add Linux and stir" it says on the page. Use Konq Embedded while you're at it, which is also complete. No vaporware here! Of course, you need a capable PDA to run these on. Hehe, are those available?
Oh and...
``The thing that impressed me the most is that it's a full Outlook client,'' he said, meaning the computer can have receive e-mail without relying on a desktop or laptop computer."
Golly gee. You could've received email with other PDAs for years too, like the Psions. Too bad they never got the recognition they deserve here in the states. At least with the built-in keyboard you could actually compose meaningful replies. Now that's power.
When your code is on center stage you want it to look good.
Developers who accept patches could just consider the patches as public domain contributions in order to avoid this problem.
For instance, if I ever got a patch from someone for one of my programs, I would only accept it under the condition that I gain ownership of the submitted code. No way am I losing my ownership over a 3 line patch. Only if the changes are huge would consider joint ownership of the program.
-Justin
VMware does NOT run any x86 OS
As another reply pointed out, OS/2 apparently doesn't run in VMWare. I really can't explain this because I don't use OS/2, but I would attempt to guess that OS/2 does some really wacky things. My PC's setup utility has an option that includes OS/2. It's the only OS-specific option in my entire BIOS menu! Can anyone shed some light on why OS/2 is "special" ?
Anyway, I would classify this as a hardware incompatibility, which is what I mentioned as a VMWare Con. And if OS/2 (or any similar non-working OS for VMWare) didn't exist, you could simply make a Linux bootdisk that crashes if USB is not found and call it an OS. Maybe I shouldn't have been so broad in a statement that could be voided so easily.
How about: VMWare will run anything x86 as long as it obeys VMWare's hardware/bios compatibilities.
It does not run in a self-contained window (whatever that means).
Funny how you should mention you don't know what I mean and yet still disagree with me at the same time. VMWare runs the VM session it its own window. Compared to WINE, this gives the effect of having your Windows applications self-contained in a single window.
VMWare Pros:
- Emulates an x86 and much of its hardware
- Zero software incompatibilities
VMWare Cons:- Slow
- Some hardware incompatibilities (VMWare doesn't have 3D support, for instance)
- Runs in a self-contained window
WINE Pros:- Fast
- Lots of hardware support, including DirectX acceleration and 3D.
- Applications run as native apps
WINE Cons:So there you have it. Problems in one are generally made up in the other. This isn't to say that these programs will have such "Cons" for all time, but this is how it stands now. Ironically, VMWare does a simpler task (emulating x86 instead of emulating Windows directly) and winds up with more compatibility.
For me, I use VMWare to run any necessary Windows applications. I don't play games on my PC at all, so this works perfectly. There is absolutely no reason for me to ever dual boot. I can run IE, Media Player, etc. It all works without a hitch. Granted, VMWare is not free, but $100 wasn't much for me considering I haven't spent much on Linux software anyway.
The only odd-men-out are PC gamers. Damn games! Here's to hoping Loki can pull through.
Actually, if you have a GPS receiver you could contact your home government and give them your coordinates to within a meter. That's more information than most 911 operators have to go on. But would you stay alive long enough for help to arrive?
Was that a sarcastic comment?
While you may not enjoy programming in your spare time, I do. For me, it's my way of recreation. So yes, I, and the many many others, will continue to "write that free software." We're not necessarily writing it for you in particular, but I hope you like it.
If software is to be free, then who can we expect to write it.
I dunno, me? I enjoy writing programs. I want to give them away for free. I enjoy this because free software helps the world.
You forget that some programmers enjoy programming as a hobby. I'm definitely not the only one. So who will write this free software? Everyone, of course. 99% of the free software out there is written by hobbyists.
-Justin
Psi - an ICQ-like Jabber client
Parsing XML isn't as bad as you think, especially with the availability of libraries. Understanding the protocol is loads easier when everything you get is plaintext XML. I think this is one of the positive sides to Jabber.
As an open source project, you should understand why it has taken them so long. Developing a client is one thing, but developing an IM system takes much more work. Compare it to writing the first mail server.
Anyway, it's much more mature today than ever. The main faults are: lack of good clients (which I am trying to fix), and transport instability. The instability generally comes from IP blocks by AOL to the jabber.org server. This can be solved by simply running your own server, which is the whole point of Jabber anyway.
At this point in time, my day-to-day IM consists of a private Jabber server, the AIM and ICQ transports, and the client I wrote. It's a proven system at this point. I say we run with it, rather than try to create something new again.
-Justin
There's nothing particularly wrong with single-signon, just so as long it is done securely and the data of everyone on the planet isn't stored in one bank. Users are going to like the convience that Passport provides. Thus, we need a good alternative.
I found this, which discusses a way of doing a Passport-like identification over Jabber, dubbed "Jident". Maybe this, or something like it, could be implemented as a proper open-source/distributed counter to Passport.
Jabber is definitely what the world should be using instead of this new "Windows Messenger". Perhaps an alternative to Passport could be added/layered to it as well? Definitely check out that Jident page, especially the bottom where it lays out the pros and cons (and a neat scenario).
Maybe something like this will be discussed at JabberCon.
-Justin
I probably worded the part about cell phones badly, but I believe if you reread the sentence you would still see what I meant: cell phone companies sell phones for a high price normally, but lower the price if you pay for service. Metricom doesn't do this. They don't offer the modems for full price. They offer the modems for a discounted price, assuming you will pay for service later. This is a much bigger risk because the modems are actually useful without service, while cell phone carriers know you can't really do anything until you come crawling to them for cell service.
The beef I have with Metricom is this:
a) I buy two modems
b) They work on their own just fine in non-Metricom territory.
c) They fail to operate in Metricom territory.
I don't even live in Metricom territory, but I am just close enough to a city that _is_ covered and so I am affected. If the Fry's I had purchased the modems from was just a few more miles away, I probably wouldn't have needed to write that web page.
I know Metricom has a business to run, but there are better ways to handle these situations. First of all, they could have just stopped building modems with peer-to-peer support (it was definitely an engineering decision to include it, not a management one). Instead, they try to block it via their network nameserver. As it stands, it almost looks like Metricom is sabotaging nearby P2P networks. It works fine in one area, but not another. Perhaps I should have built my own nameserver system for my modems to use. But what if Metricom subscribers near me started using my nameserver instead of Metricom's? Ick, what a situation that would be. And then who is right?
Around a mile or more, depending on obstructions. See my other reply in this thread.
It's a range/speed tradeoff. Ricochet modems have been known to operate at least a mile in most cases. My own tests prove this true, and I can't get near that range with my 802.11 cards.
I've also heard stories (from Metricom representatives before they went anti-P2P) of cases where people have achieved up to 10 miles in areas with no obstructions; ie, when used over water, plains, or to link two tall buildings.
-Justin
They sucked anyway.
'course, if they are truly going to pack up and go home, maybe it's time to head to Fry's and stock up?
Konqueror in KDE2.2 has the option to prompt you before opening popups. This allows you to get the best of both worlds.
They both made a very critical mistake early on that falls along the lines of this statement:
"Lets build our desktop to look like Windows, because thats what people are used to."
Wrong. I can't speak for GNOME, but for KDE let me rephrase:
"Let's build the best desktop possible for developers (us) and users alike, modeled after both present functionality and new ideas."
it immediately commits you (and your project) to a life of constantly playing second fiddle..
Open source projects don't care about taking ideas. They take and they add. KDE has a launch button and task bar, made famous by Win95. It also has a desktop menubar, popularized by MacOS. Minimizing, shading, dockapp swallowing, system tray, desktop icons, multiple desktops. It's all there. Anything cool you've ever used, and then some, is there. Here's a recent scenario: a coder is sitting at his computer wishing he had a sidebar in Konqueror -- you know, something like what is in Internet Explorer 6 and Mozilla. Does he live the rest of his life without such a feature? Making some sort of sacrifice to use Linux? Of course not! He duplicates the feature in Konqueror. The point is that it doesn't matter where the idea comes from. If it is useful, it is added. That's how Open Source projects work.
Rather than try out new ideas, take a few risks here and there, and rethink the ways in which things have always been done, they both followed like puppy dogs into the same bloody mess. Now both are stuck. The defacto standard Linux GUI is now roughly equivalent to a Windows desktop from seven years ago. Clap at your leisure.
Right... and could you open a remote file from within the included Windows text editor 7 years ago? And would selecting the "save" option cause it to be uploaded back to the remote location? Did you have a command prompt that supported scrollback and multiple tabbed sessions? Could you disable popup windows, but keep the rest of Javascript in your web browser? Could you log your windowing events to stderr? Can you do any of this with even the latest version of Windows? I think not.
refine that departure into a stable, usable, likeable model. They didn't do that. Now they're paying the price, and have no one to blame but themselves.
The KDE libraries are a desktop perfection. I fail to see this price they are paying.
Proudly posted from Konqueror.
-Justin
Psi - ICQ-like Jabber client
As a long-time unix developer, I love the command-line. But I also love KDE. No one says you can't use both at the same time. Konsole is one of the best applications that come with KDE.
While most of KDE is easy to use without touching the manual, it doesn't mean it is dumbed down. KDE 2.x stays true to its unix roots, and I would consider it essential software (ie a "major part") of any unix workstation.
Yes, the current system works, but it is not ideal. I don't hate Microsoft or AOL. They have done a great job in promoting IM. There's nothing wrong with using these systems either. The problem I have with their systems, as do all other Jabber developers, is that we think we can make a better one.
We don't consider Jabber a YAIMS (yet-another-IM-system). Odigo is YAIMS. What makes Jabber unique is the open/distributed nature. It's the only IM protocol that has a snowball's chance at being accepted as an RFC standard. Maybe one day in the future, ISP's will give you a free Jabber account along with your POP3 email. They can't do this with AIM or MSN or even ICQ, and none of these systems have such aspirations. We're trying to change the world here. It may be a longshot, but we can dream can't we?
Please don't discount Jabber just because it is not entirely ready for prime time. We're working on it!
-Justin
Psi - ICQ-like Jabber client
Obviously you don't seem to have a problem with the fact that ICQ, MSN, and AIM are all closed systems with a central server. You can throw Odigo in there while you're at it. Each of these systems are against the original spirit of core Internet protocols, which is to be open and distributed.
Jabber is has created an open _decentralized_ standard, something you will never see coming from any of these other companies. Maybe you don't care that all of your conversation and personal data goes through these central systems? Maybe you don't mind the single point of failure in these systems? Will you be using MS Passport too?
It's all a matter of what you care about. A lot of people are content with "what works." For others, that's not enough.