FTP support

KompoZer 0.8b1 - FTP console All previous versions (Mozilla/SeaMonkey Composer, Nvu, KompoZer 0.7.x) relied on a nsWebBrowserPersist object to publish files on a remote FTP server. Basically, this is the same mechanism as when you save a “full” page with Firefox (i.e. including images, stylesheets, etc.): the HTML document is published more or less where you want it, but all related files have to be in one subdirectory. This is fine if you only want to publish a single page, but it has two main drawbacks:

  • you can’t keep a single stylesheet for all HTML pages on a website;
  • it can't be used to publish linked files like PDF documents, media files, etc.

KompoZer 0.8b1 now has a real FTP upload feature. Most of the credit goes to Mime Čuvalo, developer of FireFTP, who allowed me to reuse his main FTP class in KompoZer.

In this version, it’s only available in the Site Manager (right-click > “Publish…”); I still have to tweak the “Publish” button in the main toolbar to publish the current HTML documents… and all its related files. One of the nice things is, this FTP upload will create all the necessary remote folders to ensure we have the same directory structure on the remote site and on the local disk. With this upload feature, the workflow is more DreamWeaver-like: first edit your files on your hard disk, then publish them to a remote server.

Compared with previous versions, this should also bring some support for passive mode and FTPS — this has to be tested yet. Unfortunately, there's no SFTP support and I’m afraid there won't be any in this 0.8 branch: the Mozilla core has no SSH support we could use for SFTP. I understand this is a major limitation, and I'll see what we can do to have a proper SFTP support in the 0.9 branch… but I can’t work on this for KompoZer 0.8.

In the SiteManager, I’ve dropped the remote tree for now. I'm not sure yet to re-implement it: I might prefer to adapt FireFTP to KompoZer, in order to keep the SiteManager as simple as possible.

Syntax highlighting in split view

In the previous versions, the split view used a deck to:

  • display the source in a <browser> element (with syntax highlighting)
  • edit the source in a <textbox> element

I didn’t mind having a modal editor for this split view — I’m a Vim fanboy — but wasn’t pleased to lose the syntax highlighting when entering the edit mode. So this deck has been replaced by an <editor> element, that both displays and edits the HTML code of the current element. This is much more comfortable to use, I hope it won’t cause too many bugs.

Before you ask: no, there’s no syntax highlighting in the “Source” tab yet. But try to use the split view and select the <html> element (either in the status bar or on the DOM Explorer sidebar), and you’ll have an idea of what the “Source” tab will look like in the next version.

Ability to edit text files

Mozilla/SeaMonkey Composer is able to edit text files. It’s just a Notepad-like feature, but it works. Because of the way tabs have been implemented in Nvu 1.0 and KompoZer 0.7, we lost this feature. Even worse, it wasn’t possible any more to export any HTML document as text.

I’ve tried to solve this in this release. It works quite well for ASCII files but it’s not suitable for other encodings yet - but at least, this should be enough to edit an .htaccess file. The user interface should disable all toolbar buttons and menu items that are specific to HTML, but I’ve seen a few bugs already.

For the next versions, I’ll try to implement some syntax highlighting for text files. There’s a bunch of JavaScript syntax highlighter around, we’ll just have to pick one and use it to transform a text file to an HTML one. That will bring the same pseudo syntax highlighting we have in split view.

Better PHP support on GNU/Linux

One of the very irritating bugs in Nvu 1.0 and KompoZer 0.7 was that it couldn’t edit *.php files on GNU/Linux. I’m not speaking of a PHP class file: save an HTML page with a *.php file extension, try to open it with Firefox or KompoZer and you’ll get a pop-up asking you to choose an external editor to open it. This behaviour is caused by the MIME-type handling on GNU/Linux.

A pretty nice workaround has been brought by Vivien Nicolas — Fennec contributor known as “vingtetun” on irc.mozilla.org. His patch consists in a “phpStreamConverter” component, which is fired when KompoZer has to open a PHP file: the input application/php stream is converted into a text/html one, and sent to KompoZer.

One of the nice things in this component is that we can use it to check wether the PHP file is editable in wysiwyg mode before opening it as text/html in KompoZer, without creating any temp file: if the PHP file doesn't have any Doctype or <html|head|body> node, it will be opened as text in KompoZer.

Another good news is that this component might be a good alternative to the patch we use on the Gecko core to handle PHP blocks in KompoZer. If we can get rid of that patch, KompoZer could be built as a pure XUL Runner app.

The main limitation at the moment is that I’m not sure this “phpStreamConverter” component can be used on Windows or Mac OS X. Gotta spend some time on this.

New SVG icon

As you can see, we’ve refreshed the icon a bit. Many thanks to Joaclint for his work and Zéfling for the feather he’s drawn! I’m glad we finally have a nice SVG icon for KompoZer.

Unfortunately, like many features in this first beta version, we have to work on this a bit more. The icon itself is fine as far as I’m concerned and it looks great on my Mac; but the XPM and ICO conversions gave such an ugly result that I couldn’t decently include it in this release. As a result, the application icon isn’t updated yet on Windows and Linux.

If you know a good way to convert an SVG file to XPM and ICO properly (i.e. without too much aliasing), please ping me. And if you know why we still need to use XPM for the application icons on Linux (resulting to ugly, aliased icons in the Alt-Tab), please explain me. :-/

For future releases, we’d like to replace the globe by the unbranded Mozilla one. We haven’t done it already because we don’t have a suitable SVG version of this globe yet, and we’d have to tweak the colors of the feather a bit to make it look nice in 16px.

New UUID

So far, KompoZer used the same UUID as Nvu: {136c295a-4a5a-41cf-bf24-5cee526720d5}
There were two reasons to that:

  • KompoZer 0.7 has been developed as “Nvu’s unofficial bug-fix release”. I’ve hoped that Linspire would take KompoZer 0.7.10 and rebrand it as Nvu 1.1…
  • I wanted to keep the compatibility with existing Nvu add-ons. There weren’t many Nvu add-ons, I didn’t want to cause more work to extension developers.

KompoZer 0.8 is a very different app, and doesn’t share much code with Nvu. We realised that the UUID compatibility has become a problem.

So here’s the new UUID: {20aa4150-b5f4-11de-8a39-0800200c9a66}
Extension developers and theme designers: please double-check you’re using the right UUID.

What’s next?

Don’t expect any new feature before the final 0.8 release: we’re now in the beta stage and I’ll focus on bug fixing from now on. Please report bugs in the SourceForge tracker: Frédéric Chateaux (QA lead) will have a close look at all your bug reports.

I rely on Cédric Corazza (l10n lead) and all l10n contributors to update the langpacks. Cédric will try to upload localized builds for all langpacks that are fully translated; for all locales that are partially translated, we’ll provide only langpacks.

There should be another beta version in November, and we’ll do our best to release the final 0.8 before the end of the year.