Kodewerx

For those of you unaware, I have been floundering about in XULRunner application development for quite some time. Recently, (within the past few months) an official Mozilla project called "FizzyPop" has been released, which greatly reduces the stress of starting a new XULRunner app. In literally 5 minutes, you can go from nothing to Hello World. This is a great accomplishment, considering the battles I had to fight getting my very first Hello World running on this framework.

In any case, if you're an application developer, and you don't currently have a means of building applications supporting the major operating systems (Windows, Mac OS X, and Linux) then you should probably look into XULRunner. Or, at the very least, hack your projects until they can be used on all three platforms! The old saying "two out of three ain't bad" does not apply here. It's all or nothing!

And if you have no idea what the hell I am blabbering about, you should just read these articles to educate yourself. Trust me, it's good info.

I've tried to write these articles with "real world" semantics. That means, it's not overly officiated or pompous, but uses casual language like you might in your everyday speech. This, I think, will help ease readers into the strange new world of developing real desktop applications with web technologies like JavaScript. (Yeah, seriously ... that JavaScript ... get to reading!)

So far, I've written two parts. The first is a gentle introduction to the what's and why's, as well as a little bit of history. Part 2 guides you through a [real quick] Hello World application, and presents several resources for learning how to use the framework to actually do things. I imagine a third part could come in handy. Perhaps it will go over a little bit of JavaScript, and building an installer.

A Brief Introduction To XULRunner: Part 1
A Brief Introduction To XULRunner: Part 2

_________________
I have to return some video tapes.

Feed me a stray cat.

My only trouble with XUL at this time is the same trouble I have with CSS; that is, the problems associated with HTML+CSS translate almost perfectly to XUL+CSS. It's still a pain in the ass to make your CSS pixel-perfect. Unless you are some form of CSS demigod who knows all of the ins-and-outs of both CSS and the HTML/XUL box models, you're going to spend a good deal of time making your application look "purdee".

My first example is Firefox's "tabbrowser" widget. This XUL element is not included in XULRunner, since it is specific to Firefox. So, if you want "closable tabs", you're going to have to make them yourself. When I attempted to do this, I was taking advantage of the very box model which caused me so much grief; you can put almost any XUL element inside almost any other element, a lot like HTML. But placing a button inside a tab element meant that the button couldn't be clicked, nor would it receive any other events; even the CSS :hover pseudo-element wasn't working.

A simple work-around is placing the button outside of the tab, and then using nasty CSS hacks to position the button inside it, while making some room for the button and moving the tabs closer together. It's not "purdee" XUL or CSS, but it can be made to work the way you would expect. C'est la vie.

Now, while closable tabs written this way work great for mouse navigation, they explode under keyboard navigation circumstances. Not to mention having buttons and tabs mixed inside a "tabs" element screws up XUL's automatic selection of tabpanels as you click through your tabs. For these reasons (and others) it is probably best to re-implement your tabs with styled box elements and a deck, instead of basing them on XUL tabs.

And so, I did exactly this. I am mainly a Mac OS X user (as many of you know, by now) so I decided to style mine based on Firefox 3.5's tabbrowser under Mac OS X. the styling was pretty easy. I used background images from the Open Komodo Mac skin (SVN repository; also useful for example XUL and XBL!) and wrote some XBL magic to bring it all together. Speaking of the skin, I decided not to use all of the images from Open Komodo. Instead, I used CSS3 for the rounded borders and drop shadow.

