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.

Re:Quite a shift

[swillden]

It was Microsoft who wrestled the computer world from the headlock IBM had it in.

This is almost certainly a troll, but for those who might share the same misapprehension, it's worth pointing out that the above statement is completely false.

If there is a single cause of IBM's loss of control (and, actually, the company still is a monopoly in some spaces, though a relatively well-behaved one), it's the US Department of Justice. The consent decree IBM signed forced the company to stop bundling, which pretty much gutted the company's market strategy. If you want to add a second reason, it's the emergence of the personal computer, but the fact that IBM didn't retain control of that market is also largely attributable to the consent decree. At the time the IBM PC came out, IBM was deeply mired in red ink and floundering badly, which was a lot of the reason why IBM never put any real focus on the PC market and ended up giving it to Microsoft instead.

The reason that the DOJ hasn't had a similar effect on Microsoft's anti-competitive behavior, of course, is that Microsoft chose to ignore its consent decree and force the DOJ to make it stick in court, which has been so difficult, expensive and time-consuming that the US government has pretty much lost the will to press the charges home.

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.

Trolls?

[ThumbSuck]

TrollTech?

Trolls! They invade everything nowadays

Re:Why not Linux?

[WindBourne]

Qtopia is qt on embedded Linux. Same environment as Sharp's Zaraus. Good Stuff.

Broadening the user base

[bluegreenone]

I am glad to see this since it should broaden the Qtopia user base significantly. You may or may not know that Qtopia is also used by the Sharp Zaurus Linux PDA (both the Sharp software and OpenZaurus distros use it). There is also the OPIE project, which is basically a suite of PDA apps built on top of Qtopia. This bodes well for getting more Liunx PDA users on board, and provides some existing apps for those using Qtopia for the first time.

Yes and No

[burgburgburg]

If you go here, you'll see that they have three licenses: a Commercial Development licence, a Commercial OEM license and a GPL Development license. So it depends on what you're planning on doing with what you build. You can't build a commercial product with the GPL license.

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:This can hardly be a surprise

[dhovis]

With IBM's resources, they should be able to take the technology all the way.

Yep,

Just like OS/2....

Re:Linux footprint too general-purpose.

[Sunnan]

Most of that stuff can be removed at compile time.

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.

GGI was never an X replacement

[maynard]

It was a combination of a kernel driver for the video card and a set graphics libraries, which working together would provide a common hardware abstraction layer for all applications which might need to paint to a display. This way all applications could use the same functions to paint the display no matter what the underlying hardware. They then created a GGI X Server as a proof of concept that X could work over GGI. The real intention was to replace SVGAlib and get X drivers out of userspace - for both performance and security reasons. Pretty much what we have today with frame buffer and DRI support in the kernel, but far advanced for its time. There was some kind of falling out between Linus and the project so it never got added to the baseline kernel, the politics of which I can't remember. This is going back to 1996 or so. Too bad, it was a good idea which didn't survive.

You might be thinking of the Berlin Project, which I see has moved over to something called Fresco. Haven't followed up on that in some time so I can't speak to its current development activity.

Cheers,
--Maynard

Re:This is probably not needed,

[Balinares]

> Is there any programmers out there who have some real experience?

I have no experience of the embedded version of Qt, so keep in mind I'm talking about the X11/Windows library here.

In three words: it fucking rocks.

Qt is simply the single best designed piece of software I have -ever- seen. While it sets out for a huge task, being a completely self-sufficient C++ framework, a multiplatform one at that (and it can indeed easily replace the entire MFC), the class hierarchy is extremely clean, and it's very easy to get the hang of it. Actually, the entire documentation is absolutely excellent, clear and very well cross-referenced. I've never stayed stuck while looking for some info in there (quite unlike the MSDN documentation!). Go take a peek, someday.

One of the nice things with Qt is, if you need to do some basic task, Qt makes it trivial. Reading a file line by line is an example I was confronted to just today: using the MFC's idea of files, it's tedious at best -- gotta do the nitty gritty job manually. Wasted time. Using Qt, it's, well, trivial.

The other thing about Qt is, if you need to do something complex, Qt makes it very straightforward. For instance, yesterday, our VB programmer was trying to make a custom widget that lets you stack frames vertically, each under its own tab, and showing only one at a time. After hours of work, he got to work a simple version of it that couldn't resize, among other shortcomings. Well, it took me much less time to rapidly put together the same thing in Qt, only it worked right away without those shortcomings, could accept any kind of subwidget, and, oh, of course, could resize at will and would work right away on any platform. Keep in mind that this guy is very experienced with his tools, while I'm a relative beginner with Qt.

There are countless useful features in Qt. For instance, it doesn't duplicate data when duplication is not either required or specifically requested by the programmer. Copy a QString or a QPixmap ten times, and Qt will keep only one copy of the data in memory for all the instances. Modify one of the ten instances, and Qt will then replicate its data to modify it without touching the nine other instances.

And those guys actually license their boon of a tool under the GPL. That's almost too good to be true.

Anyway, enough rambling. If you're a programmer, do yourself a favor, and check out Qt. Even if you don't end up using it, you will likely learn quite a lot about how powerful object orientation can be when used by people who know what they are doing.