Posted on

XUL Explorer 0.3

After getting sidetracked for a while, I have finally made some progress on XUL Explorer. I have been tinkering around with the editor and integrating the XUL validator. I also reorganized the code a little so I could support sidebars in the future.

xulexplorer.png

I have been trying to stick with the XUL as much as possible. Anyone who has worked with the editor would probably tell me it’s a lost cause, but it’s also been quite a learning experience. I have added tabbed editing by dynamically creating elements inside a . It seems to work well. I make use of the tab-close-button and even change tab image if the editor is modified.

editor-tabs.png

You are prompted to save a modified editor when closing the editor or the application. One thing I have not been able to add was a way to display the current cursor position (row, column). I am still looking into it.

I rearranged the UI a little because of the tabbed editors. The preview pane is no longer below the editor. It was taking room away from the editor, so I added a code/preview toggle. I removed the “Insert Snippet” button from the Snippet Sidebar, but added drag-and-drop as a method of inserting snippets. Double-clicking a snippet also inserts it.

I added a Messages pane at the bottom of the workspace to display output from the, incrementally improved, XUL validator. I’ll probably make more use of the Messages pane in the future.

messages-pane.png

Next up for XUL Explorer:

  • Property Sidebar – Will display the structure of the XUL as a tree and properties of the selected element in a grid. Most likely, it will also allow users to insert/delete XUL elements.
  • Wizards/Generators – Will walk the user through creating XUL files, JavaScript XPCOM, extensions and XULRunner applications. For extensions and application wizards, I really need to add a Project Sidebar.
  • Project Sidebar – Will show the bundle of files needed to support extensions and wizards.

Overall, this project is still giving me lots of Mozilla stuff to play with and learn. And it’s fun.

Keep the feedback coming!

The install is still Windows only. I failed to get a Mac DMG file assembled yet, but I just got some tips on IRC. I am hoping to get Mac and Linux installs someday.

Install: xulexplorer-setup-0.3.exe 4.9MB
Source: xulexplorer-src-0.3.zip

Posted on

FUEL Project Status

FUEL is the little library that John Resig and I are working on which should make developing extensions a little easier. It’s been a while since we last talked about it so I thought an update was in order.

FUEL now has a place in the Mozilla CVS tree (browser/fuel) and development is happening in a branch (FUEL_DEVEL_BRANCH). We have been tweaking the API (0.1 and 0.2) a little over the past couple weeks. We have also added some information on the testing plan. We are using the Mochitest framework to run our unit tests.

So far, we have the basics parts in place, including:

  • Global Application object.
  • Ability to associate user data with the Application and Extension. No more hidden window hacks.
  • Easy access to preferences, again global with Application and per extension with Extension. The extension-based preferences automatically use an “extensions.your-ext.” branch.
  • Simple events for Application (“start”, “ready”, “quit”) and Extension (“install”, “uninstall”). Events can also be used to watch for changes on preferences and storage items.

We hope to get the code and tests ready for review this week. Then we can get something pushed to the trunk after that. As always, feedback is welcome – comments, email, IRC, or Wiki.

Posted on

Thinking About a XUL Validator

A validator for XUL could be a good idea. I am thinking about something more than just ‘schema’ validation. Something to help with best practices and accessibility. Maybe ‘validator’ isn’t the right word. Here are some checks that could be useful:

  • Basic Structure – Stuff a schema language would check:
    • Is the XML well formed?
    • Are any elements unknown?
    • For a given element, are any attributes unknown?
    • For a given element, is it the child of a valid parent?
    • For a given attribute, are the values allowed?
  • Best Practices – Stuff that’s recommended for a good, localizable, skinnable and accessible UI:
    • Are access keys on menus, checkboxes, radiobuttons, buttons and labels linked to controls?
    • Are labels linked to controls using control attribute?
    • Do toolbarbuttons have labels and tooltips (even if the label is hidden)?
    • Are there menu alternatives to toolbar actions (use keyset and commandset)?
    • Is the context attribute used to attach context menus?
    • Are radiogroups contained in a groupbox with a caption?
    • Does the source declare a DTD for localization of string resources?
    • Are labels, captions, accesskeys and other strings pulled from a DTD?
    • Does the source import a stylesheet (exception: overlays)?
    • Are toolbar, menu and button images assigned via CSS or hard coded image attributes?
    • Does the source avoid using inline style?

What else could a validator check? I pulled some of these from a good MDC article on accessibility guidelines. Localization is definitely important and MDC has guidelines and examples to help. The skinning stuff came from this skin/CSS guide.

I have most of these checks in the current version of XUL Explorer (to be released soon). I was planning a simple web version too.

Note: There is a web-based accessibility checker for XUL (and other types) at WebAIM. To test it, choose “XUL Report” for the LRAE file and pick “Form Test (XUL)” or “Browser (XUL)”, then press “Process” button. You can also supply your own XUL URL.

Update: Added localization and skinning guidelines to the list (thanks Axel)

Posted on

The More You Know

A few common questions seem to be asked a lot, especially by developers new to the Mozilla platform. So, I wanted to draw attention to some relevant articles on the Mozilla Developers Center (MDC).

  • How do I get access to the browser? If your writing an extension for Firefox, there is a good chance you want access to the browser. You might want to add tabs, get the selected text in the current tab or whatever. This tabbrowser code snippet article has enough information to get you started.
  • How can I debug problems in my code? It can be really frustrating when you seem to have everything put together right, but nothing appears to be working. This extension FAQ article can help you debug some common problems.
  • How can I be notified when ‘X’ happens? Web developers are familiar with the concept of ‘events’. It is common to use events to be notified when a web page loads or when a keypress occurs on an input. The same is true when developing extensions and other chrome-based code in Mozilla. The UI is made up of XUL, which is very similar to what you know of DHTML. Here is a list of XUL events and a helpful XUL reference with information about the various kinds of elements you’ll come across.
