Hi everyone, this is my first post ever on Planet GNOME!
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 , 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 . 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.