I was so excited about finally being able to attend a KDE developer conference and applied for holding a talk. I’m in the position of requiring subsidies so I made a deal with myself I would only attend if I would be able to do something that would enrich KDE in some way.

With KDE 4.0 development about to start and my background on Mobile Computing through www.handhelds.org and opie.handhelds.org and an internship at www.road-gmbh.de I wanted to make my fellow developers aware where Smartphone/PDA development is going and what KDE should and could do to integrate such devices.

I predict the following development in the market:
The physical formfactor will not change much, it might grow first and then shrink again, it will be touched screen based, its’ display will have at least a VGA resolution, it will have sensors for determining movement of the device and to things like autorotation or generate ‘Left, Right, Up, Down, Page Up, Page Down’ like events. The Itsy was a prototype at Compaqs’ CRL that already featured such sensors.
It will be a beast network wise, it will feature UMTS, Bluetooth, WiMax, Wireless USB with these technologies integrated you will be able to be always connected to the Internet. And that is the key. With technologies like Citrix, Tarantella or NoMachine’s NX you will be able to reach applications too heavy to run on your Gadget/Mobile Client.

I’m confident we will carry such devices in the near future but one thing is for sure it will be a client. The devices will get more powerful and gain new input methods (shaking…) but your Desktop PC will remain more poweful, more comfortable and will be controlled by Mouse instead of a touchscreen.
But in contrast to your Desktop PC you will be able to carry such a device day in, day out. While going to the office, while flying to the Mars, while driving qanu, while sitting in the jacuzzi.

So currently integration of such devices look the following:
(1) You wake up, synchronize your device and download news, go to the office/uni, take notes, finish agenda, take new dates and you go home and synchronize again. If you’re lucky and not a Palm user you can synchronize in your office as well (risking taking confidential data).

How integration can look in the future (remember you’re always connected):
(1) still the same
(2) you will be able to communicate with your Groupware solution from wherever you want. You can partially synchronize data, for example only four pages out of a 1200 pages big PDF document. At some sort of demonstration you take notes on top of these four pages and the next time you synchronize these notes get transferred to your groupware/desktop again.
(3) Your phone is just like your desktop a client to the Groupware/Storage solution but simply with less resources.

Currently KDE has even issues with point (1). Applications, APIs and Frameworks were not designed to implement synchronization. For example KDE PIMs KResource framework renders synchronization solutions impossible to reliable synchronize. In contrast the GNOME Evolution DataCenter solution is more easy to write synchronization solutions for.
KitchenSync did not find acceptance instead synchronization algorithms and features were reinvented for each Groupware Solution support leading.
Solutions like Kolab – often explained as the dumb server – is not suited for mobile applications. The disconnected imap approach works wonderfully for the desktop where disk space is no issue any more but nor for mobile devices with limited space and resources. For integrating mobile clients one currently would need server side query possibilities.

So what can KDE4 do (Part1):
-Support resolutions 640×480 (VGA) to allow Mobile Clients to run KDE (over NX or such)
-Maybe try to support touchscreen input (mouse over effects are useless, no right button…)
-Integrate synchronization support in the core of KDE:
-Allow converting documents to subsets and supersets on the fly
-Allow KDE apps to expose information in a compact way
-For example if you view a page in konqueror be able to safe it in the plucker format
and schedule it for synchronization
-Rewrite KResource with locking/unlocking and query possibilities
-Lock to operate on a fixed point of data
-Query to see all changes since last sync

Imagine the day all company desktops’ are switched to KDE. Imagine the reasons for such a switch, more cost effective, more secure, no vendor lock in… But which client will we support? The marketshare of Microsoft is growing in the Smartphone market and it looks like one more market to be controlled by Microsoft only. Isn’t it funny that we will need to support Microsoft Based Phones in a free desktop that just konquered the market? Why isn’t it important that your Phone is secure, you will be able to customize it, open, you’re not locked in?
I do not see any reason why your phone should be less free than your desktop and with all means we should try to prevent Microsoft controlling the market.

I also believe you can not switch huge amounts of Desktops without integrating Mobile Clients and as I said I do not see a reason why we should support proprietary infrastructure for the same reason libkdecore is not proprietary.

So what can KDE4 do (Part 2)?

• Provide smaller and fine tunable libs usable on Mobile Clients
• Share implementations for freedesktop.org standards with a free Mobile Client
• Make use of ModelView to provide different user interfaces for different clients
• Build Mobile and Desktop Edition out of the same source tree
• Just two different GUIs

• Make Free Mobile Clients perfectly integrated in KDE

Q&A:
Q: I do not see the people using PDAs in my company?
A: They carry Mobile Phones but probably do not recognize they can use the builtin Calendar, Todolist and Addressbook, or find these applications not usable, or can not utilize synchronization. All these will change when devices are getting more powerful and KDE evolves

Q: Why are the decies always connected?
A: More and more WLAN Hot-Spots are accessible prices for GPRS/EDGE and UMTS will fall as well.