Neil's Place

July 13, 2006

3:38 PM XML Templates

Just added support for spinbuttons, a widget for the arrows to adjust a numeric value. This will used for widgets for selecting numbers and times, which will also be coming soon. Also, the XUL sort service has been reworked to be better. See the bottom of the template features in 1.9 page for more details.

I've also added a page on how I plan to make XML sources be useable with XUL templates. I've already implemented most of this but still need to do some debugging. Comments on the syntax are most welcome.

Comments ( 3 )

June 7, 2006

5:43 PM XUL Features I've been working on

Hi, I'm Neil Deakin. You may already know me as the author of much of the content on XULPlanet. Or, you might know me from some of the other Mozilla related work I've done. Or, you may have never heard of me. Since February, I've been working for the Mozilla Corporation as the guy responsible for improving XUL. Some of the things I've done so far include:

I have been working on a wide variety of other things. Unfortunately, I sometimes tend to implement 90% of some feature and then get distracted by something or someone else, leaving the other feature not quite done. But, over the last few weeks I've managed to set myself down with the goal of not starting anything new until I've completed everything else. Some of these features I've been working on:

  • Improving the sort service - the XUL sort service is used for sorting menus and trees and the like. It currently does what the RDF tree builder does, but with the added bonus of requiring 5 times as much code. So, I've restructured that code in bug 335122. It will also support non-RDF templates, as well as XUL content that isn't built from a template, sorting instead based on attributes.
  • Tree improvements - Jan Varga recently added support for cell selection in trees, allowing individual cells in a tree to be selected. In addition, soon, support will be added for inline editing of cells
  • New widgets - I mentioned above that the <scale> widget is already available in Mozilla 1.9. Other widgets include the <spinbuttons>, which is two arrows for increasing and decreasing a number, styled using the native theme, a numeric entry box, and a timepicker and datepicker. I haven't done anything with the datepicker yet but I will likely just use the one from calendar. The timepicker, however, works nicely and looks and behaves much like the native platform one.
  • XML Templates - I've mostly finished support for building XUL content from templates and XML datasources.

But the main feature which has occupied the last couple of weeks of my time is reworking the XUL popup code.

Right now, in XUL, popups are opened and closed in a fairly complicated way that only crashes if you do it right. Also, popups opened from menus, those not opened from menus and those opened via the showPopup API are handled using three different pieces of code, creating inconsistencies. I've written a short note about how popups behave.

I've reworked how popups are created and opened to avoid the most obvious way of crashing, as well as many others, and have consolidated all the popup opening code into one place. I've also removed the XPCOM usage and made the popup API more logical. I'll post more details soon.

Comments ( 6 )

April 17, 2006

12:22 AM XUL IDs

Right now in XUL, an XML ID isn't actually implemented. It just happens that getElementById returns something reasonable, and is generally what people expect. But XUL doesn't implement anything that conforms to the XML specification in terms of IDs. There are two specific differences:

  1. There are two attributes that can be used as the id. Most people use 'id', but the 'ref' attribute is actually equivalent, at least in all the code where people realized when they were writing it that both attributes were equivalent. That means that in the following code, pressing the button will display, surprise, not the button's label OK, but the checkbox's label 'Check Me':
    <checkbox ref="sample" label="Check Me"/>
    <button id="sample" label="OK" oncommand="alert(document.getElementById('sample').label);"/>
    
    This is despite the fact that the checkbox doesn't even have an id attribute.
  2. XUL actually allows more than one element to have a particular id. That is, ids don't have to be unique. You wouldn't know this in any way, unless you looked at the underlying XUL implementation. It stores a hashtable mapping every id (and ref) to a list of nodes which have that id. The getElementById function returns whatever happens to be first in the list.

The reasons for this date way back to when XUL was actually just a nicer way of displaying RDF. Since a single RDF resource could be displayed in numerous places, it was necessary to map all of them in a table, identified by resource URI. Later, someone decided to implement a DOM for XUL, so the getElementById function used these ids. Little of this history remains today, as XUL has slowly moved away from its RDF roots to a separate language. The need for duplicate ids still remains when using templates however, as a single template or several templates in the same document may generate the same result in multiple places. You can see this, for example, in Thunderbird's account settings window, where preference panels with the same name in the tree all have the same id.

