GNOME – make everything intensely

GeoClue and Meego: Connman support

As promised, GeoClue now supports Connman as the connectivity manager module for acquiring network based location data.This step has been essential to complete the integration of GeoClue in the Meego architecture.

Check the patch if you want to know the details.

Thanks to Bastian Nocera for reviewing and pushing the commit, which is now part of the master branch of GeoCLue. Let see if it passes the appropriated tests before becoming part of some official release.

Network based positioning is one of the advantages of using GeoClue as Location provider. That’s obvious for Desktop implementations, where GPS and Cell Id based methods are not the most common use cases. On the other hand, Mobile environments could also get benefits from network based positioning, assisting the GPS based methods for improving the fix acquiring process; perhaps indicating where the closest satellite network is or showing a less accuracy location while the GPS fix is being established.

Finally, I would like to remark that my work is part of the Igalia’s bet for the Meego platform. I think the GeoClue project will be an important technology to invest in the future, since it’s relevant also for GNOME and Desktop technologies. In fact, GeoClue is also the Ubuntu’ s default Geolocation component.

GUADEC experiences

After spending the last week attending the GUADEC, it’s time to share some thoughts and impressions. The warm-up days were not such bad after all; some networking, hacking face-to-face with people you only know from irc or email. Also, some important meetings took place during those days and it’s a good forum for exchanging information and ideas about Gnome and Free Software.

Besides, I think those early, and probably more relaxed, days are the perfect moment to perform activities like the GNOME Developer Training. It was a very good experience, from the feedback I’ve got. I think it was the proof that it fits fine in the GUADEC purposes and, having more time for planning and some additional marketing actions, the success of future editions will be guaranteed. In my opinion, this training is a very interesting marketing tool to get more companies involved in Gnome and Free Software, providing some knowledge to ease the change.

Thinking about it, I think it could be a good idea to prepare some meetings with local companies where next conferences will take place. Some months before the GUADEC, a marketing plan should targeting the local companies and governments to embrace this kind of courses as a way of understand both, social and business, advantages of Free Software.

Once we reached the Core days the technical conferences got the spotlight. They were really interesting, as always, full of new and interesting stuff. The Luis Villa key note at the opening talk, even not being breaking news, gave me the clear message that Gnome Desktop should look at the Web if it wants to keep, at least, its relevance in the desktop and mobile markets.

During the talk about WebKitGtk presented by Xan López and Gustavo Noronha, this fact was exposed again in detail. They suggested a new path for GNOME to strengthen the community and get new developers interested in Web technologies that could help the Desktop to become a more integrated tool.

There were several other talks about Web and Javascript as the perfect language for UX development. Specially interesting the talk given by John Palmieri, titled The future is Javascript; let see 🙂

Another interesting talk I would like to remark is the one made by Bastian about GeoClue. Despite not having too many improvements since the last GUADEC, I think this is one of the most promising projects in the GNOME/freedesktop environment. Geolocation will be one of the keys of the new devices, not only mobile phones, but any kind of device which is designed to be carried while traveling; I mean laptops, tablets, wayfinder navigators, portable TVs and the like.

And finally, the talk about Grilo presented by Iago. The Grilo component was presented to a quite interesting audience; its architecture, main features like searching and browsing, and potential uses of this piece of software. I think this component will play an important role in the future, since Internet, as media content provider, is reaching high rates of use, stealing users from the typical channels like TV, DVDs, or even direct downloads.

GeoClue: Analysis and Architecture

After the first post introducing this cool project is time to go further and deeply analyze the GeoClue internals and general behavior, describing briefly he most relevant components of its architecture.

The first thing I noticed during the analysis of this piece of software is that is a quite complex component, at least, from the architecture design point of view. It provides a set of interfaces and DBus bindings to provide a very general and flexible tool for handling and extending location providers implementations. The following picture illustrate this idea:

Lets start analyzing the architecture, exploring each module and the relationship and interactions between the internal components.

Interfaces

GeoClue provides several interfaces to expose the different locations services and configuration operations. The following interfaces are currently defined:

GcIfaceGeoclue: Interface for administrative and configuration operations.
GcIfaceAddress: Interface for address acquiring operations.
GcIfacePosition: Interface for global positioning operations.
GcIfaceGeocode: Interface for geocoding operations.
GcIfaceReverseGeocode: Interface for reverse-geocoding operations.
GcIfaceVeolcity: Interface for velocity monitoring operations.

Some of those interfaces are exposed through DBus interfaces. An XML file define the structure of the DBus bindings. The *Glue generated classes are created from those specification files.

Location Providers

The most direct way to obtain the location is through the specific Location Providers implementation, each one using a different strategy for acquiring the data. There are several implementations for both, Position and Address providers, but lets analyze one simple for the time being, say Localnet.

Every Location Provider is defined through the following configuration files:

