[Thunar-dev] On Emblems

[Clemens Buss]

Hello,

may I briefly introduce myself, for those who don't know me and who are
probably the majority as I suppose. My name is Clemens Buss and I
currently do a Summer of Code for GNOME (
http://code.google.com/soc/2008/gnome/appinfo.html?csaid=C4B0B39CD64C9CE6
) mentored by Christian Kellner.
The title of my project is "Tagging and Emblems on the GNOME Desktop".
The goal is sort of a cleanup of the whole emblems-concept in GNOME and
a connection of it with a decent tagging system. But I don't want to
repeat what's on my SoC page and a lot will become clearer below anyway.
Let's try to come to the point.

Since a while but more actively since last week I am working on a design
and implementation for the representation of emblems together with
GIcon. Yesterday, Matthias Clasen and I figured that we are both kind of
working on the same problem right now, which is the support for Emblems
in GIcon.
Today we had a good discussion or IRC on the whole matter and he asked
and encouraged me to post my design for discussion.



So I would like to present and explain what I have in mind. Essentially
it is the following:

- GThemedIcon
   +----GEmblem: it inherits from GThemedIcon, plus then adds
properties, which can indicate for instance where the emblem "comes
from" (see ? below).

Why inherit from GThemedIcon? That's what emblems are now in Nautilus
and in the end with this design, loops (emblemed emblems) can be avoided.

Why the properties? We have to remember that emblems can be and
represent a lot. Either they represent live-metadata(e.g. read-only),
user-metadata(e.g. tags), also they are a good way to composite the
right device icons
(https://bugzilla.gnome.org/show_bug.cgi?id=506532#c19) or something
else we don't think of, yet.
Very connected to this is that I am also working on a concept which
actually provides the list of emblems for let's say a file. The
information where an emblem comes from is then for instance useful to
decide (either fixed or user/app-based) if an emblem should be drawn or
not (if there's not much space one wants to leave out the less
important, not an issue on the desktop maybe but it is one in the
filechooser ...), or also where it should be drawn (e.g. live-metadata
emblems at the bottom and the others ... you name it)
The API which will give a list of emblems is not finalized. Anyhow, it
is quite clear that it will give a list of emblems from different
contexts. Like we have it now in GList*
nautilus_file_get_emblem_icons(), which gives a list of user-set
emblems(Nautilus: keywords) and live-metadata
emblems(automatic-keywords), but without the possibility to distinguish.


- GInterface
   +----GEmblemableIcon: an extension of the GIcon interface. The vtable
would be something like:

void   (*add_emblem)   	(GEmblemableIcon* icon, GEmblem* emblem);
void   (*add_emblems)	(GEmblemableIcon* icon, GList* emblemlist);
GList* (*get_emblems)	(GEmblemableIcon* icon);

So the emblems would be stored very conveniently in a list together with
the icon which implements the interface (see below). This is also pretty
consistent with the way how Nautilus is processing and passing the
keywords/emblems.

Why having an Interface? The way I think of emblems is that they are
attached to an icon. So I tried to mimic that in the design. Another
advantage would be that one has less hassles with compability issues.
One can always pass an EmblembedIcon(see below) to a function which is
not aware of emblems at all and it can still handle the themedicon or
fileicon "underneath".


- GThemedIcon
  +----GEmblemedThemedIcon: inherits from GThemedIcon and implements the
GEmblemableIcon Interface

Probably something similar would be needed for the fileicons. But the
implementation is rather straight-forward.



Conclusion:

I would like now to come back briefly to yesterday's commit in
glib-gio(gemblemedicon.[hc]) by Matthias Clasen. I think that our
approaches are a bit different and I unfortunately don't see how to
bring both together in a consistent way, yet. Moreover, I fear having
troubles handling several emblems (which have to be nested in the case
of gemblemedicon) and being less flexible for other use cases designing
my other API(the one for the gathering of emblems, see above).
Also the gemblemedicon approach doesn't seem to be very consistent with
the way Nautilus is handling emblems now. But maybe I have missed
something and I want to leave that open for discussion.


I hope I made my design and the thoughts behind as clear as possible,
while hopefully not being too verbose. The design is also based on
discussions I had with a lot of very helpful people, mainly I want to
name Hans Petter Jansson, Cosimo Cecchi, of course my mentor Christian
Kellner and also Michael Monreal and Alexander Larsson, who I discussed
with during my application period.

Additionally, I studied the source of Nautilus and Thunar(in fact where
I say Nautilus the same holds for Thunar), which are the only real users
of emblems at the moment, yet and also a bunch of bugreports: feature
requests, regressions about emblems and so forth.


Of course it is hard to keep all the different thoughts, wishes, bugs &
use cases in mind.
However I maintain that the architecture above can tackle the current
problems, while providing a smooth transition and being flexible enough
for the future.



Best Regards


Clemens

ps. Feel free to contact me via email, XMPP:harlan at jabber.ccc.de or in
IRC:harlan

pps. A lot of the design is implemented as all the boilerplate code and
some of the functions. I will work on making it available asap.