Planète GNOME-FR

Today I wanted to locate an HSBC branch in London, close to either the office or my home. Thanks to HSBC I got upset before 8.

That starts fine, they have an "interactive map" or allow you to enter your postcode. Unfortunately they use only the beginning of the postcode (SW in my case) and then list you many towns in this area. Using the map stops at the same level. Then you click one of them (I should do all of them as I don't know some which may be close) and get No branch exists in ...

Is it so hard to list the closest ones from the given postcode or place them on a map? And what about just removing from the list the places without a branch?

Bugfixes and new translations.

To upgrade from previous version, run the following scripts:

1. sql/upgrade-sql-vtm-1.0.1-to-1.0.2.sql
2. sql/upgrade-sql-vtm-1.0.1-to-1.0.2.php

* MAJOR FIX to get the last user who has locked the module
* New $url_hosted_link and $url_hosted_name variables to set in
localconfig.inc.php
* FIX Sending of emails to the committers on 'Ready to commit'
* New Brazilian Portuguese translation by Leonardo Ferreira Fontenelle
* New Czech translation by Lucas Lommer (#237486)
* FIX #237472 reported by Lucas Lommer
VARCHAR > 255 needs MySQL 5.0.3 or later

I was a Fedora user until Fedora Core 6 but the second Ubuntu distribution was a really nice experience so I made the jump (fast packaging system, huge repo, etc).

Since 9.04 (or just before) I have been annoyed by the notification system NotifyOSD, I find disturbing to blur (or hide w/o compositing) the message on mouseover and the popup doesn't provide contextual actions. The Ayatana project get Ubuntu away from the upstream development (many patches to integrate libindicate, etc).

The Fedora Core 12 releases notes caught my attention and so many of my GNOME heroes (such as Alexander or Owen) work for Red Hat so after one test I  jump back. After one month, I'm still an happy Fedora user

What I like:

• yum is fast (for my needs)
• Eclipse packaging (CDT, valgrind, systemptap)
• all stable updates of GNOME
• good integration of PulseAudio with the kernel
• recent version of Empathy
• meta-package for development
• PackageKit
• rpmfusion is very useful to collect bytes from the dark side or for the freeworld (eg. font rendering)

What I don't like:

• wrong French keyboard by default
• easy_install is provided by setuptools-dev package not setuptools
• no sudo user by default
• the kernel updates doesn't update the default GRUB entry to the latest kernel
• SElinux (enabled by default on my desktop)
• no /etc/ld.so.conf.d/local.conf by default (for /usr/local/lib)
• gtags.el isn't in Emacs site-lisp directory
• you need to install control-center-extra to have access to Windows settings (that really sucks)!

Some would have named it OMG! GNOME SHELL! but Jon gave an excellent "Shell Yes!" talk at GUADEC (the videos, they are coming!), and that title is really nice so I decided to reuse it.

Many things are happening in and around the shell, but rare are those with the time to follow whatever happens in the git repositories, wiki pages, mailing list, or IRC channel. So here I am, I don't promise something very regular, this won't be the "weekly shell news", but whenever I get a stack of news, I'll try to post…

An initial design proposal for the date panel has been posted to the wiki : current time is always visible on the top bar, but expanding this panel gives additional information on world time and appointments.

The calendar widget shows days with appointments in bold and slightly lighter type. Current day is prelit with the same glow background as active items in the top bar. Selecting a day replaces the agenda on the right with one specific to that day. The panel uses a two column layout with a dotted line separator to avoid menu entries to span across very wide space.

Sean Wilson has been playing with CSS, creating a few alternative themes, even if themability is not a goal at the moment, this shows how well the technologies are suited to graphic experiments. It has been proposed to Sean to look into application startup animation, hopefully he will come with something really nice.

Codewise it has been a complicated ride since GTK+ 3 removed many GDK drawing functions, that were used by librsvg, Mutter and others, but things are getting in shape again, and we should be back to the normal situation where building and testing the Shell is easy.

This also delayed the new design, presented at GUADEC, as Florian put that branch to rest during the breakage, he is now getting back to it, with platform stability coming back we will sure get it soon.

As mentioned in my previous post, Bugzilla and translations project setup were still pending.

I've got a brand new netbook to test MeeGo images I'm generating and I thought it could be useful to have some comparisons data regarding boot speed across the various distributions available, on the same hardware (even if it is considered as a low-entry system, it shares the same kind of hardware as most netbooks around)

Hardware : eMachines M350 : CPU : Intel Atom N450 1.66GHz, 1GB memory, 160GB hard-disk

Test was done with system running on AC power and with Ethernet cable plugged. Each distribution was installed then updated to latest bugfix / security updates and rebooted several time to ensure readahead (or similar mecanism) were working properly (when available)



Values there are not extremely precise (I used my watch to measure them) but bootcharts data (measured with each distribution integrated bootchart tool, which explains why they don't display the same data) are available at http://www.gnome.org/~fcrozat/bootchart/

• Win XP preinstalled with the netbook:
• 56s : user interface visible (but still stuff running in the background)
• 1min27s : ready
• JoliCloud 1.0 :
• 36s to get to gdm
• 1min 16s (to get from grub to main interface ready, in autologin mode)
• Mandriva 2010 Spring (GNOME)
• 34s to get to gdm
• 48s (to get from grub to main interface ready, in autologin mode)
• Fedora 13 :
• 41s to get gdm
• 55s (grub to main interface ready, autologin, with readahead enabled)
• Ubuntu 10.04 Netbook
• 25s to gdm
• 36s (grub to main interface "ready", mouse cursor no longer busy), but interface visible and usable at 26s
• Ubuntu 10.04 Desktop (GNOME)
• 22s to gdm
• 27s (grub to main interface "ready", mouse cursor no longer busy)
• openSUSE 11.3 (GNOME) (with preload working)
• 37s to gdm
• 55s (grub to system ready)
• Intel MeeGo 1.0.2 :
• 25s (after first boot)
• 18s (bootloader to system ready) with sreadahead working
• SUSE Meego 1.0:
• 24s (bootloader to system ready), without prelink
• 20s (bootloader to system ready), without prelink when sreadahead is done
• 17s (bootloader to system ready), with prelink + sreadahead

I've been at Novell for two years and a half now, and it's been an interesting ride. I must say I've had two amazing bosses who understand the way I work and who have been really supportive, so that definitely helps! I don't know if Klaas will stand me much longer, though ;-) In addition to that, being part of the Boosters is a good way to be with people as crazy as I am, working on weird stuff like me.

Of course, it has been hard to see good people leave the company in the past few months — they are generally still involved upstream, though, so that's positive :-) But recently, we've been joined by two friends: Frédéric, who's working on SUSE Meego, and Jos, the new openSUSE community manager. And guess what? We expect more! Because we're still hiring:

• the very same team I'm part of (remember, the crazy people) is looking for a new member. The job description is, well, you know, a job description ;-) What is most important, in my opinion, is that we're looking for someone who understands free software communities: the goal of the team is to grow the openSUSE community by enabling the community, and we're having fun with that! You can have the right profile even if you don't know the openSUSE community well at the moment: for example, it's totally fine to come from upstream (some of us do have an upstream-only background). I heard that some people even wonder if it's normal to get paid for such a job. But yes, you will get paid. To apply, go here and use the openSUSE booster keywords.

• our SLED team is looking for a GNOME developer to help with the maintenance and the development of SLED, and I certainly hope that this developer will also work with the GNOME team in openSUSE :-) If you enjoy fixing bugs and adding some nice features that make a difference to users, this could be a good position for you! To apply, go here and use the SLED GNOME keywords.

If you want to chat about any of those jobs or about how it feels to work at Novell, don't hesitate to ping me!

I found today the API documentation to use http://www.google.com/loc/json in order to get a location from the seen wifi APs or GSM/CDMA cells.

It is very easy to use:

$ curl -X POST -d '{
  "version": "1.1.0",
  "host": "perdu.com",
  "request_address": true,
  "address_language": "en_GB",
  "wifi_towers": [
    {
      "mac_address": "56:7a:e8:68:15:4B"
    }
  ]
}' https://www.google.com/loc/json
{"location":{"latitude":48.868646,"longitude":2.355392,"address":{
"country":"France","country_code":"FR","region":"Ile-de-France","county":"Paris",
"city":"Paris","street":"Rue Sainte-Apolline","street_number":"2","postal_code":"75003"
},"accuracy":150.0},"access_token":"2:yWOkYM4kI79VH1Bj:cvMZFkJhXSflywZB"}

I guess this is what was used for this attack, and this seems to be used by Firefox and Chrome geolocation features.

Update: I found on http://code.google.com/p/gears/wiki/GeolocationAPI the following note: "Note that the JSON protocol described here and at http://code.google.com/apis/gears/geolocation_network_protocol.html is published to allow developers to provide their own network location server for use through the Gears API. Google's network location server is only to be used through the Gears API", so this is nice but you can't use it.

GUADEC Open Space by Sense Hofstede (Creative Commons by-sa)

See my previous post for the first GUADEC tidbits.

• Of course, Fernando and Xan's talk was a great moment!

• Apparently, I was not for sale (I didn't know, or well, I knew it). And the result is that someone I won't name (let's call this someone Kat) tried to buy me. Without success.

• Sílvia and Gil won the GNOME Pants this year! Woo! It's a bit sad that they chose to wear it only during the Collabora party: they pretended they were not the right size...

• I had quit an interesting chat with Luis during the Collabora party. I liked his keynote.

• Gustavo and I are invincible at table football when in the same team. Mwahahaha!

• Some people didn't know how to easily get GNOME Shell running from GDM. I hope that by now, most distributions do something like openSUSE, where you can select a GNOME 3 Preview session in GDM.

• Ryan made some I support the release team stickers. Sweet. He also made some that used a cryptic vuntz 3.0 message...

• Bastien didn't win the FreeFa Cup 2010. Good: it's a tradition :-)

• Jos, the new openSUSE community manager, happens to live just a few kilometers away from the Hague. He was still at his previous work back then, but we were able to share a dinner before the Canonical party.

• I got a very nice Openismus t-shirt (thanks Kat!). I was told there's a fox on it. I see a cat.

• Lennart now loves me.

• In reaction to the I support the release team stickers, we got a great "Down with the release team" banner. I loved it :-)

• It was great to have more time with Dominique, one famous openSUSE hero.

• I finally found two secret git repositories used by designers: gnome-design and gnome-shell-design.

• Bastien and I tried to send a poster to a generous Friends of GNOME donor. During 45 minutes, we walked around, asked people, looked on maps, etc. to find a post office. And when we found one, it didn't have what we needed to send the poster. Oops!

