Nvu, a web authoring system built on Gecko
Daniel Glazman
http://disruptive-innovations.com
What is Nvu?
Nvu is
- a standalone HTML editor
- a wysiwyg crossplatform editor
- built upon Mozilla Composer
- open-source
Why Nvu?
- Netscape/AOL was ready to drop Composer
- it started, and killed, the Anvil project
- because I believed in Composer
- that's a dirty job but something has got to do it
- I firmly believe we need an editing tool
Why do we need an editing tool?
- to prove Gecko can be used in non-browsing environments
- to prove Gecko can be used as the ground for professionnal apps
- because an editor is a perfect testcase for our too browser-oriented world of geeks!
- because there is a market for it
How did it start?
- feb-2003, Brian King's zibblings here at Fosdem
- apr-2003, I become Composer's maintainer right after AOL drops Anvil
- why?
- jul-2003, Netscape black tuesday
- aug-2003, Brian King and Pete Collins give my name to Lindows.com
- sep-2003, Lindows.com knocks on my door asking if I am available for hiring or a one year contract
- oct-2003, Disruptive Innovations
What's new in Nvu?
|
|
13-oct-2003/04-feb-2003; ten packs of Lindt chocolate; dozens of oranginas; hundreds of visits to xulplanet and black magic spells; a few beers
What's immediately next?
- frameset editor (chrome)
- template editor and management (chrome + core)
- direct link to CSS validator (chrome)
- extended inline styles, only text and border properties for the moment (chrome)
- class assignment (chrome + core)
- preservation of PHP
<? ... ?>(core) - cvs repository
- Mac OS X version
How is it built?
- it's a standalone chrome app just like Firefox and Thunderbird. It shares a lot of configuration with T'bird.
- uses the "new toolkit"
- MOZ_STANDALONE_COMPOSER=1
- just replace mozilla/composer with Nvu's tarball and rebuild
- I try to check in all core patches into Mozilla trunk to avoid a fork
- avoid only?
#include "nsXULAppAPI.h" #include "nsISoftwareUpdate.h" #ifdef XP_WIN #include#endif int main(int argc, char* argv[]) { nsXREAppData appData; appData.SetSplashEnabled(PR_FALSE); appData.SetProductName(NS_LITERAL_CSTRING("Nvu")); appData.SetUseStartupPrefs(PR_TRUE); return xre_main(argc, argv, appData); } #if defined(MOZ_WIDGET_GTK) || defined(MOZ_WIDGET_GTK2) char* splash_xpm[] = {0}; #endif #ifdef XP_WIN // We need WinMain in order to not be a console app. This function is // unused if we are a console application. int WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR args, int ) { // Do the real work. return main( __argc, __argv ); } #endif
pref("general.startup.browser", false);
pref("general.startup.mail", false);
pref("general.startup.news", false);
pref("general.startup.editor", true);
pref("general.startup.compose", false);
pref("general.startup.addressbook", false);
Tweaking the chrome
Everything is done by the jar packager!
comm.jar:
+ content/editor/editor.xul (content/editor.xul)
+ content/editor/editorOverlay.xul (content/editorOverlay.xul)
content/editor/about-composer.png (content/about-composer.png)
*+ content/editor/mainCore.js (content/mainCore.js)
+ = update
* = run through XUL preproc
So basically, we just launch Composer as always!!! We've just replaced some of its chrome files by new versions!
the XUL preprocessor
- allows conditional statements in all chrome files
#ifdef MOZ_STANDALONE_COMPOSER <checkbox label="&makeNvuSystemDefaultEditor.label;" oncommand="MakeDefault()"; /> #endif - does not allow
#if defined(FOO) || defined(BAR)conditions, and that has a strong impact on simplicity, readability and maintainance
the customizable toolbars
- I had to hack the code for various reasons (explain!)
The FTP site manager
- implied extending nsIFTPChannel.idl and nsFtpConnectionThread.cpp
- very easy to do
- but we need to rearchitecture the FTP channel if we want more FTP commands (already discussed with dougt and darin)
- it's just a sidebar
Tabs
A deep modification of Composer's chrome made easy by Composer's architecture
- replaced
<editor>by<tabeditor>in editor.xul - implemented tabeditor.xml; that 450 lines XBL does 99% of the work
- hacked editorUtilities.js to be able to select the active editor and not the first one
GetCurrentEditor(), bug 169029, checked in 15-nov-2002 - minor hacks to editor.js, openLocation.js and ComposerCommands.js
- new menus and buttons
You said heavy weight, heavy process?
- we can get rid of a lot of useless modules
- we can remove a lot of chrome dependencies to browser and mailer
- we can cleanup the chrome
- cooler checkin procedures into mozilla/composer
Directory structure
- mozilla/composer
app: application c++ main file, app icons, profilebase: main app's chrome, including locale, skin and imagescomponents: preferences panelextensions: sitemanager
So what's hard or problematic here???
- From a code's perspective? Almost nothing. Just takes time.
- new toolkit's documentation is lighter than light. Sorry to say, but Mozilla.org sucks on documentation... Again. If we want embedders, we NEED documentation. Example: the autocomplete textbox
- Firebird^H^H^H^Hfox and Thunderbird people ping me when they need a review with an editor's eye point of view but are almost unresponsive to my r/sr requests.
- it's extremely hard to make evolve the standalone app AND Seamonkey at the same time. Standalone Apps move faster because of Seamonkey's checkin rules and decrease of number of r/sr!!!
- Mozilla.org did not even announce Nvu's 1st release on its web site :-( Even with a short news on the side column... Right, it's not a Mozilla.org product, for the moment. So what? Does it help the spread of Mozilla or not?
What's next?
- make Nvu becomes a good basic crossplatform alternative for personal (X)HTML web authoring
- build a community of addon contributors (smart widgets)
- make a few more professionnal addons (JS behaviors, timelines)
- the longer-term goal is a RelaxNG-conformant XML editor based on Standalone Composer. It's not that hard to implement, we already have all the ground elements for that, it will only take time.
