Neil's Place

July 13, 2004

10:40 AM Apple Canvas

In order to compare for the Mozilla canvas tag, I took a look at the Apple Dashboard canvas tag source code to see what it did. I found the canvas code fairly easily since the KHTML code is pretty understandable, compared to, say, Mozilla's code. Here's the API:

HTMLCanvasElement {
  Context getContext()
}
Context {
  save()
  restore()
  scale(float x, float y)
  rotate(float angle)
  translate(float x, float y)
  beginPath()
  closePath()
  setStrokeColor(string color)
  setStrokeColor(string color, int alpha)
  setStrokeColor(int graycolor)
  setStrokeColor(int graycolor, int alpha)
  setStrokeColor(int r, int g, int b, int a)
  setStrokeColor(int c, int m, int y, int k, int a)
  setFillColor(string color)
  setFillColor(string color, int alpha)
  setFillColor(int graycolor)
  setFillColor(int graycolor, int alpha)
  setFillColor(int r, int g, int b, int a)
  setFillColor(int c, int m, int y, int k, int a)
  setLineWidth(float linewidth)
  setLineCap(string type) - type is either "round" or "square"
  setLineJoin(string type) - type is either "round" or "bevel"
  setMiterLimit(float limit)
  fillPath()
  strokePath()
  moveToPoint(float x, float y)
  addLineToPoint(float x, float y)
  addQuadraticCurveToPoint(float cpx, float cpy, float x, float y)
  addBezierCurveToPoint(float cp1x, float cp1y, float cp2x, float cp2y, float x, float y)
  addArcToPoint(float x1, float y1, float x2, float y2)
  addArc(float x, float y, float r, float startAngle, float endAngle)
  addRect(float x, float y, float w, float h)
  clip()
  clearRect(float x, float y, float w, float h)
  fillRect(float x, float y, float w, float h)
  strokeRect(float x, float y, float w, float h)
  drawImage(image, int x, int y, int w, int h, string composite)
  drawImageFromRect(image, int sx, int sy, int sw, int sh,
                    int dx, int dy, int dw, int dh, string composite)
  setShadow(float width, float height, float blur, string color)
  clearShadow()
  setAlpha(float alpha)
  setCompositeOperation(string composite)
}

It's pretty logical. Could be adapted to other browsers for the most part. One advantage of building an API like this is that Apple can construct it suit their platform. For instance, the Mac has a function CGContextSetMiterLimit, so the canvas has a similar setMiterLimit function. Mozilla doesn't have such a function. Interesting that there are no text drawing in the above set of functions. The Mozilla graphics code has stuff to draw text and get the width of text in certain fonts, which is why these functions would appear in the Mozilla canvas tag. Everyone does code this way, which is why the IE specific features tend to look like things created by Microsoft since developers tend to make things in a similar fashion to the rest of the platform.

If a standardized canvas tag appears, perhaps through the WHAT-WG, I'd imagine it would incorporate the best or worst of everything.

Comments ( 33 )

July 11, 2004

11:14 PM Updated ReoPath Expression Language Release

Since someone brought it up, I thought I'd release a new build of ReoPath, which is a Mozilla component which adds an XPath-like expression language for RDF. ReoPath consists of two parts, an expression language, which you can use to evaluate and retrieve results from RDF, and a template language, which you can use to bind RDF data to XUL or XML nodes, as a databinding system. Here is an simplified example which displays a list of the titles of things.

<listbox id="theList" rp:repeaton="%*[dc:creator='Neil']">
  <listitem rp:assignattr="label" rp:assign="dc:title"/>
</listbox>

This version has a number of new features. It is much more efficient, much less crashy, and it auto updates when the RDF changes. And more interesting, it also supports templates using XML sources and XPath as the expression language. In addition, it's also possible to use custom expression languages.

It's also now available for both Linux and Windows. Mozilla 1.7 or Firefox 0.9 are needed.

Install: Linux | Windows