geoclue-localnet.xml: This file defines the exposed DBus methods and signals. The associated *Glue classes are generated from this file.
geoclue-localnet.provider: This file defines the settings of the Location Providers, like description, Dbus specification (path, service, iface), accuracy and some special features provided by the provider (e.g. automatic updates).
org.freedesktop.Geoclue.providers.Localnet: DBus service launcher file.

The Location Provider class, in this case called GeoclueLocalnet, should inherit from the GcProvider abstract class, which implements the GcIfaceGeoclue interface. It also should implement the abstract methods defined in the corresponding generated *Glue class, which allows the provider to receive calls through the DBus system or session bus.

Location Data Containers

In order to retrieve different kind of Location data there are several classes defined for that purpose, all of them derived classes from GeoclueProvider. This class holds a DBus proxy object to the instance which actually implement the Location mechanism. The specific provider container instantiated, GeoclueAddress for instance, should receive the DBus service specification (path, service); in the case of the Localnet example, it would be org.freedesktop.Geoclue.Providers.Localent and /org/freedesktop/Geoclue/Providers/Localnet.

Master Provider

The Master provider is designed by a client/server structure, where the server holds a reference to a DBus proxy object to the selected Location provider. The client will evaluate the available providers choosing the best one, following a provider selection algorithm and based on the user requirements.

The Master server could attend several clients and it monitors the currently selected Location Provider, notifying all the clients any status transition and events, or even the change of the selected provider.

Both components, client and server, are accessed through the DBus interface, org.freedesktop.Geolcue.MasterClient and org.freedesktop.Geolcue.Master interfaces respectively.

Master client/server

As commented before, the Master Provider has a client/server based design; the server is defined as a singleton of the class GeoclueMaster and its the responsible of the clients instantiation.

