Video: Charles McCathieNevile — Opera Dragonfly

Video published 2009-05-13.

• Download iPhone/iPod-compatible video file (320x240, .m4v)
• Slides

Transcript:

Charles McCathieNevile: Talk about Dragonfly, which is Opera's developer tools stuff. I'm clearly the ideal person to talk about it, because I'm not the developer of it. I'm not even one of Opera's developers, I'm Head of Standards, so I mostly do middle management stuff, but I'm what you get. In the presentation there's a bunch of other stuff that was hanging around in my slides, so if you want to play with different stuff, there's just new toys.

But the basic idea — I don't know, has anyone used Dragonfly in particular? People use Firebug, right? Or the equivalent in WebKit, or whatever. Dragonfly is the same beastie. The big difference is what I'll talk about, which is the Scope API, and what that lets us do.

So Dragonfly — why do you have a debugging tool? So you can debug stuff. [laughs] It's kind of obvious. And I guess you know big chunks of Opera's markets — some places more, some places less, are mobile, and similar kinds of weird devices — so, being able to debug stuff on a phone. I don't know if anyone's ever run Firebug on a phone, or thought about it, but if you want a nightmare go and dream about it tonight, and tell me what it looks like in the morning. We wanted to make something a bit different.

So we built this thing called Dragonfly. It's a web application; a big pile of Javascript, a little bit of CSS, a few ping images, and some XML and stuff. And it runs as a widget, so if you have an idea about what widgets mean in the Opera sense, kind of like a Konfabulator widget, or Google gadget. It's the same thing.

It has a couple of handy things: it has a live updating feature, so it can go and check if there's another version, and will download a new piece of code, fix itself up, give you the later version. It's open source — our goal is to actually have an open source project with a BSD license, so other people can go and play with it, mess around and do stuff. And it's been around... We shipped, I think, the first version in '95. It's been around awhile. It's in alpha — it seems to spend most of its life in alpha. One day we'll get a beta. When it's absolutely perfect we'll call it a gamma, or something. We might actually ship a release, but we have lots of things that we still want to do.

And what does it do? Developer stuff. You can edit the DOM, you can export the DOM, you can poke through it, you can do script debugging, you can put in break points, you can do command line stuff. I'll do the little talk bit, and then I'll open it up if it doesn't crash, because I'm running the latest version of the browser, then we'll play with it a bit. But you've got a command line, so you can actually step through stuff, and you've got a few commands so you can look at the objects you've got. You can play with styles, you can change the styles live, you can see computed styles, and style rules. You can see SVG errors, you can do network traffic, see what's going on with Mail, because you have Mail in the desktop version at least, and dig into all that stuff. So it does pretty much what you would expect it, or want it, to do.

But it has this kind of complicated structure where it works through Scope. Scope is an inspection API — it's like a browser colonoscopy device or something; you can just look inside and see what's happening with the applications. And you typically have your Dragonfly running, and it hooks up — there's a little tiny proxy layer to hook up through Scope, into the browser. So you have your browser, you open Dragonfly. I actually have it running here. Some widgets. This is Dragonfly — this is the beastie. And it's the sort of thing you expect.

So you just run it in your browser, and you start poking around with what you've got. The nice bit is, because you have the separation, you can actually run two instances. So if I turn on another version of Opera, I can start debugging something that I know will crash my browser, and that's why I'm debugging it. And I can run Dragonfly here, and connect it up to the version that I know is going to crash at about the point that everything goes screwy. But at the point I don't actually lose Dragonfly, so I get to keep the debugger itself running. And that's kind of nice — it's a little bit more helpful in figuring out what's going on.

And equally, I can run it across a network. So what I didn't do today is charge my phone and actually make it work, and I haven't got a network here, so I can't hook it up. But I could have one of my slides, which is the simple example.

So what I can, here, open up my network. Right now Opera is waiting for a connection, and I just say: alright. That means the first smart person to find my laptop can actually go in and edit my slides now, and make something cool for me to talk about. Or change the presentation.

But the Scope thing we think is actually pretty valuable, and there's a bunch of benefits. You don't crash your debugging tool when whatever you're debugging crashes your browser, which is the worst case scenario, but it happens. Equally, I can actually turn on my phone and go into the debugging thing and just, say, open up some port, and allow a Dragonfly to connect to this phone. So I can debug applications running live on the phone, instead of in some kind of emulator, or live on other kinds of devices. The big deal: Scope runs in what we call Core 2.1 or above.

And that reminds me — David wanted to tell everybody something about Opera. In Opera 10, we've started messing with the UA string. But we call 10, 9.8, because we discovered that a whole lot of scripts that do browser sniffing will die if they run into a two digit number for the normal version number. Which is a bit sad, but this is the way things are. But you have normal stuff: Presto and then a number. Presto is the core engine, the rendering engine. And now the all new Operas, whether it's on the forward pick up, or on a Linux machine, or Windows '95, or whatever device you run it on — even on a shiny new MacBook — they'll have that Presto string, and that's the bit that tells you what version of the Opera engine you've got. You want something bigger than 2.1 to know that the system will work.

And then you can actually sit down and test different browser versions, as well. If you've got Opera 9.5, and Opera 10, and Opera 11, and Opera 16, and you actually want to run content or applications in more than one version of a browser, then you open up all the old ones and you have one Dragonfly running. You just connect to all of them in turn, and see what they're doing. Makes life easier.

