Kaz’hack

I’m glad to announce that I’m joining Phoxygen today as a senior Firefox OS engineer. A new angle on the same project, and a great team to work with!

As a welcome bonus, I get to work with Ahmed to finish the work on RTL we started two years ago. More on that soon.

Following yesterday’s post about using “npm install -g” without root privileges, here are the Python and Ruby counterparts for your beloved OSX or Linux box.

By default, pip install and gem install try to install stuff in /usr/, which requires root privileges. Hence, most users will “naturally” do a sudo to perform the install — which is, in my opinion at least, a very bad idea (do you really want to give root privileges to packages that haven’t been reviewed?). Fortunately, there’s more than the default setting.

Python: pip install --user

With Python 2.6 and later you can avoid “sudoing” your pip install by using the --user argument (thanks @cmdevienne for the tip!). Let’s test this with html-linter:

$ pip install --user html-linter

By default on Linux and OSX (non-framework builds) this will install your package into ~/.local, which is just fine for me. All executables are in ~/.local/bin/, which is included in my $PATH, and all Python libraries are in ~/.local/lib/python2.7/. The world couldn’t be any better.

You can specify a custom destination by setting the PYTHONUSERBASE environment variable:

$ export PYTHONUSERBASE=/myappenv
$ pip install --user html-linter

Of course, you’ll have to add that to your $PATH to make it work. You can add the following lines to your ~/.profile like that:

export PYTHONUSERBASE=/myappenv
PATH="$PYTHONUSERBASE/bin:${PATH}"

The only downside (compared to npm) is that you’ll have to remember to use the --user argument when installing Python packages. If there’s a way to make it the default mode, please let me know.

EDIT: a good workaround is to define a custom pip function in your ~/.bash_aliases (or bashrc, zshrc, whatever), as suggested in comment #1.

Ruby: gem install --user-install

gem’s --user-install argument is quite similar. One good thing is that you can easily make it the default mode:

$ echo "gem: --user-install" >> ~/.gemrc

Now let’s try that with the most valuable gem I know:

$ gem install vimgolf
Fetching: vimgolf-0.4.6.gem (100%)
WARNING:  You don't have /home/kaze/.gem/ruby/1.8/bin in your PATH,
          gem executables will not run.