The GeoclueMasterClient class instances are the ones used for external applications to interact with the Location framework. It creates the necessary providers (Address, Position, Velocity, …) associated to the Master DBus interface (org,freedesktop,Geoclue.MasterClient. The corresponding GcMasterClient instance will receive all the requests, forwarded thought the Master Dbus interface (org.freedesktop.Geoclue.Master) to the Master server, which will derive the call to the selected Location Provider, using the specific provider DBus interface (org.freedesktop.Geoclue.Providers.Localnet).

And thats all; there are other components, like the connectivity manager and the related interfaces, or the web services supporting classes, but i think the contents described in this post are far enough to understand how GeoClue works, or at least, to show what a complex structure it has.

The following sequence diagram could help to understand how the classes interact to get the address, for instance:

A more interesting debate would be if such a complex design is necessary, or if the advantages it provides, in terms of flexibility and generalization, are enough to justify that, or even they could be obtained as a result of a different design, perhaps simpler. But such an interesting debate will take place in future posts 😉 stay tunned.

Creating camera software with GDigicam

After the release of the GDigicam project some months ago we have received some requests about creating documentation and examples of how to use the GDigicam component for handling specific camera devices. I’ve eventually got time to commit, truth being told, a very preliminary code which pretends to be the first full GDigicam example, showing some of the most important features of this piece of software and how to interact with the GStreamer GstCamerabin component.

First of all, for those who still don’t know what GDigicam actually is, i would like to briefly introduce it. GDigicam is a framework for handling camera related low level software inspired in the OpenMax standard. GDigicam provides a complete API for implementing a set of functionalities very useful when building camera UI software:

ViewFinder
Flash Modes
Scene Modes
Resolution and Aspect Ratio
Autofocus
White Balance
Quality
Zoom
Video and Photo Capture

The GDigicam component is intended to ease the setup and handle the software components which actually control and implement the video and photography features, and in addition, hiding the technologies used in such lower layers.

The first implementation of the abstract API exposed by GDigicam is based on the GStreamer toolkit, using the GstCamerabin component. You can check it out from the git repository:

git clone git:gitorious.org/fremantle-gdigicam/gdigicam.git

The stable branch is totally focused on the MAEMO platform, so if you have plans to work on any different platform you will have to use the master branch. The new example added is only available at the unstable branch, since the GstCamerabin component is slightly different in MAEMO. Hopefully, I’ll be able to merge this example to the stable branch soon, but it will require some important design changes that could take some time.

When I was implementing the new GDigicam example I realized other possibilities to be built on top of the GDigicam component. I think a benchmarking tool could fit perfectly on the purpose of showing how to use GDigicam, but it also provides an interesting tool for the community, to be able to compare and analyze different kind of camera hardware and software platforms.

Here you are a video briefly showing this tool, being run in the MAEMO platform and using the N900 hardware. The UI interface is very simple, and perhaps a little rudimentary; user experience is not the key at this stage. In the video you can see how to configure the camera settings (flash, scene mode, resolution, quality and so on). After the configuration stage, you can enable or disable your own benchmarking set of tests. You can implement your own tests, grouping them in your own way and execute all of them in a row. In the video you can see the execution of the Set1 – Test1: Capture still images in a row (default is 5 iterations).

There are lots of additional features, like a full verbose log of whats going on, performance metrics, comparison and analysis of different HW used for benchmarking. Of course you can forget about testing and building your own Camera for your device.

Besides, the GDigicam component could provide other interesting features, very useful for implementing camera UI applications:

Video/Audio resource policies.
Metadata management.
Geolocation.

What could we do with Clutter ?

These last months i’ve been working with Clutter project as part our GNOME R&D project. Firstly, for who don’t know what Clutter project exactly is, i would like to briefly introduce you this technology.The Clutter project has created an open source software library for creating fast, visually rich and animated graphical user interfaces. Clutter uses OpenGL (and optionally OpenGL ES for use on Mobile and embedded platforms) for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.

Basically, Clutter provides a Canvas for drawing complex graphics and effects. This Canvas could be inserted inside a Gtk context, using the Clutter-Gtk library.

The second part of my post will be focused on my work during last R&D project iteration and what were my thoughts about this new and promising technology; there were several discussions in the gtk-devel list about the new GTK 3.0 evolution and what would be the role of Clutter project.

The best way to understand a technology, after read carefully all related documentation, is to implement a proof of concept. For that purpose, i’ve chosen the YouTube client applications domain to develop new UI concepts, in order to test the powerful of Clutter as toolkit.

The first thing i’ve realized when i read the Clutter project documentation is that Clutter is not actually a toolkit, as it’s mentioned in Clutter project web page. With my understanding of the toolkit concept, it should be a set of tools for implementing user interfaces. However, user interfaces are not only graphical elements, but window management, theming support, advanced graphical components, translation support, applets and icons management, shortcuts, toolbars and menus or similar ways of activating user actions, … In that sense, Clutter lacks of several important features required to be considered as UI toolkit. I think that, at least at this moment, Clutter could be just considered as a graphical engine or scene graph tool. This point was also mentioned by some people inside gtk developers community who are considering the approach of using Clutter as scene graph concept for the next GTK 3.0.

When finally i began to develop my test application i had assumed that it actually wont be a functional YouTube client application, just an user interface proof of concept. Who knows what will happen in future, but for this project i’ ve focused the development in just one use case: querying for videos and show the results. For implementing the communication with YouTube web services i’ve found a very interesting implementation of YouTube GData API: libgdata and libgdata-google.These libraries, also used inside evolution-data-server as static libraries, are also provided as independent libraries, at least, in Ubuntu hardy. These libraries, implemented using a GLib GObject approach, provide Client access to google POA through SOAP interface.

During the implementation of this YouTube client application i’ve implemented several UI for showing YouTube top_rated query results. The first approach was obviously a GtkTreeView view.

The first and simpler clutter approach would be to show results in a square grid. I have to say that the square grid its also possible to implement in Gtk, although Clutter provides more fancy effects.

After this first UI proposals, and after understanding better advanced operations with Clutter, i tried to define new ways of showing information, always thinking about how to improve the end user experience.

The most interesting questions i’ve made to myself at this point have not been about Clutter technology capabilities, but what new UI concepts we want to achieve. I think there are several graphic technologies today providing new ways of drawing user interfaces, the important point is to define precisely how to present information and services to end users in a more intuitive way.

GUADEC 2007 – Birmingham

It was a really, really interesting conference.

The mobile environment was present in a lot of talks and i notice some exciting in GNOME community about this topic, Web desktop was a very interesting new approach, Gtk 3.0 brainstorming was started in this GUADEC, … well, community lives and grows .

I would like to emphasize excellent talk about Tinymail and Modest projects , a new approach to build mail clients for mobile services. They are very interesting talks and i would congratulate to Dirk-Jan Binnema and Philip Van Hoof for their fantastic job. I had the opportunity to work in Tinymail framework and i could ensure it’s a very good tool for implementing mail clients for mobile devices.

Business management software and GNOME

I recently was in the Guadec conferences at Vilanova to present the Fisterra development platform as a first try to build an open architecture to build business management applications (ERP). I knew this is a few popular kind of project inside GNOME roadmap and i would like to summarise my experiences during this conference.
The conclusions about this subject can be described in the following list :

There is a low interesting about this kind of applications by the GNOME community.
The GNOME project is focused to improve the GNOME desktop , making special efforts to build new multimedia applications and to optimise the performance of all GNOME technologies.
There are a few projects oriented to this kind of applications like Glom, Stock, Gapzacho, Kiwi.
There isn’t a open architecture proposal for business management applications.
The GNOME community does not takes into account the business wok environment as target of future developments.

These are only a few ideas and personal experiences extracted from my first Guadec conference. I would like to discuss about them in this blog, show my efforts to change the current situation and notice the importance of business management software to increase the GNOME desktop implantations.