I'm thinking of removing this need, and making XUL have a real ID type. This would mean changing templates to set the ref attribute on generated results rather than the id as it is now. This would make the id attribute an XML ID, and the ref atribute would be used to identify the resource associated with a template-generated element. A function would be added to the template builder to retrieve a specific node by its ref attribute. This is a fairly backwards-incompatible change, but won't affect most usages, unless someone happens to use the generated ids in some way.

Thoughts?

Comments ( 157 )

March 6, 2006

12:31 AM AOL and XML UIs

One of the architects behind Boxely, the XML GUI toolkit used by AOL, describes a long list of requirements that such a toolkit should have. The list is here.

Of course, we're also waiting to find out why an AOL senior VP thinks that IE is a better choice for AOL users than Firefox.

Comments ( 189 )

February 24, 2006

2:59 PM Mac Scales

The Mac native theme code is a lot easier to deal with than any other platform. While it took several days to implement a scale/slider on each of other platforms, it took only an hour to implement on Mac.

Comments ( 179 )

February 23, 2006

3:47 PM New XUL Templates Work

Last week, the huge patch to improve XUL templates was checked in. After a few regressions were fixed, it should now be usable. Of course, you'll need a nightly build to try it out. But, some new features are available, such as support for better conditional checks and simple control over recursion. For more information about these feautures, see Template Features in 1.9

Soon, support for building templates using XML, Storage or other data will be available. I have some code for these about half written, although it needs updating a bit for more recent changes to the template builder. If you'd like to actually help implement these properly, you may wish to comment on the corresponding dependency of bug

Comments ( 138 )

November 30, 2005

8:52 PM XPCOM Reference 1.8

Just in time for Firefox 1.5, the XPCOM Reference and Object Reference have been updated. It includes all of the new interfaces and components available in Mozilla 1.8. Likewise, those interfaces that are no longer available have been removed.

The index page has been altered so that more categories are available, hopefully so that finding particular interfaces is easier, or perhaps harder. Note that the search isn't up to date yet so that method of finding things may not work well. In addition, most but not all interfaces are marked as to whether they are expected to be used as a service.

Comments ( 128 )

October 31, 2005

9:57 PM Bugzilla's nonsensical patch review UI