(A slight tangent, if I may: My first research into XBL landed me squarely in the XBL 2.0 Primer. While this is a wonderful resource for learning XBL 2.0, Mozilla (specifically XULRunner) only supports XBL 1.0, which is vastly different, and in many ways, more cumbersome to work with. I'm already spoiled by the idea that you can include binding-global scoped JavaScript in XBL 2.0; in version 1, you can only use scripts in the per-element scope. So writing reusable functions in version 1 requires methods on your top-level elements which children elements must bubble up the DOM tree to access...)

In this initial closable tabs implementation, I have everything working with the exception of keyboard navigation (CTRL-Tab: forward one tab, CTRL-Shift-Tab: backward one tab, CTRL-W: close tab, etc. Basically just keyboard shortcuts to managing your tabs). There is also some funkiness in the way I'm handling the close button. The event phases aren't working out so well for me, so I've settled [temporarily] on using the mousedown event for the close-tab-buttons. This just means the tab closes immediately when you begin clicking on the close button, rather than waiting until you've released your mouse. The reason for this in the first place is that clicking on a close button will first switch to that tab, then close it. This breaks my idea that you should be able to close a tab without switching away from the one you are currently viewing; if I didn't want that, I wouldn't have gone to so much trouble giving each tab its own close button!

After those problems are solved, the only thing remaining is allowing scripts to capture tab-close-requests. Useful (for example) if you are working on something in a tab that hasn't yet been saved; the application should ask to save before allowing the tab to close. And those are the only problems I can think of. (Not including missing features, like a right-click context menu, or the linkedpanel attribute.)

With that, here's a screenshot (tab 1 selected, tab 3 close button hovered):


I briefly worked on a Windows theme, as well. It was just slightly modified to include the red "x" close button from the Firefox tabbrowser. It was kind of nice looking, but it really didn't "fit in" ... which is the point to theming XUL, in my opinion; make it look native first ... leave it to the users to make it strange but sexy.

If anyone is interested in the XUL/CSS/XBL for this sample project, I'll post it here.

_________________
I have to return some video tapes.

Feed me a stray cat.

What exactly is this sample project of yours for?

_________________

Closable tabs. Pretty much just what I explained above. It's a set of widgets to implement independently closable tabs in XUL. (See screenshot.)

XUL makes UI development pretty easy. With exception of creating new widgets, (good learning experience, though). Since it's difficult [impossible?] to find information on getting closable tabs into a XULRunner application, I had to reinvent the wheel here. Uploading it might be nice, since it could save someone the trouble. I'll be releasing these under a Mozilla-style tri-license, so it should be usable for just about any project.


I also hacked together a quick and painless sidebar widget and companion splitter. The style mimics Finder/iTunes. The sidebar can be placed on the left or the right of content (or even in the middle, with content on either side!) and still look nice. This is done by giving the splitter a different class for the left and right sides. Here's a screenshot of the application with the sidebar added. I chose to place the tabs above the sidebar, instead of attaching them directly to the content. It seems odd at first, but then you realize how much it maximizes screen real estate. (The close button is not yet implemented.)

Anyway, I'm just building some reusable XUL/XBL widgets (and a Mac OS X theme ... will be theming for other OSes later). That's this sample project of mine. It will be good resources for the tutorial, if nothing else. Eventually, I'll move on to some application logic for a real program! Hooray! (Can't say just yet what this real program will be. It would ruin my motivation.)

I would like to get some people interested in application development with XULRunner. (*cough*Viper187*cough*cough*) So that we can have some truly portable applications around here. And if it's just a fad that fails to take hold, fuchas. At least I'm doing my part...

_________________
I have to return some video tapes.

Feed me a stray cat.

Update for "XUL Closable Tabs":
* Close button event propagation works, using the same element detection as Open Komodo.
* Added "closing" event which can be handled per tab. The "closing" event fires before the tab is closed, and can be prevented simply with event.preventDefault(). The tab number which fired the event is provided in event.detail.
* Now tri-licensed, ready for its eventual release.

I'm going to work on the Windows theme (at the least) before I release anything. I also want to fix keyboard navigation. Both of these will require some preprocessing, which means I'll want to setup a simple build system. (Build system implies packaging, so I can also finish part 2 of the tutorial, which kind of dropped off there.)

Why preprocessing? Well, it seems the only way to get your default theme to look OS-native on multiple platforms is to choose the correct [platform-specific] CSS/images/etc. and shove them into the /skins/ directory; which is best done at build time. I don't think default themes can be loaded automagically. And similar for keyboard navigation, where you might need platform-specific keyboard shortcuts.

