New in this release:
What's new:
New in version 0.4.2:
That is all. Obligatory link: XUL Widgets extension project
So what's new this time around?
Branch tags are listed under src/data/branches.inc in the XUL Widgets repository.
The purpose of this branching is to allow trunk-based and Gecko 1.8.x-based XUL Widgets extensions to line up more with their respective bases. For example, if trunk has implemented a XUL Widgets extension, there's no need to keep that extension on XUL Widgets's trunk. Also, new features which could not be supported on Gecko 1.8.0.x branch may now be included for trunk-based and possibly Gecko 1.8.x-based XUL Widgets packages.
The best part about this is that XUL Widgets now supports Gecko 1.8.x and trunk builds. I didn't fully realize it before, but the packages for XUL Widgets were previously restricted to only the Gecko 1.8.0.x series.
If you installed the flat chrome edition of XUL Widgets, please uninstall version 0.3.x before installing version 0.4.x. If you update directly, the update service will return a jarred chrome edition instead.
Your test results and feedback are most welcome!
I've been thinking the last few months about a change for XUL Widgets, and now that Firefox 2.0 Beta 1 is available, I need some advice from the community.
XUL Widgets, for those of you who haven't followed it, is a MozDev project to extend the standard mozilla.org toolkit of XBL-based widgets. Other projects are invited to adopt XUL Widgets as an extension and use the extended toolkit in their own applications. I've been updating it from time to time with new features (or fixing bugs in the update code), but now I have to decide which version of mozilla.org's toolkit XUL Widgets should support.
Currently, there are three versions I'm concerned about: 1.8.0.x branch (Firefox 1.5), 1.8.x branch (Firefox 2.0), and trunk (Firefox 3.0). A few of the changes I've made for XUL Widgets have landed in the 1.8.x branch, and a few more in the trunk. So my own unreviewed changes may conflict or degrade the expected results in these versions. On top of that, there are new capabilities in trunk (and to a lesser extent, 1.8.x branch) that weren't available in 1.8.0.x.
To my knowledge, I'm the only one actiovely using the XUL Widgets extension. If I am truly the only one interested in using it, then there's no reason for me not to switch its base to trunk. My usage of XUL Widgets is for Verbosio, and that cannot run on the 1.8.0.x or 1.8.x branches.
I'd like your feedback, especially if you use XUL Widgets. Which version of the toolkit should I base my extensions on?
UPDATE: Case in point: Trunk code just now received an active spinbuttons widget, which my integercontrol could easily depend on.
To quote Jamie Hyneman, "Whoops!"
In posting the 0.2.* series of XUL Widgets XPI's, I listed incorrect information in the install.rdf and update.rdf files. This mandates posting a new XUL Widgets 0.3.0 XPI & XULRunner series.
No new functionality, but you will find XULRunner 0.2 will not receive any future updates. So please uninstall it before installing version 0.3. XUL Widgets version 0.3 should be available in 24 hours or less.
UPDATE: Another well-formedness error bit me, install.rdf. 0.3.1 released now.
UPDATE 2 : Note to self: chrome.manifest is useful. 0.3.2 released.
XUL Widgets installation instructions
By this, I mean XUL Widgets now packages its chrome to be easily dropped into an existing XULRunner application. It's a beginning step (possibly incorrect, but simple) for building a chrome package for a larger app. I'll be porting the code used to make this chrome package over to jslib and xpistubs shortly.
UPDATE: JSLib and xpistubs now have code checked in to support XULRunner as well! No new packages generated for jslib yet; I leave that up to the mozdev team.
If you have a xpistubs-based project, drop me a line. I may be able to help you apply the patch to your own project.
<xul:textbox/> visual examples
This is my initial attempt to give XUL controls a standard set of icons and styling to support new features in XUL Widgets. XUL Widgets will soon support several flavors of <xul:textbox/>:
This is a first draft, and subject to change based on feedback. I asked a11y on news.m.o for some, and got all my replies from /dev/null...
You might be wondering: why would I try to create icons to go with textboxes? The answer is simple: color-blindness is a real and not-so-obvious problem.
I'm also wondering how I can display these icons for people who need the accessibility support, and not display them for those who don't.
I'll maintain current drafts of these icons with the XUL Widgets installables fairly soon. (I still have some <xbl:implementation/> code to write.)
A few observations:
Comments welcome!
I've just released an updated version of XUL Widgets. New features:
Accessibility is a big concern I have, and I'm going to spend some time tonight making icons for a future version 0.2.*.
XUL Widgets Installation instructions
Note version 0.2.* is NOT backwards-compatible with version 0.1.*. If you've installed version 0.1.* of XUL Widgets, please uninstall it before installing XUL Widgets 0.2.*.
In the preceding article, I demonstrated adding a SVG graphic to a <xul:menuitem/>. This is one case where I saw a quick & easy way to bend the rules of XUL. Menu items typically don't have children, so giving it a <svg:svg/> child somewhat made sense.
XUL Widgets uses a similar trick for <xul:textbox/>. In this one, the textbox gets menuitems, menuseparators, and menus which should be added to the standard textbox's context menus, before the first item in the context menu. Admittedly, this is not as clear-cut as the SVG example, but it does have one benefit: it doesn't break existing textbox functionality. (I blogged about this previously.)
I made a mistake several years ago in filing bug 180512. That was my earlier attempt to add items to a textbox's context menu - by replacing the context menu. The problem is that change broke Undo, Redo, Cut, Copy, Paste, Delete in any non-default context menu. It should never have been done. (I since filed bug 312869 to fix this botch.)
These are to date the only reasons I've had to define new behaviors for children of XUL widgets. The two are different enough that the behaviors for these specific cases can be clearly defined and have a clear benefit.
If you have other ideas, I'll definitely consider them.
For a while I've been thinking about a desire to add SVG graphics to XUL Widgets. You might wonder why anyone would want to do that. My answer: SVG, like XUL, is XML markup. Verbosio will be able to edit XML. So it'll be able to edit SVG and XUL. Why not?
One drawback: the SVG is included inline in the document, not as an external file. This is somewhat unavoidable, and violates the niceties of multiple skins in a XUL package. (XUL skins can't have .xul files in them, and this has to be inline or inserted via overlay.) So I'm wondering if there's a better way to do this.
Lots of changes checked in today:
<xul:slicedstack/> element. It's a stack, with anything up to its selectedIndex visible, and everything after it hidden.I've not finished the manual yet. Sorry!
Following up on a previous blog entry about extending current toolkit widgets, I have just landed a good amount of new code to XUL Widgets.
Many thanks to prefiks (give me your real name & e-mail, so I can thank you properly!) for the idea of using regular expressions on textboxes. That's one of the improvements obvious enough that I had to include it.
Dialogs (with xulwidgets="true") now check for invalid="true" attributes, as does serverpost. However, in case an invalid XUL element is hiding in an invisible xul:deck panel, I created a xul:deck extension that vetoes any hidden invalid elements.
I've deprecated and removed menudeck, in favor of a more flexible widget called controldeck. This one lets you use any XUL element that implements selectedIndex as a selector for the deck. You have to make the selector a child element of a <xul:selector/> element, and that in turn becomes a child node of <xul:controldeck/>.
Several new testcases have been added, including a main index page for all testcases within the package. chrome://xulwidgets/content/tests/tests.html
Still to come: the testcases for DOM utilities, preconditions, and user error boxes. Also, the XUL Widgets manual (which I would have gotten done today if I didn't have so many failures of the testcases initially... but the testcases pass now). The latter I hope to have up tomorrow.
If you try to download the latest XUL Widgets version, and it comes back as 0.0.0, reject it! The latest version number is 0.1.1.
The current set of XUL widgets in the Mozilla toolkit is quite nice. For the most part they are stable, simple, and work well. That isn't to say I'm not interesting in making them more useful.
I've filed a number of enhancements to current widgets. Once in a while, I even get some fixed. More often, though, ideas I consider good just aren't adopted by mozilla.org code. This isn't to say the mozilla.org code base is bad. More accurately, the case is that I haven't made a strong enough effort to see these enhancements through, especially in seeking reviews and confirming that mozilla.org actually wants them in their code base.
With that said, one of XUL Widget's goals is to lower the barrier for creating new functionality for current widgets. Hopefully, these widgets will be useful enough for other developers to bring some of them back to the mozilla.org code base. Whether that will actually happen or not, I don't know. There's a pretty solid chance my place of employment, ManyOne Networks, Inc., will be using some of XUL Widgets' functionality, so it will be supported. (One idea I haven't yet explored is a tabbrowser with multiple rows of tabs. That ought to be fun to implement. It's a request from a fellow developer at ManyOne.)
Probably in the next couple of days, I'll start showcasing these widget improvements through XUL Widgets. They'll build on current functionality, through a special attribute, xulwidgets='true'. That way, the original widgets will still be available simply by omitting the attribute (or the XUL Widgets bindings stylesheet). I'll also move certain common constructs into DTD entities, so they may be reused. My goal is to enhance current features, not to replace them.
As a follow-up to my original post suggesting a XUL widgets project, I finally launched it. Right now, it collects most of the widgets I've written in a generic format. In the next twenty-four hours, I hope to have a XUL Widgets Manual written for project development and for users.
So if you have a XUL element you've created and think others might be able to use, come on in! I would also welcome compentent reviewers to point out obvious mistakes.