Once installed, and you've restarted your browser, you can go to the URLs below to try the samples. The first displays a list of actors and you can select one to see a bit of information about them. The second is a very simple RSS 2.0 viewer implemented in less than 1K.

chrome://reopath/content/reotest.xul
chrome://reopath/content/feedtest.xml

There's some documentation on the project page. If someone is interested, I can write some more.

Comments ( 25 )

July 3, 2004

12:39 PM Ideas with nowhere to go

People have asked recently if any of my ideas have had any kind of influence over Mozilla developers. Probably not, but it's hard to tell.

I've noticed that there tends to be three types of developers in the Mozilla community. At the top you have Mozilla Foundation employees and anyone that used to work at Netscape. In the middle are the people that don't fit that group but are key developers. Finally, you have all the extension and XUL developers. I find that communication between two adjacent tiers is fairly decent, but communication between the upper and lower tiers is poor. This is a big generalization, of course; some people don't fit that model.

The more interesting question is that the various people building XUL applications feel that they don't have any way of expressing their opinions either. They ask me if I have any contact into Mozilla rather than than just asking Mozilla folks directly. Mozilla doesn't have any clear way for these voices to be heard. The best idea Mozilla folks have come up with is Bugzilla voting and mailing lists apparently about screen savers. Are there other options? Probably. Does any one know what they are? Unlikely.

I have all kinds of grand visions for what I'd like to do. I've posted many of them or hints about them over the last year or so. Remote XUL, improved templates, a canvas tag, and so forth. In some cases, I started an implementation only to be blocked by some non-implementation related issue. I actually started implementing something so that chrome URLs could be mapped onto http URLs but I stopped after it seemed unlikely that it would ever make it into Mozilla. I started working on some features for XUL templates, but Axel said that "creating template enhancements [is probably not] the right thing to do at the moment", so I didn't continue. I did get to the point where I posted a patch about the canvas tag, but then other developers seemed to take over and the patch disappeared into the Pit of Forgotten Patches. When Alex Vincent created a serverpost tag, no one seemed to want to accept it so it never got any where.

Anyway, various factors have made it very discouraging to try to improve Mozilla in some way, even though I think I'm able to.

Comments ( 17 )

July 2, 2004

NextIs - A XUL front end for handling audio from a server database
As posted in the XULPlanet forums

June 25, 2004

12:08 PM Updated XUL Tutorial Intro

I just rewrote portions of the first few sections of the XUL Tutorial (sections 1.1 to 1.4). Hopefully, this will make the chrome system clearer. Some people were having problems understanding how the chrome URL relates to files. In addition, I've added a bit more detail about the difference between chrome and non-chrome content, as well as a bit about XUL documents in general.

Comments ( 9 )

June 22, 2004

10:27 PM Some UI for a Remote XUL whitelist

Some recent remote XUL discussion (here and here) inspired me to create some dialogs for a whitelisting UI for web sites.

When a site wants extra permission:

Clicking the OK button does not allow the application to do privileged operations. Instead, the user must click the Allow button and then click Add in the resulting whitelist dialog, as shown here:

The idea is that the user has to click a series of buttons before the site can do anything, yet isn't particularly tedious. In my opinion, the icons, which are just the site icons, make the dialog look nicer and, in some cases, allows sites to be distinguished better.

Comments ( 27 )

June 19, 2004

1:04 AM Server Push and Server Sockets

Someone was asking about server sockets, so I wrote some info about how to use them in Mozilla. In addition, this document describes how to use the 'multipart/x-mixed-replace' content type with XMLHttpRequest. In case you're wondering, both features may be used as a form of sending data from a server to a browser client.

Comments ( 38 )

June 16, 2004

Interview with Scott Collins
Talks about Mozilla/Netscape history and decisions made.

June 9, 2004

Why JavaScript isn't the worst invention ever
Good document about HTML, Javascript and web applications.

June 7, 2004