-- Although, there might be some JavaScript voodoo that can do all of that. I just don't know how to make that kind of voodoo work.

_________________
I have to return some video tapes.

Feed me a stray cat.

I didn't realize that was your project. I thought it was merely a component for it.

I suppose my intended question remains; what plans do you have for this widget? What top secret application are you going to drape the interface of with these components?

And more importantly, how is your plan to get us onto XUL any good if it involves scaring us away with anecdotes about the difficulty in creating widgets and the lack of them that makes the creation of them desirable in the first place?

Edit: Funny story; I just got done complaining about my loathing for cases of "Reinventing the Wheel" to a fellow staff member of another forum.

_________________

1) The project I'm discussing here is "A brief introduction to XULRunner" which is basically just that; an intro. It's not about a full-blown app written for the technology.

2) It's a secret to everybody.

3) XUL has plenty of widgets that are perfectly usable out-of-the-box. Just like HTML has plenty of structural elements perfectly usable as-is. Also like HTML, your XUL going to be mostly making big widgets by combining a bunch of smaller ones. Thus, the only reason to use XBL is if you want to extend pre-existing widgets (of which there are many!) or build completely new ones (which you might like to do, anyway!)

It's only "difficult" because it's weird. It's weird because it's different. And it's different in that you are describing logic and transformations in XML (that's what XBL really is). But it's not unusable or anything; you just poke around with it for a bit, and soon you have a widget doing something totally new and fantastic. And then you can put as many of them on your UI as you want, because they are reusable. As an added benefit, it cleans up your XUL.

As for why I'm bothering to do this... I like it. I really like XULRunner. And if throwing out some cool widget implementations will spark some interest in this technology, I'm all for it.

That, and I can make a wheel a hundred times better than anyone else. So there.

_________________
I have to return some video tapes.

Feed me a stray cat.

So what exactly are you trying to make in XUL?

This interests me, I'll probably learn it over the next few months. Why do I say "in the next few months"? I'm real busy trying to get through my Senior year of High School. I have a Computer Engineering class at school, so I'm overflowed with work.

_________________

WWDD? - What Would Dale Do?

_________________
I have to return some video tapes.

Feed me a stray cat.

Even you?

Come now, give us a hint.

_________________

Ah, the "I'll make it look like my favourite theme, screw system settings" design anti-pattern. That's a fun one.

What is this about hacking together widgets anyway? You're having to actually code your own widgets?

People, if you want a simple cross-platform UI, it's GTK. If you want it even simpler (and totally customizable), do the GUI code in Lua using LuaGnome. It's so simple and does just about everything you need, on all major platforms. Check it:
Beautiful.
Code has no relation to Microsoft Xbox.

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

I must be missing something. Or maybe you are? Have you ever used OS X?

Safari 4:


Firefox is not so different as you make it out to be.


