Project title: kpnp - k plug'n'play manager ============================================ Name, e-mail: ============= Sebastian Kügler Synopsis: ========= Kpnp is a program that lives in the systray and helps the user to "connect" a certain software or chain of actions to a plug'n'play device that has just been plugged in, or more generally, to new hardware. Goals: ====== * Make Linux and the KDE desktop more aware of hotpluggable hardware, like USB sticks, digital cameras, PCMCIA adapters * Make KDE more easy accessible for entry level users * Create a userfriendly application * Create a showcase for the python binding to KDE Project details: ================ Use case-based description -------------------------- Chris is a new user of "Kool Linux", a KDE-based Linux distribution, which is installed on his new notebook. Mark is a friend of Chris. Julie is Chris' girlfriend. Use case A : digicam ..................... A.1) Chris plugs in his digital camera into his (fresh install) of the Kool Linux Distro. A.2) A passive popups acknowledges the existance of a new device, recognizes that it's a digital camera and proposes starting digikam's import photos dialogue every time Chris plugs in his camera. A.3) Chris accepts that, since plugging in his camera usually means that he's going to download photos from his digicam. A.4) Chris downloads the photos and does everything he wanted and goes on working. Use case B : digicam 2 ....................... B.1) Two weeks later, Chris returns from a holiday. B.2) Chris plugs in his digicam. B.3) The digicam import photos dialog is launched automatically. B.4) Chris downloads his photos and is happy. Use case C : Wireless LAN .......................... C.1) Chris brought his laptop to Mark where he wants to check his e-mail C.2) Mark offers Chris to use his old wireless PCMCIA adapter. C.3) Chris plugs in the adapter. C.4) A passive popup acknowledges the existance of new hardware, recognizes it as $SOME_WIRELESS_ADAPTER and offers to open kwifimanager to configure a connection. Use case D : wireless LAN 2 ............................ D.1) Two weeks later, Chris visits the Mark again. D.2) He plugs in the wireless adapter. D.3) kwifimanager opens and has remembered the settings from two weeks ago. D.4) Chris clicks OK to use the 'old' connection data and checks his e-mail. Use case E : USB storage device ................................ E.1) Chris's girl friend Julie asks if Chris would review a report she wrote. E.2) Chris plugs in the USB stick. E.3) A passive popup offers Chris to browse the data on his USB stick, and additionally asks if the filemanager should be opened every time Chris plugs in a USB stick. E.4) Chris acknowledges this, a filemanager is opened and Chris can open Julie's report. Use case F : MP3 player ........................ F.1) Chris has a birthday. He's given the latest "Pear MP3 player" F.2) Chris wants to use it immediately, so he needs some music on it. F.3) Chris plugs in the MP3 player into his notebook to upload some music to the new device. F.4) A passive popups acknowledges the presence of new hardware and asks Chris if he wants to open amarok to fill his MP3 player with music. F.5) Chris acknowledges that. F.6) Next time Chris plugs in his "Pear MP3 player", amarok opens automatically and lets him edit the playlist. Use case G: Burning a CD ......................... G.1) Chris wants to make a backup of personal data G.2) He inserts a blank CDROM in the tray of his CD writer G.3) A passive popup appears asking him if he wants to start k3b, every time he inserts a blank CDROM G.4) Chris acknowledges that. Now every time he inserts a blank CDROM, k3b will be started automatically. Use case H: Watching DVD ......................... H.1) Chris bought a DVD with his all-time favorite movie on it. H.2) He inserts the DVD. H.3) kpnp offers him by means of passive popup if he wants to start playing immediately, and if he wants to have the DVD player software launched every time he inserts a movie DVD. H.4) Chris acknowledges that, now inserting a DVD is connected to playing the movie on it. Technical details: ------------------ The first version which will work on KDE 3.x will be written in Python, using PyKDE and PyQT. It's basically a systray-based kind of daemon that is waiting for hardware that's newly added to the system. It uses HAL/DBUS to get acknowledged of new hardware. Features: --------- Derived from the use cases use cases, kpnp's features are: * HAL/DBUS interface * Core that listens to the DBUS, waiting for new hardware * extendable set of "helpers" that have information about hardware. These helpers basically connect a hardware class (like "digicam", "USB stick", "removable wireless adapter") to an action (e.g. "opening $PROGRAM", "mounting devices", "accessing files" etc.). A helper is implemented in the form of a class that's added to the "list of known devices" of the core. A helper should be very easy to code and have a strong API inviting everyone to add support for $OBSCURE_PLUGNPLAY_DEVICE. kpnp should be able to easily handle hundreds of these helpers, having support for all kinds of hardware available. Documentation for writing such a helper application will be available. * Generic helper that "just" offers to open $PROGRAM on insertion of $DEVICE. * (Bidirectional) DCOP interface to interface to all sorts of programs. * Storage of configuration: kpnp remembers devices and connected actions. * Of course, certain functionality of kpnp can be switched *off* in order not to annoy users. More thoughts: -------------- Kpnp will help new users to explore the features of their desktops. An action like inserting a USB stick will spare them having to look up how to make data accessible. All that magic is probably something the user isn't interested in anyway. Also, the user won't have to keep in mind all kinds of applications. The desktop can be preconfigured in a way that usage is much more simplified by connecting an action the user already knows and has to do anyway, like inserting hardware into the USB port to an application. Kpnp will be easily configurable. I'm thinking of a fresh install, and then just plugging in all your hardware once, connecting actions or programs to an action. This is very intuitive. Kpnp will also make extensive use of 'new' features of the desktop, like HAL/DBUS, but will also show that full-fledged KDE applications do not necessarily have to be built in C++ any more. Of course, kpnp will use existing KDE technologies wherever possible. Knotify, KConfig and DCOP come to mind. Passive popups will assure the workflow is not disturbed, yet giving feedback that the system is aware of the existance of the new device. Design of kpnp will be modular, of course, integration into plasma / KDE4 will be kept in mind so that porting it as soon as a complete Python / KDE toolchain is available will be easy. Project schedule: ================= Step-based schedule: -------------------- 1) Research: gather information about all technologies involved, work out feature list, write proposal. 2) Design create mockups of user interfaces, get feedback from other developers and potential users, work out application design. 3) Code proof-of-concept. 4) Work out proof-of-concept to a working application, try to reach release quality. Time-based schedule: -------------------- Phase 1) should be finished by the end of june Phase 2) should be finished by mid-June Phase 3) should be finished mid-july Phase 4) should be finished after Akademy, using the hackathon to bring kpnp to release quality ad 3) The proof-of-concept will show that the system basically works. It will be working for some of the simple use cases and will generally show the capabilities of this application. ad 4) i18n support will be added, tasks like streamlining DCOP interfaces, re-checking the "helper" API for consistancy and flexibility will be done. Also, of course lots of testing. Short biography: ================ I am a 28 year old student economical sciences from Nijmegen in the Netherlands. I'm using Linux and KDE since 2001. I'm also working freelance as a webdeveloper. I have experience in programming PHP (5 years) and Python (4 years). I got involved with KDE about a year ago when I wanted to learn more about desktop application programming and chose Python and Qt as a starting point. I joined Simon Edwards with guidance (http://www.simonzone.com/software/guidance), that's also what I'm mostly working on when I don't have to write code for a living. I'm getting more and more involved with Open Source software as I visit events like FOSDEM in late winter and akademy this summer. I'm also involved with KDE_NL, mostly thinking, attending promo events and helping with keeping the website up-to-date. More information about me can be found on my personal website, http://vizZzion.org. Sebastian Kügler Vossendijk 95-6 6534 TH Nijmegen sebas@vizzzion.org / http://vizZzion.org