• Didier helped me find a real post office on Saturday. And there we were able to send the Friends of GNOME poster.

• I was finally able to chat with Adam from Yorba. I've been wanting to meet the great people at Yorba for a long time!

• Some people are talking about a French Conspiracy. I don't know why. Anyway, after Reinout's closing speech, Bastien and I went on with the closing ceremony together.

• The Foundation released three press release this week. Many thanks to Zonker for his help for this!

• The next GUADEC will be in Berlin, with Akademy! I'm already excited!

Cette année encore, l'association Autres-M-Ondes et plusieurs radios, dont Panik, organisent une radio éphémère sur le festival Esperanzah!; même dispositif que ce qui était utilisé pour radio RMLL, en plus gros, vingt personnes, deux studios, captation des concerts, etc.

De mon côté je m'occuperai encore, pas tout seul heureusement, du montage des interviews, cartes blanches et cie, et des concerts, et on publiera un maximum de tout ça en podcasts au fil des jours sur le site de radio Esperanzah!.

GUADEC 2010 was great (as always), meeting unknown and new faces, attending great talks. My favorite was Open Design Thinking Workshop and I hope InventedHere.de folks will be to future GUADECs and maybe other events, like FOSDEM (hint, hint).


I guess most people who discussed with me there knew already and  Michael already let the cat out of the bag: I've joined Novell, to work on SUSE MeeGo.

I was delighted to see that the GNOME Census presentation I gave yesterday at GUADEC has gotten a lot of attention. And I’m pleased to announce a change of plan from what I presented yesterday: The report is now available under a Creative Commons license.

Why the change of heart? My intention was never to make a fortune with the report, my main priority was covering my costs and time spent. And after 24 hours, I’ve achieved that. I have had several press requests for the full report, and requests from clients to be allowed to use the report both with press and with their clients.

This solution is the best for all involved, I think – I have covered my costs, the community (and everyone else) gets their hands on the report with analysis as soon as possible, and my clients are happy to have the report available under a license which allows them to use it freely.

You can download the full report now for free.

Once again I'm attending GUADEC thanks to my employer Collabora. There are certainly a lot of interesting things going on during these 3 days but I'd like to highlight 2 events that you certainly don't want to miss.

The traditional Collabora GUADEC party will take place on Thursday night at 7pm and will be a barbecue over the beach! Check the parties map for the exact location.

Friday at 9:30 am I'll give a talk called GNOME 3: the Telepathic Desktop. The first part of the talk will be some kind of overview of the cool new stuff we have recently added to the Telepathy framework or which should land soon. I'll also talk about the work we have done to make Telepathy easier to use by third party applications. The second part of the talk will present new features we have added to Empathy during this cycle. I'll also focus on integration of Telepathy in the GNOME desktop in general. I'll have some demos to show hoping they won't fail horribly. :)

Hope to see you there. I know that's pretty early in the morning, especially after the Collabora party but I'll be there in time so you don't have any excuse. :p

edit: Seems there is a live stream of sessions so you should be able to watch the talk even if you are not at the conference.

(Reposted from Neary Consulting)

Today at GUADEC I presented the results (Slides are now on slideshare) of the GNOME Census, a project we have been working on for a while. For as long as I have been involved in GNOME, press, analysts, potential partners and advisory board members have been asking us: How big is GNOME? How many paid developers are there? Who writes all this software, and why?

By looking at the modules in the GNOME 2.30 release, made last March, we aim to answer many of those questions, and give deeper insight into the motivations of participants in the project.

Here are our key findings:

• GNOME has a rhythm – there is a measurable increase in activity before release time, and after the annual GNOME conference GUADEC
• While over 70% of GNOME developers identify themselves as volunteers, over 70% of the commits to the GNOME releases are made by paid contributors
• Red Hat are the biggest contributor to the GNOME project and its core dependencies. Red Hat employees have made almost 17% of all commits we measured, and 11 of the top 20 GNOME committers of all time are current or past Red Hat employees. Novell and Collabora are also on the podium.
• A number of top company contributors are consultancy/services companies specialising in the GNOME platform – Collabora, CodeThink, Openismus, Lanedo and Fluendo are in the top 20 companies. As many of these companies grew initially through work on Maemo, this is a sign of the success of Nokia’s strategy around the GNOME stack.

One of the interesting things that we have done for the census is to look at who is maintaining modules by looking at commits over the past two years, and use this data to identify areas of the platform which see lots of collaboration, areas where the maintenance burden is left to volunteers, and areas where individual companies assume most of the maintenance burden.

There are a number of modules in the platform which see a considerable amount of co-opetition, including Evolution, Evolution Data Server, DBus and GStreamer. Most modules in the platform, however, are either maintained to a large extent by volunteer developers, or see the vast majority of their contributions from one company.

I see this information being useful for companies interested in using the GNOME platform for their products, companies seeking custom application development, potential large-scale customers of desktop Linux or customers buying high-level support who want to know who employs more module maintainers or committers to the project.

Update: Two significant omissions in the maintenance map were pointed out to me. After correctly associating a number of commiters to a company, Lanedo is responsible for 16.5% of the commits in GTK+ over the past two years, and volunteers are also responsible for at least 17%. Red Hat are still the largest contributor, with 32% of all commits to the module. libsoup is maintained by Dan Winship, who left Novell to join Red Hat in 2007, where he developed and maintains the module.

Update 2: As I announced in this post, the report is now available as a free download via neary-consulting.com licensed as Creative Commons by-sa 3.0

En fait, tout est dans le titre :)

La semaine dernière, j'étais à Prague pour le distro sprint… enfin distro rally maintenant^[1] où les employés de Canonical travaillant sur ubuntu se retrouvent pour une semaine de bière travail. :) Malgré une tentative d'assassinat de Robert Ancell (développeur de gcalctool, également membre de la desktop team) lors d'une soirée de kart où il a sauté sur le mien^[2] tout s'est bien passé et beaucoup de progrès et de nouvelles features arrivent pour l'alpha3. Je ne vais pas les détailler ici, vous les verrez bien assez tôt ;)

De Prague, nous nous sommes envolés pour Amsterdam, puis pris le train pour la Haye, où le GUADEC (rencontre des développeurs GNOME) bat son plein.

J'essaierais de détailler un peu plus si le temps (et la connexion Internet) le permet, mais en attendant, voici quelques photos:

Ceux qui me connaissent me reconnaitront en train de travailler activement pendant une discussion avec les développeurs de Shotwell qui sera très certainement l'outil de visionnage par défaut d'Ubuntu 10.10(.10). Pour information, c'est déjà le cas pour la version netbook (UNE).

Ubuntu-fr tenait un stand ainsi qu'une install party lors des RMLL 2010. Une fois de plus, je vois cet évènement plus comme un évènement social que technique, et les retours et échanges humains^[1] ont rendu la chaleur de Bordeaux supportable. :)

J'ai moi-même donné deux conférences (une sur bughugger qui a failli à cause d'une connexion Internet douteuse) et une sur Quickly qui ont, je pense, touchées leur public.

En plus de rencontrer des veilles connaissances^[2] comme Vincent Untz, Frédéric Peters, framasoft^[3] le CA de l'April, fedora, mandriva, opensuse, et bien entendu toute la clique ubuntu-fr, j'ai eu le plaisir de faire connaissance avec ubuntu-lyon et quelques nouvelles têtes du TCT^[4]. Merci à eux pour les bons moments partagés^[5]!

Bref, il est temps de rentrer avant une semaine de travail chargée.

PS: Évidemment, nous avons enfin pu profiter d'une glace ensemble pour terminer les RMLL en beauté !

As a good GNOME citizen, Empathy 3.0 will have to be able to build with GTK+3. As Ubuntu is not going to ship GTK+3 by default in its next release, we decided to stay compatible with GTK+2 for this cycle.

Empathy already built with GSEAL checks so porting was just a matter of playing with autoconf. Libraries linking to GTK+ itself have to be updated as we can't use GTK+2 and GTK+3 in the same process:

• libcanberra-gtk, webkit-gtk and libunique now have releases using GTK+3 instead of GTK+2 so all we had to do was to change the PKG_CHECK_MODULES calls to check for the -3 flavour of the libs.

• nautilus-sendto plugin has been ported as well since 2.90.0 but it breaks its public API so we had to do some #ifdef magic to stay compatible with older versions.

• Since 0.5.1 libnotify doesn't link on GTK+ any more but use GModule instead (Thanks Bastien!) so we just had to make sure that this version was used when building with GTK+3.

• Unfortunately clutter-gtk and champlain haven't been ported to GTK+3 yet so we had to disable champlain support for now. I hope to see a port of these libs soon.

During configure, we check if GTK+3 is present; if it is then we check for these new version of the deps. If it's not or if Empathy has been configured with --enable-gtk3=no then we continue to use GTK+2 and the old versions of the libs.

If you're interested in details, everything has been merged to master so you just have to look at Empathy's configure.ac file.

This should hopefully make all the distributions happy during the transition. Once Empathy 3.0 is released we'll drop GTK+2 compatiblity and will start using the fancy new features offered by GTK+3.

A couple months ago, Facebook announced announced that their chat system would also be available through XMPP. So it is possible to just configure it like any other Jabber server on a N900. And then to merge Facebook contacts with other contacts and it the address book will store it as a field of type « X-JABBER ».  Since the PR1.2 version of Maemo5, Nokia has added a specific profile for Facebook to the N900 software. But instead of calling the address book field « X-JABBER », they created a « X-FACEBOOK » field (since Facebook Chat is not XMPP in the backend, it can not talk to other Jabber servers). So if you remove your old Jabber account and re-add it as a Facebook account and use Marco’s contact merger to merge back the contacts. You’re still stuck with a bunch of extra « X-JABBER » fields in your contacts. So to clean them up, I wrote a really simple program to remove them. It is based on Marco’s jid-to-email program. You can get the source code or a precompiled binary. You can just put the binary on your N900 and run it from the Terminal as « ~/MyDocs/remove-old-facebook » (if you put it in the N900’s documents root). Be warned that is is not a good example like Marco’s code, I stripped all error handling and it never frees anything. If you want a good example, look at Marco’s code.

About a month and a half ago, I had a smallish bike accident, I did not have a single scratch, but I managed to fall right on my N900 and crack the LCD. So I’ve used a Nexus One as a replacement until I managed to fix the N900. That gave me a chance to compare them.