Let's say you've created your very first Mozilla patch for some bug, for instance making Control+left and Control+right work properly (By the way, if this bug isn't fixed soon, Firefox is doomed to fail). You're fairly new to Mozilla development so you aren't very familiar with the whole process. You do know however that you need to create a patch and attach it to the necessary bug in Bugzilla. So you click on the handy link that says "Create a New Attachment". You fill in the bits about the file path, the description and check the "patch" checkbox indicating that you are submitting a patch. Then you get to a bit with a bunch of flags. It looks something like this:

You've read somewhere in a place you can no longer find that Mozilla code needs to be reviewed by someone before being applied, so you assume by the labels that the flags have something to do with reviewing the bug or patch. There are a bunch of flags, each with a dropdown menu, and two of those have a grey box beside them. You look in the menu of the "review" line and see that your choices are "+", "-" and "?". Confused, you wonder why there are just symbols and no descriptive text. You reload the page just to make sure the page loaded properly, and then, being a curious sort, you look at the source code to see that indeed, yes, those labels are what is intended to be there. Hmmm. Do the labels mean "Addition", "Subtraction" and "Whaaa..?". There's no description of what the flags mean, nor any link to any help.

But you aren't going to give up just yet. You try choosing the items from the list. The only thing of note is that the neighbouring grey box turns white when "?" is selected. Perhaps that's what you should choose, but it's the last item on the menu, so that seems unlikely. You'd imagine that the item you are supposed to choose is first on the list, or better, chosen by default. You choose "?" and notice that you can now type something into the now white box. But what should you enter? There is the label "Requestee" above the box. Since "Requestee" isn't a real word, it doesn't tell you much, although it implies from the form of this "word" that it is referring to some person. Maybe you are supposed to enter your name there. That would be strange though, since Bugzilla should know your name since you already logged in. Perhaps, you are supposed to enter someone else's name in there, such as the person who should look at your patch. Sadly, you're new here, and the only Mozilla person you are familar with is Asa, and you don't think he does anything with code. You aren't sure how to find out who the real Mozilla developers are that might be able to help you or how to contact them.

You look at the other flags but they are all similar in nature. No descriptive text and the same choices in the dropdown. Resigned, you just press Submit and hope somebody knows what to do. Two months later, you get a flurry of messages pertaining to the bug created by someone named Boris Zbarsky; although you don't understand the messages, after a while the bug somehow gets fixed. You wonder what it all meant, but you try downloading a new Firefox build and note with joy that the bug is indeed fixed, and Firefox isn't doomed after all.


In case you're wondering, to request a code review for a patch, you're supposed to choose "?" from the list beside "review", and then enter the email address of the person who you want to do the review in the "Requestee" field. It's usually fairly difficult to determine who you should enter unless you have been working with Mozilla code for a while, usually over a year or so, and it's usually about 2% easier when you have. You can also set the superreview flag in a similar way, and set various approval flags. The difference between a review and a superreview can be difficult to understand -- I certainly don't really know exactly -- but generally a superreview is just a regular review but done by someone wearing a cape. Approvals can only be done by people with cars.

Then there's a bug that I filed that has an entirely different set of flags, in this case 'first-review' instead of 'review' and 'second-review' instead of 'superreview'. I don't know why this is different, nor what it means. The first person to correctly answer this will receive a free box of gummy worms.

The + and - values for a review flag mean code reviewed and accepted versus rejected respectively. Now, it really doesn't make sense to be able to mark a patch as reviewed by the person submitting the patch, yet the UI still provides this option. The other thing the UI lets the submitter do is decide whether a patch should be reviewed or not, which would only be of value to an experienced developer -- these people sometimes submit works in progress as patches.

The additional more complex concern is what to enter in the "Requestee" field. There's no indication of who might be allowed to do such a review. There's actually a finite number of people from a list that can do a superreview, so the list might just be presented there for someone to choose from. For review, it could just select from a set of reviewers associated with the component the bug is filed in. Naturally, that won't work if the bug is misfiled, but the bug should actually be recategorized anyway. For instance, a bug in View Source would allow selection from one of the reviewers associated with the View Source component.

To go further, there's no real reason to be selecting a specific person to do a review. Instead, a suitable reviewer should be selected automatically either based on the component, or for the brave, by analyzing the patch to see which files are modified. For most components, this would generally work since there's only one reviewer doing reviews of that code anyway. For other things like layout bugs, the patches could just go into a queue for triage by someone who knows better who should be reviewing it. Of course, I'm not suggesting that the ability to select a specific reviewer be removed, for those people that know what they're doing, they should be able to select a specific person.

When selecting a reviewer, Bugzilla should provide an indication of how active a reviewer is and how many patches are in that person's queue. For instance, if a reviewer has fifty patches and hasn't reviewed any for two months, it probably isn't a good idea to choose that person. In fact, any automated reviewer selection should take this into account and select the reviewer who is most likely to actually do a review.

Thus, the UI for review should just have three options: Request code review from the default reviewer, Request code review from a specific person, and Don't request code review. The superreview could be similar, or for simplicity, only available to be specified if the code review option was set to 'specific person'. The approval flags should either be removed, if it's the case that unreviewed patches can't be approved anyway, or if approving unreviewed patches is allowed, the labels changed to clarify what you're actually requesting. For instance, instead of 'approval1.8rc2', there should be a checkbox that reads "Request approval for Mozilla 1.8 Release Candidate 2" with a link that describes what requesting approval actually means.

If you think these are good ideas, let's discuss and file enhancement bugs to improve Bugzilla's review request UI.

Comments ( 155 )