Kaz’hackNo ducks were harmed in the making of this weblog.2015-03-15T00:07:32+01:00Kazéurn:md5:a9f47af44d37c17f59ac5db8d567a80dDotclearJoining Phoxygenurn:md5:392773c12aec2c5fa367de3b2ea35ec32015-03-12T21:30:00+01:002015-03-12T23:25:20+01:00KazéfirefoxOSphoxygen <p>I’m glad to announce that I’m joining <a href="http://www.phoxygen.com/">Phoxygen</a> today as a senior Firefox OS engineer. A new angle on the same project, and a great team to work with!</p>
<p>As a welcome bonus, I get to work with <a href="http://nefzaoui.tn/">Ahmed</a> to finish the work on <abbr title="right-to-left">RTL</abbr> we started two years ago. More on that soon.</p>"pip install" & "gem install" without sudourn:md5:c4608726e75f8f8b2468c23748c955922014-12-12T14:10:00+01:002014-12-12T17:40:26+01:00Kazélinuxosxpythonruby <p>Following yesterday’s post about using “<code>npm install -g</code>” without root privileges, here are the Python and Ruby counterparts for your beloved OSX or Linux box.</p>
<p>By default, <code>pip install</code> and <code>gem install</code> try to install stuff in <code>/usr/</code>, 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.</p>
<h3>Python: <code>pip install --user</code></h3>
<p>With Python 2.6 and later you can avoid “sudoing” your <code>pip install</code> by using the <code><a href="https://pip.pypa.io/en/latest/user_guide.html#user-installs">--user</a></code> argument (thanks <a href="http://kazhack.org/?post/2014/12/12/">@cmdevienne</a> for the tip!). Let’s test this with <a href="https://pypi.python.org/pypi/html-linter/">html-linter</a>:</p>
<pre>
$ pip install --user html-linter
</pre>
<p>By default on Linux and OSX (non-framework builds) this will install your package into <code>~/.local</code>, which is just fine for me. All executables are in <code>~/.local/bin/</code>, which is included in my <code>$PATH</code>, and all Python libraries are in <code>~/.local/lib/python2.7/</code>. The world couldn’t be any better.</p>
<p>You can specify a custom destination by setting the <code>PYTHONUSERBASE</code> environment variable:</p>
<pre>
$ export PYTHONUSERBASE=/myappenv
$ pip install --user html-linter
</pre>
<p>Of course, you’ll have to add that to your <code>$PATH</code> to make it work. You can add the following lines to your <code>~/.profile</code> like that:</p>
<pre>
export PYTHONUSERBASE=/myappenv
PATH=&quot;$PYTHONUSERBASE/bin:${PATH}&quot;
</pre>
<p>The only downside (compared to npm) is that you’ll have to remember to use the <code>--user</code> argument when installing Python packages. If there’s a way to make it the default mode, please let me know.</p>
<p><ins>EDIT:</ins> a good workaround is to define a custom <code>pip</code> function in your <code>~/.bash_aliases</code> (or bashrc, zshrc, whatever), as suggested in <a href="http://kazhack.org/?post/2014/12/12/pip-gem-install-without-sudo#c1025">comment #1</a>.</p>
<h3>Ruby: <code>gem install --user-install</code></h3>
<p><code>gem</code>’s <code>--user-install</code> argument is quite similar. One good thing is that you can easily make it the default mode:</p>
<pre>
$ echo &quot;gem: --user-install&quot; &gt;&gt; ~/.gemrc
</pre>
<p>Now let’s try that with the most valuable gem I know:</p>
<pre>
$ 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.
</pre>
<p>As you can see, <code>gem</code> installs everything in <code>~/.gem</code> by default; unfortunately, the file structure does not allow to put executables in the same <code>~/.local/bin/</code> directory. Never mind, we’ll add those <code>~/.gem/ruby/*/bin/</code> directories to the <code>$PATH</code> manually by adding these lines to the <code>~/.profile</code>:</p>
<pre>
for dir in $HOME/.gem/ruby/*; do
[ -d &quot;$dir/bin&quot; ] &amp;&amp; PATH=&quot;${dir}/bin:${PATH}&quot;
done
</pre>
<p>Source your <code>~/.profile</code>, you’re done.</p>"npm install -g" without sudourn:md5:73c466d71752a551ff536a7be8ddbd2b2014-12-11T19:33:00+01:002014-12-12T17:23:53+01:00Kazélinuxnode.jsosx <p>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 <code>$PATH</code>, e.g.:</p>
<pre>
$ npm install jshint -g
</pre>
<p>… which usually results in this kind of error:</p>
<pre>
npm ERR! Error: EACCES, mkdir '/usr/lib/node_modules/jshint'
[…]
npm ERR! Please try running this command again as root/Administrator.
</pre>
<p>Being a naive Linux user, I’m <strong>not</strong> 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.</p>
<p>A common workaround is to “chgrp” <code>/usr/lib</code> and/or <code>/usr/local</code> so that modifying these directories doesn’t require sudo. I find that even worse.</p>
<h3>Solution: npm prefix</h3>
<p>(I’ll suppose you’re using OSX or Linux here. If anyone knows how this works on Windows, please leave a comment)</p>
<p>After a bit of ddg’ing, I’m happy to see there’s a clean solution:</p>
<pre>
$ echo prefix=${HOME}/.local &gt;&gt; ~/.npmrc
</pre>
<p>And <em>voilà</em>, npm will install everything in <code>~/.local/bin</code> and <code>~/.local/lib</code>:</p>
<pre>
$ npm install -g jshint
/home/kaze/.local/bin/jshint -&gt; /home/kaze/.local/lib/node_modules/jshint/bin/jshint
jshint@2.5.10 /home/kaze/.local/lib/node_modules/jshint
</pre>
<p>Of course, this supposes that <code>~/.local/bin</code> belongs to your <code>$PATH</code>. If not, just edit your <code>~/.profile</code> to add the following line:</p>
<pre>
export PATH=&quot;$HOME/.local/bin:$PATH&quot;
</pre>
<p>Source your <code>~/.profile</code>, you’re done.</p>Back from Mozillaurn:md5:e66909b7c38b4a0eb22502c68522130f2014-12-10T16:10:00+01:002014-12-10T22:57:43+01:00KazéfirefoxOSmozilla <p>During the last 3 years I’ve worked full-time for Mozilla Corp, and now it’s more than time to move on.</p>
<p>Leaving the MoCo has been a very difficult step for me. I’ve been a <a href="https://mozillians.org/en-US/u/kaze/">Mozillian</a> 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 <a href="https://www.mozilla.org/firefox/os/">what we did</a>, and I’m even prouder of <a href="https://www.mozilla.org/about/manifesto/">why we did it</a>. Working for Mozilla felt like a love story, and ending a love story is always painful.</p>
<p>I just took a long, <a href="https://en.wikipedia.org/wiki/Kitesurfing">refreshing</a>, <a href="https://en.wikipedia.org/wiki/Windsurfing">offline</a> 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.</p>
<p>Best wishes to all Mozillians, especially to the folks in the Paris office, the <a href="https://twitter.com/TEF_FirefoxOS">Spanish Connection</a>, 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. :-)</p>Still thereurn:md5:c7523602cd6b44f85c1b4f2b4a1d2f302012-12-02T21:21:00+01:002012-12-02T22:32:57+01:00KazéfirefoxOSl10nmozillavim <p>Wow, the last year just flew by! Time for a quick status update.</p>
<p>First of all, I’m not working on the editor back-end any more. I joined the <a href="http://mozilla.org/firefoxos">Firefox OS</a> dev team last January and I mostly work on the <a href="https://wiki.mozilla.org/Gaia/Hacking">Gaia front-end</a>. 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!</p>
<p>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 <a href="http://kompozer.net/">Kompozer</a> or <a href="http://wam.inrialpes.fr/timesheets/">timesheets.js</a> until the end of the winter. :-/</p>
<p>Among the cool things we do with Firefox OS, I’m the proud developer of <a href="https://github.com/fabi1cazenave/webL10n">webL10n</a>, a client-side i18n/localization JS library. This library is used by all Gaia apps and by other cool projects like <a href="http://mozilla.github.com/pdf.js/">PDF.js</a> or <a href="https://github.com/ether/etherpad-lite/blob/master/doc/localization.md">Etherpad Lite</a>. We’re ironing webL10n at the moment and we’re trying to optimize its performances, so expect a first public release soon. :-)</p>
<p>Last, I’m organizing monthly <a href="http://wiki.mozfr.org/TupperVim">French-speaking Vim meet-ups</a> 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. :-)</p>DocEng2011urn:md5:2039c5c51b6d874e9ed51b89b84715032011-09-17T00:29:00+02:002011-09-17T01:49:08+02:00Kazéhtml5smiltimesheets <p>Next week I’ll be in Mountain View for <a href="https://sites.google.com/site/doceng2011/">DocEng2011</a> — a symposium on Document Engineering, which is hosted by Google this year.</p>
<p>I’ll present my work on <a href="http://wam.inrialpes.fr/timesheets/">timesheets.js</a> (= JavaScript implementation of SMIL Timing and SMIL Timesheets), which has been nominated for the <a href="https://sites.google.com/site/doceng2011/symposium/best-paper-award">best paper award</a>. Wish me luck!</p>A Bad Surpriseurn:md5:76b8a92d61d8b5774e708e7e4966f07a2011-08-17T12:05:00+02:002011-08-17T12:30:13+02:00Kazémozilla <p>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.</p>
<p>Yesterday, Cédric, a very long time l10n contributor and key person of the French localization, gave us a bad surprise by announcing that <a href="http://blog.frenchmozilla.fr/index/post/2011/08/16/De-la-contribution">he’s suspending his contribution to Firefox</a>.</p>
<blockquote><p>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.</p></blockquote>
<p>At least Cédric isn’t dropping the <a href="http://frenchmozilla.fr/">FrenchMozilla community</a>:</p>
<blockquote><p>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.</p></blockquote>
<p>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 <a href="http://www.clochix.net/post/2011/08/17/Quel-g%C3%A2chis%E2%80%A6">Clochix</a> said:</p>
<blockquote><p>who would want to get involved in a project without being respected and listened?</p></blockquote>
<p>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. <strong>Our community is what makes us different and better — let’s not take it for granted.</strong></p>
<p><em>[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]</em></p>Mauvaise surpriseurn:md5:5ce2856684ba834255670c1eec5517d62011-08-17T09:52:00+02:002011-08-17T09:52:00+02:00Kazémozfrmozilla <p>Ce n’est un secret pour personne, la nouvelle politique de <em>6-week releases</em> 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.</p>
<p>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’<a href="http://blog.frenchmozilla.fr/index/post/2011/08/16/De-la-contribution">il suspendait sa contribution à Firefox</a>.</p>
<blockquote><p>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.</p></blockquote>
<p>Qu’on se rassure, Cédric n’abandonne pas la communauté Mozilla francophone :</p>
<blockquote><p>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&nbsp;: le logiciel, les sites Web, les campagnes marketing.</p></blockquote>
<p>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 <a href="http://www.clochix.net/post/2011/08/17/Quel-g%C3%A2chis%E2%80%A6">Clochix</a> :</p>
<blockquote><p>qui voudrait s'impliquer dans un projet sans y être un minimum respecté et écouté&nbsp;?</p></blockquote>
<p>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.</p>Vim Syntax Highlighting for Mozilla C++ Filesurn:md5:a7c907fd82ab37c5c886a43a3272d63f2011-08-11T17:50:00+02:002013-05-19T20:26:27+02:00Kazémozillavim <p>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…</p>
<p>Most nsI* interfaces can be grabbed with find/grep/sed:</p>
<pre>find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^\(class\|interface\)\s*nsI" '{}' \; | sed 's/\(:\|;\|,\|{\).*$//' | sed 's/^.*nsI/nsI/' | sed 's/\s*$//' | sort -u</pre>
<p>same thing for NS_ERROR* / NS_IMPL* macros and constants:</p>
<pre>find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_ERROR" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u</pre>
<pre>find src/mozilla -regex ".*\.\(idl\|h\)" -exec grep "^#define\s*NS_IMPL" '{}' \; | sed 's/^#define\s*//' | sed 's/\s.*$//' | sed 's/(.*$//' | sort -u</pre>
<p><a href="http://kazhack.org/tmp/cpp.vim">Here’s the resulting cpp.vim file</a> including the ~900 Mozilla-specific lines (ouch!). Copy it to your <code>~/.vim/syntax/</code> directory and <em>voilà</em>, your C++ files should be much more colorful.</p>
<p>Now it’d be really great if:</p>
<ul>
<li>we had <strong>omni-completion</strong> for the nsI* interfaces instead of just the keywords;</li>
<li>we had a similar file (keywords + omni-completion) for JavaScript — mostly for the DOM API</li>
<li>this file could be generated automatically — say, <a href="https://github.com/mozilla/dxr/issues/8">with DXR</a>;</li>
<li>this file could be included in the Mozilla tree (e.g. a .vimrc file in the top source dir).</li>
</ul>
<p>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?</p>
<p>EDIT: (2013-05-19)</p>
<ul>
<li>this work is now available on github: https://github.com/mozfr/mozilla.vim</li>
<li>there’s been an article about this in Russian: http://softdroid.net/Vim-Syntax-Highlighting</li>
</ul>Editor Progress: make <p>, not <br>!urn:md5:ee2807b284e1755cb278831e8f6749ce2011-07-27T14:00:00+02:002011-07-28T11:55:49+02:00KazécontentEditableeditormozilla <p>The Mozilla HTML editor creates a bunch of &lt;br&gt; elements for historical reasons. One of the most irritating situations is when you expect a &lt;p&gt; but get a &lt;br&gt;… for example in this <a href="http://html5demos.com/contenteditable">ContentEditable demo</a>:</p>
<style type="text/css">
.demo {
width: 400px;
margin: 1em auto;
padding: 1em;
border: 1px solid navy;
background-color: #fff;
}
*[contenteditable] {
background-color: #eef;
}
</style>
<div class="demo" contenteditable="true">
<h3>Go ahead, edit away!</h3>
<p>Here's a typical paragraph element</p>
<ol>
<li>and now a list</li>
<li>with only</li>
<li>three items</li>
</ol>
</div>
<h3>[Return] in paragraphs</h3>
<p>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.</p>
<p>When editing HTML documents in comm-central apps (Thunderbird HTML messages, SeaMonkey Composer documents) the behavior is slightly different:</p>
<ul>
<li>pressing [Return] once at the end of a paragraph creates a &lt;br&gt; element;</li>
<li>pressing [Return] twice at the end of a paragraph creates a &lt;p&gt; element.</li>
</ul>
<p>The reason is, the editor component has a <code>returnInParagraphCreatesNewParagraph</code> 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:</p>
<pre> document.execCommand("insertBrOnReturn", false, "true")</pre>
<p>Note that the <code>insertBrOnReturn</code> command is Mozilla-specific.</p>
<p>SeaMonkey and Thunderbird parse the <code>editor.CR_creates_new_p</code> preference (false by default) and apply its value to <code>editor.returnInParagraphCreatesNewParagraph</code>. You can change the value of <code>editor.CR_creates_new_p</code> in “about:config” if you prefer the Firefox behavior (and you probably do).</p>
<p>A trickier case in Firefox is when the active editing host is an inline element:</p>
<p class="demo"> Try to
<span contenteditable="true">press [Return] here</span>
and complain. </p>
<pre> &lt;p&gt; Try to
&lt;span contenteditable&gt;press [Return] here&lt;/span&gt;
and complain. &lt;/p&gt;</pre>
<p>As Firefox always tries to create a new paragraph in such situations, and since the editing host is a &lt;span&gt;, nothing happens when [Return] is pressed. This should be fixed with <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=460740">bug 460740</a>.</p>
<p>Of course, in all cases a [Shift+Return] creates a &lt;br&gt;, which is fine.</p>
<h3>[Return] in headers and lists</h3>
<p>With current versions of Firefox (5, Beta, Aurora):</p>
<ul>
<li>pressing [Return] at the end of a header element (&lt;h[1…6]&gt;) creates two line breaks (&lt;br&gt;), though most users expect a new paragraph.</li>
<li>pressing [Return] once at the end of a list element (&lt;li&gt; or &lt;dt&gt;) creates a new list item (&lt;li&gt; or &lt;dd&gt; respectively); pressing [Return] twice splits the list if necessary and creates a line break, though again, most users expect a new paragraph.</li>
</ul>
<p>Note that there’s no equivalent to the <code>editor.returnInParagraphCreatesNewParagraph</code> property for headers or lists: pressing [Return] at the end of list or header element never inserts any &lt;br&gt; within this element.</p>
<p>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 (&lt;p&gt;) 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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=449243">bug 449243</a>. You can test this behavior in Firefox Nightly.</p>
<p>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.</p>
<h3>Consistency: &lt;p&gt; everywhere?</h3>
<p>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.</p>
<p>I don’t think the editor should force all text to be enclosed in paragraphs, though. As an example, in this editable &lt;div&gt; there’s no HTML structure so I expect [Return] to create &lt;br&gt;:</p>
<div contenteditable="true" class="demo">
Type your text here!
</div>
<pre> &lt;div contenteditable&gt;
Type your text here!
&lt;/div&gt;</pre>
<p>When [Return] is pressed at the end of the line of text, I expect to get a &lt;br&gt; (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:</p>
<div contenteditable="true" class="demo">
<p> Type your text here! </p>
</div>
<pre> &lt;div contenteditable&gt;
&lt;p&gt; Type your text here! &lt;/p&gt;
&lt;/div&gt;</pre>
<p>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 <code>editor.CR_creates_new_p</code> would make sense.</p>
<p>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 &lt;br&gt; instead of &lt;p&gt; when [Return] is pressed… if that’s the case, please let me know.</p>
<p><strong>[update 2011-07-28]</strong> <a href="http://blog.whatwg.org/html-editing-apis-specification-ready-for-implementer-feedback">Aryeh Gregor (WhatWG)</a> has just published a preliminary draft of the <a href="http://aryeh.name/spec/editing/editing.html">HTML Editing APIs</a> specification. Thanks <a href="http://hanblog.info/blog/">Anthony</a> for the link!</p>From editor/ui to mozilla/editorurn:md5:c2766edb59f344dd802a30f0d0e613f62011-07-27T11:50:00+02:002011-07-28T10:25:39+02:00Kazé <p>Finally! After a one year contract with INRIA working on <a href="http://wam.inrialpes.fr/timesheets/">SMIL Timesheets</a> I’m getting back to what I’ve been doing as a Mozilla community member: working on the wysiwyg HTML editor.</p>
<p>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.</p>
<p>The other difference is that instead of working on the editor on my free time, I have an official contract now. Yay!</p>
<p>I’ve just spent a week in Toronto working with <a href="http://ehsanakhgari.org/">Ehsan</a>, 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.</p>One Year At INRIAurn:md5:3858033b332d1dd105d2b6d077ecd9c82011-06-13T20:41:00+02:002011-06-13T20:41:51+02:00Kazéeditorlibremozillasmiltimesheets <p>I have been working for <a href="http://wam.inrialpes.fr/">INRIA</a> for one year now. I am still alive, though extremely busy… and it is high time to give a quick update.</p>
<h3>About My Work</h3>
<p><a href="http://wam.inrialpes.fr/timesheets/">timesheets.js</a>: I have been hired to develop a FLOSS, cross-browser implementation of <a href="http://www.w3.org/TR/SMIL3/smil-timing.html">SMIL Timing</a> and <a href="http://www.w3.org/TR/timesheets/">SMIL Timesheets</a>. 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.</p>
<p>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.</p>
<p>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.</p>
<h3>Unexpected Side-Effects</h3>
<p>I was accepted as a <strong>member of the SYMM Working Group at W3C</strong>. Not as fancy as being part of the HTML5 WG but still, that means something to me.</p>
<p>I wrote a paper that has been <strong>accepted by the <a href="http://sites.google.com/site/doceng2011/">DocEng2011</a> conference</strong>, which will take place in Mountain View in September.</p>
<p>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 (<a href="http://mediaelementjs.com/">MediaElement.js</a> was a rescuer to me) or designing demos than working on the JavaScript library itself… *sigh*</p>
<p>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.</p>
<h3>The Bad Part</h3>
<p>I thought I could still work on <a href="http://kompozer.net">Kompozer</a> 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.</p>
<p>Just to make it clear:</p>
<ul>
<li>yes, the KompoZer project is stalled at the moment since I am the only regular developer and I am too busy;</li>
<li>no, there is no so-called “successor” for KompoZer; there are other projects which address the same needs but with another codebase…</li>
<li>yes, I am still interested in finishing the job I have been doing on KompoZer, i.e. backporting the codebase to comm-central / SeaMonkey.</li>
</ul>
<p>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.</p>
<p>I am convinced that wysiwyg HTML editors should be focussed on <strong>content</strong> instead of presentation. I am thinking of a <strong>“Web Processing Suite”</strong> 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.</p>
<h3>The Best Part</h3>
<p>I am not looking for any job at the moment. <strong>I have just signed a 6-month contract with Mozilla</strong> and I will start working with <a href="http://ehsanakhgari.org/">Ehsan Akhgari</a> on the &lt;editor&gt; back-end in mid-July.</p>
<p>Needless to say, I am more than thrilled about this new challenge. More on this subject soon. :-)</p>HTML Timingurn:md5:2275f3fa556c669ba855434dc94bf0612010-08-26T20:30:00+02:002010-09-03T09:54:28+02:00Kazéeditorhtml5mozillasmiltimesheets<p>I’ve just been hired by <a href="http://wam.inrialpes.fr/">INRIA</a> 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 <a href="http://www.w3.org/Amaya/">Amaya</a> a while ago. After three months working here, I came up with two conclusions:</p>
<ul><li>the full SMIL spec (≠ SVG animations) is completely overkill for web browsers</li>
<li>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!</li>
</ul>
<p>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.</p>
<p>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 <a href="http://labs.kompozer.net/timesheets/">labs.kompozer.net/timesheets</a>.</p>
<h3>Timesheet Scheduler (Demo!)</h3>
<p>I’ve started to implement the SMIL/Timing and SMIL/Timesheets specs in a JavaScript <a href="http://labs.kompozer.net/timesheets/index.xhtml" hreflang="en">Timesheet Scheduler</a>: 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:</p>
<iframe src="http://labs.kompozer.net/timesheets/index-frame.xhtml" scroll="no" style="width: 670px; height: 420px; margin-left: -30px; border: medium none; overflow: hidden;">
<a href="http://labs.kompozer.net/timesheets/"><img alt="HTML Timing" src="http://kazhack.org/public/screenshots/htmlTiming.png" title="Your browser doesn’t support iframes — click to see the demo!"></a>
</iframe>
<p> The full demo is available here: <a href="http://labs.kompozer.net/timesheets/">labs.kompozer.net/timesheets</a>. </p> <p> Instead of trying to implement the whole SMIL/Timing spec, I’ve focused on four basic use cases:</p>
<dl>
<dt>
<a href="http://labs.kompozer.net/timesheets/banner.xhtml">Rotating Banner</a>
</dt>
<dd>
a simple example to demonstrate the basic concepts of time containers
</dd>
<dt>
<a href="http://labs.kompozer.net/timesheets/video.xhtml">HTML Subtitles</a>
</dt>
<dd>
synchronizing rich subtitles with a video stream <br />
<em>(requires &lt;video&gt; support)</em>
</dd>
<dt>
<a href="http://labs.kompozer.net/timesheets/audio.xhtml">Annotated Audio</a>
</dt>
<dd>
synchronizing textual descriptions of musical sections
and introducing declarative user interaction <br />
<em>(requires &lt;audio&gt; and SVG support)</em>
</dd>
<dt>
<a href="http://labs.kompozer.net/timesheets/slideshow.xhtml">Slideshow Engine</a>
</dt>
<dd>
nesting time containers to create a highly flexible slideshow engine</dd>
</dl>This is the very first release of this Timesheet Scheduler (v0.1, MIT license). The next version should support event-values and open up a lot of user interaction possibilities.<br /><h3>Browser Requirements</h3>
<p>This demo works with all modern browsers: Firefox 3.5+, Safari 5+, Chrome 5+, Opera 10.60+.</p>
<p><strong>Firefox users</strong>: these demos work with Firefox 3.x but you’ll get a better experience with Firefox 4 (read: with
CSS transition support).</p>
<p><strong>Internet Explorer users</strong>: I’m
afraid your browser isn’t supported yet — the IE9 support should come
soon, though.</p>
<h3>Timing Markup</h3>
<p>Here’s an overview of the markup used in the first slideshow:</p>
<pre>&lt;<span class="tagName">div</span> <span class="attrName">class</span>="<span class="attrValue">highlight</span>" <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">excl</span>" <span class="attrName">smil:<em>first</em></span>="<span class="attrValue">restart.click</span>"&gt;<br /><br /> &lt;<span class="tagName">div</span> <span class="attrName">id</span>="<span class="attrValue">slide1</span>" <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:00</span>" <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">par</span>"&gt;<br /> &lt;<span class="tagName">p</span>&gt; Ever wanted to… &lt;/<span class="tagName">p</span>&gt;<br /> &lt;<span class="tagName">ul</span> <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">par</span>"&gt;<br /> &lt;<span class="tagName">li</span> <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:02</span>"&gt;<br /> create your own slideshow in HTML?<br /> &lt;/<span class="tagName">li</span>&gt;<br /> &lt;<span class="tagName">li</span> <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:04</span>"&gt;<br /> synchronize HTML content with multimedia streams?<br /> &lt;<span class="tagName">small</span>&gt;(subtitles, transcriptions, annotations…)&lt;/<span class="tagName">small</span>&gt;<br /> &lt;/<span class="tagName">li</span>&gt;<br /> &lt;<span class="tagName">li</span> <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:06</span>"&gt;<br /> animate HTML elements?<br /> &lt;/<span class="tagName">li</span>&gt;<br /> &lt;/<span class="tagName">ul</span>&gt;<br /> &lt;<span class="tagName">h2</span> <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:08</span>"&gt;<br /> …without writing any single line of JavaScript?<br /> &lt;/<span class="tagName">h2</span>&gt;<br /> &lt;/<span class="tagName">div</span>&gt;<br /><br /> &lt;<span class="tagName">div</span> <span class="attrName">id</span>="<span class="attrValue">slide2</span>" <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:12</span>" <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">par</span>"&gt;<br /> […] <br /> &lt;/<span class="tagName">div</span>&gt;<br /><br /> &lt;<span class="tagName">div</span> <span class="attrName">id</span>="<span class="attrValue">slide3</span>" <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:24</span>" <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">par</span>"&gt;<br /> &lt;<span class="tagName">dl</span> <span class="attrName">smil:<em>timeContainer</em></span>="<span class="attrValue">par</span>"&gt;<br /> […] <br /> &lt;/<span class="tagName">dl</span>&gt;<br /> &lt;<span class="tagName">p</span> <span class="attrName">smil:<em>begin</em></span>="<span class="attrValue">0:04</span>" <span class="attrName">class</span>="<span class="attrValue">menu</span>"&gt;<br /> &lt;<span class="tagName">a</span> <span class="attrName">href</span>="<span class="attrValue">about.xhtml</span>"&gt;Learn more…&lt;/<span class="tagName">a</span>&gt;<br /> &lt;<span class="tagName">a</span> <span class="attrName">href</span>="<span class="attrValue">#download</span>"&gt;Download!&lt;/<span class="tagName">a</span>&gt;<br /> &lt;<span class="tagName">button</span> <span class="attrName">id</span>="<span class="attrValue">restart</span>"&gt;Restart&lt;/<span class="tagName">button</span>&gt;<br /> &lt;/<span class="tagName">p</span>&gt;<br /> &lt;/<span class="tagName">div</span>&gt;<br /><br />&lt;/<span class="tagName">div</span>&gt;</pre>
<p>The markup is rather self-explanatory and relies on two basic concepts</p>
<ul><li>time containers define the timing model of child nodes (&lt;par&gt;allel, &lt;seq&gt;uential or &lt;excl&gt;usive);</li>
<li>the "begin" and "dur" attributes provide a basing timing description. Yes, this is the same syntax as the one used in SVG Animations.</li>
</ul>
<p>That’s simple and efficient. The four examples on <a href="http://labs.kompozer.net/timesheets/">labs.kompozer.net/timesheets</a> should be a step-by-step tutorial, and I have a few other demos in mind that I’ll add with the next release of our timesheet scheduler.</p>
<h3>References: SMIL Timing and Timesheets</h3>
<p>
The <a href="http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-IntegrationAttributes">SMIL/Timing</a>
recommendation specifies two attributes, <code><a href="http://labs.kompozer.net/timesheets/timeContainer.xhtml">timeContainer</a></code> and <code><a href="http://labs.kompozer.net/timesheets/timeAction.xhtml">timeAction</a></code>, to integrate timing and
synchronization features into HTML documents:
</p>
<blockquote>
<p>
The modularization of SMIL 3.0 functionality allows language designers
to integrate SMIL Timing and Synchronization support into any XML
language. In addition to just scheduling media elements as in SMIL
language documents, timing may be applied to the elements of the host
language. <strong>For example, the addition of timing to HTML (i.e.
XHTML) elements will control the presentation of the HTML document
over time, and to synchronize text and presentation with continuous
media such as audio and video.</strong>
</p>
<p>
Two attributes are introduced to support these integration cases. The <a href="http://www.w3.org/TR/SMIL3/smil-timing.html#adef-timeContainer">timeContainer</a>
attribute allows the author to specify that any XML language element has
time container behavior. E.g., an HTML <code>&lt;ol&gt;</code> ordered
list element may be defined to behave as a sequence time container. The <a href="http://www.w3.org/TR/SMIL3/smil-timing.html#adef-timeAction">timeAction</a>
attribute allows the author to specify what it means to apply timing to
a given element.
</p>
</blockquote>
<p>
The <a href="http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Introduction">SMIL/Timesheets</a>
draft suggests another way to use SMIL/Timing (and SMIL/BasicAnimation)
with HTML documents:
</p>
<blockquote>
<p>
<strong>This language allows SMIL timing to be integrated into a wide
variety of a-temporal languages</strong>, even when several such
languages are combined in a compound document. Because of its similarity
with external style and positioning descriptions in the Cascading Style
Sheet (CSS) language, this functionality has been termed SMIL
Timesheets.
</p>
<p>
<strong>SMIL Timesheets can be seen as a temporal counterpart of
CSS.</strong> Whereas CSS defines the spatial layout of the document and
formatting of the elements, SMIL Timesheets specify which elements are
active at a certain moment and what their temporal scope is within a
document. And as with CSS, SMIL Timesheets can be reused in multiple
documents, which can provide a common temporal framework for multimedia
presentations with different contents but identical storylines.
</p>
</blockquote>
<p>In other words, we’re not re-inventing the wheel or thinking of another slideshow engine: we’re just implementing an official W3C recommendation.</p>
<h3> What's The Point? </h3>
<p><strong><q> Web Browsers Already Support SMIL </q></strong></p>
<p>
No they don't.
</p>
<p>
Modern web browsers (read: all except Internet Explorer) support
<em>declarative SVG Animations</em>, which rely on the SMIL/BasicAnimation
module — hence the (common) confusion — but can't be used for HTML timing.
They don't support the whole SMIL recommendation.</p>
<p><strong><q> Why Don't You Implement SMIL Instead? </q></strong></p>
<p>
The SMIL spec is huge, it includes a specific box-model which is very far
from the HTML/CSS one, and it's only partially implemented by a few media
players. It might be possible to implement SMIL in modern web browsers,
too, but we think it would be inadequate:
</p>
<ul>
<li>
web authors would have to learn SMIL, which is much more difficult to
use than HTML
</li>
<li>
we don't want to include a SMIL section in a web page: we want to
control the timing of the whole web page!
</li>
<li>
HTML5 and CSS3 are already fine to describe the content and layout;
all we need is a standard, declarative timing language.
</li>
</ul>
<p>
SMIL has been designed for <em>advanced</em> synchronization tasks. Some
SMIL aspects have already been ported to web standards (e.g. SVG
animations and CSS transitions), our project is about porting
SMIL/Timing and Timesheets to web documents.
</p>
<p><strong><q> I Can Already Do That With Flash/JavaScript </q></strong></p>
<p>
That's right. And you can still use JavaScript to get some rollover
effects if you don't want to use the CSS <code>:hover</code>
pseudo-class. ;-)
</p>
<p>
The point is precisely to use a <strong>declarative</strong> language for
all the common tasks that currently require JavaScript development:
</p>
<ul>
<li>
that's much easier for web authors (and for web authoring tool
developers);
</li>
<li>
that's a much better way to achieve a good accessibility / indexability;
</li>
<li>
that's easier to maintain, since no specific JavaScript code is used.
</li>
</ul>
<p>
As this declarative language is (almost) standard, web browsers could
implement it eventually. Until then, we'll provide a free, generic,
JavaScript implementation.
</p>
<p><strong><q> IE Already Supports HTML+Time And Nobody Cares </q></strong></p>
<p>True: Microsoft started supporting HTML+TIME 10 years ago with IE 5.5;
but without SVG, &lt;audio|video&gt; elements and CSS transitions, there
hasn't been many real-life use cases so far.</p>
<p>
We think it's more than time to bring a modern, standard equivalent of
HTML+Time to the web. Especially for multimedia-related tasks.
</p>
<h3>Roadmap</h3>
<p><strong>Bugfixing</strong>: before starting to work on the new editor, I have to get a stable Timesheet Scheduler first. In case you want to contribute: this JS lib is open-source (MIT license), code reviews and patches are welcome.</p>
<p><strong>Event-values support</strong>: I’m not planning to implement the whole SMIL/Timing spec but at the very least, I need a better <a href="http://www.w3.org/TR/SMIL3/smil-timing.html#Timing-EventValueSyntax">event-values</a> support to describe more complex user interactions. Our goal is to get a full-featured web documentary engine.</p>
<p><strong>Internet Explorer support</strong>: IE9 should be relatively easy to support (though CSS transitions will probably not work on this browser), but for older IE versions this is gonna be tricky as this SMIL/Timing implementation focuses on media synchronization, and requires &lt;audio|video&gt; support. A solution would be to use &lt;object&gt; fallbacks targetting the Windows Media Player plugin and design a JavaScript layer that would expose an HTML5-like API to control these object nodes (i.e. play/pause and the “timeupdate” event). If you heard about such a library, please ping me.</p>
<p><strong>Timesheet Editor</strong>: the final goal of this project is to get an easy-to-use, multimedia page authoring tool. It will be based on Kompozer / SeaMonkey Composer, which will leave me some time to port Kompozer to Gecko 2 and backport most of its code to SeaMonkey. Yes, somehow I’ll get paid to work on Kompozer! *\o/*</p>
<p>Many thanks to <a href="http://hanblog.info/blog/">Anthony Ricaud</a> for his tips, and to Kompozer contributors for their early feedback.</p>KompoZer 0.8b3 in Ukrainian and Brazilianurn:md5:04c38082b0b08909f1a7f3ecbc2c4b3b2010-04-08T01:28:00+02:002010-04-08T01:33:46+02:00Kazéeditorl10nmozilla <p><img src="http://kazhack.org/public/kompozer-logo.png" alt="KompoZer logo" style="float:right; margin: 0 0 1em 1em;" title="KompoZer logo, apr. 2010" />
Two new locales have just been added to the official “Download” page: <a href="http://kompozer.net/download.php" title="http://kompozer.net/download.php">http://kompozer.net/download.php</a></p>
<p>The Ukrainian one is mainly (only?) the result of <strong>Andriy Radyk</strong>’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!</p>
<p>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.</p>
<p>We’re still looking for a Brazilian contributor to review and maintain this langpack: please ping us if you want to contribute.</p>KompoZer n’est pas Nvuurn:md5:6d8e25de04eb7126e7d0b341b385b37c2010-04-07T01:35:00+02:002010-04-08T22:37:55+02:00Kazéeditorlibremozfrmozilla<p>Daniel Glazman a <a href="http://www.glazman.org/weblog/dotclear/index.php?post/2010/03/31/BlueGriffon-news" hreflang="en">annoncé</a> 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&nbsp;: être payé pour bosser sur son domaine de prédilection.</p>
<p>En revanche, j’ai sérieusement tiqué en lisant <a href="http://standblog.org/blog/post/2010/04/02/Interview-Glazman-BlueGriffon">l’entretien</a> publié par Tristan sur son blog. J’ai longtemps hésité à réagir (pas envie de déclencher une <em>flame war</em>), mais la réaction des autres contributeurs KompoZer m’impose de répondre à quelques points en particulier.</p> <h3>Les approximations sur KompoZer</h3>
<blockquote><p>« Si Kompozer a un succès mérité aujourd'hui, il reste que c'est Nvu™ à 99%. »</p></blockquote>
<p>KompoZer 0.7, en 2006, était une proposition de bugfix pour Nvu visant à corriger les bugs les plus handicapants de l'application, donc effectivement c’était du Nvu à 99%. À l’époque, je découvrais le XUL et je bossais tout seul sur ce projet…</p>
<p>Mais nous sommes en 2010 aujourd'hui et KompoZer 0.8 n’a plus grand-chose à voir avec Nvu : il emprunte bien plus de code à SeaMonkey Composer qu’à Nvu. Et la version en développement (0.9) est bâtie à 100% sur SeaMonkey Composer.</p>
<p><strong>KompoZer est devenu un vrai projet communautaire</strong>, ce que Nvu n’a jamais été. Si demain je me faisais écraser par un autobus (ou pire, si je trouvais un boulot salarié ^^), le projet continuerait sans moi — probablement moins vite, mais il continuerait. À l’inverse, quand Linspire a arrêté le support de Nvu, les forums d’assistance et de développement ont tout simplement disparu du jour au lendemain, avec toutes les données qu’ils contenaient.</p>
<blockquote><p>« Nvu™ est obsolète. »</p></blockquote>
<p>C’est complètement vrai, et je ne l’aurais pas relevé si le sous-entendu n’était pas que KompoZer était obsolète au même titre que Nvu. Mais maintenant qu’on en parle, pourquoi Nvu est-il obsolète ?</p>
<ul>
<li>parce que son développement a été abandonné dès que le financement s’est arrêté, soit le jour même de la sortie de la version 1.0 ;</li>
<li>parce qu’il est construit sur un noyau Gecko 1.7 fortement modifié (15'000 lignes de patch), qui ne fonctionne plus sur les postes Mac ou Linux récents ;</li>
<li>corollaire : impossible de rétro-porter un tel code dans le tronc Mozilla (contrairement à ce qui avait été annoncé au départ du projet).</li>
</ul>
<p>Parallèlement, SeaMonkey Composer a poursuivi son petit bonhomme de chemin. Il suit l’évolution du noyau Gecko (HTML5, CSS3, etc.), certes sans ajouter de fonctionnalités coté interface, mais avec une stabilité irréprochable : un bon exemple de projet pérenne car maintenu par la communauté Mozilla.</p>
<p>Le but qu’on poursuit avec le projet KompoZer c’est précisément de ramener le code dans le giron Mozilla. Toute la branche 0.8 est une étape intermédiaire qui consiste à supprimer le patch Nvu pour que la branche 0.9 soit intégrée directement au comm-central Mozilla. Les améliorations profiteront donc directement à SeaMonkey, indirectement à Thunderbird.</p>
<p><strong>Nvu était obsolète <em>“by design”</em>, mais KompoZer et SeaMonkey Composer ne le sont pas</strong> — au contraire, ces projets font le choix de la pérennité. Ce sont des projets communautaires proches de Mozilla, on a déjà de nombreuses locales (22 pour Kompozer 0.8) et des contributeurs réguliers.</p>
<h3>Les nouvelles fonctionnalités annoncées</h3>
<blockquote><p>« Aujourd'hui, il est temps de faire apparaître un outil d'édition plus moderne, offrant la puissance des versions récentes de Gecko et les fonctionnalités de CSS3 et HTML5. »</p></blockquote>
<p>Tout comme SeaMonkey Composer, <strong>KompoZer 0.9 supporte déjà CSS3 et HTML5</strong>. Nul besoin de faire une nouvelle application pour supporter le dernier moteur Gecko en date, il suffit d’avoir une application qui soit respectueuse du code Mozilla — comme SeaMonkey et KompoZer ≥ 0.8.</p>
<p><a href="http://kazhack.org/public/screenshots/kpz09a1pre-css3.png" title="KompoZer 0.9a1pre, CSS3 demo"><img src="http://kazhack.org/public/screenshots/.kpz09a1pre-css3_m.jpg" alt="KompoZer 0.9a1pre, CSS3 demo" style="display:block; margin:0 auto;" title="KompoZer 0.9a1pre, CSS3 demo, avr. 2010" /></a></p>
<p>KompoZer 0.9 est encore en pré-alpha précisément parce que je préfère rétro-porter toutes les fonctionnalités stables dans comm-central (SeaMonkey) *avant* de sortir une version publique. Avec l’équipe SeaMonkey, nous allons mettre en place un système de <em>nightlies</em> pour que les utilisateurs puissent se rendre compte de l’avancement du projet.</p>
<p>Tant qu’IE9 n’est pas sorti, je ne ressens pas d’urgence à proposer un éditeur web supportant CSS3 : il suffit de jeter un œil sur les forums de support pour se rendre compte que l’incompréhension la plus fréquente concerne les différences de rendu entre IE et les navigateurs modernes.</p>
<blockquote><p>« Un des buts de l'amélioration de l'extensibilité est clairement la distribution au moment de la 1.0 de BlueGriffon d'un premier jeu assez étoffé d'add-ons »</p></blockquote>
<p>Je ne pense pas que KompoZer soit difficile à étendre. Jean-Bernard <em>“Goofy”</em> Marcon, qui n’est absolument pas développeur, a déjà codé des petites extensions pour KompoZer 0.8 : <a href="http://addons.kompozer.net/" title="http://addons.kompozer.net/">http://addons.kompozer.net/</a></p>
<p>Par ailleurs, cinq étudiants du projet CoMETE réalisent des extensions KompoZer plus ambitieuses : <a href="http://labs.kompozer.net/" title="http://labs.kompozer.net/">http://labs.kompozer.net/</a></p>
<p>L’extensibilité de KompoZer est certes perfectible, mais la plus grosse marge de progression résiderait dans le fait de se rapprocher de Firefox autant que possible (typiquement, en exposant un <code>gBrowser</code>), afin de pouvoir porter facilement les nombreuses extensions Firefox qui sont orientées développement web.</p>
<p>Réciproquement, je crois qu’il faut aussi privilégier la réutilisation d’extensions existantes plutôt que de recoder une fonctionnalité dans son coin. À ce titre, c’est à ma demande et pour le projet KompoZer que les auteurs de <a href="http://fireftp.mozdev.org/">FireFTP</a> et <a href="http://www.scribefire.com/">ScribeFire</a> ont accepté de changer de licence afin de les rendre totalement compatibles avec la base de code Mozilla. Les fonctionnalités de publication FTP et XML-RPC seront donc mutualisées, ce qui ne peut qu’améliorer la stabilité pour tous les utilisateurs.</p>
<p>Pour qu’un projet reçoive des extensions il faut aussi en assurer la pérennité : un projet maintenu par une personne seule n’est jamais viable à long terme. C’est la raison pour laquelle les équipes SeaMonkey et KompoZer travaillent en commun sur la branche 1.9.3, dans le but de reverser autant de code que possible sur comm-central — ce qui profite directement à SeaMonkey, indirectement à Thunderbird et potentiellement à Firefox.</p>
<h3>Quel intérêt pour Mozilla ?</h3>
<blockquote><p>« longue vie à BlueGriffon™ ! »</p></blockquote>
<p>Bien sûr, c’est ce que je souhaite à Daniel ; mais <strong>ça ne sera pas positif pour Mozilla</strong>.</p>
<p>Qu’est-ce que Nvu a apporté au projet Mozilla ? Absolument rien. Ce projet paraissait pertinent en 2005 puisqu’il fallait bien faire une version standalone de l’éditeur à l’heure où on séparait la Suite Mozilla en Firefox + Thunderbird ; mais de par sa conception, il était impossible de reverser le code au tronc Mozilla.</p>
<p>Est-ce que BlueGriffon sera différent ? Je ne le crois pas. Au contraire, là où Nvu n’était qu’un petit fork de la base de code Mozilla, BlueGriffon est une réécriture majeure, où même l’interface utilisateur a une base de code différente : les améliorations de BlueGriffon ne pourront pas être réutilisées dans Thunderbird ou SeaMonkey Composer.</p>
<p><strong>Toutes les nouvelles fonctionnalités annoncées par Daniel pourraient être réalisées sur la base de code Mozilla</strong> — dont il est théoriquement responsable du module "editor", soit dit en passant. Je comprends bien que pour un investisseur, le modèle économique est plus rassurant avec un écosystème d’extensions distinct. Je comprends aussi qu’il est plus satisfaisant intellectuellement de développer une nouvelle application plutôt que de déboguer l’existant. Mais <strong>techniquement, il n’y a rien qui justifie de forker à nouveau la base de code Mozilla</strong>.</p>
<p>À plus long terme, il faut aussi se demander à quoi va servir un éditeur web WYSIWYG en 2010 : nombre d’utilisateurs débutants préfèrent publier leurs pages sur MySpace ou FaceBook, voire sur un CMS type WordPress, Joomla, Drupal ou autre. Les utilisateurs avancés, eux, n’ont pas l’utilité d’un éditeur WYSIWYG (inutilisable avec PHP, Python, etc.) et ont besoin avant tout d’un bon IDE comme Komodo — qui est lui aussi extensible et propulsé par Mozilla.</p>
<p>Je pense donc qu’<strong>il vaudrait bien mieux viser à avoir un éditeur web WYSIWYG stable et pérenne car débogué en bonne intelligence avec les autres développeurs Mozilla, et développer un écosystème d’extensions qui soient compatibles avec Firefox et/ou Komodo</strong>. L’éditeur CSS en est un très bon exemple. Et je ne vois pas en quoi ça serait incompatible avec le modèle économique de Daniel.</p>
<h3>Quelles conséquences pour KompoZer ?</h3>
<p>À priori aucune si BlueGriffon n’utilise pas la base de code comm-central. Le but de KompoZer 0.8+ étant de pérenniser le développement en le rétro-portant sur comm-central, je ne pourrais que regretter que le talent et l’énergie de Daniel ne contribuent pas à cet objectif, mais il serait dommage de s’arrêter si près du but.</p>
<p>En revanche, si BlueGriffon utilisait la base de code comm-central pour l’interface de base et implémentait les fonctionnalités spécifiques dans des JSM séparés, il serait bénéfique pour tout le monde que le projet KompoZer s’efface au profit de BlueGriffon et SeaMonkey Composer : mon temps serait alors bien mieux employé à contribuer à ces deux projets.</p>
<h3>Contribuer</h3>
<p>Si vous souhaitez contribuer à KompoZer *et* à l’éditeur Mozilla, vous pouvez nous rejoindre sur le canal <a href="irc://irc.mozilla.org/kompozer">#kompozer</a>.</p>
<p><ins>Mise à jour :</ins> voir aussi <a href="http://standblog.org/blog/post/2010/04/08/Interview-Fabien-Cazenave-Kompozer">l’entretien que m’a accordé Tristan</a>. :-)</p>KompoZer 0.8b3 in Slovenianurn:md5:d049c9f2be2b74cf07241c79c7ac256f2010-03-12T04:57:00+01:002010-03-16T00:17:51+01:00Kazéeditorl10nmozilla<p><img src="http://kazhack.org/public/kompozer-logo.png" alt="KompoZer logo" style="float:right; margin: 0 0 1em 1em;" title="KompoZer logo, mar. 2010" /></p>
<p>While most of the KompoZer 0.7.10 language packs have been upgraded to KompoZer 0.8, we’ve set up a <a href="http://kompozer.sourceforge.net/l10n/narro/">Narro server</a> 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.</p> <p>The Slovenian localization has been done by <strong>Roman Bobnarič</strong>. The only untranslated strings were related to the <a href="http://kompozer.hg.sourceforge.net/hgweb/kompozer/kompozer/file/ed97e65cd43b/l10n/en-US/dom/chrome/layout/css.properties">css.properties file</a>, and there hasn’t been any progress on these strings for months. But yesterday we found out that these strings weren't translated for other official <a href="http://mxr.mozilla.org/l10n-mozilla1.8/source/sl/dom/chrome/layout/css.properties">Gecko 1.8</a> applications either, so Cédric Corazza (l10n lead) and I had a little talk about that.</p>
<p>Cédric’s opinion is simple: <q>if any single string is untranslated, the locale isn’t ready, period.</q> He doesn’t care if some losers working on an unknown project like Firefox don’t have similar quality standards. :-)</p>
<p>However, this css.properties file has been fully translated for <a href="http://mxr.mozilla.org/l10n-mozilla1.9.2/source/sl/dom/chrome/layout/css.properties">Gecko 1.9.2</a>, so I’ve copied as many strings as possible from the new file. On the 89 untranslated strings, 73 could be updated and 16 couldn’t be translated.</p>
<p>As these strings only show up in the JavaScript console to describe CSS errors, and since KompoZer’s JavaScript console doesn’t display CSS errors by default, Cédric finally agreed to use this file “as is” and leave 16 untranslated strings. He still insists that it’d be much better if a Slovenian contributor could finish the job.</p>
<p>Anyway, the result is that we’ve just published Slovenian builds of KompoZer for Windows, MacOSX and GNU/Linux on the <a href="http://kompozer.net/download.php">download page</a> — 20 languages are now supported by KompoZer! \o/</p>
<p><ins>Note:</ins> there’s little work to do to finish the following locales:</p>
<ul>
<li><a href="http://kompozer.sourceforge.net/l10n/narro/narro_project_text_list.php?l=pt-BR&amp;p=1&amp;tf=4&amp;st=1&amp;s=#p1">Brazilian (pt-BR)</a>: ~70 strings</li>
<li><a href="http://kompozer.sourceforge.net/l10n/narro/narro_project_text_list.php?l=ga-IE&amp;p=1&amp;tf=2&amp;st=1&amp;s=#p1">Irish (ga-IE)</a>: ~180 strings</li>
<li><a href="http://kompozer.sourceforge.net/l10n/narro/narro_project_text_list.php?l=ko&amp;p=1&amp;tf=2&amp;st=1&amp;s=">Korean (ko)</a>: ~ 280 strings</li>
</ul>
<p>Feel free to drop a message if you’re willing to help on these locales. Of course, if you feel like contributing another translation, you’re very welcome. :-)</p>
<p><ins>Update:</ins> <a href="http://mozilla.si/" hreflang="si">Matjaž Horvat</a> has just submitted a patch to fix the 16 untranslated strings (and a little more…). Thanks! Cédric will sleep much better now. :-D</p>KompoZer 0.8b3 in Czechurn:md5:53a5efff79f9ed3e0c1148a0e7ca57e02010-03-09T19:15:00+01:002010-03-15T23:49:30+01:00Kazéeditorl10nmozilla <p><img src="http://kazhack.org/public/kompozer-logo.png" alt="KompoZer logo" style="float:right; margin: 0 0 1em 1em;" title="KompoZer logo, mar. 2010" /></p>
<p>Jaroslav Krejčí (aka “JardaK”) has just submitted a Czech language pack for KompoZer 0.8.</p>
<p>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.</p>
<p>As a result, there are now Czech builds of KompoZer 0.8b3 on the official <a href="http://kompozer.net/download.php">download page</a> for Windows, MacOSX and GNU/Linux. Thanks a lot JardaK!</p>
<p><ins>Note:</ins> 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 (sk) and Bulgarian (bg) ones. Feel free to drop a message if you want to upgrade one of these langpacks. ;-)</p>
<p><ins>Update (2010-03-15):</ins> the above note could be misunderstood, let’s clarify:</p>
<ul>
<li>the Brazilian langpack is almost ready (~70 untranslated strings)</li>
<li>the Bulgarian langpack is in progress (&gt; 500 untranslated strings)</li>
<li>nobody’s working on the Slovak langpack yet</li>
</ul>
<p>Note that <a href="http://kompozer.sourceforge.net/l10n/narro/">Narro</a> allows several contributors to work on the same language pack simultaneously.</p>KompoZer 0.8b3urn:md5:c1c8aa88cd259b072b339d4dac8542472010-03-02T18:18:00+01:002014-12-11T21:59:28+01:00Kazéeditorlinuxosxwindows<p><img src="http://kazhack.org/public/kompozer-logo.png" alt="KompoZer logo" style="float:right; margin: 0 0 1em 1em;" title="KompoZer logo, mar. 2010" /></p>
<p>We’ve just released KompoZer 0.8b3:</p>
<ul>
<li><img src="http://kompozer.sourceforge.net/images/os_win.png" alt="" /> <a href="https://sourceforge.net/projects/kompozer/files/current/0.8b3/windows/exe/kompozer-0.8b3.en-US.win32.exe/download">kompozer-0.8b3.en-US.win32.exe</a> (Windows™ installer)</li>
<li><img src="http://kompozer.sourceforge.net/images/os_win.png" alt="" /> <a href="https://sourceforge.net/projects/kompozer/files/current/0.8b3/windows/zip/kompozer-0.8b3.en-US.win32.zip/download">kompozer-0.8b3.en-US.win32.zip</a> (Windows™ archive)</li>
<li><img src="http://kompozer.sourceforge.net/images/os_mac.png" alt="" /> <a href="https://sourceforge.net/projects/kompozer/files/current/0.8b3/macosx/kompozer-0.8b3.en-US.mac-universal.dmg/download">kompozer-0.8b3.en-US.mac-universal.dmg</a> (Mac OS X™)</li>
<li><img src="http://kompozer.sourceforge.net/images/os_linux.png" alt="" /> <a href="https://sourceforge.net/projects/kompozer/files/current/0.8b3/linux-i686/kompozer-0.8b3.en-US.gcc4.2-i686.tar.gz/download">kompozer-0.8b3.en-US.gcc4.2-i686.tar.gz</a> (GNU/Linux)</li>
<li><img src="http://kompozer.sourceforge.net/images/sources.png" alt="" /> <a href="https://sourceforge.net/projects/kompozer/files/current/0.8b3/kompozer-0.8b3-src.tar.bz2/download">kompozer-0.8b3-src.tar.bz2</a> (source tarball)</li>
</ul>
<p>Localized binaries are available on the official download page: <a href="http://kompozer.net/download.php" title="http://kompozer.net/download.php">http://kompozer.net/download.php</a>.</p> <p>This maintainance release fixes two regressions that have been introduced in the previous beta:</p>
<ul>
<li><a href="https://sourceforge.net/tracker/index.php?func=detail&amp;aid=2957813&amp;group_id=170132&amp;atid=853122">bug #2957813</a>, the "Source" mode was not applying modifications properly</li>
<li><a href="https://sourceforge.net/tracker/index.php?func=detail&amp;aid=2959534&amp;group_id=170132&amp;atid=853122">bug #2959534</a>, the "class" drop-down list was broken by a dirty attempt to make it UTF8-friendly</li>
</ul>
<p>I didn’t want to take the risk of addressing other bugs but I did work on <a href="https://sourceforge.net/tracker/index.php?func=detail&amp;aid=1831943&amp;group_id=170132&amp;atid=853122">bug 1831943</a> by disabling line wrapping for Asian users. The relevant preference (editor.htmlWrapColumn) it now set to zero for Chinese (zh-CN, zh-TW) and Japanese (ja) builds, and it should be read properly by KompoZer — both when switching to “Source” mode and when saving HTML documents. This is still experimental, so your feedback will be welcome.</p>
<p>We’ve spent a few hours designing a <a href="http://kompozer.hg.sourceforge.net/hgweb/kompozer/kompozer/file/3f49ca5a63b2/release.py">bash/python script</a> to make localized binaries for the 18 languages that are currently supported by KompoZer. This script works fine on Linux and OSX and it can build win32 installers by launching the InnoSetup compiler through Wine. It also checks that I haven't forgotten to include the MSVC7 DLLs in the win32 binaries, which should avoid us a few <a href="http://forum.mozillaitalia.org/index.php?topic=44156.msg282135#msg282135" hreflang="it">bad surprises</a> for the next releases…</p>
<p>For the next beta we’ll focus on the “Source” view and the FTP module. We’ll do our best to release it in March.</p>
<p><ins>EDIT</ins> In case you’ve downloaded a Windows build with missing MSVC7 dlls, I’ve just changed the path of all Windows binaries on SourceForge. Please download KompoZer 0.8b3 again, the problem should be solved. Sorry for the trouble. :-/</p>KompoZer 0.8b2urn:md5:21e601a26844ce213b03d8c6f47a1ae52010-02-23T04:58:00+01:002014-12-11T21:59:37+01:00Kazéeditorlinuxosxwindows<p><img src="http://kazhack.org/public/kompozer-logo.png" alt="KompoZer logo" style="float:right; margin: 0 0 1em 1em;" title="KompoZer logo, feb. 2010" /></p>
<p>KompoZer 0.8b2 is finally ready. Few visible changes, but a lot of bugfixes and code cleaning under the hood.</p>
<p>You can grab KompoZer 0.8b2 here: <a href="http://kompozer.net/download.php" title="http://kompozer.net/download.php">http://kompozer.net/download.php</a></p>
<p>Enjoy, and please report bugs!</p> <h3>Bug Fixes</h3>
<p>We’ve tried to solve the most frequently reported bugs:</p>
<ul>
<li>the CSS Editor shouldn't add those annoying “*|” strings in the selectors any more</li>
<li>the preview in the “Image Properties” box now works properly</li>
<li>better FTP support (right-click in the Site Manager context menu)</li>
<li>the markup cleaner doesn't crash on nested lists any more</li>
<li>Enter in a paragraph now creates a new paragraph</li>
<li>the “Credits” panel in the About box is back ;-)</li>
</ul>
<p>KompoZer 0.8b2 is now a more reliable editor: the regressions in the CSS editor were a complete blocker for myself, so I guess it’s been a real nightmare for most users. We’ve fixed a lot of small bugs and I think the overall user experience should be much better than with the previous versions.</p>
<h3>18*4 Localized Binaries</h3>
<p>Cédric Corazza, our l10n lead, has done a great job to release localized binaries for all the supported languages at once. This time he’s had much more work than for the previous beta:</p>
<ul>
<li>we had 9 locales for the 0.8b1 release, there are 18 locales for 0.8b2:
<ul>
<li>Catalan, Dutch, Hungarian, Japanese got ready after the 0.8b1 release</li>
<li>Simplified Chinese, Esperanto, Finnish, Portuguese, Upper Sorbian have been added for the 0.8b2</li>
</ul></li>
<li>Cédric has made <strong>Windows™ installers</strong>, which should put an end to one of the most frequent feature request</li>
<li>he’s built all binaries manually, as we don’t have any kind of script to ease this task (I considered that as a typical “l10n lead job”)</li>
</ul>
<p>Cédric, congrats! and go get some sleep, the Korean and Bulgarian locales are getting ready. ;-) I’ll definitely write a few scripts to ease your work for the next release.</p>
<h3>Inline Spell Checker</h3>
<p>The inline spell checker in KompoZer 0.7.10 was inherited from Nvu, it was implemented with a specific patch against the Gecko 1.7 core and it caused a lot of freezes and crashes. As a result, most users (including myself) disabled it and I didn’t see it as an important feature to bring back in KompoZer 0.8.</p>
<p>As you can guess, a lot of users had a very different opinion on this. :-)</p>
<p>Unlike Gecko 1.7, Gecko 1.8.1 has a very good built-in inline spell checker. I’ve had a look at Thunderbird’s code and I found out enabling the inline spell checker in KompoZer was a snap. I’m sorry I didn’t do it sooner — but now it’s done, and it’s working fine as far as I know.</p>
<h3>DOM Explorer Sidebar</h3>
<p>I’m working with <a href="http://rocu.fabien.free.fr/blog/" hreflang="fr">Fabien ’Kasparov’ Rocu</a> on the next version of the DOM Explorer. As Fabien is implementing his ideas in an extension, I had to clean up the DOM Explorer and add a few hooks for his addon. To ease the development of his add-on, we’ve decided to implement a part of his work directly in KompoZer 0.8b2:</p>
<ul>
<li>the DOM Explorer now shows the HTML attributes of the current element</li>
<li>a double-click on an element in the DOM Explorer brings up its “Property” dialog</li>
</ul>
<p>The real improvement will come with Fabien’s extension, which should be released in April 2010. I’ll come back to this in another blog post.</p>
<h3>New Keyboard Shortcuts</h3>
<p>I’m known to be a dangerous pervert when it comes to computer keyboards — I admit I hate having to use a mouse when I’m editing a text. These new keyboard shortcuts aren’t documented, you can see them as a hidden bonus:</p>
<ul>
<li>Ctrl+(Up|Down) moves the caret to the (beginning|end) of the current element</li>
<li>Ctrl(+Shift)+Enter adds a new line after (before) the current element</li>
<li>Alt+Shift+Enter switches to “Source” view</li>
</ul>
<p>The Ctrl+Up/Down shortcut is more than a productivity booster. One of the known problems of the Mozilla editor component is that in some situations, it can be difficult to put the caret where you want it: for instance, there’s no easy way to put the caret right after a &lt;div&gt; block if it’s the last block in the page. With KompoZer 0.7.10 you had to select the &lt;div&gt; in the status bar, press the right arrow and hit Return; now all you need is to do a Ctrl+Down.</p>
<h3>The “Source” View Still Sucks…</h3>
<p>…and I’m aware of that. Please configure KompoZer to use your favorite text editor to work on the HTML source, there’s a specific “HTML” button by default in the main toolbar for that. I can’t help it, I hate the “Source” view in Nvu and KompoZer 0.7:</p>
<ul>
<li>I don’t see much point in a pseudo syntax hilighting that doesn’t update as you type</li>
<li>I don’t see any point in showing line numbers that don’t match the *real* line numbers in the HTML file</li>
<li>nobody understands why the “Source” view hides the document tabs</li>
<li>it was the main source of crashes for KompoZer 0.7</li>
</ul>
<p>The SeaMonkey-like plaintext editor, in my opinion, is much better at the moment — and on my first trunk builds (KompoZer 0.9a1pre / Gecko 1.9.3), <a href="http://mozillalabs.com/bespin/">Bespin</a> is already working quite well.</p>
<p>Again, I understand a lot of users have a very different opinion on this, so I’ve tried an interesting experiment with this “Source” view: basically, I’ve re-written the main &lt;tabeditor&gt; element so it includes its own source editor. This embedded source editor could be used either for the “Split” view or for the “Source” view, and I could switch to “Source” mode without loosing the document tabs.</p>
<p>Unfortunately, this new &lt;tabeditor&gt; element raised a few problems that I couldn’t solve easily for this 0.8b2 release, so I’ve had to revert to the good old plaintext editor. For the 0.8b3 I’ll probably re-implement an Nvu-like “Source” view, rather than spending too much time on a feature that won’t work as well as Bespin: I prefer to release KompoZer 0.8 sooner in order to propose a Bespin-based KompoZer 0.9 as soon as possible.</p>
<h3>The HTML Serializer Still Sucks…</h3>
<p>…but we’re working on it. As you may have noticed, the HTML output of KompoZer 0.8 is already much cleaner than the one we had in KompoZer 0.7, especially if you check the <em>“reformat HTML source”</em> option: the most visible point is, there are (almost) no empty lines any more in the output files. But your well-defined indentation is still destroyed by KompoZer, which is a real pain when switching to “Source” mode.</p>
<p>Of course, you can use HTML Tidy as a workaround; I even used to design an Nvu extension for that. But this means dealing with temp files, serializing the files twice (once with KompoZer + reformatting with Tidy), and risking data losses (especially in utf-8, don’t ask me why). And the HTML code in the “Source” view is still a mess.</p>
<p>The great news is, <a href="http://ljouanneau.com/en">Laurent Jouanneau</a> has backported his <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=422403">XHTML serializer</a> to Gecko 1.8.1 so I could use it for KompoZer 0.8 — and the first results look great! See this small example I saved with <a href="http://kazhack.org/tmp/serializer/serializer-17.txt">KompoZer 0.7.10</a>, <a href="http://kazhack.org/tmp/serializer/serializer-181.txt">KompoZer 0.8b2</a> and <a href="http://kazhack.org/tmp/serializer/serializer-181-patch.txt">KompoZer 0.8b3pre</a>. Looks like we can finally get rid of HTML Tidy!</p>
<h3>Almost Done</h3>
<p>There are four main points to address before we can release a third (and hopefully last) beta:</p>
<ul>
<li>adapt KompoZer 0.8 to the new HTML serializer;</li>
<li>get some kind of colored source view working;</li>
<li>fix the bugs in the “Split” view so people start using it;</li>
<li>work on FTP support to replace the current “Publish” button.</li>
</ul>
<p>Please test this new version and report bugs. Many thanks to all users who <a href="http://kompozer.net/donate.php">donated</a> or gave some time to keep this project running!</p>FOSDEM 2010urn:md5:5081470ed4a1ae831502ea9755b7a63d2010-02-14T19:20:00+01:002010-02-14T20:23:00+01:00Kazéeditoreventlibremozilla <p>Another year, another FOSDEM. This year I haven't been surprised by the overall nerd factor, I guess that's a clear sign that I’ve significantly nerdified myself. Never mind — as <a href="http://blog.mozilla.com/seth/">Seth B.</a> told me:</p>
<blockquote><p>It’s okay to be a nerd. Look at <a href="http://informationisart.com/stas/">Staś</a>!</p></blockquote>
<h3>One Year In Review</h3>
<p>I've had the opportunity to give a <a href="http://kazhack.org/tmp/fosdem10/" hreflang="en">lightning talk</a> about the work that has been done on KompoZer since the last FOSDEM — i.e. since the first alpha release of the 0.8 branch:</p>
<ul>
<li><strong>code cleaning</strong>: KompoZer 0.7 was built on Nvu, which required a 15'000 line C++ patch against the Gecko core. Most of this patch concerned UI improvements, which are now implemented in XUL/JavaScript. KompoZer 0.8 builds on an almost pure Gecko core — we just need a little patch for the PHP support.</li>
<li><strong>new features</strong>: the DOM Explorer sidebar and the split view should help KompoZer users learning HTML and CSS, the new Site Manager (still in development) should solve most of the publication issues we inherited from Mozilla Composer.</li>
<li><strong>team building</strong>: KompoZer isn't a one-man-project any more. Cédric Corazza and Frédéric Chateaux have joined the team to help me with the localization support and the quality assurance. Thanks to them I can focus on development.</li>
</ul>
<p><a href="http://www.flickr.com/photos/36827738@N08/4346092509/"><img src="http://kazhack.org/public/events/BeerEvent-500px.jpg" alt="fosdem10-CedricFrederic.jpg" style="display:block; margin:0 auto;" title="Cédric and Frédéric, as seen on the FOSDEM 2010 opening keynote, feb. 2010" /></a></p>
<h3>KompoZer Labs</h3>
<p>The best news in these last months is that <strong>the KompoZer community is growing</strong>. Last year, we've set up a <a href="http://labs.kompozer.net/" hreflang="en">KompoZer labs</a> page with a few projects that we’d like to experiment, and five projects have already been selected by <a href="http://kazhack.org/?post/2009/10/28/Comete-Course-on-Mozilla-Education-and-Technologies-at-Evry" hreflang="en">CoMETE students</a>:</p>
<ul>
<li>real-time collaborative HTML edition (XMPP/SXE)</li>
<li>CMS publication (XML-RPC)</li>
<li>enhanced DOM Explorer sidebar</li>
<li>easier CSS Editor</li>
<li>SFTP support</li>
</ul>
<p>The CoMETE team is very motivated and these projects are making good progress — I'll detail them in another blogpost soon. In case you’re interested in working on another “Labs” project, or if you’d like to submit another idea for this “Labs” page, feel free to ping us on the <a href="http://kompozer.sourceforge.net/irc/">#kompozer</a> channel.</p>
<h3>KompoZer.next</h3>
<p>This FOSDEM has also been the opportunity to organize the development of the next KompoZer branch along with the SeaMonkey team. Last year, we’ve had a simple deal:</p>
<ul>
<li>the SeaMonkey team would help us <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=477845">build a standalone editor</a> from the comm-central codebase</li>
<li>in exchange, we’d help <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=477840">backporting KompoZer to SeaMonkey Composer</a></li>
</ul>
<p><strong>This deal is now becoming effective, and I already have a pre-alpha, Gecko 1.9.3 build of KompoZer.</strong> So instead of just porting KompoZer to Gecko 1.9.3, we’ll open a few tickets on Bugzilla to backport the main KompoZer features and bugfixes on comm-central: putting the code in a public place like <a href="https://bugzilla.mozilla.org/">BMO</a> and getting reviews from other Mozilla developers should help keeping the project stable and open in the long-term. I’ll do my best to release an official alpha version before the Firefox Summit, with the features that I’ve announced in the <a href="http://kazhack.org/?post/2009/10/06/EU-MozCamp-2009%2C-Prague">EuMozCamp09</a>: Bespin code editor, xml-rpc publication, collaborative edition…</p>
<h3>Back To Real Life</h3>
<p>I’m almost done with the urgent work, which means I can focus on KompoZer 0.8b2 again. I realize it’s been a while since the last release (0.8b1), so I’ll probably drop some of the unfinished work I’ve been doing on this branch to release the 0.8b2 version ASAP — hopefully next Sunday.</p>