You should also know that I am entirely biaised as I was paid to make the VVoIP calling on Maemo incredibly awesome. I have no relationship with  Google and they did not pay me to make their stuff awesome (so it is not awesome). The opinions stated here are mine and mine only. They are not approved by my employer Collabora, any of our clients or competitors, the Queen or anyone else than me.

I’m comparing both devices with the latest software version as delivered by their respective OTA update system. So it is Maemo 5 PR1.2 for the N900 and Android 2.1 (Eclair) for the Nexus One. I make no claim of fairness. This is not a guide to chose which phone to buy.

Browser:

• Extensions: The N900 browser supports (badly) a few Firefox extensions (like Adblock Plus or Greasemonkey). That said, they’re already quite useful. Maemo +1
• Windows:  Maemo 5 also handles multiple windows as regular windows, while the Android browser has them hidden in a menu. I did not discover that menu until I had a « Too many windows open, can not open new window » pop up. Also, the way « popup windows » appear in Android is really annoying, especially the fact that they are hard (impossible?) to zoom. Maemo +1
• Flash:  It’s not really usable (more like really unusable). Flash video playback is really slow (since all decoding is done in software). Steve is right, Flash is a disaster on mobile devices. Maemo -1
• Text column width cheating and reflowing: The Android browser has a nice feature where it scales the width of text columns to the screen width to be nicely readable. It tends to break the layout of some sites, but it’s well worth it. Opera Mobile seems to do the same thing. But the Maemo browser doesn’t. Newer Firefox Mobile builds seem to also lack that. This means it is also unusable in vertical mode. Android +1
• Scrolling performance: The Maemo browser uses tiles for when scrolling, so if you scroll too fast, it has to work real hard to render the next tile. It was much smoother on Android. That said, I heard the Mozilla people are trying to fix this in Fennec 2. Android +1
• Rotation: The vertical mode of the Android browser just works better than the half-baked rotation support in Maemo 5.  And holding it in one hand is much easier if its vertical. Android +1

Browser totals:   Maemo 1- Android 3

Contacts & IM:

• IM protocols: Android only supports Google Talk out of the box, while Maemo supports  Skype, SIP and XMPP (including Google Talk) right of out of the box. And it is easy to add 3rd party support for other protocols (MSN, Yahoo!, etc) and it integrates fully into the existing system. Maemo +2
• SMS/IM integration: SMS and IM are entirely separate in Android, but they are the same app in Maemo. Maemo +1
• Metacontacts: Both platforms have metacontacts. Sadly, they are both incomplete. Contacts in both platforms include the basics: name, nickname, phone, email. Maemo can also link contacts from all IM accounts together, while Android only does it for Google Talk. But Android applications can put their own info in the contacts, so you can link in Facebook and Twitter contacts easily. On Maemo, well you can do it with Hermes, but you still don’t get the phone number or email address from Facebook (blame them for it). Equal points
• Synchronisation: Out of the box, Android only supports synchronization with Google’s servers. Maemo only supports SyncML over USB (not over http) or Mail for Exchange. No points.

Contacts & IM totals: Maemo 3 – Android 0

Calling:

• Ringtone: The Nexus One ringtones are just not loud enough. I’ve missed many calls because I just didn’t hear it. My colleague complained it wasn’t loud enough to wake him up making it useless as an alarm clock. That’s a pretty big fault for a phone. Nexus One -2
• Voice quality: I did not do any objective testing, but I feel that despite the active noise cancellation of the Nexus One (with a second microphone), I can still hear calls better on the N900. N900 +1
• VoIP:  Android only has Google Voice (only works in the US) built in. Skype is only available from select providers. And I could not get any of the 10 SIP apps in the Market to work with SipPhone.com (a Google service). So no VoIP on Android for me. On the other hand, the N900 has excellent VoIP support (I know its excellent, it uses Farsight2, my project!). Out of the box, it supports Skype, SIP as well as XMPP Jingle calls. That means Maemo support Google Talk compatible calls, but not Android. How ironic. Maemo +2
• Video calls: There is no front-facing camera on the Nexus One. The N900 has awesome video calls, including GMail compatible calls (a mobile first)! As well as Skype compatible video calls (another mobile first). Maemo +1
• Accepting calls: The « incoming call » screen on Android has slide buttons. On Maemo 5, it has push buttons. Combined that with the fact that is auto-unlocks the screen when it rings and with the resistive screen, it means that I sometimes accidentally hang up or answer in my pocket. Really annoying. Maemo -1

Calling totals: N900 3 (Maemo 2) – Nexus one -2

E-Mail:

• Both devices have email clients supporting IMAP. Android also has a separate application for GMail. Since I don’t use GMail, I did not try it seriously.
• Combined inbox: Android has a nice feature where the inboxes of all account are shown at once. Android +1
• Searching: It’s a funny thing. The Android mail application does not have any search feature. At least, Modest (the Maemo email client) has gained minimal searching in PR1.2. Maemo +0.5
• Performance: The android mail app just feels faster and doesn’t get stuck waiting for God knows what all the time. Android +2

E-Mail totals:  Maemo 0.5 – Android 3

Maps:

• Overall: The Ovi Maps application for Maemo is a disaster, Google Maps just works on Android. Android +1 Maemo -1 (I’m giving a -1 because Ovi maps is so disappointing, they should have released the device without it)
• Network access: That said, Ovi Maps has one nice things, you can download maps, while Google Maps is just pre-rendered tiles, which means it always requires Internet Access.  Maemo +1
• Navigation: Google has free navigation (in select countries), Ovi Maps for Maemo does not have navigation. Android +1
• Voice commands: Android has them (including search), Maemo does not. Android +1
• Search: Google Maps has Google search.. Ovi Maps has some crappy search that fails half the time if you don’t spell the address exactly the way it expects it. Ovi Maps can not search for things that are not addresses (like a restaurant ou a gaz station). Android +2
• Extras: Google Maps also does nice things like public transit. I wish they had bike routes in Canada. Android +1

Maps totals: Maemo 0 – Android 6

Camera & Photos:

• Camera Hardware: Both devices have 5 mega pixel cameras and they seem to have more or less similar performance. That said, I did not do any serious comparison. Equal points
• Photo browser: The Android Gallery has a bit more bling, but it is the only built-in app that I’ve seen crash on the Nexus One. But functionality-wise, they seem pretty similar. Equal points
• Button: The N900 has a hardware camera button. On the Nexus One, it is an on screen button. Touching the on-screen button while holding the camera in the right direction is really hard. N900 +1

Camera & Photos total: N900 1 – Android 0

Hardware:

• Size: The Nexus One is quite a bit thinner, the N900 is a pretty bulky device. Good thing I don’t like thigh pants. Nexus One +1
• Keyboard: The N900 has one, the Nexus One doesn’t. I though it was a fatal flaw until I discovered Swype, which is really awesome… if you only write in one language. But I write in both French and English.. Sometimes I send one message in French and the next one in English.. Sometimes I mix languages in the same message. Swype only does one language at a time. That’s not a problem with the keyboard. So N900 +1
• Screen resolution: The same. Equal points
• Touch screen: The N900 has a resistive touch screen, the Nexus One has a capacitive screen. Everyone is saying that capacitive touchscreens are nicer… I’m unconvinced. Yes, you need more pressure on the N900.. But the Nexus One’s screen sometimes strangely fails to react. It is also much less precise. That said, resistive screens have the annoying habit of reacting to pockets (especially annoying when it rings). Equal points
• Digital compass: The Nexus One has one, N900 doesn’t. Nexus One +0.5
• Volume buttons: On Android, when not in the music app or in a call, the volume button control the ringer volume. That means it’s really easy to turn it even lower than it already is. This is especially annoying sine the Nexus One volume buttons are too easy to push. Nexus One -1
• Included Flash memory: The N900 has 32 GB. The Nexus One has none. Both have a microSD slot. The Nexus One did come with a 4GB card. That’s just not enough, I have 7 GB just for music on my N900, and that replaced a full 30GB iPod. N900 +2
• TV out: The N900 has TV-out, the Nexus One doesn’t. I though it was completely useless (its just analog low def). But it was really useful when I cracked the LCD. N900 +0.5
• Bands: The Nexus One is available in both AT&T/Rogers/Bell/Telus (850/1900) and T-Mobile USA (900/1700) bands for 3G. The N900 is only sold for the T-Mobile USA band (900/1700). Which mean no 3G in Quebec until Videotron launches its network (and they are one year late already). Both phones support the European 2100 band. And they’re both quand-band for GSM/EDGE. Nexus One +1
• FM transmitter/receiver: The N900 has a FM transmitter and a FM receiver. I’ve only used them briefly. N900 +0.5
• Speakers: The build-in speaker of the Nexus One is terrible, the N900 has some of the best stereo speakers I’ve seen on this kind of device. N900 +1

Hardware totals: N900 5 – Nexus One 1.5

3rd Applications:

• Availability: There are lots of apps on the Android store. There are TWO paid games on the Ovi store for the N900 as of today (when it is not down). That said, Maemo has a lot of ports of existing Open Source apps in Maemo Extras. That said, many of the apps in the Android Market are terrible…  Android +1
• Application installer: The Android Market (which also acts as an app installer) just works. The Maemo 5 application installer is a complete disaster. It is user hostile and developer hostile. Maemo -1
• Developer story: Nokia decided to scrap most of the Maemo 5 platform and review everything with a brand new toolkit. They’re completely unable to get a straight story about developer APIs. I think that is in part because they also want people to do Symbian apps. Nokia please, please, just forget about Symbian apps, just use J2ME like on S40. Google has provided a stable Java API.. But not a stable C/C++ API. Maemo -2
• Python: A lot of the Maemo apps are in Python and therefore are memory hungry (on a memory starved device). Maemo -1

3rd Application totals: Maemo -4 – Android 1

User experience:

• Maemo’s greatest weakness is the out of memory handling. There is only 256 megs of RAM and 768 megs of swap. That means that as soon as you do too many things, it starts swapping and the performance becomes terrible. This is made even worst by the fact that application startup is really slow, so many applications are in pre-started. Nokia should put a lot more memory in the next device and seriously fix the application startup time. Android has a nice thing where apps can serialize their content and be shut down when the system in under memory pressure. This leads to a much better impression of performance. Android +4
• CPU speed: The Nexus One has a 1Ghz Qualcomm Snapdragon CPU, much faster than the 600Mhz TI OMAP 3430 of the N900. Nexus One +1
• The real « multitasking » is much nicer in Maemo5, Android just fakes multitasking by having applications save their state and restart at the same point. That means you can not load two web pages at the same time or anything like that. Maemo +1
• Both have multiple desktops with applets. Sadly, when I load my N900 desktops with applets, the system becomes sluggish. Maemo -0.5

