Diary of a CrazyFrench

Thursday 28 June 2007

Hack week 2007 day 3

Hack week, day 3:

  • polished the Nautilus patch
  • modified the EOG patch to be reconcile data in the same place (not finished yet)
  • tried to learn RPM packaging to provide packages for libopenraw, exempi and raw-thumbnailer
  • raw-thumbnailer code is on gitweb.fdo, at least temporarily.

Tuesday 26 June 2007

Hack week 2007 day 2

Day 2 of hack week: XMP support in nautilus. Today I did:

  • filed 2 bugs in Nautilus to were blocking me. With patch attached. Bug 451242 just prevented the build as Nautilus has to be build with -Werror. Bug 451344 was IMHO a problem loading the metadata that occur when there is a bit too much data in the APP1 markers, which is triggered by JPEG with XMP embedded.
  • filed the third bug, bug 451380 as a feature request with patch attached, and this is the core of the work. Nautilus will show the XMP metadata if they are available. This only works for local files (Exempi cannot read off gnome-vfs) and only JPEG (the later is Nautilus limitation, related to libexif). Screenshot:

Monday 25 June 2007

Hack week 2007 day 1

This week is Hack Week at Novell. Work on the Linux and Free Software project of your choice.

I choose to work on bringing digital camera RAW and metadata.

Several defined goal reached today:

  • Thumbnailing digital camera RAW for Nautilus. The current solution I know and packaged a year and a half ago for Ubuntu was based on dcraw. Mine is based on libopenraw, and is faster. It just handle less format, but this will be solved in the future. In the mean time I discovered that the Debian package of UFRaw was setting UFRaw to produce the thumbnails (using the provided mime-info). So why reinventing the wheel? Because I believe that a solution based on libopenraw is much better integrated and probably much more efficient[1]. Other alternative hacks I have seen require the use of ExifTool (with Perl) or dcraw command-line tool. I have a raw-thumbnailer working, to be released.
  • XMP support in EOG - bug #451101. Patch is attached. This one make use of Exempi 1.99.2 (that I have not released soon). The support is a bit rough in the UI, and only works for JPEG as it is currently a limitation of EOG. I also think that the metadata should be reconciled in one set for clarity.

To be done:

  • XMP support in Nautilus. Same strategy as for EOG. Possibly add it for digital camera RAW files.
  • See if the metadata in EOG can be reconciled (see above).
  • See how to provide support for editing.

Notes

[1] I'm seriously biased :-)

Wednesday 13 June 2007

Browser wars: a new hope

Nothing was lost in the browser and in the last years, Firefox has taken back some point in the browser market. So interestingly that after disbanding the team and not doing anything on IE for 5 years but plugging security holes, Microsoft decided to release IE 7, solely for XP SP2 and upward, in the hope to regain some market.

But this is not without counting on Safari.

Safari by itself made Microsoft not develop IE Mac anymore a by itself took a good chunk as the Mac market is somewhat growing a bit. The interesting part is that it is not based on Gecko, but on KHTML, turned into WebKit. Lars Knoll interview gives us a brief overview of the past and the future of KHTML and WebKit development, notably how Apple collaboration ended up working well and how KDE4 will have KHTML coming directly from Apple's repository[1]. Now the WebKit for Windows is about to disturb the source: Apple's Windows port did land in the repository, and that port has apparently no relation with the non contribution from Adobe for WebKit + Cairo on Windows[2]. I'm still unsure of the direct benefit of the port source code for Free Software, as it apparently use a mix between Windows native GDI and Apple own proprietary CoreGraphics (delivered as a non-free DLL[3]), but nonetheless.

Now how will that still matter for Free Software?

It brings a standard compliant Free Software web rendering engine a broader audience, on that it is different from Gecko. Competition is good, and diversity is good. This engine is at the heart of KDE4, and is being brought to Gtk by the work put in by various contributors, including Alp's port to Maemo (Alp, you rock dude) making it valuable for GMAE and Gnome in general. Nobody will argue, Gnome is in dire need to something better than Gecko for its HTML needs: DevHelp, Yelp, Liferea, Evolution, etc would all benefit from it. All the enhancements made to the main engine, including support for new standards will directly serve the purpose of any Free Software using it.

Even more, being the browser inside the iPhone (and actually Apple's blessed development platform for the iPhone[4]), this could leverage enough market share to make WebKit a major browser and have actually enough power to convince the Web 2.0 developers to ensure their development are compatible[5] with it. And that is something noticeable. Remember when IE was the only browser tested and that developer didn't care to fix their mistake or standard conformance because anything else was too small for them?

Notes

[1] no I didn't say developed by Apple

[2] they released the source of their version but didn't contribute it back to the main WebKit

[3] Update: I need to clarify: since the non-free DLL does not even come with the targeted platform said Free Software is rendered useless... until a Free Software replacement of the component comes.

[4] more on that later

[5] bonus point: the iPhone does not have Flash capabilities which is good for standard compliance