Heads up. The last part to the series I’ve written, entitled “Why Mozilla Deserves Our Attention”, is up on InsideRIA now.
Just a heads up, I’m writing a series of articles dealing with Mozilla and RIAs over on InsideRIA entitled “Why Mozilla Deserves Our Attention”.
Go check it out!
[Update]…and they’re gone, Matt in the comments was right. Didn’t quite have their game together.
Caught this news this morning. A service called Qtrax that allows unlimited, permanently free music downloads that apparently has the support of all the major record labels.
What I see as interesting is the client technology they are using and requiring for use. ReadWriteWeb mentions that it’s built on Songbird.
On the Qtrax site as well, they highlight in multiple spots it’s “A Mozilla Web Browser”, and a “Mozilla Based Browser”.
This is cool as it’s another use of Mozilla technology. Too bad it has so much press and is associating together Songbird, Mozilla, DRM, and Windows-only support not even including iPods. This is in direct opposition of some of the strongest aspects of Mozilla technology.
I’m continuing with my XUL Dark Matter series, which I started with TabPress, a visual editor for simple tabbed content. (Which is at 0.3 now and has theme support)
Now I’ll be looking at Phloneme. Phloneme is a desktop authoring tool as well. It is currently configured to work hand-in-hand with Vocab Collab. Unlike the other XUL projects that I’ve done, Phloneme and Vocab Collab are personal projects that I’ve done in my scant personal free time. I wanted to discipline myself in sticking with something and finishing it through, and this combo was the guinea pig!
(Now, evangelizing a project is a whole different beast and I’m not really pushing that real hard right now with Phloneme and Vocab Collab, but if you know someone interested in the subject domain, pass it along!)
So the whole point of Phloneme (Combination of flow and phoneme), is to write rhymes. It allows you to create, edit, save and publish rhymes directly to Vocab Collab.
The interesting part of the whole thing comes from the ability for the author to easily create structured content, and then push that structure online in the form of a special microformat I’ve created just for rhymes. The structure they add are user-defined rhymes.
The authoring tool allows the user to designate rhyming words in a highly visual way. This is all edited and kept track of through microformat style overloaded class attributes. The document format is XHTML. The editing is taken care of via the awesome Mozilla Midas Spec.
So when the user publishes online, you get all the structured rhymes inserted into the database. The visual display of the rhyme also matches that in the authoring tool, since they can use pretty much the same CSS and everything.
One of the cool advantages of the structured content can be seen in the search feature in Phloneme. You can search for rhyming words for a particular word, and it will return live results from Vocab Collab.
If the user simply wants to copy and paste some rhymes from a search result into his own document, an automatic attribution and link will be created, so once published it will link to the work it derived from. That brings up another feature that I’ve added, which is the ability to select a Creative Commons license when publishing.
This was just one of those personal project ideas that I thought would be cool. Don’t really know what to do with it now. I sure did learn a lot about XULRunner, XUL, and the Midas spec while working on it though.
If you would like to play around with Phloneme, go ahead and have fun. You don’t need a Vocab Collab account unless you plan on publishing. Bust a rhyme!
Getting started tutorial on Phloneme. (With some screenshots)
I’m not done with the XUL Dark Matter series, still have a couple to go yet!
I’ve already received some encouraging feedback to my latest Mozpad post (I’ll be posting a followup soon). Further positive news is that I’ve made good, in a small way at least, on my pledge to devote some time to the Mozpad documentation project.
Having labored to get Prism to build using the Mozilla build system, I was struck by the lack of documentation on this topic for XULRunner developers in general. There’s a blog post by Songbird’s Ben Turner and there’s Dave Townsend’s McCoy project, which is a great practical example of how to do it. But nothing comprehensive on the documentation site.
So I decided to turn my original “Creating Custom Firefox Extensions with the Mozilla Build System” article into a franchise with “Creating XULRunner Apps with the Mozilla Build System”. The article has yet to be reviewed, and to quote Douglas Adams, “it has many omissions and contains much that is apocryphal, or at least wildly inaccurate.” (Unfortunately I didn’t think to adorn it with a prominent “Don’t Panic” label, although this would certainly have been apt.)
Stay tuned for new additions to the series, including “Traditional Chinese Calligraphy with the Mozilla Build System”, “Mastering the Mental Game of Golf with the Mozilla Build System” and the much-anticipated “12 Days to a Flatter Stomach with the Mozilla Build System”.
Mike Shaver asked me about Mozpad the other day, and a few hours later Brian King posed the same question on his blog. Clearly it’s high time to take a step back and evaluate where we are and where we’re going.
The short answer is that not much has happened on the Mozpad front recently. To some degree this is just a case of things taking time. There is definitely ongoing interest in a XULRunner IDE, and ActiveState has brought this a whole whack closer to reality with their Open Komodo initiative. But the initial excitement and momentum has largely dissipated.
I was musing months ago that the group lacked a clear raison d’être. The problem isn’t so much a dearth of things to do, but the commitment and time investment that would be necessary to do them right. This isn’t just a case of setting up some discussion forums for technical support (Mozilla already has them) or an IRC chat room (Mozilla has several) or a great, user-editable documentation site (cause, well, you get the point). Turning XULRunner into a real product with branding, packaging, development tools and marketing is perhaps too big a task for a volunteer organization without any full-time participants. Once folks realized how hard it was going to be to achieve anything substantive without jeopardizing their other projects (including the ones that pay the rent), their initial enthusiasm cooled. I can’t claim to be an exception in this regard.
There are other issues as well. First of all, where are all those XULRunner projects we’ve heard so much about? When we started Mozpad, I was expecting a lot of that XUL dark matter to come out of hiding and express interest in what we were up to. This simply didn’t happen. We got a lot of love from Mozilla die hards who find the idea of an open, multiplatform application development framework appealing, but virtually none from companies that are actually using the technology. It has to be said that Robert O’Callahan’s speculation about “hundreds or even thousands” of stealth XUL projects was based on rather scant evidence. Or perhaps the main interest is in developing intranet applications using a web server and XUL, rather than desktop apps on top of XULRunner. Or, equally plausibly, people are using XULRunner but weren’t aware of Mozpad or were waiting to see concrete results before making their interest known.
Moreover, I have to admit that I’ve cooled somewhat on the idea of XULRunner as a general purpose framework because I’m so excited about the potential of Prism. Since I believe rich web apps are the future, I’d rather spend whatever time I have for Mozilla platform work improving Prism rather than documenting XULRunner APIs and the like. And whereas Mozilla has stated unequivocally that a standalone XULRunner product is not a priority, Prism clearly is. I proposed Mozpad to a large degree because I felt that Mozilla had dropped the ball on the whole “future of apps” thing. Now I’ve got crow casserole heating in the oven as they pick up the ball and sprint for the goal line. (And with that let me pledge publicly: no more ball metaphors in 2007.)
(To be absolutely clear: none of this should be construed in any way as diminishing the heroic work that has been put into making XULRunner a viable platform and getting Firefox to run on top of libxul. Apart from anything else, Prism is a natural consequence of this extraordinary vision, which has been gestating for over three years.)
All this to say that a lot has changed since May, and I’m not sure that we need a Mozpad to further our goal of helping Mozilla to play a defining role in the future of applications. ActiveState has expressed interest in helping out with the development of a XULRunner IDE on top of Open Komodo. All the usual mechanisms are available for those who want to contribute ideas, bug reports and code to the Mozilla platform. Personally I’ve been spending a fair amount of time working on Prism. From my perspective, things are going great despite Mozpad’s lackluster second act.
It goes without saying that I’m extremely keen to hear what others have to say about this. While you’re tucking into your Christmas goose, please take a minute to give this some thought. Nothing would make me happier than an impassioned rant or two about why we desperately need Mozpad after all.
I'm working on a simple extension for Firefox that would notify the user when an SSL/TLS site's certificate changes. This way an informed user could decide if the certificate change was valid / expected and opt out of an ssl session in questionable circumstances. Is there any interest in such an extension? My friend ask me whether there was a way to do it so I'm working on proof of concept code, I will release it as open source if anyone cares.
Some random snippets/observatiosn…
Google’s new Android mobile platform chose Java for it’s application development language. But what’s lacking in developing a Java GUI app? Oh, but of course, something that Mozilla and Adobe have implemented already as part of their platforms, an XML based user interface language!
I made up the name of course, since I couldn’t find a name for it: AXUL.
The format looks a little like SWIXML without the Swing.
This reinforces the whole strategy of using a markup language to layout interfaces and custom widgets, taking advantage of a nice box layout mechanism. But one thing I don’t see is the ability to create new AXUL components by simply composing other AXUL components. (without a hosting Java class)
But why didn’t they choose HTML 5? Ha.
Hi folks !
A generous artist, Marianne Thoyer, has made some work about the Mozpad identity. She works on some Mozpad logo attempts. Here some drafts:
And my favorite one:
After seeing these pictures, I thought the 'cell' ones could fit for a XulRunner logo, so, just for fun, I've asked her to change the label mozpad to xulrunner:
Before going forward, she needs to know the community feeling. Feel free to comment :)
Just read the NYTimes write-up on Prism.
Interesting comments by Mark Finkle:
if the Web can’t do it, Prism can’t do it
and
We’re not asking Web apps to change at all.
So thats the big thing really. It’s an incremental nicety to classic web browsing. This is really not in competition to Adobe AIR at all.
It’s more in line with something like Mac OS X’s new Safari Web Clips. Yank an app out of the browser and run it by itself.
As a real-world example, imagine Google Analytics without browser chrome, and then look at the Google Analytics AIR app. Designing an experience more with the user in mind, than browser limitations. And this is using Open Internet protocols and APIs. Maybe that’s not as good as the Open Web though, not sure?
Wow, a lot of writing and discussion over Prism lately! And to think, all from a new name, logo, and a Labs post. (And I guess some weight from being an officially sanctioned experiment too.)
Of course, I’ll follow suit. Partly because I am interested in the technology, and partly because I am interested in how this relates to Adobe AIR, and Mozilla’s own technologies, like XUL. How is it integrated? How can some important features and functionality be integrated with HTML/JavaScript only?
I thought I would start by comparing the installation story with Adobe AIR. A lot has been made of how easy it is (or will be?) to make a web app into a desktop app. (A simple menu command from Firefox, and voila!) But that’s not the whole story. How does Prism get installed in the first place?
With Adobe AIR (which runs web apps as well on the desktop, built with HTML/CSS and JavaScript), there is a really cool installation story. You can create a special badge that a user can install your app (with permission of course) from a web page. The cool part though, is if they don’t have the Adobe AIR runtime, it will be installed auto-magically (with permission of course) along with your app! No need to direct them to a different website, instruct them to download something, then come back and get your app.
So how will Prism get installed? Sure, after it’s installed it’s somewhat smooth sailing. But getting software installed is a hurdle which should not be ignored. Adobe has excellent experience with this. Heck, installs of Firefox are dwarfed by Flash Player. So what’s Prism’s installation story?
I was waiting for this to happen. Didn’t think it would happen this soon though.
The very first Prism app built with Flex.
Speaks to the pervasiveness of the Flash Player, since in the first batch of Prism apps out of the gate, one is built with Flex. It also speaks to the flexibility and strength of the Prism idea, especially since it’s already wooing prime Adobe AIR candidates: Flex developers.
A Flex app as a Prism app?! This doesn’t fall in lock step with the shining goal of the “open web” as defined by some folks.
But, man wouldn’t that be cool if Mozilla had their own user interface markup language? Oh, wait they do, XUL. Does something like this, and that Mozilla doesn’t even mention XUL with Prism mean that it’s pretty much lost the fight to Flex/MXML?
Daniel has posted his unpleasant surprise about eBay using Adobe AIR for their internet desktop application instead of XULRunner.
Here are two lists attempting to document the application landscapes with each technology:
Mozpad’s Mozilla App List
AIRApps Adobe AIR App List
Daniel Glazman has a followup post on the whole “Powered by Mozilla” thing (excellent initiative, did I mention?), which points to a droll and frustratingly anonymous rant on a new blog called “The Truth about Mozilla”.
I fell off my chair when I read that AllPeers is a “Mozpad front-company” and not just because of the incorrect hyphenation. (Save your cards, flowers and chocolates, I’m fine beyond a few psychological bumps and bruises.) That said, Mr. Anonymous does provide a reasonable if caustic counterpoint to Daniel’s and my contention that Mozilla platform developers would benefit if there were some way for them to leverage the better-known Firefox brand. (But what’s all this about Schrödinger’s cat? I’ve heard of mixing metaphors, but throwing in a physics thought experiment is a bold move. What good shit are you smoking, dude?)
Anyway, as my previous post on the topic implies, I disagree with the idea of trying to create a second trips-off-the-tongue brand out of Mozilla. Like I said, it’s hard enough to get traction with even one brand. As things stand, I must say “you know, the guys who make Firefox” about ten times a day.
And then there’s the general problem of what to call the platform. Mozilla, Gecko and XULRunner are often used interchangeably, and all of them have considerable drawbacks. Calling the platform “Firefox” is obviously problematic too, as Anonymous Mozilla Guy points out. But what about taking a feather out of BitTorrent’s cap? “Firefox DNA” is a bit me-too-ish. But something that uses the word “Firefox”, gets across the idea that “this is the stuff inside Firefox” while remaining clearly distinct from Firefox The Browser would be killer.
UPDATE: Before anyone else chastises me for “feeding the troll,” let me say in my defense that I didn’t read the earlier, more obnoxious posts on the “Truth about Mozilla” blog before linking to it. The post I link to seemed reasonable enough to me. I’d be on thin ice, after all, if I criticized his sarcastic tone and childish sense of humor (though I might plausibly demand royalties). Anyway, a lot of the posts do look like trolling, and the whole idea of a muck-raking Mozilla blog is silly, so please don’t patronize or link to his blog unless I explicitly say it’s okay.
UPDATE: Apparently it isn’t obvious that the bold portion of the previous update is tongue-in-cheek, at least if Cedric is any guide (a dubious premise, I admit). So lest it be too obtuse for some: I’m kidding!
I often talk to people who aren’t developers but still want to be able to contribute somehow to the open source world. If you have any kind of graphic design skills and want to support our effort to promote the Mozilla platform for developers, why not consider giving the Mozpad website a makeover? Let’s face it, considering the way it looks currently, it wouldn’t take much work to improve it.
Daniel Glazman comments on John Slater’s post about the excellent “Powered by Mozilla” initiative. I’ve seen this phenomenon directly or from a distance a number of times in my professional career. It’s hard to build a brand, and it’s doubly hard to build separate brands for a company and its flagship product.
In my experience, what inevitably happens is that the product garners much larger mind share, and the company eventually adopts its name in order to leverage its brand. Just thinking out loud, mind you…
Well... the
mozpad.org website is not really sexy. Currently, the default Dokuwiki theme is
used. What about redesigning it ? There's a set of templates here. I've tried the
r7throot template. Really easy to install and to setup. It could be a good
opportunity to clean the wiki (a real home page, a clean
projects page, a news page, ...). BTW, we should work on a
logo :) Any good designer here ?
Paul Rouget and Mariano Cuenze have been pushing forward the Mozpad IDE project, and we’re all jazzed up by the potential of Open Komodo to serve as the basis for an IDE for Mozilla developers. Shane Caraveo of ActiveState (makers of Komodo) has kindly offered to provide some guidance as to how we can best extend their product. Paul has written up some preliminary requirements in PDF and ODT formats. (I promised I would edit the text for grammar, but it actually looks fine to me for our current purposes.)
We’ll be meeting tomorrow at 4pm UTC in #mozpad. If anyone else is interested in talking about a Mozpad IDE built on Open Komodo, please feel free to join in the discussion.
I’ve updated the Mozpad API analysis page with additional statistics I received for Mozilla projects. I am planning to massage the results in various ways to provide additional views (e.g. sorted by frequency rather than interface). but this should tide us over in the meantime.
Many thanks to Nick Nassar of Miro, Wladimir Palant of TomTom, Javier Pedemonte of the AJAX Toolkit Framework, Pete Wilson of Mozdev and Matt Crocker of Songbird for providing data for their projects. I ended up biting the bullet and compiling the figures from the various files I received using Python, which meant (wait for it) I had to learn Python on Friday. This went surprisingly well due to a very supportive group of folks on IRC, notably Jason Orendorff, who has made a Python convert out of me in less than an hour.
It goes without saying that we’d love to feed more data into the stats. Please take a few minutes to run the script on your project and send me the results.
I’ve updated the API usage analysis for the AllPeers source tree as part of the Mozpad API project. The main update is that mozI* interfaces are now counted in addition to nsI* interfaces. The next step is to get other Mozilla-based projects to run the script and send me their results. I would really appreciate it if anyone reading this who is working on a large Mozilla project could run the script in their source tree root (make sure you don’t have other files like patches in the same tree that might pollute the statistics) and send me the results. Please specify if you want the data to be anonymous or if we can cite your project. I’m planning to nag people about this so why not be proactive? You’ll sleep more soundly, I promise.
While we gather the data, I’m planning to devote some time to the Mozpad documentation project.
When the iPhone was released, there was plenty of bellyaching about the lack of an SDK for third-party apps. Then Apple stepped up and announced that the “SDK” for the new device would be the Safari web browser, combined with Web 2.0 techniques (i.e. gobs of JavaScript on the client). Some hailed this as a visionary idea while others griped (somewhat paradoxically) that “web apps are not applications”. The situation became muddier when rogue developers quickly released a user interface toolkit and a package manager that makes it braindead simple to install native (albeit unauthorized) OS X apps designed for the iPhone.
I’ve been plugging the idea of web apps as the future of applications for a while, with a particular emphasis on WebRunner. So naturally I’ve been intrigued by Apple’s decision to make the web their official SDK. Having got my hot little hands on one, however, I’m disappointed by the current lack of features that would make this direction viable. As far as I can see, you can’t even add an app to the pretty grid of colorful icons that serves as the iPhone’s main menu. Besides integration with the underlying OS, there are many other gaps if the browser is to serve as an application platform: offline storage, Flash, more sophisticated web forms, etc. (Mike Shaver had a great overview of future web browser features at Mozilla 24.)
When Apple announced Safari for Windows I hypothesized that this would allow them to roll out exactly these kinds of proprietary browser-as-a-platform features. I still think that the use of web apps as the standard iPhone development paradigm is brilliant, but the current offering is totally inadequate. I predict that Apple will start to announce fancy new features for Safari or (hopefully) jump on board of existing efforts like XUL, Flex, Google Gears and the like.
The good folks from the Media in Transition conference have put the video of my presentation online. The title of the talk was “Building Media Distribution Apps”, touching on the trade-offs between various distribution techniques (e.g. streaming vs. downloads) and the new generation of rich internet application platforms (including XULRunner and WebRunner).
There is also a short video of an interview I gave after the talk.
UPDATE: I should have mentioned that the slides that go with the presentation can be found here.
There’s been some discussion on mozilla.dev.platform about whether that newsgroup should be used for newbie questions and other platform user support issues. Some platform developers are understandably concerned that this type of traffic will obscure internal communication.
We set up Mozpad exactly for application developers using the Mozilla platform, and we have a newsgroup (mozilla.community.mozpad) which could be used for this purpose. Personally I’d be thrilled to see this happen since it would be a significant contribution to the community. The main issue is that there aren’t nearly as many people subscribed to m.c.mozpad (I’m guessing) so the chance of getting an intelligent answer is not as high.
Gavin Sharp suggested to me that mozilla.development.extensions would be the right place for questions about using the platform. Gavin’s proposal is certainly sensible, particularly since it apparently corresponds to the status quo. But I still think that the “extensions” name is potentially confusing to newcomers, that the target audiences don’t overlap completely and that there would be value in a group specifically devoted to users of XULRunner and WebRunner.
Whatever the case might be, don’t hesitate to point people to m.c.mozpad if they have platform questions, even if this isn’t considered to be the “official” destination.
I’ve put together an Xcode project template for XAPGen. So if you have the Xcode development tools, just download, unzip, and drop the files packaged up below in the right spot, and you’re ready to rock.
After setup, in Xcode just go to File->New Project, and choose XUL->XAPGen. You have an instant XULRunner project directory ready to build. Just choose the build-and-run target, click “Build”, and you’ll see the default Hello World app get packaged up and launched all automatically.
And of course, the build-all target will build Windows and Linux distributions as well!
When naming your new project name, remember to use all lowercase.
Mark Finkle posted an entry on the Mozilla wiki proposing a Mozilla Developer Day in Prague in the November timeframe along the lines of the one that took place in Paris in June. Reviews for the Paris day were glowing, but I know that a lot of people couldn’t make it and that others were left wanting more. If we can drum up enough interest, I’d also like to combine the Developer Day with a Mozpad face-to-face meeting. If there’s a chance you might attend, please sign up on the wiki so we can see whether the interest level is high enough to move to the next phase of planning.
I would like to share a technique that I am using to customize WebRunner's behavior without directly changing the source code. In my AppRunner extension I have created an overlay for webrunner.xul and within the overlay I include my custom apprunner.js script. Today I decided that I want to modify the behavior of a function in the core WebRunner application object.
In webrunner.js there is a global WebRunner object which is defined like this:
var WebRunner = {
_profile : null,
_ios : null,
// webrunner functions omitted...
}
In my apprunner.js file I have my own global AppRunner namespace object, defined similarly to the WebRunner object above. I will try to let the code speak for it's self with a short explanation afterward:
window.addEventListener("load", function() { apprunner.startup(); }, false);
window.addEventListener("unload", function() { apprunner.shutdown(); }, false);
var apprunner = {
startup: function() {
self = this;
var browserContext = document.getElementById("popup_main");
browserContext.addEventListener("popupshowing", self._popupShowing, false);
//replace the webrunner _isLinkExternal function with a modified version:
WebRunner._isLinkExternal = this._isLinkExternal;
},
shutdown: function() {
self = this;
window.removeEventListener("popupshowing",self._popupShowing, false);
},
_popupShowing: function(aEvent) {
var isAnchor = (document.popupNode instanceof HTMLAnchorElement);
document.getElementById("menuitem_copylink").setAttribute("hidden",!isAnchor);
document.getElementById("link_popup_separator").setAttribute("hidden",!isAnchor);
},
_isLinkExternal : function(aLink) {
if (aLink instanceof HTMLAnchorElement) {
if (aLink.target == "_self" || aLink.target == "_top")
return false;
var currentURL = this._ios.newURI(aLink.href, null, null).QueryInterface(Ci.nsIURL);
var commonBase = currentURL.getCommonBaseSpec(this._getBrowser().currentURI);
//alert(commonBase + ":" + aLink.href + ":" + this._getBrowser().currentURI.href);
return (commonBase.length == 0);
}
return true;
},
copylink: function(event) {
var gClipboardHelper = Components.classes["@mozilla.org/widget/clipboardhelper;1"].
getService(Components.interfaces.nsIClipboardHelper);
gClipboardHelper.copyString(document.popupNode.href);
},
doCommand : function(aCmd) {
switch (aCmd) {
case "cmd_aboutconfig":
window.open("chrome://global/content/config.xul", "About:Config", "chrome,extrachrome,dependent,menubar,resizable,scrollbars,status,toolbar");
break;
}
}
}
The code above is mostly for other functionality that I have added in my webrunner extension, however, the startup function shows the technique which I wanted to highlight. Notice the bold face code which replaces a function in WebRunner with my own version of the same function. This doesn't have much effect right now because I have not rewritten the function to my liking, however, my changes to that function will override WebRunner's version of the same function, all without touching webrunner.js or webrunner.xul.
This is the beauty of Mozilla's platform for extensibility and the flexibility of JavaScript makes it even more powerful. This is incredible extensibility due to the simple and intelligent design of the Mozilla platform in general and WebRunner in particular.
Shane Caraveo of ActiveState sent me a heads up about their new Open Komodo initiative. This looks like a pretty big deal. They’re open sourcing portions of their Mozilla-based IDE in order to cultivate a community-driven development effort. Considering that many people have cited Komodo as a potential starting point for an IDE tailored to the Mozilla platform “if only it were open source”, this could be a big step towards my long-awaited Dream Firefox IDE. I’m looking forward to giving it a spin as soon as I get back to the office.
I have been working on an authoring tool code-named TabPress. This is being built on XULRunner and is meant to be a relatively simple tool to create small learning objects delivered in a tab container.
I am experimenting with a different way of editing structured/complex content utilizing the editor and overloaded images. So far it’s working decently, but I need to conduct some more usability tests to flesh things out further.
Some quick points about the app:
It’s in an alpha state without any user documentation at the moment. Feel free to play around with it though and see whats discoverable. Just wanted to get this early version out there and make sure it doesn’t end up as dark matter. 
Updated!
Now at 0.3, there has been some bug fixes, enhancements with visual editing capabilities and support for themes when publishing.
We had a great discussion on Wednesday about where to take Mozpad. Thanks to everyone who attended. Mukunda posted the transcript on his blog.
Some highlights from my perspective: we agreed that Mozpad should be focused on making Mozilla platform products more appealing to developers, but should not itself be a destination site for product information. Instead we should use the appropriate Mozilla websites (particularly MDC). I’d still like to have a nicer-looking Mozpad site to summarize our activities, who is involved, how to get involved, etc. Mukunda said he might be able to help make this happen since my graphical design skills haven’t developed much since fingerpainting in kindergarten.
Further agreement that there isn’t a XULRunner/WebRunner dichotomy. We can work on improving materials for both, and in fact there is considerable overlap (considering that WebRunner is a XULRunner application).
Personally I am planning to finish my API project and shift my focus to documentation, especially high-level descriptions of the products and why they are important. I’m hoping to find time to give some thought to what the XULRunner and WebRunner sections of MDC should look like. One of the various first steps is obviously to coordinate with the relevant documentation people at Mozilla. You know who you are. I’ll be in touch.
Hopefully we’ll see further progress on the outreach website(s) as well (the equivalent of SpreadFirefox but for the platform). Mark Finkle said he would try to get Asa to give us some guidance from his experience with SpreadFirefox.
Finally, we seemed to agree that Komodo was worth looking at in the context of a Mozilla platform IDE since they already have most of what we need. Discussions will continue once we’ve had a chance to take a look.
I’ve been trying my best to try and figure out the current landscape of technology offerings for RIA and IDA development. So forgive me for this rant-ish post, and correct me or help me where I’m just dead wrong.
I believe in choosing the right technology for a project’s or product’s requirements. Some of the projects I work on are obviously web applications, so I target the browser and either use HTML/JavaScript for simple interfaces, or Flex/ActionScript for advanced interfaces or rich media integration.
But we’ve frequently found ourselves in the position of needing to create relatively light-weight desktop applications with advanced UI requirements, that can easily work with web technologies.
Building these IDAs with client technologies like Flash/Flex/XUL/ECMAScript has been awesome in developing fast and good, and not having to code Swing layouts. This idea has pretty much been hackish at best in the past until XULRunner came along. But now AIR is here, and I’m trying to evaluate both. So this is the type of target I’m referring to with this post, Internet Desktop Applications with advanced interface requirements.
This post and chat transcript posted by Matt of AllPeers really kind of set off some alarm bells. Not gonna summarize it, so you may have to read it. But I’m replying to some thoughts presented in it.
HTML? Hyper-text Markup Language: Formatting text documents.
XUL? XML User Interface Language: Creating user interfaces
Merge XUL into HTML, gradually over time? Why? Use the best tool for the job! Leave HTML for what it does best, for documents. And talking about some future idea that may be cool (or the worst thing ever done), is not NOW. There are excellent tools and technologies available NOW that do these things (Flex, ActionScript 3, AIR)
What is WebRunner’s or Firefox 3’s interface developed in? XUL, not HTML. Maybe once we see Firefox shipping with an all HTML interface then I’ll be able to see HTML as some sort of capable user interface language.
If Mozilla’s own evangelists are encouraging HTML over XUL, then it would be downright foolish to champion it, and makes me uneasy choosing it to develop with.
So who is putting their weight behind a modern, advanced, rich, and internet friendly programming language and user interface markup language? Adobe, with Flex and ActionScript 3.
In more than one spot I have seen this evangelism of using HTML over XUL for developing rich applications, and wonder what is at it’s core. Maybe it is because the Mozilla Foundation/Corporation is unsure of the future API or compatibility and stability of using XUL and its companions. And they figure HTML is the safe way to go for the “masses”.
Again, who has the awesome history of distributing a runtime far and fast, proven backwards compatibility in a runtime, and is at the same time making great advancements with innovation for rich media, RIA, and internet desktop application developers? Adobe. With the Flash Player, and no doubt soon to come AIR.
I’m trying my best to find something to keep me hackin’ on XUL and JavaScript, but I keep seeing these confusing mixed signals as to the future of a capable RIA/IDA platform or runtime using Mozilla technologies. (Or no signals at all)
Don’t get me wrong, I love working with XUL, JavaScript, and XULRunner, and I have a number of projects using the technology. So I’ll be continuing to develop with it. But for new and future projects I’m gonna have give it some serious thought.
As I mentioned the other day, I’m grappling with the Mozpad mission, trying to find an encapsulation of our activities that is intuitive, useful and doesn’t overlap with activities that are already well served by other forums. In my previous post I suggested that we might take the platform under our wing and make sure that associated resources (white papers, the SDK, documentation, demos/samples, some sort of IDE, etc.) are accessible to interested parties without excessive trawling.
I had a long chat about this yesterday with Benjamin Smedberg and Mark Finkle (joined later by Robert Kaiser). I would strongly encourage anyone interested in the future of Mozilla, applications and the web to read the chat log. What came out of the discussion is a new hypothesis that all three of us appear to support: the importance of a C++ SDK is diminishing and the value of a platform for deploying web apps on the desktop is growing. I’m very sympathetic to this viewpoint, not least because I spend a lot of time coding in C++ (the verbose Mozilla dialect, that is), and I’m sure I’d be a calmer, happier, better grounded and more fulfilled person with more hair and lower blood pressure if I didn’t.
What this means, concretely, is that the platform to bet on may well be WebRunner. I can’t see any reason why something like WebRunner couldn’t be the basis for most if not all kinds of apps in the future. Naturally there’s a lot of work required to achieve this, not least implementing the relevant items from various people’s XULRunner wishlists to reduce (and ideally eliminate) the need for binary code in Mozilla-based applications and better integrate with the operating system desktop. (By the way, I used to be a proponent of replacing the desktop with the browser interface, but that was before I switched from Windows to Mac.) We need to figure out our strategy for local storage (Google Gears? mozStorage? A combination? Something else entirely?) We need to decide what the fate of XUL is, since the argument that “XUL is for desktop apps and HTML is for web apps” makes less and less sense as the boundary between the two blurs.
Anyway, I probably don’t have to go on about this too much since I made exactly this point in the conclusion of my Future of Applications essay. So alongside the “people-oriented” vs. “product-oriented” discussion, I think Mozpad needs to have a serious discussion about the relative merits of XULRunner and WebRunner and where we should be investing time.
I was encouraged by the feedback (public and private) to my previous Mozpad post. I’d like to have a Mozpad meeting this Wednesday (usual time and place) to drill down on this idea. A few specific things spring to mind:
If there are other things that people feel will be important to discuss, please let me know.
Looks like my idea of Super Add-Ons might be possible with Firefox 3!
It appears its all experimental right now, but hey I’m not to proud to gobble up table scraps!
Some shortcomings to note right away:
Let’s see what we can’t do.
I’ve been thinking lately about Mozpad and its raison d’être. I can’t seem to shake the feeling that the purpose of the organization is not entirely clear, and that this will turn into a major barrier to achieving something useful. I’m starting to understand why some people (particularly Simon Lucy of Joost, who deserves credit for raising this issue) were pushing to get a clear mission statement formulated.
I originally conceived of Mozpad as a “user group” for people developing on top of Mozilla. But I’m coming around to the view that this doesn’t give it enough to do considering that Mozilla itself is an open source project and has many open forums for developers (something Mike Shaver pointed out). If I want to ask a technical question, I’d rather go to one of the newsgroups or IRC channels where I can reach the broadest possible community of Mozilla core and application developers. And that’s most of what a user group does.
This isn’t to say that we don’t have great and useful action items. But I feel that we would benefit from more clarity of purpose. Specifically, I’m beginning to think that Mozpad should aim to create and distribute a real product. People should be able to go to mozpad.org to get the latest version of the platform and access documentation, demos and other materials (hosted locally or through links to the appropriate mozilla.org). As I’ve made clear, I believe that a truly usable SDK is a must so that people don’t have to go through the fiery crucible of the build system as their very first experience with Mozilla (the software development equivalent of spending a week as a crash test dummy before being allowed to buy a car). I’m also a huge fan of the IDE-in-Eclipse idea. The nice thing is that none of this contradicts our existing action items, it just gives us a better handle on where we are heading.
In fact, I’d like to brand the platform “Mozpad”. It’s a cool name for a platform although it wasn’t conceived as such. There might be some issues with this, however, which I’m looking into.
What do people think of a Mozpad product based on Mozilla, with an SDK, IDE and platform documentation so that it is a viable choice for people who want to develop “rich internet applications” or other multiplatform software? Am I seeing a problem where there isn’t one? Is this far too ambitious? Personally I can’t invest silly amounts of time into this, so if this doesn’t jibe with what other people were hoping to get from Mozpad then it’s not going to fly.
/* widget.js - shared code used in all widgets.
*/
window.addEventListener("load", startup, false);
var widgetRunner= window.opener.widgetRinner;
function startup() {
window.opener.widgetLoaded(window);
if (loadWidget) {
loadWidget();
}
var startPos=0;
var mouseDown = function(event) {
startPos = [ event.clientX, event.clientY];
}
var mouseMove = function(event) {
if (startPos != 0) {
var newX = event.screenX-startPos[0];
var newY = event.screenY-startPos[1];
window.moveTo(newX,newY);
}
}
var mouseUp = function(event) {
startPos=0;
}
window.addEventListener("mousedown",mouseDown, false);
window.addEventListener("mouseup",mouseUp, false);
window.addEventListener("mousemove",mouseMove, false);
}
I just attended a session here at OSCON squaring off a couple of new Rich Internet Application (RIA) technologies: Sun’s JavaFX and Adobe Flex. Nandini Ramani of Sun and James Ward of Adobe were on hand to demo their respective approaches.
As I understand it, JavaFX is Java but better integrated with other web technologies. The original pitch for Java was as a way to run multiplatform code on a webpage. As it transpires, it had its clock cleaned by JavaScript and Flash, and has found far more success as a server-side technology. Nandini plausibly suggested that one of the biggest barriers to adoption has been the inadequacies of Java graphics frameworks such as Swing. Now Sun is giving it another go, using HTML as the UI language with lots of whiz bang script goodness. The result looks a lot like, well, Flash.
This is certainly a big improvement. The only problem is that Adobe has moved on, and the Flex demos were nothing short of jaw-dropping. James kept muttering mea culpas to the effect that “I’m not sure why anyone would actually want to do this,” but who cares when flipping the pages of a virtual book that overlay as transparencies or run live video looks so damn cool? He made a big deal about Adobe’s Tamarin scripting engine, which has been open sourced and donated to the Mozilla project. Thanks to just-in-time compilation, it apparently runs tens or even hundreds of times as fast as old school JavaScript.
Bottom line: If JavaFX is Sun’s last gasp in the web client space then they have their work cut out for them. When the session ended, James was mobbed by adoring open source geeks as Nandini looked on forlornly.
Seeing these sexy demos steeled my resolve to soup up the AllPeers user interface with some sort of RIA technology. As a Mozilla shop, the natural inclination would be to explore the use of more open technologies like SVG or simply HTML and JavaScript. (Am I still allowed to call it DHTML?) But Flex has the indisputable attraction of building on tried-and-true Flash and has a slick Eclipse-based IDE. I asked some Mozilla folks at their booth what they thought, and they said “try both”. Hopefully I’ll be able to free up some of our UI people’s cycles to do exactly that, in which case I’ll be reporting back here with our conclusions.