Posted on

Extension Development with FUEL

Removing obstacles for extension developers is my group’s primary task at Mozilla. There are lots of ways we can do this and areas include documentation, tutorials, samples and tools. One thing that becomes clear after watching and helping extension developers is the difficulty some have getting familiar with the Mozilla framework and the plethora of object and interfaces available. Not only are some of the concepts foreign, but in many cases there are no clear ways for extension developers to achieve their goals. There are places to get help. The Mozilla’s IRC channels are a great place to ask questions, especially #extdev.

We have also started work on a JavaScript library to help extension developers shorten the learning curve, feel more comfortable and generally be more productive. Codenamed FUEL, the library is primarily a wrapper around commonly used parts of the Mozilla framework which are unfamiliar or complicated. Some of the goals are:

  • Make it easy for developers to do common extension tasks.
  • Use terminology and interfaces familiar JavaScript developers.
  • Hide as many implementation details as possible.
  • Allow developers to get access to underlying XPCOM interfaces if they want to.
  • Act as a buffer between extensions and Firefox internals.

In addition to making it easier for extension developers, we also want to help improve the overall quality of Firefox. A broken extension appears to be a broken Firefox. Anything that can be done to help extensions avoid breakage and use clearly defined methods of hooking into the browser will help.

Currently, we (myself and John Resig) are in the planning and prototype phases. John’s JavaScript library experience (jQuery) is a huge plus for us. It’s great to have him working at Mozilla.

I invite you to take a look at the FUEL wiki pages and send us feedback and comments. You can use the discussion pages on the wiki or visit IRC (we hang out there way to much) or even use the newsgroup thread.

Update: I forgot to mention that our goal is to ship this library with Firefox (and other Mozilla applications as needed). Of course, we would also want it be able to usable in older Firefox releases too. Packaging could be a challenge.

Posted on

XUL Clippings – Canvas

Here are some XUL clippings that show different uses of the element. The purpose of this post is not to show off uses of , but to point out that it can be used in XUL (Firefox extensions and XULRunner applications) very easily.

I also updated the XUL/E (XUL in IE) post to include some of these samples as well. That’s right, you can use in IE using the Mozilla ActiveX control discussed in the post.

Note: These are simply XUL files and if you’re using Firefox (or another XUL enabled browser), clicking the links will open the files in the browser instead of downloading to your machine. Right-click on the links and pick “Save Link As…” to save them to your machine.

Posted on

Extension Hacks Wanted

A large part of my job at Mozilla is trying to make life easier for extension developers. In order to do my best, I need to understand the pains of extension developers. Up to now, I have been writing various types of extensions myself (sidebars, statusbars and components) to try to understand what an extension developer goes through. I even download extensions just to look at the code, trying to find comments like “hack” or “sucks”. But really, that’s not enough. So now I am asking extension developers directly:

What can Mozilla do to make writing extensions easier?

The title of this post mentions hacks, but I am interested in all aspects of extension development:

  • Tutorials
  • Installation / Updating
  • Using frozen XPCOM interfaces/ components/ services
  • Intergating into Firefox/ Thunderbird UI code
  • Protecting against version to version breakage
  • Documented best practices (or lack of)
  • Anything else (extension related)

Feel free to leave comments on this post (preferred) or send to mark dot finkle at gmail dot com

Posted on

Code Snippets – Get Your Code Snippets

If you’re new to Firefox extension or XULRunner programming, one of the first things you may want to do is find a good tutorial to help get a “hello world” project bootstrapped. Mozilla Developer Center (MDC) has more than a few to help you get started: Firefox Sidebar, Firefox Statusbar, XULRunner Application. We are working to get more on the way too.

The next thing you may need is small code snippets to help show you how to do common things. Things you probably already know how to do in another language or framework. You just need to know how to do it with XUL, JavaScript and XPCOM. You should definitely check out the Code Snippets section on the MDC. There is also an Example Code section on Mozillazine.

If there is something you want to know how to do, but it’s not on the MDC yet, let me know. Also, for any of you experienced Mozilla developers out there, go check out the code snippets and please add some of your own. Just keep the code snippet short and sweet, we’re not writing a full sample extension or application. If you do want to write a large sample extension or application, create a full blown tutorial.

Posted on

Site Specific Browers

Recent posts from Zach Lipton and Robert O’Callahan share a common theme: Give web applications better integration into the desktop.

I have a strong interest in this area myself. A while ago I came across a desktop application for the Mac called Pryo. It’s an application with an embedded browser designed to work exclusively with a single web application: Campfire (a web-based IM service from 37Signals). Pryo allows for many things that are either difficult or impossible for Campfire to do on its own. The guys behind Pryo call it a Site Specific Browser. There is even a Windows clone in the works.

Zach provides a simple proposal for “appifying” Firefox for specific sites. I am wondering if a Firefox extension couldn’t be used to test out some of these features. Instead of a tag, I was thinking of a to some sort of manifest file. The manifest could specify how to modify the Firefox UI to be more site specific as well as setup desktop shortcuts. Of course, the user should be in full control of allowing any of this to happen. Preferences would control a site’s ability to “appify” itself and the user should be able to revert back to the “non-appified” version of the site.

Site specific browsers could be the Next Big Thing with Ajax applications appearing faster than rabbits. Seems like TechCrunch has 2 or 3 new web applications popping up everyday. Better desktop integration would definitely enhance the user experience.