Neil's Place

November 29, 2003

12:22 AM Canvas Tag Update

I tend to get carried away when I work on something I think is really useful and interesting. Such is the case with the XUL canvas tag I'm working on. Joe Hewitt's original version creates a simple image buffer which can be drawn into using a few drawing functions. My updated version can do that, but also quite a bit more. It supports lots of drawing functions to draw lines, text and images, as well as pixel drawing.

The canvas also supports custom layouts, which can be used to position and size the children of the canvas in interesting ways. XUL doesn't really need this capability -- it's various layout types are quite suitable. However, there was another task I was working on where I realized it would be very useful to be able to use a simpler set of layout tags, where the complexity was hidden behind a custom layout. With the canvas, this custom layout is done in XBL. Actually, I designed the canvas such that one could create custom elements where the actual painting and layout was hidden in XBL.

In fact, I managed to implement a few XAML elements such as GridLayout using the canvas, and was successfully able to display some of the XAML examples from the MSDN documentation completely unmodified. OK, I only implemented the very basics of the examples, but there's potential for some interesting things. Note that I'm not trying to create a XUL-XAML layer -- that would be almost impossible.

Since I don't have CVS write access to the Mozilla, I'm not sure if there's an easy way of creating a patch. So I may have to zip everything up and then hope that I haven't missed something.

Comments ( 13 )

November 28, 2003

1:36 PM nsIObservers Info

I added a small bit of documentation on nsIObservers , which can be used to listen to and notify about global topics in Mozilla.

Comments ( 7 )

November 26, 2003

6:59 PM Browser as Component

Many internal company applications require some component, or extra installation to be done before the application can be used by employees. There are many Web sites that use content that need a plugin. For example, there's lots of Flash, Quicktime, Real video files, Adobe PDF's around. To view them, you either need to install a plugin or perhaps it was included with the browser. Often, a certain version is required (Flash 6, for instance). For internal corporate tools. there's all kinds of speciaalized components that are used. Many applications are written in Java, or Python or whatnot, and require a runtime of some sort to be installed.

Nobody seems to have a problem with requiring that users have such plugins installed. Web sites will just point you to where they can be downloaded. When it comes to browsers, however, people seem to have a notion that browser usage is a either-or thing. You can use either one browser or another, but you can't use both.

But who says you can't use lots of different browsers? Do I even need to have a default browser set? If an application that I need to use wants an Opera HTML/CSS engine, I'll download one and use it. Why does it matter that I don't use Opera to browse the web? There are all these web-based applications that seem to demand that you be using IE as well as some specialized ActiveX controls. But is it really a web application, if it has such requirements? What's the difference between that and requiring that someone be using Mozilla Firebird?

In the last poll, someone seemed to think that XUL couldn't be used by people who normally use IE. This isn't logical. There's no reason an application couldn't insist on the appropriate browser or browser component to be installed, as with plugins. Many XUL features will work, for instance, in the Mozilla ActiveX Control. There are many applications that require downloads first. Why should browsers be any different? On one hand, I could insist that someone have IE 6 on Windows, with an extra component installed to do more specialized UI, or I could just require they have Mozilla and write the application in XUL.

Is it a download size thing? Surely not. Both Opera and Mozilla Firebird are about the same size or a smaller download than Real Player, Quick Time, Acrobat, and many other plugins.

This is why I think a proper GRE is a good idea. If Gecko could be treated as a simple component that can be used with other architectures, it will better be able to distance itself from being a browser that people think you can only have one of.

Comments ( 5 )

November 24, 2003

A project to make some Mozilla RDF creation and query tools. I wonder if ReoPath could fit into it in some way.

November 22, 2003

1:12 PM What I'm going to do

I think I'm going to take the Netscape Communicator source code and make it Open source. That way anybody can use it, change it and distribute it openly. Then I'm going to create a UI markup language and call it XUL. Then, I'm going to promote everything so that other companies like IBM, Sun and Redhat want to help out. As well as lots of independent news sites, documentation sites and projects. All of them will come together to form a number of Alliances.

Then, more open, XUL-based projects, perhaps hosted on a site that provides free hosting for such things, will be created, and each will form their own alliances. I think I'll call these Open XUL Alliances.

Then, we'll need a way to bring the alliances together, since using a generic term to refer to all things that are open, about XUL, and has groups of people, would be a good idea. To to this, I'll hire someone who works at Opera to create a site

That would be a lot of work though. Maybe I'll just go cause trouble in some newsgroups instead.

Comments ( 17 )

November 21, 2003

An Introductory Tour of Mozilla's XUL
By Nigel McFarlane

5:12 PM Experience Required

When I was younger, I used to think applications used too much disk space. I used to think that they were filled with all sorts of useless features. I might have got upset when I saw a bug that had been sitting in a bug database for two years was still broken. I used to hate Microsoft when they borrowed a feature from a competing product. I might have spent time advocating open standards and criticizing a company that came up with a proprietary solution. I used to think like a naive, young, end-user.

Then I got a job doing software development. I found out how software development is really done. After a while, I understood why I was so wrong about the above.

