Slashdot Mirror
Palm OS Spinoff
iCharles writes "According to this SEC filing per this Palm Infocenter story, it would appear that Palm is spinning off its OS devision. I'm a Handspring user, so it sounds quite interesting to me."
← Back to Stories (view on slashdot.org)
One of the problems with dealing with the Palm OS is the brick wall you hit when you want to extend the OS. To get access to parts of the OS source code, you have to go through all sorts of rigmorole, signing NDAs, etc. Maybe now with the spinoff, they might Open Source it.
:)
One project I was investigating recently was to see whether I could replace the default HotSync mechanism with a dynamically compressed XML-RPC connection so that systems could connect to the Palm across the Internet, and vice versa, thus obviating the whole PC HotSync requirement. I eventually lost enthusiasm for it, though, given the huge task of reimplementing the same mechanisms used by the HotSync subsystem, without the benefit of OS source.
Maybe if they Open Source it, I might reinvestigate doing it.
Incidentally, let's all hope that they drop the Newco moniker.
-jim
These are the same industry analysts that thought "Wireless Web" and "3G" would be big, because they brought "content" and "multimedia" to cell phones.
Nobody beyond a handful of wannabe-geeks who want to say "look what my handheld can do!" give a damn about multimedia on a handheld. "Ooh, I can look at 3"x2" color Powerpoint slides, and listen to supercompressed MP3s over tinny speakers!"
Remote display is extremely useful for developing software for the handheld and for debugging it. Also, a 200MHz handheld is a powerful machine--with X11, you can use it like a desktop and with desktop applications running on it when you connect it to a network.
2) Why the need for different toolkits?
Because there are already lots of handheld applications written for toolkits other than Qt. Face it, the world isn't going to switch its vertical application development to Qt just because some people think it would be nice.
On a PDA, a single, integrated, interface is the way to go.
If you think "consumer market", perhaps. But Linux PDAs are for vertical apps, and the cost and success of vertical apps is driven by ease of development and porting among platforms, not by some nebulous notions of appearance. Multiple toolkits are a reality in that market.
Linux programmers need to start programming apps for 320x240 displays, and QT/Embedded sounds like a good place to start.
FLTK and Java are already much more widely used than Qt/Embedded, and they don't cost anything.
Palm does NOT own BeOS. The deal hasn't been accepted yet by the shareholders. We will know for certain on Nov. 12th, when there will be a special shareholders meeting.
As for BeOS itself, check out http://www.befaqs.com/save or http://www.beunited.org . There are efforts to get Palm to license BeOS itself (which they have no intention of using, they only bought the Be Engineers remember? so they could build a new PalmOS).
The Zoomer used a V20 CPU and had 1MB of ram and 4MB of rom. It had stroke-based handwriting recognition (a first in portable devices) and a GREAT selection of bundled apps, including a 20 language translator (which didn't have a word for "computer" in it, oddly - it would come in handy when trying to explain what the hell you were scribbling on) and a currency converter - Imagine that!
The software was PC-GEOS, with basically three new things; An updated digitizer driver to support the input method, a new CGA driver to support a 384 wide by 512 high mono CGA display, and handwriting recognition. It was at least as stable as PalmOS with a hack or two, and had a whole hell of a lot more bundled software. I don't remember what kind of expansion it had, I seem to recall it took Type 2 flash cards from sandisk. I think I had a 1.8 MB card.
Anyway, I mention it because it was Palm's first job, they did the GEOS and apps bundle for it. It was actually a pretty cool little device, and it's also where Graffiti, the PalmOS' input method came from; Graffiti was originally an upgrade for the Zoomer. You loaded it and it created a little box you drew your characters in. The Zoomer's text input was done all over the screen. Graffiti differs from the original handwriting recognition largely in that there are no multi-stroke characters.
So now they're "spinning off" the software division? Big shock. They worked well as an independent company; Now that there's quotes around that, they should at least be able to get most of their efficiency going again. I refuse to speculate on any Be issues, though.
Side note; You can put GEOS on a GRiDPad 1710, and use the version of Graffiti from the Zoomer on it. I know this because I've done it. I need to make up some new battery packs for my GRiDPad, though. I'd really like to have it available while I work on my car, so I can take notes and whatnot. It's got a big (640x400x1bpp) monochrome CGA display, which is supported by GEOS' default CGA driver, a tethered pen which is actually better for industrial use because you can't lose the damn thing, and a nice, bright backlight. Hell, I've found my keys by that backlight before.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Running Qt/Embedded has all sorts of disadvantages, however:
You can't use X11 remote display for development on/for the handheld anymore.
Use VNC instead then. VNC is also much more useful than X once the palmtop is out in the wild - palmtops don't usually have constant network access when they're in your pocket, and VNC can detach and reattach easily to existing sessions, even if you change your IP address in the mean time. X requires a constant network connection or else the app that you're running over X dies.
You can't share the handheld screen between applications written in different toolkits anymore.
And this is a bad thing? Personally I'd be very happy to see embedded Linux not making the same usability mistakes that desktop Linux has in the past, and which it is only now recovering from. Lots of toolkits == inconsistent interface == usability problems. Diversity is great, but there are places where it is inappropriate, and user interface is one of them. Not to mention the bloat aspect of having multiple toolkits...
You are tied to a single toolkit for handheld development.
See above.
Don't forget that Qt/embedded is also API-compatible with Qt/X11, which means that porting Qt apps from the Linux desktop is a cinch - and that's how Opera and Konq/e have been so rapidly successful - they are both based on Qt. Don't underestimate the importance of having a good browser for a palmtop. The only browsers I've seen for X11 that are optimized for display on a small palmtop screen are... Opera and Konq/e. You might as well run them under Qt/embedded.
How many full-blown browsers do you know written in FLTK or Java? Maybe when there's a nice tiny browser for FLTK using Gecko as a rendering engine there'll be something to talk about.
As for size, well, perhaps TinyX+FLTK+Blackbox really is no bigger than Qt/e. But think about what you get with Qt - Signals and Slots, a fast and very powerful canvas widget, full-blown Unicode support, in fact, all the nice features that have made Qt a huge success on the desktop. And, as I've said above, porting the multitude of existing Qt desktop apps is a no-brainer. Not to mention of course that the superb QPE is available, so if you want a complete environment for your users, it's just a compile away. No additional coding required.
FLTK doesn't offer any of this. In fact, no current X11 toolkit other than Qt itself offers all this. If you start adding other toolkits on top of TinyX then you can make up for some of the more important features... but oops, there goes your size, and your consistent interface.
If you have political problems with Qt, then say. You certainly seem to be short on valid technical problems.