User experience totals: Maemo 0.5 – Nexus One 6 (Android 4)

Geek experience:

• Maemo is the ultimate mobile Geek OS. Having an x-term built-in is just amazing. Maemo +3
• Maemo is a real Linux desktop-like operating system. To anyone who knows Linux, it just feels right. Android is the Linux kernel + Android. It was done in secret in a corner and Google has not made any serious attempt to join the great community. They re-wrote everything from scratch all the way to writing their own libc. Maemo +2
• The choice language on Android is Java (beurk!). On Maemo is it C (or C++). Maemo +1

Geek experience totals: Maemo 6 – Android 0

Other stuff:

• Media player: I didn’t really try the Android media player since there isn’t enough space on the SD card to hold any significant amount of music.
• Notes: Android does not seem to come with a built-in notes apps. The Maemo Notes app is just pretty bad. They could have just shipped ConBoy instead…
• PDF reader: the PDF reader on Maemo 5 is terrible, the Android one seemed kind of ok (but not great either)
• RSS Reader: Does Android have one? I use the web-based Google Reader anyway

Total: N900 16 (Maemo 9) – Nexus One  17.5 (Android 17)

The Nexus One is really being dragged down by its its hardware. Especially when it comes to the bad speaker quality and the low ringer volume.. Did I mention how much it annoyed me ? That said, Android is pretty good. Better IM integration would be a  big plus. And some VoIP too.

Our Nokian friends have their work cut out for them. First, they need to fix the memory handling story on Meego. Running out of memory and swapping all the time is just annoying. An almost desktop-class operating system requires desktop-class amounts of RAM (that means more of it). Ovi Maps needs a lot of work, hopefully they can work a deal with Google to get decent search in there.  The browser could get its share of small screen friendliness and a performance upgrade. If they fix these few problems, Meego (as the future of Maemo is called) could very well be a success.

Were it not for its high geek factor (built-in X Terminal!), the N900 would have lost badly. That said, it’s still my favorite phone ever (did I mention I was horribly biaised?)

A few weeks ago my shuttle box stopped booting. For the record, it's a one year old core2quad box with 8 gigabytes of memory and 1.5 Terabytes of hard disk. All packed in a little box that is no wider than an A4 sheet of paper.

When I hit the power button the fans would start rotating a little bit, maybe 25° and then nothing. The LEDs of the motherboards stay lit but nothing happens.

I opened the box, wiped the dust from the fans, measured the voltage and current coming out from the pins of the power supply. Both current and voltage were a bit lower than expected, but to my surprise, the box did boot again. I made sure my hourly incremental backup (rsync powered!) was doing OK, and I went back to hacking G++ as usual.

Then last Tuesday the box stopped working again. This time I removed most of the parts from the motherboard: Hard disk, DVD burner, memory sticks one by one. Each time I remove of a part, I'd try to power the box on. Still nothing.

At that point, I thought it was either the mother board or the power supply that was at fault. But how would I know? I bet it was the power supply as it was the less expensive part to replace :) So I did the "power supply paper clip test" and it appeared that the odds of the power supply unit being broken were quite high.

I figured I should probably order a more powerful power supply as the 300 Watts of the current one were probably a bit too tight for my usage.
I ordered a 500 Watts PSU (power supply unit) and got it two days later. And yes, the PSU was indeed the culprit!

Let's see how long is this new PSU going to serve.

A brief history of plugin support in Gedit (and Gnome)

Gedit is one of the oldest softwares of the Gnome fame, and it got a major overhaul in time for Gnome 2.14. This was an eternity ago: the new mdi branch was merged in late 2005. This nearly full rewrite dropped many then-obsolete dependencies (BonoboUI, popt) and introduced many innovations over the previous versions, some of those spreading into the whole Gnome project.

One of the best known innovations was a replacement for all those annoying dialog boxes that popped for very good reasons at the worst possible moment. Understanding that those messages were very contextual in nature (they were always related to a particular document in some tab), the dialog boxes were replaced by coloured message areas embedded directly in the tab. This brand new idea got used by several other applications, and eventually got into Gtk+ lately under the name “GtkInfoBar”.

Another of those innovations was the brand new plugin capabilities it offered. At that time, it was possible to extend Gedit with C plugins for a long time, but with Gedit 2.14 came a few new capabilities:

Object-Oriented Plugins. From then on, plugins were objects that inherited from a base plugin class. Overriding virtual methods became the standard way of defining the plugin behaviour. And this was nice, as more and more people are familiar with object-oriented programming these days.

Python Plugins. PyGTK was in a very good state and Epiphany, the web browser everyone likes, was already using it to give access to its internals to python developpers. Gedit borrowed it and extended it to allow writing plugins as python objects as well.

This plugins engine has been very successful, and a lot of specialised plugins appeared in a few years. It was also transplanted to a lot of other Gnome applications (Eye of Gnome, Rhythmbox and Totem to cite the most prominent ones) but we never made a library out of it: creating and maintaining python bindings was time consuming and tedious, and it didn't make sense to have a library if every users of it would have to duplicate half of the code anyway.

But things have changed...

Thanks to the recent gobject-introspection project, “immediate” bindings are flourishing. Out of a single easily generated introspection dataset, it is now possible to benefit from full bindings for several languages, including Python (through PyGI) and the new kid in town, Javascript (through Seed or GJS). In total contrast with the old “PyGTK way”, bindings are now generated in minutes and require close to no maintainance and very few specific code. This fact alone creates the ideal condition for a librarified version of the Gedit plugins engine.

Introducing libpeas

This is why I am very proud to announce the first release of libpeas. libpeas is the next evolution of the Gedit plugins engine, and is targetted at giving every application the chance to assume its own extensibility. It also has a set of enhanced features with regard to what Gedit used to provide, mirroring the desiderata of your favourite text editor's developpers.

Multiple extension points. One of the most frustrating limitations of the Gedit plugins engine was that it only allows extending a single class, called GeditPlugin. With libpeas, this limitation vanishes, and the application writer is now able to provide a set of GInterfaces the plugin writer will be able to implement as his plugin requires.

On-demand programming language support. libpeas comes with a set of supported languages (currently, C, Python and Javascript). Those languages are supported through “loaders” which are loaded on demand. What it means is that you only pay for what you use: if you have no Python plugin, the Python interpreter won't be loaded in memory. Of course, the same goes for the C and for the Seed/JS loader.

Damn simple to use (or at least we try hard). Adding support for libpeas-enabled plugins in your own application is a matter of minutes. You only have to create an instance of the plugins engine, and call methods on the implementations of the various extension points. That's it, no clock harmed.

A shared library for everyone. As I noted earlier, the latest improvements of our beloved development platform made it possible to create bindings for apps very quickly. And with the Gnome 3 announcement, this looked like the perfect timing to make the plugins engine and its latest improvements available to everyone, with a library. Also, hopefully it will reduce code duplication and allow bugs to be fixed at the right place, once and for all, improving the quality of our applications.

As a member of the Gnome community and as an offspring of gedit, libpeas already shares most of the Gnome infrastructure and philosophy:

• You can download the first release tarball on the Gnome FTP server.
• You can browse the source and contribute using our git repository.
• You can come and discuss with me and others on #libpeas (GimpNet)
• And you can report bug or propose new features through the good old Gnome Bugzilla, against the libpeas module.

Many many thanks for their support to those who made this possible, and especially to the current very active gedit team (Paolo Borelli, Jesse van den Kieboom, Ignacio Casal Quinteiro and Garett Regier)

A few hints on using libpeas

As always for the new projects, it can take some time to grasp all the subtleties at first.

Plugins versus Extensions.

Something that is going to puzzle most of the newcomers is the fact that the libpeas API talks about both plugins and extensions, two terms that are usually used interchangeably, but who have very different meanings in libpeas.

Let's try and give a definition of both of these words in this context:

Plugin. In the context of libpeas, a plugin is a logical package. It's what you will enable or disable from the UI, and at the end it is what the user will see. An example of plugin for gedit would be the file browser plugin.

Extension. An extension is an object which implements an interface associated to an extension point. There can be several extensions in a single plugin. Examples of extensions provided by the file browser plugin would be the configuration dialog, the left panel pane and a completion provider for file names.

Building libpeas

Building libpeas is quite straightforward. But you need to be careful to build pygobject with the --enable-pygi option if you plan on using the Python bindings capability, or you will experience weird bugs.

Sample code

The libpeas package contains a sample application called peas-demo, and sample plugins written in C, Python and Javascript.

I'm not going to cut and paste a lot of code here, but the global idea is this one: you create a new PeasEngine instance and give it the information needed for it to find your plugins. Then you load some plugins (you can use the PeasUIPluginManager for that purpose) and perform actions through some PeasExtensions objects you can get from the engine.

PeasEngine. The engine is the main object for the libpeas integration. It will handle the loading and unloading of the various plugins, and it will give you PeasExtensions.

PeasPluginInfo. The plugin info object contains all the information about a plugin. It is available even when the plugin is not loaded.

PeasExtension. This is an extension, as seen from the application point of view. It is actually a proxy to the real extension, and provides a single peas_extension_call method that will allow you to call a method of the extension by name. The reason why it is a proxy instead of being the actual extension from the plugin is that some of the bindings don't support GObject subclassing (and don't plan to). Also, not using the actual object directly avoids quite a lot of hard-to-debug reference issues. Thrust me on that, I tried!

PeasExtensionSet. This is an automatically updated group of PeasExtensions. At any moment of time, a PeasExtensionSet instance will contain one PeasExtension for each plugin loaded that provides the target extension.

PeasActivatable and PeasUIConfigurable. Those are the two current built-in extension interfaces. The former defines an object which will be activated on object creation and deactivated on object destruction, while the latter is used by the embedded plugin manager UI, to provide a configuration dialog. You can of course provide your own extension interfaces!

What's next?

We are now planning on porting a few apps to libpeas in the following weeks. Several contributors already marked their interest in libpeas for the application they contribute to, and I would like myself to see our mighty text editor ported as well. I guess I will be posting more announcements for ported apps and niceties as time passes.

But libpeas is far from a finished project yet. Below are a few tracks for future development of libpeas. Don't hesitate to jump in!

Great documentation. The current documentation for libpeas is, well, the bare minimum. There is a quite complete reference documentation for the API, but there is no howto, no implementation guide for the plugins in various languages, etc. And a good documentation contributes a lot to making a good library.

Named extension points. Extension points are currently defined by interface types. While this works great for many use cases (Nautilus has done this for ages), it's actually quite limitative sometimes. For instance, the PeasActivatable interface, which defines an extension that can be activated, and then deactivated on objects of a certain type, could easily be re-used in different contexts: windows, tabs, documents. So you can easily see that named extension points here would be a nice feature.