As you can see, gem installs everything in ~/.gem by default; unfortunately, the file structure does not allow to put executables in the same ~/.local/bin/ directory. Never mind, we’ll add those ~/.gem/ruby/*/bin/ directories to the $PATH manually by adding these lines to the ~/.profile:

for dir in $HOME/.gem/ruby/*; do
  [ -d "$dir/bin" ] && PATH="${dir}/bin:${PATH}"
done

Source your ~/.profile, you’re done.

I use more and more Node.js tools, mostly for my web development tasks: linters, code formatters, unit tests… Most of the time, you want these tools to be installed “globally” so that they’re in your $PATH, e.g.:

$ npm install jshint -g

… which usually results in this kind of error:

npm ERR! Error: EACCES, mkdir '/usr/lib/node_modules/jshint'
[…]
npm ERR! Please try running this command again as root/Administrator.

Being a naive Linux user, I’m not giving root/Administrator privileges to an install script that hasn’t been reviewed — call me a freak. And I’m quite surprised that most Node.js users just “sudo” it.

A common workaround is to “chgrp” /usr/lib and/or /usr/local so that modifying these directories doesn’t require sudo. I find that even worse.

Solution: npm prefix

(I’ll suppose you’re using OSX or Linux here. If anyone knows how this works on Windows, please leave a comment)

After a bit of ddg’ing, I’m happy to see there’s a clean solution:

$ echo prefix=${HOME}/.local >> ~/.npmrc

And voilà, npm will install everything in ~/.local/bin and ~/.local/lib:

$ npm install -g jshint
/home/kaze/.local/bin/jshint -> /home/kaze/.local/lib/node_modules/jshint/bin/jshint
jshint@2.5.10 /home/kaze/.local/lib/node_modules/jshint

Of course, this supposes that ~/.local/bin belongs to your $PATH. If not, just edit your ~/.profile to add the following line:

export PATH="$HOME/.local/bin:$PATH"

Source your ~/.profile, you’re done.

During the last 3 years I’ve worked full-time for Mozilla Corp, and now it’s more than time to move on.

Leaving the MoCo has been a very difficult step for me. I’ve been a Mozillian for the last 8 years, and it’s been much more than a friendly community or a challenging job for me. I’ve had a lot of fun, met amazing people, worked on exciting technologies. I’m very proud of what we did, and I’m even prouder of why we did it. Working for Mozilla felt like a love story, and ending a love story is always painful.

I just took a long, refreshing, offline break. Sorry if you tried to reach me during this period — I’m getting through the mailbox hell, and I’ll do my best to reply to every message.

Best wishes to all Mozillians, especially to the folks in the Paris office, the Spanish Connection, and my drinking pals all around the globe. I’ll be happy to share a few beers with you at a web or FLOSS event someday. :-)

Wow, the last year just flew by! Time for a quick status update.

First of all, I’m not working on the editor back-end any more. I joined the Firefox OS dev team last January and I mostly work on the Gaia front-end. It’s been heart-breaking to stop working on the editor, which is the reason why I started contributing to Mozilla in 2006… but I have to confess I feel much more useful in the Gaia team, and I’m proud to be part of such an amazing project!

Sad corollary: like you would expect for such projects, the work pace is very high and I haven’t been able to work significantly on any other FLOSS project. The first official Firefox OS release is scheduled for mid-January 2013, so don’t expect any update on Kompozer or timesheets.js until the end of the winter. :-/

Among the cool things we do with Firefox OS, I’m the proud developer of webL10n, a client-side i18n/localization JS library. This library is used by all Gaia apps and by other cool projects like PDF.js or Etherpad Lite. We’re ironing webL10n at the moment and we’re trying to optimize its performances, so expect a first public release soon. :-)

Last, I’m organizing monthly French-speaking Vim meet-ups in the Paris office. It was supposed to be an experiment but it’s been working out surprisingly well since March! If you use Vim, speak French and are in Paris next Thursday, ping me. :-)

Next week I’ll be in Mountain View for DocEng2011 — a symposium on Document Engineering, which is hosted by Google this year.

I’ll present my work on timesheets.js (= JavaScript implementation of SMIL Timing and SMIL Timesheets), which has been nominated for the best paper award. Wish me luck!

That’s not a secret, not everybody is happy with Mozilla’s new “6-week release” policy. Everything has already been written about that: the advantages of a rapid release cycle are real, and so are the drawbacks of the lack of a long-term-support version. The Firefox project is in a sensitive phase.

Yesterday, Cédric, a very long time l10n contributor and key person of the French localization, gave us a bad surprise by announcing that he’s suspending his contribution to Firefox.

The recent change about the release cycle has overturned the community habits and the irresponsible statements of some Mozilla representatives as well as the decision not to support a Firefox LTS release, for companies or end-users, are the root of the new nature of my contribution to the project.

At least Cédric isn’t dropping the FrenchMozilla community:

For my part, I won’t desert totally the project, because I truly agree the Mozilla Manifesto and I think the Mozilla Foundation is indispensable for the good health of Internet, but I will stop contributing in anything related to Firefox: the product, the websites and the marketing campaigns.

Beyond the fact that it will be very difficult to find anybody rivaling Cedric’s hard work and experience, I’m really bitter to think of the resentment of our community. Like Clochix said:

who would want to get involved in a project without being respected and listened?

Is the “sacred fire” fading out? I want to think it’s not, and I hope Mozilla will give a positive signal to the community before the upcoming MozCamps. Our community is what makes us different and better — let’s not take it for granted.

[Edit] just to make it clear: here in Europe, “community” refers to all Mozilla contributors, and most of them are volunteers — they’re giving their time, their energy, their talent to Mozilla “for the cause”. They do software development, translations (products and web pages), user support, evangelism… on their free time, because they think it’s valuable. [\Edit]

Ce n’est un secret pour personne, la nouvelle politique de 6-week releases de Mozilla ne fait pas que des heureux. Je ne m’étendrai pas sur le sujet, tout a déjà été écrit sur la question : les avantages d’un cycle de développement rapide sont indéniables, les inconvénients de l’absence d’une version maintenue sur 12 à 18 mois (comme c’était le cas jusqu’ici) le sont tout autant. Le projet Firefox est entré dans une phase d’évolution délicate.

Hier Cédric, contributeur de très longue date et clé de voute de la localisation francophone de Mozilla, nous a fait une mauvaise surprise en annonçant qu’il suspendait sa contribution à Firefox.

Le récent changement du cycle de développement qui a bouleversé les habitudes de la communauté, les déclarations inconsidérées de certains responsables du projet ainsi que la décision de ne pas maintenir une version de Firefox dite LTS, autant pour les entreprises que pour les utilisateurs, telles sont les trois raisons majeures qui me font envisager un nouveau mode de contribution au projet Mozilla.

Qu’on se rassure, Cédric n’abandonne pas la communauté Mozilla francophone :

Pour ma part, je ne déserterai pas totalement le projet, car je souscris au manifeste de Mozilla en beaucoup de points et j’estime que la Fondation Mozilla est indispensable à la bonne santé d’Internet, mais j’arrêterai toute contribution en ce qui concerne Firefox : le logiciel, les sites Web, les campagnes marketing.

Outre le fait Cédric sera très difficile à remplacer, tant pour sa capacité de travail que pour son expérience, je suis particulièrement amer en pensant au ressentiment de la communauté. Comme l’a écrit Clochix :

qui voudrait s'impliquer dans un projet sans y être un minimum respecté et écouté ?

Le feu sacré est-il en train de s’éteindre ? Je veux croire que non, et j’espère que Mozilla saura redonner confiance à la communauté d’ici le prochain MozCamp.

I’ve tweaked the cpp.vim file that comes with Vim 7.3 to highlight most Mozilla-specific keywords when working on the editor core. A lot of Mozilla-specific types and that can be added manually but the task gets bigger when it comes to nsI* interfaces or NS_* macros…

Most nsI* interfaces can be grabbed with find/grep/sed:

find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^\(class\|interface\)\s*nsI" '{}' \; | sed 's/\(:\|;\|,\|{\).*$//' | sed 's/^.*nsI/nsI/' | sed 's/\s*$//' | sort -u

same thing for NS_ERROR* / NS_IMPL* macros and constants:

find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_ERROR" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u

find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_IMPL" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u

Here’s the resulting cpp.vim file including the ~900 Mozilla-specific lines (ouch!). Copy it to your ~/.vim/syntax/ directory and voilà, your C++ files should be much more colorful.

Now it’d be really great if:

• we had omni-completion for the nsI* interfaces instead of just the keywords;
• we had a similar file (keywords + omni-completion) for JavaScript — mostly for the DOM API
• this file could be generated automatically — say, with DXR;
• this file could be included in the Mozilla tree (e.g. a .vimrc file in the top source dir).

To all Vim fanboys among the Mozilla community: I’d love to get your input about that. Maybe we could start a “vim-moz-syntax” project on github or something?

EDIT: (2013-05-19)

• this work is now available on github: https://github.com/mozfr/mozilla.vim
• there’s been an article about this in Russian: softdroid.net/Vim-Syntax-Highlighting

The Mozilla HTML editor creates a bunch of <br> elements for historical reasons. One of the most irritating situations is when you expect a <p> but get a <br>… for example in this ContentEditable demo:

[Return] in paragraphs

When editing a “contentEditable” element in Firefox, pressing [Return] in a paragraph splits the paragraph: if you press [Return] at the end of a paragraph, a new paragraph is created.

When editing HTML documents in comm-central apps (Thunderbird HTML messages, SeaMonkey Composer documents) the behavior is slightly different:

• pressing [Return] once at the end of a paragraph creates a <br> element;
• pressing [Return] twice at the end of a paragraph creates a <p> element.

The reason is, the editor component has a returnInParagraphCreatesNewParagraph property which is true by default on Firefox, but not on Thunderbird and SeaMonkey. You can set this property to false on Firefox (contentEditable) with:

 document.execCommand("insertBrOnReturn", false, "true")

Note that the insertBrOnReturn command is Mozilla-specific.

SeaMonkey and Thunderbird parse the editor.CR_creates_new_p preference (false by default) and apply its value to editor.returnInParagraphCreatesNewParagraph. You can change the value of editor.CR_creates_new_p in “about:config” if you prefer the Firefox behavior (and you probably do).

A trickier case in Firefox is when the active editing host is an inline element:

Try to press [Return] here and complain.

 <p> Try to
     <span contenteditable>press [Return] here</span>
 and complain. </p>

As Firefox always tries to create a new paragraph in such situations, and since the editing host is a <span>, nothing happens when [Return] is pressed. This should be fixed with bug 460740.

Of course, in all cases a [Shift+Return] creates a <br>, which is fine.

[Return] in headers and lists

With current versions of Firefox (5, Beta, Aurora):

• pressing [Return] at the end of a header element (<h[1…6]>) creates two line breaks (<br>), though most users expect a new paragraph.
• pressing [Return] once at the end of a list element (<li> or <dt>) creates a new list item (<li> or <dd> respectively); pressing [Return] twice splits the list if necessary and creates a line break, though again, most users expect a new paragraph.

Note that there’s no equivalent to the editor.returnInParagraphCreatesNewParagraph property for headers or lists: pressing [Return] at the end of list or header element never inserts any <br> within this element.

There’s no spec that describe the expected behavior of the HTML editor in such case. I think the only intuitive rule would be to create a new block element (<p>) when we’re getting out of another block element with [Return]. That’s what Chromium and Opera do (and probably IE and Safari as well), and that’s what I’ve done in bug 449243. You can test this behavior in Firefox Nightly.

Note: when editing a list in Thunderbird or SeaMonkey Composer with this patch, if you click on the “list” toolbar button the list content will be converted to body text, not to a paragraph. I’ll have to work on that in order to preserve the consistency.

Consistency: <p> everywhere?

Again, there’s no spec for the behavior of the [Return] key in an editable document fragment but we can assume that the [Return] key action should be as consistent as possible across the different editing situations. That’s the idea behind the new behavior of the [Return] key in headers and lists.

I don’t think the editor should force all text to be enclosed in paragraphs, though. As an example, in this editable <div> there’s no HTML structure so I expect [Return] to create <br>:

 <div contenteditable>
     Type your text here!
 </div>

When [Return] is pressed at the end of the line of text, I expect to get a <br> (FWIW, that’s what Chromium does, too). I don’t expect [Return] to turn the text into a paragraph, then create another paragraph. If I wanted all text to be enclosed in paragraphs I could just use this instead:

 <div contenteditable>
   <p> Type your text here! </p>
 </div>

I think comm-central apps (Thunderbird, SeaMonkey…) might want to adapt to this new behavior: since HTML messages in Thunderbird and documents in SeaMonkey Composer are structured HTML documents, these apps could initialize the editor not on “about:blank” as they do now, but on an empty HTML document containing a paragraph. In this case, changing the default value of editor.CR_creates_new_p would make sense.

I’m pretty sure that’s what SeaMonkey Composer users want, but I don’t know if this applies to Thunderbird. In fact, Thunderbird might even prefer creating <br> instead of <p> when [Return] is pressed… if that’s the case, please let me know.

[update 2011-07-28] Aryeh Gregor (WhatWG) has just published a preliminary draft of the HTML Editing APIs specification. Thanks Anthony for the link!

Finally! After a one year contract with INRIA working on SMIL Timesheets I’m getting back to what I’ve been doing as a Mozilla community member: working on the wysiwyg HTML editor.

The difference is, with Kompozer I’ve been dealing with the XUL/JS front-end (editor/ui), trying to find workarounds to the bugs in the core editor, whereas now I’m working on the C++ back-end (mozilla/editor), trying to fix bugs at the source. As the HTML editor component is used in Firefox (contentEditable elements), Thunderbird, SeaMonkey and Kompozer, I hope my work on this back-end will improve the user experience on all these apps.

The other difference is that instead of working on the editor on my free time, I have an official contract now. Yay!

I’ve just spent a week in Toronto working with Ehsan, who got me started with the editor codebase and the development tools. I’ve already addressed a couple bugs and I’ll do my best to make the editor better for everyone in the next few months.

I have been working for INRIA for one year now. I am still alive, though extremely busy… and it is high time to give a quick update.

About My Work

timesheets.js: I have been hired to develop a FLOSS, cross-browser implementation of SMIL Timing and SMIL Timesheets. I learned a lot about SMIL and I believe that we are bringing a modern approach of SMIL, reusing HTML/SVG and CSS wherever possible. Most use cases so far are related to multimedia annotations but I think the true power of this technology is to design interactive slideshows in a declarative way — i.e. relying on a standard W3C markup.

My contract has just been extended a bit to work on a wysiwyg editor for timesheets. I am rushing to deliver something usable, I hope I will be able to write another blogpost about this when it is ready.

As this work was a research program focussing on XML edition, I learned a lot on XML and XML editors. I am pretty disappointed by most XML editors so far, mainly because they are often misused — I am more and more convinced that an HTML-based, template-oriented document processing tool-chain would suit most needs.

Unexpected Side-Effects

I was accepted as a member of the SYMM Working Group at W3C. Not as fancy as being part of the HTML5 WG but still, that means something to me.

I wrote a paper that has been accepted by the DocEng2011 conference, which will take place in Mountain View in September.

I learned much more than I would have liked to on cross-browser compatibility issues — read: IE-related issues. I thought I was a good JavaScript developer, but writing JS for Mozilla applications is very different than writing a JS library. As a result, I spent more time struggling with IE (MediaElement.js was a rescuer to me) or designing demos than working on the JavaScript library itself… *sigh*

I have been working a whole year with a non-free OS! Now, I have a lot to say about MacOSX… and I am happily getting back to GNU/Linux. I have to admit that there are a few OSX features that I would like to see in GNU/Linux, though.

The Bad Part

I thought I could still work on Kompozer while at INRIA. Unfortunately, I had absolutely no time to take any vacation during this year and very little free time to work on other free projects.

Just to make it clear:

• yes, the KompoZer project is stalled at the moment since I am the only regular developer and I am too busy;
• no, there is no so-called “successor” for KompoZer; there are other projects which address the same needs but with another codebase…
• yes, I am still interested in finishing the job I have been doing on KompoZer, i.e. backporting the codebase to comm-central / SeaMonkey.

I think dom2text editors are not relevant any more for modern web development. They are still useful and appreciated to learn the basics of web design, a wysiwyg CSS editor can be useful as well, but they will never be an alternative to text2dom editors like DreamWeaver™ or Komodo.

I am convinced that wysiwyg HTML editors should be focussed on content instead of presentation. I am thinking of a “Web Processing Suite” that could be a real-world alternative to word processors and slideshow editors, and we need a modern, stable, community-maintained editor for that. This has always been my main motivation with KompoZer, and after my work at INRIA I have a pretty sharp idea of what a “Web Processor” should look like.

The Best Part

I am not looking for any job at the moment. I have just signed a 6-month contract with Mozilla and I will start working with Ehsan Akhgari on the <editor> back-end in mid-July.

Needless to say, I am more than thrilled about this new challenge. More on this subject soon. :-)

I’ve just been hired by INRIA to develop a Mozilla-based, multimedia-dedicated, web authoring tool. I’m working in a team that has been very active in the SVG and SMIL working groups and that has developed Amaya a while ago. After three months working here, I came up with two conclusions:

• the full SMIL spec (≠ SVG animations) is completely overkill for web browsers
• the SMIL/Timing module is magic: simple to use and offers a lot of cool features to web pages like timing, media synchronization and user interaction management. I wish this could be part of HTML5!

I’m currently working on a JavaScript implementation of the SMIL/Timing module. I’ve had the opportunity to give a lightning talk about this project at the Mozilla Summit in Whistler, and I’ve made significant progress since.

Here’s a quick overview of SMIL/Timing and how we can use it in web pages. The full story and all the demos are on labs.kompozer.net/timesheets.

Timesheet Scheduler (Demo!)

I’ve started to implement the SMIL/Timing and SMIL/Timesheets specs in a JavaScript Timesheet Scheduler: with this small JS lib (less than 4KB for the minified/gzipped version), a lot of timing features and user interactions can be described without writing any specific JavaScript code. This can be easily used to design an slideshow like this one:

The full demo is available here: labs.kompozer.net/timesheets.

Two new locales have just been added to the official “Download” page: kompozer.net/download.php

The Ukrainian one is mainly (only?) the result of Andriy Radyk’s work. He’s done the whole translation on Narro pretty quickly before taking the time to check his langpack carefully in KompoZer itself. Thanks Andriy!

The Brazilian locale is the work of many contributors — Narro can be frustrating for us, but it sure rocks when distributing the work load among several contributors. Unfortunately, and despite the fact that there were only 60 strings to translate, there hasn’t been any activity on this locale lately. So Cédric has decided to take the untranslated strings (all related to the CSS Editor) from the Portuguese langpack: as these strings are very technical, we've supposed there won't be any problem, but let us know if there's a mistake.

We’re still looking for a Brazilian contributor to review and maintain this langpack: please ping us if you want to contribute.

Daniel Glazman a annoncé qu’il avait trouvé un financement pour BlueGriffon. J’aimerais pouvoir en dire autant pour KompoZer, mais je ne peux que m’associer à la joie de Daniel qui va à nouveau connaître le rêve de tout libriste : être payé pour bosser sur son domaine de prédilection.

En revanche, j’ai sérieusement tiqué en lisant l’entretien publié par Tristan sur son blog. J’ai longtemps hésité à réagir (pas envie de déclencher une flame war), mais la réaction des autres contributeurs KompoZer m’impose de répondre à quelques points en particulier.

While most of the KompoZer 0.7.10 language packs have been upgraded to KompoZer 0.8, we’ve set up a Narro server to help localization teams work on new locales. The Finnish locale has been the first one to be fully translated, other locales are still in progress: Irish, Korean, Ukrainian, Brazilian, Swedish, Turkish, Bulgarian… and Slovenian.

Jaroslav Krejčí (aka “JardaK”) has just submitted a Czech language pack for KompoZer 0.8.

We’ve imported the strings from the langpack JardaK did for KompoZer 0.7.10 and added the Mozilla 1.8 strings. Then, JardaK has translated all the new strings and fixed a few problems we had in the previous version.

As a result, there are now Czech builds of KompoZer 0.8b3 on the official download page for Windows, MacOSX and GNU/Linux. Thanks a lot JardaK!

Note: most of the langpacks we had for KompoZer 0.7.10 have been upgraded to 0.8 by now, but we’re still missing the Brazilian (pt-BR), Slovak (