My test environment is simple
- Create an XPI file with all files unzipped (no jar file inside)
- Install the XPI on a separated (and clean) profile, this is applicable to any Gecko application: Firefox, Thunderbird, Komodo, SeaMonkey 2.x
- Run unit tests or use the extension
- If some test fails I edit code (xul, js, css) directly on installed files
- Move edited files on main code build tree
- Repeat the process starting from 1.
Any developer uses its own approach, someone prefers to edit the chrome.manifest to point to files on specific directories, someone uses other enterprise-big-team oriented ways.
No matters the approach you use under Gecko 2.0 (ie Firefox 4.0) the XPI file will not unpacked by default, this can complicate your development process but the solution is easy.
Add to your install.rdf the following line and everything comes back (more details here)
My dev environment has two XPI creation tasks, debug and dist so it’s easy to insert <em:unpack/> only when necessary (debug mode in my case)
Please visit often Firefox 4 for developers (better to follow the feed) because FF4 is a little/big awesome revolution and extensions can be affected in many ways.
I spent the Christmas holidays working on VisualDiffer, the Komodo visual folders/files comparison extension.
Now I want to migrate VisualDiffer from extension to standalone application using XULRunner because the folders comparison feature is mature and using it from an extension can be a bit complicated.
The migration requires some intermediate steps
- Remove dependencies from Komodo code (especially the unified diff algorithm)
- Remove dependencies from unified diff algorithm!!
- Complete the file comparison feature allowing in-place editing using Bespin.
Bespin can greatly simplify syntax highlight for different languages, search in file and so on
Honestly I’m considering also to stay with Scintilla (actually used by Komodo) but I love Bespin
- Use a cool graphic layout, especially toolbar icons
I’m not a GIMP guru so if somebody would to help me he/she would be welcomed 🙂
- Allow user defined fonts and colors (low priority task)
I hope to release the VisualDiffer V1.2 for Komodo in a couple of weeks but also not Komodo aficionados can take a look to it installing the beta version on Firefox 3.5.x (also 3.6b5) and SeaMonkey 2.x.
Under Firefox and SeaMonkey the “files differ” feature isn’t implemented (Komodo dependencies) but you can test the folders differ feature that is totally based on standard Gecko interfaces, you can find the VisualDiffer item under the Tools menu.
Obviously VisualDiffer on Firefox is a nonsense because it isn’t a browser oriented extension I distribute this version with Firefox support with the hope a larger community can try it and give me feedback before I jump on the XULRunner world.
The V1.2 beta 1 can be downloaded from here.
VisualDiffer is inspired by the fantastic Beyond Compare but this isn’t a mystery 😉
I’ve written a little XPCOM component that worked immediately thanks to the good tutorial written by Mark Finkle.
The extension stopped to work when I’ve installed it on computer different from my development environment, the error in console was
Failed to load XPCOM component: c:\Documents and Settings\…
The solution was to statically link the C/C++ runtime and add msvcrt to nodefaultlib switch.
VC++ Express 2008 (or above??) users must set from Configuration Properties
- C/C++ -> Code Generation -> Runtime Library = Multi-threaded (/MT)
- Linker -> Input -> Ignore Specific Library = MSVCRT.LIB
Comments Off on XPCOM components, extensions and Visual C++ Express
I wrote a little XBL component to allow menuitems to have images centered, I added it to Firefox 2 browser context menu and worked fine immediately, after a while I installed component on Firefox 3 beta 4 and surprisingly the menuitem didn’t show the image 😦
I’ve asked help on Mozilla IRC and after about an hour the mistery was revealed.
The innocent CSS declaration shown below works fine on Firefox 2
but requires a little modification on Firefox 3 beta 5pre (at this time the latest available)
You must notice the selector without !important attribute works on Firefox 3 when applied on menus different from browser context menu.
I suspect the browser context menu should have some special treatment on new Firefox…
Sometime obtaining informations about components isn’t so quick, you must iterate over RDF, XML or call many API.
Sometime is very simple like get a pref string… well this time I’m lucky 😉
The pref general.skins.selectedSkin contains the current active theme name.
var currentThemeName = Components.classes['@mozilla.org/preferences-service;1']
Comments Off on How to detect the current active theme name on Firefox
When I started Richscrollbar (RSB for friends) development I could not figure out a so difficult programming life cycle.
After all its task is simple, add extra buttons to browser scrollbars to speedup movements inside web page.
Gecko is affect by a bug that reduces RSB productivity dramatically but I’ve created it anyway.
Now I discover RSB totally doesn’t work with Firefox 3 beta 2, Mozilla guys changed API and I suspect introduced some regression.
Obviously it is impossibile to explain the problem to Mozilla, they are so busy to fight against the world.
After some frustrating debug I found the problems and fixed them.
Problem nr 1.
The nsIStyleSheetService.USER_AGENT has changed behaviour without documenting it (at least at this date)
I used USER_SHEET in Firefox 2 but under FF3 the same code simply doesn’t work.
I’ve replaced it with the other flag AGENT_SHEET and magically RSB started to work.
Where can I read the new behaviour? Damned Mozilla 😛
Problem nr 2.
An horizontal useless scrollbar is always visible only on tab window open at browser startup, if user opens new tab and/or windows this dumb doesn’t appear, sigh!
I found a reasonable workaround hiding the scrollbar inside the notificationbox component.
I hope to publish the fixed RSB on this weekend.
Finally Komodo is open!
More informations at http://www.openkomodo.com/
Komodo isn’t a promise it is reality.
Open source === Open minds
Why I love it?
I use shanec words
#It allows you to work the way you want to
Sure, you don’t need to fit to your editor but your editor fits to you.
#It’s built for developers by developers
I’ve used ActivePerl for years a step ahead over perl language, a tool designed by programmers with my same needs
Now OpenKomodo is the new frontier, the missing piece: THE EDITOR.
D2D is the right definition: Developer2Developer
Ok OpenKomodo isn’t perfect for my needs but I can reuse my skills to enhance my programming experience
Use well know technologies to plug new behaviours, I love XUL and you?
The big problems with OpenKomodo are startup-speed and memory usage but these problems are related to Jecko runtime not to ActiveState’s guys implementation.
Do you think I’m a ActiveState employee? No! I’m a programmer that finally founds his programming home.
When I turn on my computer the first program I run (at least the second 😉 ) is my preferred text editor.
I can open it for development or simply to handle notes, list or any other textual information.
Under Microsoft Windows I can’t live without UltraEdit, sometime I believe UltraEdit’s author entered in my mind to choose what feature add to it because UE has all feature I dream.
UEdit has only a problem… It’s commercial 😦 and I’m an open source man…
When I boot up on my Ubuntu box UE equivalent doesn’t exist; gedit, kate are good but not complete like UE.
I love VIM but I’m unable to use it for intensive editing sessions… Emacs the same.
Finally I found my cross-platform full features and free (but not open source) editor and to complete my satisfation it’s built on Mozilla Gecko so I can enhance it with my XUL extensions 🙂 🙂
KomodoEdit is its name 😉
Guys at ActiveState made a really great work and the project OpenKomodo is very attractive.
KomodoEdit hasn’t all UE features but adding them it’s easy with XUL, you can create extensions in the same manner you do for Firefox, Thunderbird, SeaMonkey and any other Mozilla Gecko based application.
To fit my needs I’ve developed MoreKomodo, an extension that adds some UE features to KomodoEdit.
I decided to make MoreKomodo public because KomodoEdit is free, I don’t like to support proprietary, commercial and/or closed softwares.
MoreKomodo can be see in action on its screenshoots page locate ad dafizilla.
Comments Off on KomodoEdit, the editor I was waiting for…