The other thing you can potentially do is help your Mum. I don't know about you guys, but my Mum thinks that every time she has a problem she should ring me, so she does. And she lives in Australia, and says: this Jigsaw site doesn't work. I'm like: right. [laughs] I could ask her what version of the browser she's using, and do all the testing, but it turns out that if I could say: tell you what, Mum, let me connect up and just find out what you're doing, that would make my life 20 times easier. Because she says: I'm running the latest version. And she can tell it's the latest, because she updated it one day, like two years ago.

Why do it as a widget, which was the other thing, because we could have done it the typical way we do stuff in Opera, which is to actually build stuff into the browser. So we don't do the Firefox extension model, we write C++ code. And we do that because it runs real quick, and because it means that when the program has actually revved the browser up, change the version or change something, is part of the code they have to look at, and they get warnings out of the compiler. So that would be the normal way we would do some functionality.

Web code — JavaScript, and HTML stuff — is easier for people. So building an open source project makes it easier. We could have taken this piece and made it open source as well. We decided we'd actually run it all as this script. It produces a few problems. We do things like having the… I'll go back to Dragonfly. There is nothing interesting in this presentation, so let's find, I don't know, what am I running? Pick a widget. "This window has no runtime". Right, let me go back to a normal-ish page.

Audience member: [inaudible]

Charles: Ah yeah, that's true. Let me turn the remote debugger off, and debug my own stuff.

So this is what it looks like. I can dig through the script and see what they are. There's your command line, so I can just type stuff, and poke inside the object. I can step through and put in break points, check out the network. There's no network in this, because it's a widget. Find errors, blah blah blah.

But when I go to the script, for example, getting this kind of thing to do a nice source is really straightforward even with Javascript and CSS. You take the text and you colour it, and print it back. But when you get 20 kilobytes of Javascript, and you want to go through checking the source and actually colouring all of that, this slows down, because you've got to go through massive amounts of text, parsing it, and colouring it, and putting the CSS. So we did some weird stuff inside. If you go and dig inside the source, you'll find that, for example, this stuff is not actually laid out all in one go. When we do the source code colouring, we take 50 lines — and we take the 50 lines the user is going to look at, and parse those. So wherever you get to the start of the thing, we just parse that and colour it. And that's just to make it quick; that's just so that it performs like a normal application. Because if you do it on a slow machine, and you don't do it like that — you parse out your 20,000 lines — then you see it slow right down, people sitting there waiting half a minute to see the script, and they think the thing is broken. So we had odd drawbacks.

So I can go inside — this is a widget which is running, it's actually a game. And I can go and find the SVG, the main document. This is the game. And the main thing is just HTML page, and then you have an iframe that points into this, and because it's a widget, it's handled a little bit differently from normal web pages. It's installed on the machine. So I can go and find the piece of code that runs the widget, and I can do all the things that I would normally do with it. Open up the SVG — last time I tried this, the whole thing crashed. But I got a different build off the machine at lunchtime, and it doesn't crash anymore. This is good.

So the only other stuff I wanted to talk about: first we should standardize the console. And the developer tools are critical for all browsers, because developers need to figure out how their stuff works, but we'd actually like to standardize the Scope API. We need to stabilize it a bit, because at the moment it shifts around and jumps. So if you get a Dragonfly on a new version, and you try to hook it up to a 9.6 version, the first thing it does is say: wait a minute, the new Dragonfly uses the new Scope, and it goes and downloads a different version that has the hooks for an earlier version of Scope. The benefit of having the auto-update is that it can do that, and instead of having all of this stuff all the time, you just carry the things you're likely to use. But you could plug it all in.

But if we had a standardized Scope API, then it would be pretty easy to go to Firefox, or WebKit, or even IE, and say: figure out how to open this API, and get this information out of the browser. Because it's the sort of stuff that accessibility tools already use. Building the API, in terms of connecting into the browser, is not rocket science. Because these things exist: Firebug has access into the browser, screen readers have access into stuff that goes on in the browser, everyone has a tool.

And that would just allow us to have a dev environment, that same thing that you can do now in Opera, where you open Opera and debug stuff on your game console, or your phone, or whatever. You would open whatever your preferred development environment is, whether it's Dragonfly or Firebug, or something else, or you want to lash up your own. And you would do the same testing across all the different browsers from your own working environment. So it's really just about making the job of testing, and the job of doing that development stuff that is currently misery, often, slightly less miserable. Which would make good development go faster. If you let people use the tools they like, then they tend to be more efficient.

And really, that's as much as I want to say. We can poke into the tool — you guys know what these tools are for, more or less. The one I didn't bother putting there, because I'm an idiot, is http://dragonfly.opera.com, but that's where you find it.

Bugs is something that you should all remember, and file bugs, please. We do respond to bug reports, but if we don't get them, we don't know. And we want to talk to you guys, and make sure things work.

These are our email addresses. This is David — he's moderately well known around Yahoo!. His job is the Chief Web Opener, which is a group we have who actually work on compatibility with applications that are out there, and that includes various Yahoo! applications that, from time to time, stop working in Opera. We want to figure out why, and we want to help Yahoo!, or whoever it is, to actually fix them and make them work. So he's the guy you talk to about that.

As I said, there's more, there's other stuff — the other stuff in this slide set is video, and CSS 3, and Canvas, toys, and fun, which you can poke into if you want.