Construction-time properties. Currently, extensions are instanciated with no dynamic arguments. But in some cases, it would be nice if we were able to give some arguments at instanciation time, through GObject properties. For instance, PeasActivatable extensions are usually related to a single object, but currently this object is give as an argument for each of the methods of the interface. Passing it to the extension at creation time and removing that argument from the method prototypes would be a nice touch.

More automatisms. With the rise of GSettings, it would now be possible for libpeas to manage itself the storage of the plugins state. It would then make sense to deal ourselves with “invisible” and “autoloaded” plugins, which are currently left at the application discretion.

Vala and C++ support. Adding support for those should not be hard, and would turn out to be very low cost as both are compiled languages and would make use of the existing loader. Totem already has Vala support, too, and the C loader has been thought with C++ support in mind, thanks to Debarshi Ray.

Guile support. This might be the nasty secret desire of mine, but I've always found Scheme support for plugins appealing. And this might well become true if sbank succeeds, and with Andy Wingo's support... Andy?

So, here is the current status of libpeas. Now, download it, try it, and come and join us on #libpeas to share your thoughts!

A brief history of plugin support in Gedit (and Gnome)

Gedit is one of the oldest softwares of the Gnome fame, and it got a major overhaul in time for Gnome 2.14. This was an eternity ago: the new mdi branch was merged in late 2005. This nearly full rewrite dropped many then-obsolete dependencies (BonoboUI, popt) and introduced many innovations over the previous versions, some of those spreading into the whole Gnome project.

One of the best known innovations was a replacement for all those annoying dialog boxes that popped for very good reasons at the worst possible moment. Understanding that those messages were very contextual in nature (they were always related to a particular document in some tab), the dialog boxes were replaced by coloured message areas embedded directly in the tab. This brand new idea got used by several other applications, and eventually got into Gtk+ lately under the name “GtkInfoBar”.

Another of those innovations was the brand new plugin capabilities it offered. At that time, it was possible to extend Gedit with C plugins for a long time, but with Gedit 2.14 came a few new capabilities:

Object-Oriented Plugins. From then on, plugins were objects that inherited from a base plugin class. Overriding virtual methods became the standard way of defining the plugin behaviour. And this was nice, as more and more people are familiar with object-oriented programming these days.

Python Plugins. PyGTK was in a very good state and Epiphany, the web browser everyone likes, was already using it to give access to its internals to python developpers. Gedit borrowed it and extended it to allow writing plugins as python objects as well.

This plugins engine has been very successful, and a lot of specialised plugins appeared in a few years. It was also transplanted to a lot of other Gnome applications (Eye of Gnome, Rhythmbox and Totem to cite the most prominent ones) but we never made a library out of it: creating and maintaining python bindings was time consuming and tedious, and it didn't make sense to have a library if every users of it would have to duplicate half of the code anyway.

But things have changed...

Thanks to the recent gobject-introspection project, “immediate” bindings are flourishing. Out of a single easily generated introspection dataset, it is now possible to benefit from full bindings for several languages, including Python (through PyGI) and the new kid in town, Javascript (through Seed or GJS). In total contrast with the old “PyGTK way”, bindings are now generated in minutes and require close to no maintainance and very few specific code. This fact alone creates the ideal condition for a librarified version of the Gedit plugins engine.

Introducing libpeas

This is why I am very proud to announce the first release of libpeas. libpeas is the next evolution of the Gedit plugins engine, and is targetted at giving every application the chance to assume its own extensibility. It also has a set of enhanced features with regard to what Gedit used to provide, mirroring the desiderata of your favourite text editor's developpers.

Multiple extension points. One of the most frustrating limitations of the Gedit plugins engine was that it only allows extending a single class, called GeditPlugin. With libpeas, this limitation vanishes, and the application writer is now able to provide a set of GInterfaces the plugin writer will be able to implement as his plugin requires.

On-demand programming language support. libpeas comes with a set of supported languages (currently, C, Python and Javascript). Those languages are supported through “loaders” which are loaded on demand. What it means is that you only pay for what you use: if you have no Python plugin, the Python interpreter won't be loaded in memory. Of course, the same goes for the C and for the Seed/JS loader.

Damn simple to use (or at least we try hard). Adding support for libpeas-enabled plugins in your own application is a matter of minutes. You only have to create an instance of the plugins engine, and call methods on the implementations of the various extension points. That's it, no clock harmed.

A shared library for everyone. As I noted earlier, the latest improvements of our beloved development platform made it possible to create bindings for apps very quickly. And with the Gnome 3 announcement, this looked like the perfect timing to make the plugins engine and its latest improvements available to everyone, with a library. Also, hopefully it will reduce code duplication and allow bugs to be fixed at the right place, once and for all, improving the quality of our applications.

As a member of the Gnome community and as an offspring of gedit, libpeas already shares most of the Gnome infrastructure and philosophy:

• You can download the first release tarball on the Gnome FTP server.
• You can browse the source and contribute using our git repository.
• You can come and discuss with me and others on #libpeas (GimpNet)
• And you can report bug or propose new features through the good old Gnome Bugzilla, against the libpeas module.

Many many thanks for their support to those who made this possible, and especially to the current very active gedit team (Paolo Borelli, Jesse van den Kieboom, Ignacio Casal Quinteiro and Garett Regier)

A few hints on using libpeas

As always for the new projects, it can take some time to grasp all the subtleties at first.

Plugins versus Extensions.

Something that is going to puzzle most of the newcomers is the fact that the libpeas API talks about both plugins and extensions, two terms that are usually used interchangeably, but who have very different meanings in libpeas.

Let's try and give a definition of both of these words in this context:

Plugin. In the context of libpeas, a plugin is a logical package. It's what you will enable or disable from the UI, and at the end it is what the user will see. An example of plugin for gedit would be the file browser plugin.

Extension. An extension is an object which implements an interface associated to an extension point. There can be several extensions in a single plugin. Examples of extensions provided by the file browser plugin would be the configuration dialog, the left panel pane and a completion provider for file names.

Building libpeas

Building libpeas is quite straightforward. But you need to be careful to build pygobject with the --enable-pygi option if you plan on using the Python bindings capability, or you will experience weird bugs.

Sample code

The libpeas package contains a sample application called peas-demo, and sample plugins written in C, Python and Javascript.

I'm not going to cut and paste a lot of code here, but the global idea is this one: you create a new PeasEngine instance and give it the information needed for it to find your plugins. Then you load some plugins (you can use the PeasUIPluginManager for that purpose) and perform actions through some PeasExtensions objects you can get from the engine.

PeasEngine. The engine is the main object for the libpeas integration. It will handle the loading and unloading of the various plugins, and it will give you PeasExtensions.

PeasPluginInfo. The plugin info object contains all the information about a plugin. It is available even when the plugin is not loaded.

PeasExtension. This is an extension, as seen from the application point of view. It is actually a proxy to the real extension, and provides a single peas_extension_call method that will allow you to call a method of the extension by name. The reason why it is a proxy instead of being the actual extension from the plugin is that some of the bindings don't support GObject subclassing (and don't plan to). Also, not using the actual object directly avoids quite a lot of hard-to-debug reference issues. Thrust me on that, I tried!

PeasExtensionSet. This is an automatically updated group of PeasExtensions. At any moment of time, a PeasExtensionSet instance will contain one PeasExtension for each plugin loaded that provides the target extension.

PeasActivatable and PeasUIConfigurable. Those are the two current built-in extension interfaces. The former defines an object which will be activated on object creation and deactivated on object destruction, while the latter is used by the embedded plugin manager UI, to provide a configuration dialog. You can of course provide your own extension interfaces!

What's next?

We are now planning on porting a few apps to libpeas in the following weeks. Several contributors already marked their interest in libpeas for the application they contribute to, and I would like myself to see our mighty text editor ported as well. I guess I will be posting more announcements for ported apps and niceties as time passes.

But libpeas is far from a finished project yet. Below are a few tracks for future development of libpeas. Don't hesitate to jump in!

Great documentation. The current documentation for libpeas is, well, the bare minimum. There is a quite complete reference documentation for the API, but there is no howto, no implementation guide for the plugins in various languages, etc. And a good documentation contributes a lot to making a good library.

Named extension points. Extension points are currently defined by interface types. While this works great for many use cases (Nautilus has done this for ages), it's actually quite limitative sometimes. For instance, the PeasActivatable interface, which defines an extension that can be activated, and then deactivated on objects of a certain type, could easily be re-used in different contexts: windows, tabs, documents. So you can easily see that named extension points here would be a nice feature.

Construction-time properties. Currently, extensions are instanciated with no dynamic arguments. But in some cases, it would be nice if we were able to give some arguments at instanciation time, through GObject properties. For instance, PeasActivatable extensions are usually related to a single object, but currently this object is give as an argument for each of the methods of the interface. Passing it to the extension at creation time and removing that argument from the method prototypes would be a nice touch.

More automatisms. With the rise of GSettings, it would now be possible for libpeas to manage itself the storage of the plugins state. It would then make sense to deal ourselves with “invisible” and “autoloaded” plugins, which are currently left at the application discretion.

Vala and C++ support. Adding support for those should not be hard, and would turn out to be very low cost as both are compiled languages and would make use of the existing loader. Totem already has Vala support, too, and the C loader has been thought with C++ support in mind, thanks to Debarshi Ray.

Guile support. This might be the nasty secret desire of mine, but I've always found Scheme support for plugins appealing. And this might well become true if sbank succeeds, and with Andy Wingo's support... Andy?

So, here is the current status of libpeas. Now, download it, try it, and come and join us on #libpeas to share your thoughts!

Ouch, it seems I didn't wrote any blog entry for nearly 2 years, since our wedding. Well I would say that I have been fairly busy :-) !

Baby Cheng 程

Our son is born end of last august, so obviously this tends to keep the parents busy, but it's such a pleasure too !

libvirt project

this has been a wild ride ! The project has grown a lot, in community and contributor size, as well as code and features during the last couple of years. It acquired support for most well known virtualization hypervisors (QEmu/KVM, Xen, ESX, VitualBox, ...) the only notable exception being Microsoft Hyper-V I think. Our latest release is 0.8.0 so we are not at 1.0 yet, but we are really getting closer, for example this release now adds snapshotting support which was a big feature request.

About updates to Fedora