Yep. I don't know of any UI toolkits or widget sets that natively support the kind of widgets I need. But, you can build them in just about anything. (Some examples: Hex editor widget [that doesn't suck], disassembler widget [that doesn't suck; textbox != disassembler], tile editor widget [with support for (S)NES, Genesis, GB*, DS*, etc...], and of course ... Firefox-style god damned tabs. GTK+ can be coerced into doing it (look at Geany, for example) but then again, XULRunner can be coerced into it even easier.


I'm pretty sure you scoffed when I suggested GTK+ to you, in the first place. My, my, how things change. Anyway, GTK+ is fine... If you don't mind the application looking anything near-native on Mac OS X! (To be fair, the gtk-osx.org guys (Imendio) have done a fine job on the port. But the OS X theme engine just isn't there yet. I spent a great deal of time [some months ago] porting Geany to OS X. It ran kind of poorly on my little 1.5GHz PowerPC G4, but otherwise wasn't a bad experience. It just didn't look or feel right.)

That said, I'll see your LuaGnome and raise you my XUL:
Now, this is all personal preference, but I find that to be beautiful. Creating UI elements in code is awful. (It just doesn't have the same semantics as a structural definition language like XML.) If I were using GTK+, GLADE would definitely be a standard part of my development arsenal.

_________________
I have to return some video tapes.

Feed me a stray cat.

Did you not mean to say that because you use OSX, you're going to style your interface after OSX? Instead of letting the system style it how the user has specified? My Firefox tabs don't look like that; they look like the rest of my applications.

I maintain that GTK sucks at integrating into a Windows environment; it looks hideously awkward and out of place and doesn't obey input/interface standards that are universal to literally everything else in the system. At this point I hardly care, because with Vista and 7, now everything looks hideously awkward and out of place.
The key difference is I leave the behaviour and appearance up to the system settings, and sadly GTK does a lousy job on Windows of making its settings match its surroundings. Editing the global GTK configuration can help to an extent. Whereas an application that overrides user configuration to force a certain style is just going to be annoying and ugly. (It's also great fun when you have a dark theme, and they override text colour but not background colour or vice-versa, leaving you with white text on a white background.)

_________________
143
HyperNova Software is now live (but may take a few tries to load) currently down; check out my PSP/DS/Game Boy/Windows/Linux homebrew, ROM hacks, and Gameshark codes!

There are only two visual system settings by default for OS X, which is really just to change the main color from blue to gray. And there are at least three native tab styles that I know of (not including the different orientations of each, and also not including Safari, Camino, or AdiumX; which are all native Cocoa apps, by the way, and all have slightly different closable tab styles ... And they always look the same, no matter what brand-new ultra-different theme you install. Maybe they are trying to say something?)

The system closable tabs look similar to what Firefox provides, or at least, closer to Firefox than the others... (See "Terminal.app" below.) The main differences are, system closable tabs are more square, and have a lighter color. By default, XULRunner only gives you one option for tab styles: "new" (since OS X 10.4) aqua tabs. The "old" (pre-10.4) aqua tabs were just recently replaced, and the closable tab style cannot be used directly (but can be very closely approximated using CSS!)

Here's what the tabs look like in Terminal.app (a part of the OS X base install):


Tabs in Finder.app (also a part of the OS X base, and in fact, an integral part) iTunes also uses this style in its toolbar:


"New style" (Since OS X 10.4) aqua tabs in System Preferences:


Which one do you prefer?

FWIW, Safari (and Firefox, and iTunes, and who knows what else) also adds more tab styles to OS X. For example, the tab widget shown on the preferences window. This style of tab contains a prominent image ... sometimes including a dark gray border (with gradient) on each side.


So the question is not "is this theme native?" but rather, "does this theme fit in?"

Now you are going to throw in some rhetoric about how complicated it is. And it isn't, really. The "Finder-style" tabs you see in toolbars; the Terminal-style tabs you see in dedicated tab bars; the System Preferences-style tabs you see in group boxes...

In closing, I could make my tabs look closer to the dedicated tab bar style. But personally, I think the darker Firefox theme is even better than that. The main thing I want to change at this point is putting the close button on the left.

_________________
I have to return some video tapes.

Feed me a stray cat.

Life has not been good to me.

Even still, I've managed to continue chugging away at my XUL mini-project(s). I got maximum width and label cropping working on my closable tabs implementation, and found a sane way to do collapsible bodies in my sidebar. Over the next few days, I am hoping to work on a canvas-based widget with multiple layers and super-fast pixel drawing. We'll see about that.

_________________
I have to return some video tapes.

Feed me a stray cat.

I keep coming back to this idea, after bouncing around through all the others, I haven't updated the articles in a while, which is not good. The Mozilla platform moves so fast, and sometimes, not fast enough!

For example, the WebGL (canvas 3D) support in Firefox 4 nightly builds is great, but CSS 3D Transformations look far more suited to beginners in 3D graphics. Not to mention, more applicable to websites than canvas.

_________________
I have to return some video tapes.

Feed me a stray cat.