Planet maemo: category "feed:43af5b2374081abdd0dbc4ba26a0b54c"
I just finished the Evolution DBus metadata API’s implementation. Information about this work can be found on this wiki page.
Working on a metadata DBus API for E-mail clients. I have started a wiki page proposing the API for an implementation in Evolution.
With all the politics I didn’t really report a lot about what I’m doing behind the computarz. I’ll be brief for a change.
While working for my customers during the week I of course can’t spend time on just any subject. So I try to do something useful each Sunday evening.
For the last weeks this has resulted in these proposals and patches for GLib:
- Today I integrated Vala’s libgee into GLib’s GIO. You can find a page describing this collection API here. Now there’s a patch for GLib so that there’s initial code to back the proposal too.
- Last week I did some performance improvement for constructions of GObjects that don’t have properties in their GObjectClass.
- Last week I also did some performance improvements for construction of GObject in general, but it looks like that TLS’s ___tls_get_addr is slower than g_slist_prepend, so I’m not sure if this patch helps a lot
The two performance improvements combined together will make a GObject without properties construct almost as fast as a GstMiniObject. I have tested them with the Vala compiler, which uses GObject extensively and all GObject tests in GLib seem to work.
For my customer I’m working on these things:
- A specification for thumbnailing and here’s a prototype for it that will serve as replacement for Hildon Thumbnailer.
- A specification for media art requesting and here’s a prototype for it. The same infrastructure will in Maemo do both Thumbnailing and Media art fetching indeed.
- A specification for storing metadata on removable devices. This must still be implemented in Tracker and prototyped. This is actually quite interesting as a few other players are also interested to do this for their removable media’s content.
Just like with thumbnails are there a lot of applications that want to share media art. Media art is the politically neutral name that we picked for what I used to call album art. Instead of just for albums we concluded that art for other things like podcasts and radio channels exists too. We made sure that the specification acknowledges that.
We still have a few open and unspecified ideas like:
- Filtering patterns for fields like album, artist and title
- Support for front, back and pages in a booklet
- A way to mark artwork as temporary
- Cached thumbnails of artwork
- Storing artwork on removable media for reuse by another device
- Temporary write location to rename to final to gain atomicity (.part files)
I guess this means Aaron, Gabriel and me should do some more meetings. I think it’s time however to involve people who are working on other media players. Especially since the Banshee- and the Maemo team are fully agreeing on the necessity of such a storage specification. Which means that one will be made and most likely shared by Banshee, the advisory documentation for third party players on Maemo and by standard players that will be shipped.
You can find a draft of a draft on Live.
I believe it’s important for mobile platforms to specialize on what is important for mobile and embedded. This includes dealing with high latency networks, low amounts of disk space, high I/O costs, slow memory bandwidth. The development tools are often either far more or far less integrated.
There is a lot of overlap with desktop software development. If companies who make mobile technology want to build a developer ecosystem, like the web and the desktop already have, then my advice would be to start integrating with these overlapping areas. This is indeed more expensive and more difficult than doing your own thing. In the long run, this is how you make an ecosystem for mobile software development.
After youtube’s madness, I wouldn’t ever underestimate the creativity of the kids anymore. After wikipedia, the Linux kernel, KDE, GNOME, Webkit and Firefox as browser components, I wouldn’t ever underestimate the energy of volunteer experts anymore.
The music industry usually only allows big corporations to hook-in their music selling. Why aren’t they investing in conferences where they invite both the industry players and the developers who are making tomorrow’s music players? What if they’d involve them in specifying a standardized protocol for buying music? Right now the music industry is making it harder for its customers to buy music than it is to copy and steal music. Right now people who want to buy music are required to own a desktop. How silly is that? With a standardized protocol you’d see mobile software developers writing mobile music players that’ll also be clients communicating over 3G, UMTS or GPRS.
At the Boston GNOME summit I’m meeting Gabriel and Aaron who both developed Banshee. We will discuss a standardized cache for album art and a DBus interface to implement an album art downloader. As a Nokia contractor I will implement this specification on the Maemo platform. This way, all music players that will be made for both desktops and mobile platforms can share the same album art, use the same DBus interface to request album art, and share album art downloaders.
Why do we need thumbnailing to be a service?
My proposal
Based on those conclusions I decided to write a DBus specification. I also reimplemented Maemo’s Hildon Thumbnail to be conform this specification. This work has been merged with the TRUNK of the project and will be used on Maemo’s Fremantle release.
While rewriting Hildon Thumbnail I decided to make sure that the software compiles and runs on any normal desktop. This way the software can serve as a proof of concept and working prototype for the DBus specification. Special care was taken to make sure it feels as desktop neutral as possible.
I opened a bug to officially request a freedesktop.org project for this specification. I hope this organization will offer a platform for further development of this DBus specification. Hildon Thumbnailer can serve as a prototype and will be adapted whenever the specification improves.
People who know me probably saw this blog item coming. Here it is!
Karoliina just E-mailed me to tell me that she just finished her new song.
This one sounds more like Vangelis than I have ever done before. It combines some symphonic elements (some (sampled) instruments from symphonic orchestra were used) with synthetic sounds.
– Karoliina Salminen
A video with the song as background showing the cathedral in Mechelen (filmed by Karoliina and Kate during Akademy)
I like it!
Dear people of the world who are interested in developing with GLib. The type GStrv is a typedef for “char **”. I know C purists will think that it’s stupid to do that. The problem with a “char **” however is that it can mean hundreds of things. That it’s therefore not possible to know for a language binding tool how to deal with it (how get thing things out of it, how to free it and how the content of it will look).
With GStrv all that is known. A language binding generation tool will know that it must use g_strfreev to free it and it will know that your blob of C memory will be an array of strings.
A “char**” can also be a a pointer to the pixbuf of a grayscale image. It can be a binary blob or any kind of array of pointers.
To all our library writers, please do this:
GStrv people_bag_get_names (PeopleBag *people); GdkPixbuf* people_bag_get_thumbnail_of (PeopleBag *bag, gchar *person);
Don’t do this:
gchar **people_bag_get_names (PeopleBag *people); gchar **people_bag_get_thumbnail_of (PeopleBag *bag, gchar *person);
Replacing your “gchar**”s with “GStrv”s wont create API nor ABI problems, so please do it now and make a new release of your fixed libraries’s APIs. Then at least the array-of-string glue code of language bindings can be fully automated.
If you are returning an array of object instances, please don’t use GList, GPtrArray nor GHashTable. By using those you loose boxing (your array type is a blob of unknown C memory that contains unknown things that happen to be pointers to GObject instances - but a tool can’t know that -) and (more importantly) you don’t offer a generic collection API for your blob of C memory to other languages.
Consider using a collection API. Some people are trying to get this into GLib just like GIO got accepted as a higher abstraction for a IO and Stream API. Let’s see what happens.
Thanks!
ps. & edit: On IRC jdahlin mentioned that GValueArrays have type information, because the items get boxed onto GValues. If return performance is not an issue, you can also use that instead of GStrv.