I do write C code on a daily basis since 2001 and I don't know why I always believed that free(NULL) would crash, so I always used the painful construction:
if (p)
free(p);
Until yesterday! While talking to Lennart Poettering and we bet about that. Damn, I was so sure about it, but I'd really want to believe I was wrong, since I could avoid such stupid "if". Well, after we got David Zeuthen's phone we checked the free(3) man page and I was proved wrong!
Thanks Lennart, I owe you some bucks ;-)
I was invited to come to FOSSCamp this year, and of course I accepted. Travel from São Paulo to Prague was quite long (home to hotel time around 20hs), but it paid off: hotel is great, (un)conference is nice and lots of hackers to talk. It was great to discuss how your desktop and mobile device will work in future ;-)
Unlike other events, this is not a conference, thus the name "unconference", instead of fixed schedule with talks, we have lots of meeting rooms with good infrastructure (wifi, enough power sockets, tables...) that we can use to discuss about various issues.
Yesterday (Friday, May 16th) was the first and I participated in some desktop-oriented discussions. Some highlights:
- shorter release cycles: as was said everywhere last weeks, Mark pushed for shorter and coordinated release cycles (around 3months), so everyone can benefit;
- kde-gnome integration: there was various KDE-Gnome integration meetings with people from KDE (Lubos Lunak), Gnome (Vincent Untz), Amarok guys and others. I liked these meetings since still use KDE applications on my desktop and also because I want to represent E17 there, and then help Enlightenment to behave well. Discussios ranged whenever and how to integrate components like: bookmark format and location (XBEL?), Keyring & passwords, URI schemes and how to avoid fish:// vs. ssh:// problems, session management and trying to figure out a set of settings (double-click timeout, fonts, colors) that should be moved to a common place (X Settings?). After some discussions I'm skeptical of what will really happen: technologies are almost the same, but no group want to give up on their baby. I think it will require a 3rd party to develop or isolate the base (non-GUI) technology and then have both to use them, it make no sense to have 2 keyrings, virtual i/o, ...
- desktop search: I learned about XESAM and also raised some concerns about its use in embedded systems, that Jos van den Oever (vandenoever) wants to take a look. My initial hope was to provide some lightmediascanner (LMS) utility to integrate with XESAM, but their specification is based on DBus, XML and RDF, things that not couple well on small systems. IMHO XESAM should specify an API, a library to be used and if appropriated one can implement that library to use DBus and XML to forward it to some other daemon (like Beagle, Tracker or Strigi). Systems like Maemo or OpenMoko could just use simpler methods like LMS + SQLite. Having yet-another-process and possible transferring lots of data between processes on devices with very slow memory is not good, you gain nothing, just loose;
- inkscape, swfdec, svg, flash: another interesting meeting with Company (swfdec), Ted (inkscape) and others. Discussion ranged from why current toolkit sucks to cairo, x11, filters and more. Most problems are due the lack of people, both in X11 (to provide good drivers), GTK (to rework the widget internals), Cairo (to provide filters and optimizations)... I have to agree to the lack of people: while lots of companies invested in server-space, almost no investment was made in GUI, it's most about some individual efforts, and if you take into account the lines of code that both GUI and server requires, you'll see that GUI needs more. Mark asked us what we should use to develop an application like Canola, of course I said EFL, but others said "choose what you feel better, all the tools suck and you'd have to rely to some dirty tricks". With regard to effects/filters: unfortunately none of us have find "the magical solution" to make filters fast, so it boils down to lots of hand work to optimize some cases, cache others and avoid doing them often.
I'm often introducing new developers to Evas, part of the Enlightenment Foundation Libraries (EFL), and one common problem is to understand how Evas, Smart Objects and Edje integrates. Yesterday, while teaching some guys here at ProFUSION I came to the following picture, that describes it well:
Evas exposes just a handful object types, like solid color rectangle, gradient rectangles, images, text, text block, polygon, line and smart object.
Smart Object is the only special type because it's extensible and developers should implement its virtual methods to have it to behave like regular objects with calls like evas_object_color_set() or evas_object_resize(). Smart Objects do not have any visual representation, they can contain other objects that may have it, like images or rectangles, that's why they're represented like a box in the figure above. Their children are handled as if they were in a special layer: outside objects cannot interleave smart object children. It's recommended as good practice to not expose children to outside, instead provide methods to manipulate these children.
A regular mistake is to forget that just creating objects from inside smart object methods don't make them children! You must assign a parent to a child with evas_object_smart_member_add(child, parent). You can "unparent" them with evas_object_smart_member_del(child). As children can not have more than one parent, adding a new parent to the child will first remove its parent before adding the new one.
Edje is a smart object that loads a group of parts from a description file often called "EDJ" (or edje file). These files contains a collection of groups, each with a set of parts (evas objects), each part with various states. When a group is assigned to some Edje object with edje_object_file_set(object, file_name, group_name) the parts are created in order (first will go first, thus will stay at the bottom) using the "default" 0.0 state. If some part have relative positioning to the whole available space (Edje object geometry), when the edje object is changed, all the dependent parts are recalculated and have their geometry set. If some part is relative to other parts, then when one of these changes, the dependent part is recalculated and reset as well. One can manipulate edje by changing the state of the parts, this should be done by means of programs, which will act based on signals. Edje will dispatch some signals like "resize", "mouse,move" and "show", but users are encouraged to create their own application signals that can be emitted with edje_object_signal_emit(object, "signal", "source").
The most common mistake using Edje is to touch its children. Never, ever, change the object that you get with edje_object_part_object_get(). That call is for inspection purposes only. You're just allowed to change Edje by emitting signals from your application, EDJ should have programs to catch that signal and trigger some state change on some parts. Let's remember that it's recommended to never changed smart object children, Edje is strict, making this a rule. What can you expect if you break this rule? Before, I said that Edje would recalculate dependent parts when the dependency changes, but I lied: for simplicity purposes, when something change, Edje recalculates the whole thing, and it does so using the state information from EDJ, not the current value of the object. If you change the color of some rectangle from white to black, recalculation will enforce the rectangle to be white. Same for images, if you set the image file to be something else, it will be restored to the image specified in the EDJ.
One variation of this mistake is dealing with SWALLOW parts. These parts enable user to add an external object to be managed by Edje with the edje_object_part_swallow(object, "part_name", external_object). As said, Edje will manage this external object: it will become the object's parent, it will set clippers, colors, visibility and geometry. After that call, user don't own the object anymore, he is only allowed to change other, non managed properties, ie: images can have their file set because SWALLOW parts don't have any image property (unlike IMAGE parts!)
It's very important to understand these concepts. Real applications are a mix of smart objects and edje, one inside the other, which might led to great confusion if management ownership is not clear.
In the figure above we can see the management ownership to avoid these problems. User manages both the smart object and the background. In order to change the edje he should call some API defined in the smart object. To change the "star" image, user should call smart object that would call edje.
You can also download the printable version of the figure.
