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:[EMAIL PROTECTED] 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. _______________________________________________ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev