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.