Monday, May 31, 2010

GSoC Code Week #1: Prologue

Hello, KDE planet! :-)

I'm a little bit late with this post, but finally here I am. And for those who are not aware of my project, just read this post. ;-)

Well, last week was my first coding week on this GSoC and as a pretty newbie KDE developer I had some problems with some noob stuff like cmake, dependencies and these kind of things, but I think that I'm close to solve it all. As I said to Kevin (my mentor), I'm a Java programmer who knows some C++/Qt, but I can say that I'm having some progresses at all.

Right now I have a general class which represents an ordinary UPnP device, that I called Solid::Backends::UPnPDevice (pretty obvious, right?). I've implemented a control point too, through the Solid::Backends::UPnPDeviceManager class. My intent is to get able to list the available devices ASAP. I'm with some linking problems (here are the newbie problems again) with HUPnP, but Nikhil Marathe (who has a related GSoC project with the Amarok people) gently offered himself to help, and very soon I'll be in touch with him. :-)

Since the main library used by my project (HUPnP) is under some license incompatibility (it uses GPLv3) with the rest of libsolid (LGPLv2), I've not committed anything yet, but soon I'll do it and disable the backend of the builds and distribution, to avoid any license crime. Tuomo Penttinen, the HUPnP creator and maintainer is aware of it and is planning to change the license in a near future.

Well, that's it for now. As soon as I can list the available UPnP devices I could post some screenshots here, right? People really like screenshots :-).

Regards.

Tuesday, May 18, 2010

GSoC: Discovering Solids

Hello, all. It's been a while since my last post, but here I am to update you about my progress with my Google Summer of Code project (explained here).

Well, this community bonding period aims to get students aware of technologies involved on the projects, documentation and, of course, the code. Since I'm pretty new with Solid, Kevin told me that a Techbase page explaining the libsolid architecture would be a good exercise of my current understanding about the project. So, the document is ready and the Techbase page will be up as soon as I discover how to create one. :-D

Besides that I've decided to put it here too, for the posterity and, of course, for any feedback you can give me. Any comments would be really appreciated. It's really simple and small, as you can see right below.

Cheers.

--

Solid (kdelibs/solid)

The KDE 4 provides seamless hardware integration through Solid framework. Using its API, developers become able to easily write applications with hardware interaction features, through a hardware discovery layer which allows the detection and use of devices regardless of operating system or architecture.

Solid was implemented using a frontend/backend approach aiming portability among platforms like Linux and Windows. The frontend provides the high-level API for developers using Solid and backends deal with the specific hardware issues for the different platforms.

Frontend View

The frontend classes provide the API for developers and are also wrappers for several kinds of devices. All frontend clases are available in kdelibs/solid/solid.

  • Solid::DeviceNotifier
The device notifier is a singleton used to obtain information about the hardware available on the system. It provides to applications the unique entry point for hardware discovery and/or notifications about changes (with the use of Solid::DeviceNotifier::deviceAdded and Solid::DeviceNotifier::deviceRemoved signals). This class calls the following Solid::DeviceManager.
  • Solid::DeviceManager

This (private) class maintains the state of all devices currently available on the system. Through it is possible to get, for example, the list of all devices or a list of device matching with some criteria (using Solid::Predicate).

  • Solid::Device

This class represents a general hardware device. A device contains one or more device interfaces (capabilities).

  • Solid::DeviceInterface

A device interface represents a certain feature that a device contains. This class is on the top of the device interfaces inheritance tree. All specialized device interfaces implement it.

  • Specialized classes (Solid::Processor, Solid::OpticalDrive, Solid::Battery, etc.)

These classes actually represent the capabilities that a device can have. All classes extend Solid::DeviceInterface.

Backend View

A Solid backend deal with the platform-specific ways of handle devices. Developers using libsolid do not use the backend classes directly. Applications do it through frontend/wrapping classes in the Solid namespace.

All backends have to implement the interfaces in kdelibs/solid/solid/ifaces (namespace Solid::Ifaces) correspondent to its devices. These interfaces are the basics of which API a given device has to provide to the frontend classes.

UML Diagram

This diagram shows the relationships between the Solid frontend classes and the platform-specific backend classes (Foo backend example).

Saturday, May 1, 2010

Me, myself and my GSoC project

Hello, all.

I've finally aggregated my blog on the planet, and in this first post I'll talk a little about myself and my GSoC project for KDE. :)

Well, my name is Paulo, I'm brazilian and recently got my bachelor's degree on Computer Science. Now I'm a masters student at Federal University of Campina Grande, here in Brazil. I'm part of the Embedded Lab, where for years is made a lot of researching about pervasive computing and embedded systems, with publications all around and partnerships with big companies like the Nokia Institute of Technology (INdT) and Petrobras. In a later post I can talk about my current work on the masters course.

I begun to use Linux at the university, which gets the students involved with FOSS since the beginning of the Computer Science course. After my first glance on KDE (about 4 years ago or more) I've became an user and fan. Unfortunately I've woken up late for contribute to KDE, but before later than ever, right? ;)

So, back in 2009 I begun to study about the UPnP standard, since the Lab where I work has a quite active branch of research about UPnP (including the development of a framework widely used at Maemo community, called BRisa). Hence, in the last edition of GSoC I've applied for KDE, in a project proposed by Bart Cerneels which aimed to give UPnP support on Amarok. For my sadness at the time, the project was not accepted, but here I am now (yay!) and my project is quite related to that one: this year my intent is to work on the Solid backend (and frontend as well) for UPnP, and through it many KDE applications will have a transparent access to UPnP resources available on the network (MediaServers, MediaRenderers, InternetGateways, etc.). My mentor for the project is Kevin Ottens, from the Solid team (who is a very cool guy, by the way :).

The project will consist of two phases. In the first one the goal is to get the Solid backend working and stable, as well the wrapping side (frontend). For this first phase, the work of Friedrich Kossebau on the KUPnP backend will be taken as basis, and the tendency is that the UPnP library used will be the HUPnP stack, developed by Tuomo Penttinen. I'm not sure if the use of Cagibi, another UPnP framework developed by Friedrich, is intended too.

The second phase will consist of some integrations with the KDE SC, with the development of a plasmoid which will show some informations about neighbor UPnP devices and the improvement of Plasma device notifier to detect and show these devices, too. After that, a data-gathering application for debug purposes will be made, aiming to get all the information about the local UPnP environment and let developers aware of error situations that can happen with the integration. For this application, the Python version of BRisa framework will probably be used.

All of what I've said before is on my proposal (with the timeline for all activities), which can be seen here.

In this first week of community bonding period I've got my SVN account and now I'm setting up my development environment. I'm not sure about the necessary KDE modules, but I've checked out kdelibs, kdebase, kdenetwork and kdesupport. Any hints in that matter are welcome. By the way, I'm waiting for the first release of KDevelop4. ;)

Well, this is enough for now. I hope we can all enjoy this time working together and for now on I want to be more and more an active part of this crew.

Cheers.