There was a discussion last month about forbidding direct built to the stable branches, and I really think this makes sense, except for security erratas, one really should not push directly an updated build onto the users without some testing. But on the other hand we entered beta on Fedora 13 and apparently it's too late to push libvirt latest release and features, meaning users who don't try to update either via the virt-preview special repository or by rebuilding from the source rpm, will see libvirt features when Fedora 14 is being released i.e around the end of the year. I see people bouncing between both extreme of the features vs. stability tradeoff, and I wonder if there isn't a better way than building absolute rules. Maybe a general profile per machine where the user indicates whether he want updates, just bug fixes or just security errata, and let him do the picking. This would require some policy from package builders, and some changes at the repo level I guess, but having the user ultimately in control might be worth it.

Dear Lazyweb,

On this partly-cloudy day of April, I’ve thrown myself at Wikipedia seeking mercy upon my insatiable need to know more about diverse subjects such as the International Phonetic Alphabet.  But, as with any visit to Wikipedia, I ended up reading about even more diverse subjects such as the Mortgage word (from Law French), the Arabic loanword Orange and the Merovingian dynasty.

This was all great to read upon (thanks Wikipedians!).  But I’d like an easy way to find my way back to the original piece.  I’d like a nice Firefox extension to draw for me the threads of articles I’ve read.  Each time I’d open a new tab it would create a new branch from this article.  When an article links to an already open tab, it should be identified with a dashed line.

I’ve drawn an example of what it could look like (click for more details):

So please, tell me someone already wrote that piece of software? (It took me quite too long to draw this funny diagram).

Regards,

Pierre-Luc

NB: An attentive reader will realize that I like reading on History, Languages and History of Languages.

GUADEC Paper Selection has been slightly delayed, speakers should have been notified today (April 10th), this announcement will be done on Friday April 16th instead. So don't worry if you sent a paper submission and haven't heard from it yet :)

Voici quelques petits trucs pour savoir si un groupe/chaîne de lettres est illégitime (comme “10 voitures OFFERTES à 10 membres FACEBOOK”):

1. Si le titre inclus des mots en majuscule;
2. Si on y parle de faire de gros cadeaux mais qu’on en a pas entendu parlé dans les nouvelles;
3. Si tout ce qu’on doit faire pour participer est ridiculement simple (joindre un groupe, envoyer à tous tes amis); en plus au Québec, il faudrait répondre à une question d’habileté mathématique
4. S’il est impossible de corroborer l’information (ça veut dire de trouver d’autres sources d’information qui confirme les faits);
5. S’il est impossible de trouver les règlements officiels du concours;
6. Si vous n’avez pas été contacté directement pour ce concours: les gens de chez Facebook et MSN savent encore comment contacter leurs utilisateurs.

Merci d’appliquer ses règles simples avant de m’envoyer invitations/chaînes de lettres et autres choses qui pollue la vie en ligne.

Help gather some stats and reach the 1,000,000 people who like Linux and Open Source Software. It takes 30 seconds to fill the form on The million Tux.

These last months have been intense... I turned 30, found a new girlfriend, went to the Caribbean (Martinique, Dominica) for hollidays, and ended my work at the RATP (french public transports) after 5 years being there. I attended FOSDEM in Brussels and met with a few GNOMEys there. It has been more complicated to find time for bug reporting/slaying and I've been mostly idle in the free software front. This isn't going to change anytime soon, as I'm looking for a new job (my current employer isn't specialized in software development and I expect no carreer opportunities from him). Furthermore, it's been one year since I moved to my new appartment, but I still have no kitchen, no washing machine, and the electrical installation isn't finished, so there's still a lot to do.

At least I know what to do during the days I'm home...

GNOME was once again accepted as a mentoring organization by Google for their Summer of Code!

The fun will begin later in the summer, but there are already a few things you can do to help:

• add ideas for cool things that could be done during the summer
• apply as mentor
• or just hang around on #soc to guide students looking for help

So you know what you have to do now to help GNOME have a rocking summer!

I have been toying with webkit lately, and even managed to do some pretty things with it. As a consequence, I haven’t worked that much on ekiga, but perhaps some of my experiments will turn into something interesting there. I have an experimental branch with a less than fifty lines patch… I’m still trying to find a way to do more with less code : I want to do as little GObject-inheritance as possible!

That little programming was done while studying class field theory, which is pretty nice on the high-level principles and somewhat awful on the more technical aspects. I also read again some old articles on modular forms, but I can’t say that was “studying” : since it was one of the main objects of my Ph.D, that came back pretty smoothly…