11:15 PM Web Applications Workshop Minutes

Minutes of the recent W3C Workshop on Web Applications and Compound Documents (Part 1 and Part 2). Interesting read.

Comments ( 9 )

June 6, 2004

3:13 PM What is the WHAT?

I think I've finally understood what the new WHAT group is trying to accomplish. At first, I thought it was intended to be a group for defining ways to create sophisticated applications but using HTML. In effect, what one might do with XUL, or what Macromedia wants to do with Flash, or what many at the recent Web Applications Workshop want to do overall with other languages. That is, build standalone applications separate of browsers that communicate to servers. I was a bit worried that WHAT was essentially trying to do the same thing but use HTML instead, which wouldn't be a good idea. This, I think, is fortunately not the case.

Instead, WHAT is just trying to build a few additional features onto HTML, CSS and the DOM to allow more sophisticated interaction, perhaps what XHTML really should be. Specifically, the goal is to allow better interfaces for web pages and not to build applications like image editors or web browsers. This will certainly be simpler for web developers and is a much better transition. I personally would like to see HTML include much more document oriented features, and even XHTML 2.0 doesn't provide much of this.

The folks in the standalone web applications camp that prefer using XForms and SVG and the like seem to want to build an entire platform. That's fine, but that is rather a lot of work, and may not have a lot of return value considering that there are lots of platforms already. The biggest disadvantage is that they are starting fresh without much of an existing base to build on. Sure, they have XHTML and SVG and the like, but these are fairly new, don't have a lot of implementations to 'harden' them and are hardly the right languages to form the basis of an application. For instance, I don't know many popular Windows or Mac applications (or those of other platforms) that actually have any vector graphics in them. XForms may be sophisticated, but unfortunately a form is only one style of UI, one which doesn't necessarily fit all of the web applications that the advocates want people to create with it. It fits well when the UI is a set of fields to fill out (which is why it's called a form, since it mirrors the paper forms you need to fill out in order to communicate with the government.) Very few applications outside of web pages use this UI paradigm however. For this, an event model is generally more appropriate, since the user interacts with the UI in a fairly random fashion. Click a button here, choose a menu item there, that sort of thing. Which is why I think server side events are a good thing. In fact, I had started an implementation of XUP a while ago; I wrote everything except the part that required SOAP.

I was also wondering how all of this fit into Mozilla's plans described at the recent developer day. In fact, it does. Mozilla as a platform has the advantage that it's not starting fresh -- I doubt they want to go through that again -- it already has a base which implements much of what is necessary. For instance, Mozilla already implements much of the features listed in the requirements section of the WHAT's Web Applications work. As a platform, Mozilla succeeds since it is actually implemented and has much of the needs of a platform already in place. The WHAT's new features will be a benefit to Mozilla as a web browser and as a platform. And, atcually, due to XUL's design and implementation, don't conflict much at all.

One of the interesting aspects about XUL is that there is very little native code in its implementation. All of the box layout code could be considered part of CSS, since these layout types can be used outside of XUL as well. In fact, this flexible box model is already being worked on as part of CSS. The only code of any considerable size specific to XUL is the template builder and the tree widget, as well as some smaller features such as overlays and listbox handling. The template builder and overlays are perhaps application specific while the tree and listbox code could be adapted in a compatible manner to be useful outisde of XUL.

The WHAT is specifically not trying to define any eleborate UI widgets such as toolbars or progress meters and so on. In fact, those would be better defined in libraries of XBL, much as XUL widgets are currently. I think the eventual goal is to make as much as possible be implementable in CSS or XBL such that HTML, XUL and other languages, even XForms, could build upon them. In addition DOM APIs to do drag and drop, server side events and popups would be available to use. With all of these available in the base browsers, it might be possible for someone to implement XUL in another browser such as Opera, simply by porting the XBL to that browser. OK, this isn't really the goal, but it would be a good indicator that the base web application features were of sufficent capability.

Comments ( 9 )