IBM Picks Qtopia Over PalmOS And PocketPC

Bill Kendrick writes "ZDNet, Geek.com and others are reporting IBM's decision to choose Trolltech's Qtopia (the embedded version of their Qt library, used by the Sharp Zaurus PDA) in their forthcoming devices. See the announcement at Trolltech's website, and an earlier press release at IBM.com." Here's an earlier post about the new IBM reference platform.

Comments

Quite a shift

[creative_name]

I'd say IBM has made quite a shift since its inception. Moving from massive, room-filling mainframes to miniature gigabyte pocket drives and Qt-toting PDAs. It's nice to see that ol' Big Blue can still jump through the ever-moving hoops of technology.

Go Trolltech!

[Anonymous Coward]

The trolls have given back a lot to the Linux community. KDE would be nowhere without Qt. Dual licensing seems to be one of the few open source business models that actually work (unfortunately, mostly for libraries). Plus, Qtopia is a great platform to work with, so good lock to Trolltech.

Re:Still no sync for Mac

[Wesley Felter]

Hopefully Trolltech/IBM will support the standard SyncML protocol, which would give them iSync support "for free".

Re:X-less QT

[BESTouff]

Here we go ! I was wondering how long before the first clueless anti-X cluebie would post its rant. Guys, there have already been tons of arguments on this very subject, and many attempted X replacements (Fresco, GGI, ..), none of which are ready to takeover XFree86 in terms of functionnality/performance, much less number of ported applications/frameworks. Moreover, some bright people are working now on improving X protocol and implementation where it sucks (e.g. Keith on XRender, XRandR, Xft, etc.).

But go on, just show us what you're up to and code something better. It will be adopted and enhanced if it's really good, the free software community is very good at joining well-thought projects.

Re:X-less QT

[xchino]

How did parent get modded to +5?

Yes, let's all move over to a windowing system with serious licensing issues that's designed from the ground up to be run on embedded devices. That sounds perfect.

And what is this "plan" to start phasing out X windows? Was there a meeting I missed? Last I checked X was still being heavily developed.

"I'm not saying we take drastic steps now, but we'd be stupid to take no steps to transition the desktop to QT all the way down."

This is ridiculous. We'd be stupid TO take steps to transition "the desktop" to Qt all the way down. You're the only one who wants this. Not everyone loves KDE, and even less people love Qt. The seperation of the windowing system and the actual desktop is what gives *nix users the configurability to give their desktops personality. If you want a one-size-fits-all desktop, get windows.

As for you're space shuttle comparison, X windows is not inherently big (at least is doesn't have to be). It's not old. As I said, it is still under development, and there have been recent releases. Having history doesn't make software old.

As far as I can see, you're the only one with your head in the sand. It sounds like you're regurgitating all the inaccurate FUD-based trolling that goes on any time an article related to X is posted.

Qt is in no way a replacement for X, and it never will be, in it's current form.

Re: X-less QT

[infiniti99]

Why do people keep suggesting X is replaced? I'm not sure what sort of problems they have had, but it seems evident that they don't understand the nature of those problems and just blame X.

The problem is not X, but rather XFree86. XF86 is monolithic, and contains its own drivers. I realize this is mainly because *nixes don't have their own video, but Linux does. For years I've had problems with mixing Framebuffer Consoles and X, simply because they both fight over the same video. In a better designed system, Linux would provide the video and X would ride on top of it.

There is nothing wrong with the Linux Framebuffer except for lack of decent drivers. The DirectFB intends to solve this, but at this point XFree86 totally beats out DirectFB in driver support. Why does Unreal Tournament 2003 require XFree86? Because it needs OpenGL. Why the hell does OpenGL, something you're never going to use remotely, require XFree86? Because everyone uses X!

And that's where things have gone stupid. NVidia's drivers are for XFree86. Other closed-source vendor video drivers are for XFree86. This is a problem guys. What if we want to use the video drivers for something other than XFree86? Oops, you can't. We need to separate the hardware and X protocol layers from XFree86. This would lead to better compatibility and stability, and give ease to future expansion. At least on Linux systems, XFree86 should not be trying to roll its own drivers.

If you don't think we need to clean this up, consider that nearly every Linux crash is always due to XFree86. And please, don't tell me how you shelled in from your other box to kill XFree86, you may as well reboot if it comes to that.

So you are right, people wrongfully blame X when they should really be blaming XFree86. Before flaming me, please note that I am not against the X protocol, but the idea of an X server having its own drivers. Even so, I think using X for local applications is a bit redundant.

Which brings me to my next argument, which is about replacing X as a fundamental application layer. IMO, it should be possible to have locally running apps that access the video directly without having to go through some weird pile of extensions. 99.99% of the time, I am running apps locally. For me, and nearly all Linux users out there, "remote" should be the exception, not the rule.

The trouble, of course, is that there is a lot more to X than just a framebuffer. Try DirectFB sometime and you will realize this quickly. X has some very important things, like Window Managers, Input methods, hinting (for things like docklets), keyboard/mouse grabbing, etc. We'd need good replacements for all of these, along with X compatibility for it all. This is not trivial.

Qtopia (nor Qt/Embedded) is not the answer to the desktop. It is a really cool system, but is pretty much limited to the scope of PDAs. What we really need is a Qt/DirectFB (there is already such a port of gtk). This is just one step of many, though.

Re:X-less QT

[swillden]

X windows reminds me of the space shuttle. It's big and old and we know it won't last forever

One thing I consistently don't see in posts critical of X is an explanation of *why* it won't last forever. Seriously, what's wrong with it? The only specific points I hear are not only vague, but wrong. Just to get the crap arguments out of the way, I'll list the most obvious ones and then maybe someone can give me some *real* reasons.

• It's too big. For what? X servers of every size exist, including some that are small enough to run on a PDA.
• It's too old. Assuming a piece of software has adequate features and performance, age is a *good* thing. Not only does a long life tend to shake out the bugs, but software designs and implementations that really suck tend not to get old, in a competitive environment. And many wannabe X replacements have come and gone.
• It's too slow. No, it's not. Run some benchmarks against your favorite competing windowing system (Windows?) on a variety of graphics cards and you'll see that X is very competitive performance-wise.
• It lacks features Compared to what? Compared to Windows, yes, there are some things X can't do, but compared to all of the wannabe X replacements (which Qt really isn't), it's X's massive feature set that keeps it firmly in the lead. And the design has proven over the decades that it can easily be extended to support additional features as necessary.
• The API is too ugly. Who cares? The only people who use it are toolkit authors. We have very nice toolkits that hide all of that "nastiness" away.
• There are too many incompatible toolkits And just how is producing yet another even less compatible programmer's API going to solve this? You're better off trying to invent and push the One True Toolkit, because at least then the transition can be gradual.
• The whole client/server thing is weird. Umm, then don't think about it.
• Remote displays are useless. Then don't use them! Also, you're wrong, they're very useful.

That's a good sample. What I'd like to see is some really good, technical arguments that point out significant deficiencies in X that cannot be addressed without a clean start. I won't even demand that the deficiencies be good enough to justify all of the effort that will be required to reimplement everything for the replacement, although a *really* good answer would cover that as well.

Any takers?

Over PalmOS and PocketPC?

[treyb]

I don't see how IBM could have chosen Qtopia over PalmOS or PocketPC since those operating systems don't run on PowerPC hardware. Rather, it appears to me that IBM Microelectronics wants another market to sell PowerPC chips into and chose just about the only viable solution that wouldn't take years to deliver.