I found a few minutes to enter a brick-and-mortar shop and have a look at the ebook readers on display. There was only *one* of them : the sony PRS-600. I was pretty unimpressed : the display was too dark (because it was a touch screen?), but that wasn’t the worse deal breaker. I inserted an SD card where I had put a sample of the type of documents I read : they showed up as a flat list (pain #1), and not all of them (no djvu) (pain #2) and finally, one of them showed up too small… and ended up fully unreadable when I tried to zoom (pain #3). I guess that settles the question I had on whether my next techno-tool would be a netbook or an ebook reader… That probably means I’ll look more seriously into fixing the last bug I reported on evince (internal bookmarks in documents).

Bonjour à tous,

je vous délaisse depuis quelques temps. Est-ce le temps qui fait cela, une période dans ma vie ou simplement autre chose, je n'en ai pas la moindre idée.

Je tenais juste à vous annoncer que je vais quitter mon employeur actuel qui est un Agence Gouvernementale pour chercher de l'expérience dans le secteur privé. En effet, je suis de plus en plus déçu par l'Administration.

Depuis quelques années, comme vous le savez, je me passionne pour la sécurité de l'Information. Ceci ajouté à une formation en Management de la Sécurité de l'Information, j'ai l'ambition de faire valoir mes expériences auprès d'un employeur (à définir) qui pourrait me permettre de les améliorer tout en lui faisant bénéficier de mes compétences.

Si vous avez de bonnes adresses, je suis preneur évidemment. ^^

With the beginning of the year comes new releases of Libgda:

• version 4.0.6 which contains corrections for the stable branch
• version 4.1.4, a beta version for the upcoming 4.2 version

The 4.1.4’s API is now considered stable and except for minor corrections should not be modified anymore.

This new version also includes a new database adaptator (provider) to connect to databases through a web server (which of course needs to be configured for that purpose) as illustrated by the followin diagram:

The database being accessed by the web server can be any type supported by the PEAR::MDB2 module.

The GdaBrowser application now supports defining presentation preferences for each table’s column, which are used when data from a table’s column need to be displayed:

The UI extension now supports improved custom layout, described through a simple XML syntax, as shown in the following screenshot of the gdaui-demo-4.0 program:

For more information, please visit the http://www.gnome-db.org web site.

Le hacker est un passionné d'informatique, souvent très doué, dont les seuls objectifs sont de "bricoler" programmes et matériels (software et hardware) afin d'obtenir des résultats de qualité pour lui-même, pour l'évolution des technologies et pour la reconnaissance de ses pairs.

Les conventions de hackers sont des rassemblements où ces férus d'informatique se rencontrent, discutent et comparent leurs travaux.

Depuis de nombreuses années, la tendance est de confondre à tort le hacker avec le cracker, dont les buts ne sont pas toujours légaux.

Or, on ne le répétera jamais assez, les objectifs du hacker sont louables et contribuent de manière active aux progrès informatiques et aux outils que nous utilisons quotidiennement.

I have been a little stuck for some weeks : a new year started (no, that post hasn’t been stuck since january — scholar year start in september) and I have students to tend to. As I have the habit to say : good students bring work because you have to push them high, and bad students bring work because you have to push them from low! Either way, it has been keeping me pretty busy.

Still, I found the time to read some more maths, but got lost on something quite unrelated to my main objective : I just read about number theory and the ideas behind the proof of Fermat’s Last Theorem (Taylor and Wiles’ theorem now). That was supposed to be my second target! Oh, well, I’ll just try to hit my first target now (Deligne’s proof of the Weil conjectures). And then go back to FLT for a new and deeper reading.

I only played a little with ekiga’s code — mostly removing dead code. Not much : low motivation.

I’ve spent a lot of time lately to improve the user experience with the GdaBrowser tool which will be included in Libgda starting with version 4.2.

The idea of this tool is to give database administrators a small and powerfull tool to “do stuff” on their databases, limited for now to browse the database schema and execute some SQL statements. Even though it still has some bugs, I use it regularly for my day to day needs.

The schema browser now displays database tables in a cloud style view which makes it easier to spot tables which have a lot of relations with other tables and to search, as shown in the following screenshot where the search highlights (in blue) tables beginning with “c”, shows the one having a “c” in a dark gray color, and almost hides the ones which have nothing in relation with the searched text:

The query editor can now propose a completion list when CTRL+Space is pressed, as shown in the next screenshot. Also note that each favorite query now displays the name of the favorite, the query type (SELECT here) and the variables used by the statement.

All of these improvements are now only available from the sources in git (git.gnome.org) but will be part of the next unstable release.

Nemiver 0.7.2 is out. It is a bugfix, minor feature and translation update release.

NEWS | tarball | Fedora Packages

So, I’m back from the Rencontres Mondiales du Logiciel Libre, which took place in Nantes this year. It was great to see all those people from the french Free Software community again, and I look forward to seeing them again next year in Bordeaux (too bad the Toulouse bid wasn’t chosen).

The Debian booth, mainly organized by Xavier Oswald and Aurélien Couderc, with help from Raphaël, Roland and others (but not me!), got a lot of visits, and Debian’s popularity is high in the community (probably because RMLL is mostly for über-geeks, and Debian’s market share is still very high in this sub-community).

I spent quite a lot of time with the Ubuntu-FR crew, which I hadn’t met before. They do an awesome work on getting new people to use Linux (providing great docs and support), and do very well (much better than in the past) at giving a good global picture of the Free Software world (Linux != Ubuntu, other projects do exist and play a very large role in Ubuntu’s success, etc). It’s great to see Free Software’s promotion in France being in such good hands. (Full disclosure: I got a free mug (recycled plastic) with my Ubuntu-FR T-shirt, which might affect my judgement).

I gave two talks, on two topics I wanted to talk about for some time. First one was about the interactions between users, distributions and upstream projects, with a focus on Ubuntu’s development model and relationships with Debian and upstream projects. Second one was about voting methods, and Condorcet in particular. If you attended one of those talks, feedback (good or bad) is welcomed (either in comments or by mail). Slides are also available (in french):

• L’écosystème du Libre: interactions entre projets amonts, distributions et utilisateurs – l’exemple de Debian et Ubuntu
• Méthodes de vote: Comment consulter un groupe de personnes sans fausser le résultat ?

On a more general note, I still don’t understand why the “Mondiales” in RMLL’s title isn’t being dropped or replaced by “Francophones“. Seeing the organization congratulate themselves because 30% of the talks were in english was quite funny, since in most cases, the english part of the talk was “Is there someone not understanding french? no? OK, let’s go on in french.“, and all the announcements were made in french only. Seriously, RMLL is a great (probably the best) french-speaking community event. But it’s not FOSDEM: different goals, different people. Instead of trying (and failing) to make it an international event, it would be much better to focus on making it a better french-speaking event, for example by getting more french-speaking developers to come and talk (you see at least 5 times more french-speaking developers in FOSDEM than in RMLL).

I’m now back in Lyon for two days, before leaving to Montreal Linux Symposium, then coming back to Lyon for three days, then Debconf from 23rd to 31st, and then moving to Nancy, where I will start as an assistant professor in september (a permanent (tenured) position).

Dear Lennart,

You should probably know that typing the correct URL would work better for cloning a bzr branch (yes a branch, not a repository).

This is what I get when I try to feed git a random invalid URL:

$ git clone git://github.com/idontexist
Initialized empty Git repository in /home/asabil/Desktop/idontexist/.git/
fatal: protocol error: expected sha/ref, got ‘
*********’

No matching repositories found.

*********’

Now is probably the time to stop this non constructive “my DVCS is better than yours”, and focus on writing code and fixing bugs.

The first beta of Ekiga 3.1.0 is now available on GNOME FTP.

Please note that I started the development of Ekiga 9 years ago.

Here is the list of changes :

• Added support for the G.722 audio codec: G.722 is a 16 kHz wideband audio codec advertised as HD Voice by the famous Polycom. It is a great boost in quality and interoperability.
• Added support for the CELT ultral-low delay audio codec: CELT delivers high quality audio at 32 kHz or 48 kHz, allowing to transmit music in high quality, with low delay and low bitrate.
• Added support for SIP dialog-info notifications: they allow displaying notifications of incoming calls in the roster. With software like kamailio or Asterisk, it allows being informed of incoming calls reaching your colleagues.
• Largely improved LDAP support: the OpenLDAP guys contributed several patches to provide state-of-the-art LDAP support in the Ekiga address book. The new code even supports authentication.
• Added support to disable STUN detection: some routers do not need it anymore as they implement NAT traversal for SIP.
• Killed the gconf_test_age test: when GConf was released, Ekiga was among the first to adopt it. That annoying ‘gconf error’ was a relique of those early times.
• More efficient memory handling using gmref_ptr.
• Better handling of multiple network interfaces with dynamic addition and removal.
• libgnome is not required anymore when using GTK+ 2.14.
• Many code cleanups, new GObjects, …

The Ekiga developers team is also working on interesting new features that should be available after the 3.2 release :

• XCAP support & Resource List support: It allows storing the contacts list on the Ekiga.net server.
• GStreamer audio and video capture support.

Stay tuned for more news!

Thanks to all contributors and welcome to Eugen Dedu, our new release manager!

I’ve been a member of April, the french association for promotion and defense of Free Software, for a bit more than a year, and I often regret not becoming a member earlier. (I was feeling so guilty and shameful about not being a member that I actually postponed becoming a member.)

Stop feeling guilty and shameful, become an April member today!

Why Is becoming an April member so important?

• Clearly, April doesn’t address the same problems as your local LUG. April is a country-wide organization, and it works on country-wide problems. It’s the only group able to work on such problems at this scale (I’m not sure of the situation in other countries, but I think CCC shares a similar role in Germany for example).
• Each time I talk to people really involved in April (which I’m not), I’m amazed by how powerful they have become. They are able to talk to french or european deputies or ministers’ cabinets, and are considered important. They are doing a fantastic job spreading what matters to us to legislative and executive powers in France and Europe.

Some of the things they worked on recently (from the top of my head):

• Lobbying on :
  • OOXML
  • General announcements about politics (Plan France Numérique 2012, aka Plan Besson).
  • European telecom package and HADOPI law (french graduated response) law, through Quadrature du net. (OK, it doesn’t have anything to do with April, but most of the people involved in Quadrature du Net are also involved in April :-)
  • vente liée : the fact that it’s not possible to buy a computer without a Windows license. It’s illegal in French law, but still the de facto situation almost everywhere.
• Organization of a campaign where candidates to elections in France where asked questions, or asked to sign a declaration about Free Software. In 2007, 8 out of the 12 candidates of the french presidential election answered April’s questions.

So, really, become a member today. It’s only 10 EUR, and you already know they will be well used. April is trying to reach 5000 members by the end of 2008.

(Apparently, if you use that address, April will now that you came from me. No benefit for me at all.)

Few people know that maintaining Ekiga also means maintaining Ekiga.net, the VoIP service platform for our users.

Today, we upgraded Ekiga.net, and that’s a lot of work !

Ekiga.net is now running Kamailio as frontend (recently renamed to SIP Router due to the merge between Kamailio and the old SIP Express Router project)
and Asterisk 1.4.

Among others, it allows to run the echo test with codecs like H.264, and better SIP presence support.

The old WEB interface has been replaced by a more intuitive one thanks to
Yannick Defais. The look and feel is now similar to the one you can see on the
brother ekiga.org website.

I would also like to thank Jan Schampera who helps me daily maintaining
ekiga.net and who helped a lot for the upgrade.

You can enjoy to the new infrastructure daily by signing up for an account at
http://www.ekiga.net.

On September I finish my studies of computer science, so I start to search a job. I really enjoyed my current job at Collabora maintaining Empathy, I learned lots of things about the Free Software world and I would like to keep working on free software related projects if possible. My CV is available online here.

Do you guys know any company around the free software and GNOME looking for new employees? You can contact me by email to xclaesse@gmail.com

A new release: libvirt-0.4.3

After two months a lot of patches had accumulated, including a lot of improvements for Xenner and Linux container support. But this release brings a massive set of code cleanup, and just looking at the patches there there is a lot of obscure case failures which should now be properly handled (or at least better handled, like out of memory situations). I'm pushing testing updates for F-8 and F-9 if you have time and use virtualisation please review them, thanks !

A new name ?

I got married to Miss Wei LI last saturday, it was kept a simple family event with just a few close friends, everything went well except for a bit of rain ! For the name I wouldn't mind being called Mr Li, but it's probably not very practical at this point (ah and good luck getting the li.com domain, and I guess hijacking li.org would not be well accepted either ;-)

A very simple picture, people interested for more should know where to look for already. Oh it also made me fight with the Panasonic HDC-SD9 'new' MPEG-4 output, to get videos to render properly on that other OS, I didn't expect to learn so much about video format so quickly. I will post recipe and scripts later.

On peut, au regard des concepts développés par Slavoj Zizek dans "La Parallaxe", tenter une nouvelle interprétation, plus fondamentale, des aventures de Suzumiya Haruhi.

La mélancolie de Suzumiya Haruhi est due au sentiment de malaise créé par l'incomplétude fondamentale qui nous caractérise tous. Haruhi part donc à la recherche du grand Autre, réponse censée venir combler ce vide, ici fétichisé dans les extra-terrestres, extra-lucides et voyageurs dans le temps. Ce comportement peut être vu comme semblable à ceux des individus cherchant la réponse à leur malaise constitutif dans la religion, voir, et nous y reviendrons, dans la philosophie et la politique.

Cependant, la réalité du monde de Haruhi est qu'il n'existe pas de grand Autre, aucun extra-ordinaire comblant les vides ennuyeux de la réalité, aucun personnage tirant les ficelles dans l'ombre. Ou plutôt, de façon plus importante, que ce grand Autre est Haruhi elle-même, ce qui constitue la réponse fondamentale : c'est bien elle-même qu'elle cherche en voulant résoudre cette incomplétude.

Selon ces hypothèses, le récit de ses aventures peut donc ultimement être vu comme celui de la recherche de la Vérité par les humains, les réflexions autour de son comportement précisant de façon très intéressantes plusieurs problématiques liées à ce processus.

L'interprétation de la fin de la série, où Haruhi semble trouver son bonheur avec Kyon, reste toujours problématique. Il n'existe pas de grand Autre, le manque ne peut donc pas être réellement comblé par quelque chose d'extérieur, donc pas par quelque chose qui soit matérialisé dans un fétiche, même humain, comme Kyon. Cependant Kyon n'est pas non plus quelque chose d'extérieur, puisqu'il est, comme tous les objets du monde de Haruhi, un produit de son imagination. Il s'agirait donc d'une pure matérialisation à figure humaine de la véritable réponse à son manque, ce qui ferait de Kyon une partie de Haruhi et non un personnage distinct. On peut donc avec un peu d'audace avancer que Kyon et Haruhi ne sont qu'un, qu'il est réellement sa moitié, ce qui n'est pas sans rappeler tout en lui redonnant une piquante nouvelle perspective le "happy end" chrétien par excellence. Malgré tout, le fait que Haruhi ne le reconnaisse pas comme tel, puisqu'ils sont clairement toujours deux personnes distinctes, laisse supposer que le problème n'est pas réglé.

On ne reconnaît habituellement qu'une religion pose problème que lorsqu'elle constitue un risque potentiel pour le système capitaliste libéral dans lequel nous vivons. De fait, ces religions ont donc on potentiel subversif.

C'est à cause de celui-ci que les nombreux individus touchés de plein fouet par le malaise créé par cette société se tournent en nombre de plus en plus important vers ce type de communautés religieuses.

Or, qu'est-ce que le processus de laïcisation tel que nous l'entendons dans la bouche des libéraux, sinon le fait de rendre les religions aptes à rentrer dans le cadre libéral, ou, à défaut, de marginaliser et stigmatiser celles qui ne le feraient pas, leur retirant ainsi tout aspect nocif pour lui ?

Ce processus peut donc être vu comme la condition sine qua non du fonctionnement de l'opium du peuple comme instrument des puissances qui font l'ordre social, même si la résurgence des intégrismes en période de crise nous montre qu'il est de toute façon voué à l'échec.

L'attitude ambivalente de la laïcité promue par la droite, qui dit oui à, voir encourage, la croyance qui se veut inconditionnelle, et simultanément y porte des restrictions, reflète d'ailleurs cette contradiction.

Pour illustrer ceci, on peut prendre l'exemple des lois interdisant à la religion tout caractère visible en public, par lesquelles on leur enlève tout caractère choquant pour ceux qui n'y prennent pas part, tout en ne faisant rien contre leur effet idéologique sur les populations concernées.

La gauche radicale n'a donc aucun intérêt à aider l'ordre libéral à se maintenir en normalisant la religion pour l'intégrer, puis se renforcer, par cette laïcité.

Ce qu'elle devrait favoriser, c'est la prise de conscience par la classe dominée du fait que son malaise est dû à la structure de la société et que le seul moyen d'y remédier est la lutte politique permettant de le dépasser. Par conséquent, la seule laïcité qu'il ait un sens pour elle de défendre est celle qui permette l'émancipation de chacun, pour parvenir à ce fait.

Enterprise Social Search is a way to search, manage, and share information within a company. Who can help you find relevant information and nothing but relevant information? Your colleagues, of course

Today we are launching at Whatever (the company I work for) a marketing campaign for our upcoming product: Knowledge Plaza. Exciting times ahead!

There was some blog entries this week about GNOME stable updates on Ubuntu. There is no reason new bug fix versions could not be uploaded to stable out of the fact that the SRU rules require to check carrefully all the changes and doing this job on all the GNOME tarballs is quite some work, or the ubuntu desktop team is quite small and already overworked.

There is a list of packages which have a relaxed rules though, we have discussed adding GNOME to those since the stable serie usually has fixes worth having and not too many unstable changes (though the stable SVN code usually doesn’t get lot of testing) and decided than the stable updates which look reasonable should be uploaded to hardy-update.

There was also some concerns about gnome-games, 2.20.3 has been uploaded to gutsy-proposed today which should reduce the number of bugs sent to the GNOME bugzilla. The new dependencies on ggz has also been reviewed and 2.21 should be built soon in hardy.

The FOSSCamp and UDS week has been nice and a good occasion to talk to upstream and people from other distributions. We had desktop discussions about the new technologies landing in GNOME this cycle (the next Ubuntu will be a LTS so we need a balance between new features and stability), the desktop changes we want to do, and how Ubuntu contributes to GNOME.

Some random notes about the Ubuntu upstream contributions:

• Vincent asked again for an easy way to browse the Ubuntu patches and Scott picked up the task, the result is available there
• The new Canonical Desktop Team will focus on making the user experience better, most of the changes will likely be upstream material and discussed there, etc
• Canonical has open Ubuntu Desktop Infrastructure Developer and Ubuntu Conceptual Interface Designer positions, if you want to do desktop work for a cool open source company you might be interested by those

GNOME updates in gutsy and hardy

• Selected GNOME 2.20.1 changes have been uploaded to gutsy-updates
• The GNOME 2.21.2 packaging has started in hardy, some updates and lot of Debian merges are still on the TODO though
• We have decided to use tags in patches to indicate the corresponding Ubuntu and upstream bugs so it’s easier to get the context of the change, technical details still need to be discussed though

Update: Scott pointed that you can use http://patches.ubuntu.com/n/nautilus/extracted to access to the current nautilus version

I’ve been working wit git lately but I have also missed the darcs user interface. I honestly think the darcs user interface is the best I’ve ever seen, it’s such a joy to record/push/pull (when darcs doesn’t eat your cpu)

I looked at git add --interactive because it had hunk-based commit, a pre-requisite for darcs record-style commit, but it has a terrible user interface, so i just copied the concept: running a git diff, filtering hunks, and then outputing the filtered diff through git apply --cached.

It supports binary diffs, file additions and removal. It also asks for new files to be added even if this is not exactly how darcs behave but I always forget to add new files, so I added it. It will probably break on some extreme corner cases I haven’t been confronted to, but I gladly accept any patches

Here’s a sample session of git-darcs-record script:

$ git-darcs-record
Add file:  newfile.txt
Shall I add this file? (1/1) [Ynda] : y

Binary file changed: document.pdf

Shall I record this change? (1/7) [Ynda] : y

foobar.txt
@@ -1,3 +1,5 @@
 line1
 line2
+line3
 line4
+line5

Shall I record this change? (2/7) [Ynda] : y

git-darcs-record
@@ -1,17 +1,5 @@
 #!/usr/bin/env python

-# git-darcs-record, emulate "darcs record" interface on top of a git repository
-#
-# Usage:
-# git-darcs-record first asks for any new file (previously
-#    untracked) to be added to the index.
-# git-darcs-record then asks for each hunk to be recorded in
-#    the next commit. File deletion and binary blobs are supported
-# git-darcs-record finally asks for a small commit message and
-#    executes the 'git commit' command with the newly created
-#    changeset in the index
-
-
 # Copyright (C) 2007 Raphaël Slinckx
 #
 # This program is free software; you can redistribute it and/or

Shall I record this change? (3/7) [Ynda] : y

git-darcs-record
@@ -28,6 +16,19 @@
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.

+# git-darcs-record, emulate "darcs record" interface on top of a git repository
+#
+# Usage:
+# git-darcs-record first asks for any new file (previously
+#    untracked) to be added to the index.
+# git-darcs-record then asks for each hunk to be recorded in
+#    the next commit. File deletion and binary blobs are supported
+# git-darcs-record finally asks for a small commit message and
+#    executes the 'git commit' command with the newly created
+#    changeset in the index
+
+
+
 import re, pprint, sys, os

 BINARY = re.compile("GIT binary patch")

Shall I record this change? (4/7) [Ynda] : n

git-darcs-record
@@ -151,16 +152,6 @@ def read_answer(question, allowed_responses=["Y", "n", "d", "a"]):
        return resp

-def setup_git_dir():
-       global GIT_DIR
-       GIT_DIR = os.getcwd()
-       while not os.path.exists(os.path.join(GIT_DIR, ".git")):
-               GIT_DIR = os.path.dirname(GIT_DIR)
-               if GIT_DIR == "/":
-                       return False
-       os.chdir(GIT_DIR)
-       return True
-
 def git_get_untracked_files():

Shall I record this change? (5/7) [Ynda] : y

# On branch master
# Changes to be committed:
#   (use "git reset HEAD file..." to unstage)
#
#       modified:   document.pdf
#       modified:   foobar.txt
#       modified:   git-darcs-record
#       new file:   newfile.txt
#
# Changed but not updated:
#   (use "git add file file..." to update what will be committed)
#
#       modified:   git-darcs-record
#
What is the patch name? Some cute patch name
Created commit a08f34e: Some cute patch name
 4 files changed, 3 insertions(+), 29 deletions(-)
 create mode 100644 newfile.txt

Get the script here: git-darcs-record script and put in somewhere in your $PATH. Any comments or improvements is welcome !

Voilà, j’y pensais depuis longtemps et c’est maintenant chose faite, je me suis acheté un tout nouveau ordinateur portable.

Je l’ai acheté sur le site français LDLC.com et me suis renseigné pour savoir si il était possible d’acheter les ordinateurs de leur catalogue sans logiciels (principalement sans windows). Je leur ai donc envoyé un email, et à ma grande surprise ils m’on répondu que c’était tout a fait possible, qu’il suffi de passer commande et d’envoyer ensuite un email pour demander de supprimer les logiciels de la commande. J’ai donc commandé mon laptop et ils m’ont remboursé de 20€ pour les logiciels, ce n’est pas énorme sur le prix d’un portable, mais symboliquement c’est déjà ça.

Toutes fois je me pose des questions, pourquoi cette offre n’est pas inscrite sur le site de LDLC ? En regardant sous mon tout nouveau portable je remarque une chose étrange, les restes d’un autocollant qu’on a enlevé, exactement à l’endroit où habituellement est collé la clef d’activation de winXP. Le remboursement de 20€ tout rond par LDLC me semble également étrange vue que LDLC n’est qu’un intermédiaire, pas un constructeur, et donc eux achètent les ordinateurs avec windows déjà installé. Bref tout ceci me pousse à croire que c’est LDLC qui perd les 20€ et je me demande dans quel but ?!? Pour faire plaisir aux clients libre-istes ? Pour éviter les procès pour vente liée ? Pour à leur tours se faire rembourser les licences que les clients n’ont pas voulu auprès du constructeur/Microsoft et éventuellement gagner plus que 20€ si les licences OEM valent plus que ça ? Bref ceci restera sans doutes toujours un mistère.

J’ai donc installé Ubuntu qui tourne plutôt bien. J’ai été même très impressionné par le network-manager qui me connecte automatiquement sur les réseaux wifi ou filaire selon la disponibilité et qui configure même un réseau zeroconf si il ne trouve pas de server dhcp, c’est très pratique pour transférer des données entre 2 ordinateurs, il suffi de brancher un cable ethernet (ça marche aussi par wifi mais j’ai pas encore testé) entre les 2 et hop tout le réseau est configuré automatiquement sans rien toucher, vraiment magique ! Windows peut aller se cacher, ubuntu est largement plus facile d’utilisation !

I hate having to write about bugs in the documentation. It feels like waving a big flag that says ‘Ok, we suck a bit’.

Today, it’s the way fonts are installed, or rather, they aren’t. The Fonts folder doesn’t show the new font, and the applications that are already running don’t see them.

So I’ve fixed the bug that was filed against the documentation. Now it’s up to someone else to fix the bugs in Gnome.

Eye of Gnome comes with some nifty features like support for EXIF data in jpegs. But this depends on a library that isn’t a part of Gnome.

So what do I write in the user manual for EOG?

‘You can see EXIF data for an image, but you need to check the innards of your system first.’
‘You can maybe see EXIF data. I don’t know. Ask your distro.’
‘If you can’t see EXIF data, install the libexif library. I’m sorry, I can’t tell you how you can do that as I don’t know what sort of system you’re running Gnome on.’

The way GNU/Linux systems are put together is perhaps great for people who want unlimited ability to customize and choose. But it makes it very hard to write good documentation. In this sort of scenario, I would say it makes it impossible, and we’re left with a user manual that looks bad.

I’ve added this to the list of use cases for Project Mallard, but I don’t think it’ll be an easy one to solve.

It's been a while since my last update. A lot of stuff has happened on the MlView front !
First of all, Dodji finally decided to make a release so go and get the 0.8 release !
On my side, work has been done on the Preferences which is a really repetitive (who said boring?) thing to code. It had to be done...i did it !



This week-end i wanted to take a break on the Preferences so i added a simple command launcher for MlView. This was a feature request (see #305075) so it might even make someone happy :)



I've been talking with Dodji about porting the main view container to GDL, so my next task will (probably) be to look at that...
I had made a simple poc with textviews and it really was convincing...Watch the video to get an idea....

^^

Being the cool kid i am and given that there's a new UI paradigm for search dialogs in town, i gave MlView some love tonight.
As i didn't have much time it's just a mockup atm. I'll make the code tomorrow maybe...

And here is the little screenie :)


Update: Finished the code. Everything is in my archive in -patch5.