I can't really explain it though. To all those that still think those things I listed above: Once you get a job working in software development and have been working there for a few years, think again. You may understand what I mean.

Comments ( 25 )

November 19, 2003

A Macromedia developer discusses Flex, XUL, SVG and others.
"... I'd certainly be interested in figuring out how we could give back to the XUL community..."

Connecting XUL Applications with PHP
Sample code showing how to post some XUL fields.

1:37 AM I understand some Mozilla source code!

Spending time working on the canvas tag has given me a much greater insight as the how XUL layout actually works. I think I know enough that I can fix layout-related bugs in XUL. Actually, I did fix one, bug 214956. I'm also now familiar with parts of gfx (the graphics code), and from earlier tasks, the RDF code. One day I should sit down and update the RDF parser so that it is not only less buggy but to support some of the newer features in the latest working draft.

With regards to the canvas stuff, it is coming along very nicely. It supports all kinds of things. I'll provide a list of what it supports once I've polished it a bit more.

Comments ( 9 )

November 17, 2003

12:21 PM Macromedia doing XML UI's too

Macromedia gives a preview of their upcoming development tool Flex. It's a server-side application that runs alongside J2EE servers which generates Flash dynamically from XML descriptions. Unlike XAML, it's actually much more similar to XUL. It even has HBox and VBox tags. No mention of whether it supports the flex attribute as suggested by the name.

It uses ActionScript like Flash does, which is similar to JavaScript, although the examples given suggest that getElementById isn't used, so I don't know what DOM features are available. You might be pleased to hear though that it uses CSS for presentation. Databinding is done by web services and similar tags.

It's entirely server side and generates Flash to be sent to the client. Since it's Java-based, it does have support for interacting with server Java objects and such.

There's little documentation at the moment. I could only find a white paper and an introduction, so I'm not sure how sophisticated Flex really is.

Comments ( 32 )

November 15, 2003

Questions Parable
I was going to write about this, but Eric has done a better job

November 14, 2003

1:55 PM UI Toolkit Customizability

The best toolkits make it more difficult for the developer to do the wrong thing and easier for the developer to do the right thing.

Nowadays, it seems that more and more user interfaces are being built by people with very little knowledge of how user interfaces should be built. There was a time when user interface designers and usability people would carefully construct a user interface for ease of use and efficiency of use. Some products are still built this way. However, today a significantly larger number of companies and individuals are building applications, many used internally by a company for their purposes, for issue tracking, time tracking, project management, and so forth. Almost none of these are built by UI designers. Instead, they're built by people with no real knowledge of UI design at all. Many applications designed for end users are even created by graphics designers. Why is this? Perhaps UI designers are more expensive, or perhaps it's because, since no-one else knows UI design well, they don't think to hire a UI designer.

And so you end up with applications that everybody except the creators think are horrible but nobody wants to say anything.

Let's take a look at three UI toolkits: the upcoming Longhorn/Avalon toolkit (the one with XAML), the Apple Aqua toolkit, and Mozilla's XUL.

I've been scanning through a lot of the new MSDN info about Avalon, and many of the examples really seem to encourage developers to create radically new styles of UI widgets. Many of the examples demonstrate changing background colours, fonts, or adding gradients or vector graphics to UI elements. Take a look at the current documentation for the Button class. The very first example given demontrates changing the background color. The third example shows how to add some coloured rectangles inside the button. It seems that Microsoft really wants to encourage user interfaces to be built by graphic artists, rather than by UI designers. This is even true today, for example, how IE has a feature which lets a page author change scrollbar colours.

Let's compare that to the Aqua toolkit. I'm not intimately familiar with it, but my quick glance around the documentation suggests that not only do they not encourage button colour changing (in the Human Interface Guidelines), Apple provides no examples of it, and I don't think it's even possible to change the button colour.

Is this a good thing? Yes! In fact, I've thought quite a bit about it, and I can't think of any reason why a user interface needs to have buttons in a different colour to everything else. Anybody who thinks there is, isn't a user interface designer.

Themes are generally acceptable though, since they change the overall appearance, and they are entirely at the control of the user, not the developer. And consistency is a good thing.

Mozilla's XUL is part way in-between Avalon and Aqua. It does allow changing colours and fonts and so forth, but it's design tends to encourage one to put appearance info into a stylesheet. Due to the nature of its 'chrome system' and because Mozilla has support for themes, this provides an incentive not to change the appearance of UI elements, since one can never tell what will break if the user selects a different theme. In fact, some style changes don't work unless you look more into how the elements are constructed and add more specific style properties. Thus, XUL developers don't change the appearance.

If you look at the XUL Tutorial, you might note that I barely make a mention of style properties until much later, and even then, it's mostly under the guise of themes.

This is one of the largest disadvantages of Avalon. It seems that in five years, we'll be seeing a lot of Windows applications with purple diamond shaped buttons, translucent scrollbars, and funky animations. The talking paper clip was only the beginning. Using Longhorn will be like you're trapped in a giant Flash animation that you can't escape from.

Comments ( 11 )