Last week I have been to Istanbul, to attend GUADEC. It has been an amazing time there, and I have been really happy to meet, socialize and share ideas with the other SoC students and some of the GNOME gurus

Together with Bastien, Clemens and Felix, we planned the next final steps for the MediaManager project. Also, it seems that Felix’ project (Cheese integration) will be one of the first clients to use my MediaManager library to expose cool features in the GtkFileChooser!

== Work to be done ==

- Write a set of widgets wrapping around the backend code
- Write a GtkModule that hooks up into the GtkFileChooser to achieve my ultimate SoC goal of integration with it.

== Timeline ==

I don’t know how much work I will be able to do in this following week until the 23rd of July, as I’m having some exams in this timeframe. Anyway, afterwards I’ll be home until the 10th of August at least and working again full-time on the project, so I came up with this plan, which would be perfectly synced with both the SoC timeline and my holidays

- 24th of July to 31st of July, writing of the widgets
- 1st of August to 5th of August, writing of the GtkModule
- 6th of August to 10th of August, final bugfixing & release

Feel free to mail me for any suggestions on the widget part or if you think your application needs some specific widget to use my library. I will start coding them in the next week, so there’s still time for thinking/designing.

We’ve been discussing the issue here at GUADEC and it seems that many guys really agree this is the path we want to follow. I am pretty sure the guys from the release team will just support it as well, as all the community is so excited by the new stuff that is happening that we really don’t want to stop the effort now.

Also, it seems that GTK+ will help us by providing a cool API for that, so let’s just make it happen!

I’m really looking forward to meet many of you GNOME people…see you soon! If you want to meet me, drop me a mail, add me on twitter (cosimoc) or contact me on IRC (always cosimoc).

See you soon!

This is the report for my fifth week of work in my SoC project.
This week I managed to dedicate three days of almost full-time hacking
on the project, and I almost completed the DBus interface.

== Work done this week ==

I splitted the MMApplication and MMCategory classes into abstract
interfaces, implemented by MMSoApplication/Category and
MMDBusApplication/Category. This was needed, as the implementation of
the methods which get the categories and the hits are very different. To
pass the objects (i.e. the filters and the hit collection) over the bus,
I serialized their members into a XML tree. So I spent some time
familiarizing with the libxml2 reader/writer API and finally wrote
methods that transform my objects into strings to be sent over DBus.
I also had to refactor some code into the Manager itself to make it more
DBus friendly. In the end, the DBus interface that an app should expose
is very simple:
- GetApplicationInfo, which returns the desktop id and the supported
types
- GetCategories, which returns two string arrays; one for the names and
the other for icon names
- GetHits, which takes as arguments the category name and a filter, and
returns a hit collection.

I am quite happy with the work so far, and I think I will have finished
a first implementation of the “backend” (i.e. non-UI) part by the next
week, just like I originally planned in my proposal!

== Work for the next week ==

I don’t know if I will be able to do much hacking next week, as on the
next Monday (July 7th) I’ll be leaving for GUADEC, in Istanbul and I
have to prepare many things. Though, there’s some things that I want to
do:
- GErrorize the _unserialize () methods
- Write more tests for the DBus interface
- Re-read the code written so far and look for possible
optimizations/bugs
- (optional) Try to implement the first widgets.

So I’m looking forward to meet everyone of you in Istanbul, I hope we’ll
have a great time!

This week hasn’t been as productive as the first three, as I have been
quite busy with some personal things.

== Work done this week ==

I spent quite some time on DBus: first reading the documentation and
learning the basics and then fighting to solve some nasty crashers in
the code I was writing.
In the end, I made a separate executable helper, mm-dbus-manager, whose
activation should be auto-activated on request (i.e. when the library
wants to know the applications registered on the DBus interface or
interact with them). The helper puts a manager on the bus, which takes
care of spawning the application-specific executables, which in turn
register themselves to the manager and should expose and implement the
methods of my interface.
The manager discovers the available application-specific executables by
looking for GKeyFiles installed in a known location.
Apart from setting this up, I spend some other time autofooizing the
whole project in a much nicer way; the test suite is getting better too,
and I also wrote tests for the DBus interface.

== Work for the next week ==

- Keep the work and hopefully finish the DBus parts (i.e. implement the
queriable interface and the serialization and deserialization of library
objects).
- (optional) Do the other tasks I had setup for this week and didn’t
have the time to do.

== Resources ==

As usual, you can find my work in my git repo tagged “week4″ now.

Cheers!

Anyway, I managed to complete almost all the tasks I set for this week, finishing a first implementation of the filtering API. The only thing I did not have time to fully write are proper tests for it, so do not expect it to work and shine yet

As always, you can grab a copy of the project from my git repository on repo.or.cz. I am making a tag each week, and tagged versions should be guaranteed to compile and run the included tests.

== Work for  the next week ==

- Finish coding the tests and iron out some more the filtering API.

- Take some time to think about how object ownership works in the whole code I wrote and fix some leaks (if any).

- Implement a DBus interface.

- (optional) Try to think about a signal-enabled implementation of the HitCollection.

I finished some hours ago to give my first GNOME talk at my University The talk was called “GNOME Hacking in Guadalajara” for no specific reason other than “GNOME Hacking in Florence” seemed to be less cool. And for some hours, I have been Cosimo Garcia Lopez, a mexican uber-cool hacker The event was organized by LILiK, a stuednt free software lab I am member of.

Alessandro made an introduction about what GNOME is, and I talked about the cool libraries we have inside our platform, writing in about an hour as example, a little app that plays with libempathy and GIO to get Jabber messages and downloading http uris we receive, opening them with the default application. I ended the talk promoting bugzilla and encouraging people to spread the (GNOME-)love and start writing patches now!

