Neil's Place

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 ( 6 )

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 ( 1 )

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 ( 2 )

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 ( 1 )

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 ( 20 )

October 7, 2005

9:55 AM Scales

So I finally got around to finishing up the slider widget, which I called <scale> to make the implementation simpler. Here is an image of what it looks like under various platforms and themes.

No mac support yet, since I don't have access to one. But the other platforms are styled using the native theme. If you'd like to try them out, you need the patches in the bug.

Comments ( 4 )

October 2, 2005

Why I Hate Frameworks
Or, how to build hammers

September 13, 2005

10:22 PM How Templates Work XLIV - Conclusion

We have come to end of the guide on how XUL templates work. I hope people reading it have learned a bit more about templates and how to use them. Expect to find the whole series on the Mozilla developer documentation site soon, or even sooner if (hint, hint), someone offers to help format it.

The template guide was originally supposed to be a short series, perhaps eight to ten parts, but quickly grew into a 44 part monster that took three and a half months to complete. One main reason for doing the template guide through my weblog rather than post it to a tutorial section was because I wanted to try a new method of writing documentation where I would write in short pieces rather than large blocks at a time. Clearly, it was still a lot of work. If I write another guide like this, I'll make sure to keep it shorter.

Anyway, I hope you enjoyed the series 'How Templates Work'. Hopefully, the template changes I've been working on for the last half year will make it into a Mozilla build soon. This will make templates much more useful for the future, and, naturally, will require even more documentation.

Comments ( 8 )

September 12, 2005

5:29 PM How Templates Work XLIII - Additional Template Attributes

All the templates used so far have had the <template> placed inside the root element with the datasources attribute. However, you may use the template attribute to refer to a template located elsewhere within the document. This allows you to share the same template among two different parts of the user interface. Firefox uses this for bookmarks to display the bookmarks menu and the bookmarks toolbar, since the same template may be used to display the menu items in both cases. This is accomplished using a shared template and the clever use of multiple rules. To use this technique, place a template attribute on the root element set to the id of a template.

<listbox datasources="template-guide-photos5.rdf"
            ref="http://www.xulplanet.com/rdf/myphotos"
            template="photoTemplate"/>
...
<template id="photoTemplate">
  ...
</template>

This template will be shared with any other element that references the id "photoTemplate". The listbox here does not have any children, although it may do. If you did add children, they act just like the static content as if the template was present. However, it is possible to use different static content for each usage, even though the template is shared. The datasources and ref attributes also differ for each usage, so it is possible to use a shared template to display the same structure multiple times but with different starting nodes in each case. The generated content is always inserted into the root node, in this example the <listbox>, not inside the template.

Normally, the container and member variables are determined by the template builder automatically. The container or starting node variable is specified in the <content> tag inside a rule's conditions, while the member variable is determined by the value of the uri attribute inside the action body. It is also possible to be explicit about the two variables by using two attributes on the <template> element.

<template container="?first" member="?item">

The container and member attributes can be used to specify the container and member variables. This isn't particularly useful although there is a very slight optimization since the builder does not need to scan the action body looking for the member variable when compiling the rules. You might also use these attributes just to make the code clearer when using very complex rules.

One possible advantage is when using the simple syntax where you don't specify variables; instead you use the special 'rdf:*' syntax for the member variable and the container is implied. By using the container and member attributes, you can use specific variables instead.

<hbox datasources="template-guide-photos5.rdf"
      ref="http://www.xulplanet.com/rdf/myphotos">
  <template container="?start" member="?photo">
    <rule>
      <image uri="?photo" src="?photo"/>
    </rule>
  </template>
</hbox>

In this example, the ?photo variable can be used instead of 'rdf:*' (although you can use either even if you specify the member variable). This may make the code clearer as to its function. We could use the container variable ?start in the action body also. If you are using the simple syntax and want to use the container variable in the content, you must use the container attribute since there is no other way to refer to it. Note also that a <rule> element is needed here, otherwise the builder will think the container and member attributes are conditions to check.

Comments ( 0 )