The room wasn’t much crowded, but the people there were really interested and made me a lot of questions about GTK+ and GObject. I am quite proud of this little achievment…if someone an year ago told me I was going to hold a talk about developing GTK+ applications I would have laughed at him

== Summer of Code ==

In other news, I’ve made some more progress on the filtering API for MediaManager, but haven’t had the time (due to the talk) to write any tests yet. More about this on the next weekly report.

== Work done this week ==

Until friday I’ve finished the first implementations of MMHitCollection, MMHit and MMFilter (though the last two do not do anything interesting yet). Also, I’ve spent quite some time setting up all the autofoo needs for the project, generating libmmanager.so.

Then, I’ve written a simple applications to test the backend side of the API and another simple one to query the results, and after a bit of struggling everything seems to work fine.

Starting from today, I’m working on the implementation of the filter side.  I tried to think a clever and extendible API for queryable attributes: so we have an extensible MMAttributeManager interface, which inside the library is implemented by MMAttributeBaseManager, MMAttributePhotoManager and so on, but it can provide any kind of attribute details, so it would be easy to write implementations for other kind of things. Its duty is to list and create all the possible attributes for a speficic media type. The atributes created by the manager should only contain a type, a name and a description.

So, a MMFilterParam is created, with a MMAttribute, an operator (equal, greater, less, …) and a value. By setting one or multiple MMFilterParams on a MMFilter you can actually query the application database to obtain your hit collection. Finally, a MMHit will contain an hash table of the MMAttributes with actual values relative to the object.

All of this is not yet implemented, though I started coding it today and some things are already there (untested).

== Plan for this third week ==

- Finish the filtering part.

- Code some “real-life” tests for the filtering API.

- (optional) Start investigating the D-Bus API.

I’d really like to finish the backend + D-Bus part until the end of June, to have the time to discuss it with someone at GUADEC and then have a full month for the GTK+ part and to iron out what’s wrong.

That’s all for now

First, I’d like to introduce myself: I’m Cosimo Cecchi, I am 22 and I am from Florence, Italy. I am in the third year of Computer Engineering at the University of Florence. I already contributed to some GNOME modules during the last year, and I really enjoyed it! So I decided to try the Google SoC under the GNOME flag. I am glad I have been accepted for my GtkMediaManager idea [1], and I really look forward to accomplish it.

Here’s a report of my first week of work for MediaManager.

After some time spent on designing a good architecture for my project,
some days ago I started the actual coding, which is being done in a
public git repo [2]. Nothing is working/compiling yet, but I feel the
project is shaping up quite nicely.

Also, I spent some time contacting my mentor, Nicolas Trangez, to hear
his opinions on the design I made, before start coding, and he gave me
some nice ideas that I am looking forward to implement

== Brief overview of the architecture ==

Among the two choices I had in my project description (Xesam vs
application provided plugins) I went for the plugins way, but I am
trying to design it in a way that the manager could be easily extented
to support a Xesam plugin too.
So, applications can ideally implement the manager interface in two
ways: installing a .so in a well-known place and letting GModule do the
magic, or installing a .desktop file and using a D-Bus activated
service. This is to make it easy for applications written e.g. in Python
or C# to use the interface provided by the library. I am currently
implementing the GModule part, the D-Bus interface will come a bit later
(when I have the GModule implementation up and running).

On top of this, the manager library is about Applications, Categories
and Hits. A Manager object keeps track of the available applications,
and an application has mainly the following methods:
- GDesktopAppInfo getInfo ()
- GList getCategories ()

A Category is a subset of the content managed by the application (e.g. a
playlist, “Last Roll”, …) and each application has at least one
category (the whole library). They are provided by the application and
they can be queried to retrieve the “real stuff”. A category should have
the following methods:
- GIcon getIcon ()
- char getName ()
- HitCollection getHits (Filter f)

Hits are the “real stuff”, as they resemble the real content managed by
the system. A Hit have some generic methods like
- getName ()
- getUri ()
and the most important GFile getFile (), which I think will be
implemented in a separate subclass (HitFile) as it can be useful to
decouple the Hit from the GFile for some use cases.

Filters instead are objects on which you can set the attributes that the
application has to query on. The library will provide specialized
filters for a specific type i.e. PhotoFilter, MusicFilter,
VideoFilter, …, which will contain all the possible attributes for
that media type.

On top of this, I will eventually write libmmanager-gtk, which will
contain widgets for data provided by libmmanager.

== Weekly Status ==

As I already said, nothing is working or compiling yet, but I am quite
happy of how the project is coming up.
I have written (but not tested) a GTypeModule subclass to handle .so
files, a manager for modules, the providers to interact with the modules
and some code to handle Applications and the global manager.

Next week I plan to finish a rough implementation of Categories, Hits
and HitCollections, to make all this compile and then to write a test
program to drive further development and to test whether the API I
designed is really worth.

[1] http://code.google.com/soc/2008/gnome/appinfo.html?csaid=15C2B5BC19A9276A

[2] http://repo.or.cz/w/mmediamanager.git

A little but about myself: my name is Cosimo Cecchi, I am 22 and I live and study in Florence (third year in Computer Engineering). I’ve been doing some work across various GNOME modules in the last year (Epiphany and Nautilus mainly) and really had good time doing it and knowing some people from the community. So when I saw Calum’s post about media integration in the GNOME desktop, I thought that was a good job to work on for a Summer Of Code project so I applied for it, and guess what, I was accepted

I’ll blog about the details of my project later, now I’d like to thank some cool people for the support and the ideas they gave me and also I’d like to wish a good luck to everyone involved in GSoC this year!