Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software Technology

Opera Open Sources Dragonfly 78

netux writes to mention that Opera has released Dragonfly, their answer to Firebug, as an open source project under the BSD license. The release features a complete architectural overhaul using a modern version of the Scope Protocol (STP-1), a Mercurial repository on BitBucket, and a Wiki to get the ball rolling. "This is Opera’s first full open source project, so there will be a learning curve. We ask you to bear with us while we get everything up and running and policies in place. Coming from a closed source background there are some hurdles to overcome, such as the current bug tracking system being on a closed server. We hope to migrate to an open bug tracking system as the project gets on its feet."
This discussion has been archived. No new comments can be posted.

Opera Open Sources Dragonfly

Comments Filter:
  • by Anonymous Coward on Friday February 19, 2010 @11:42AM (#31199798)

    This just goes to show you how out of touch those in the web community are with the greater open source community. I mean, the Firefox developers fucked up twice, with the second time being when they outright stole the name of the Firebird [firebirdsql.org] RDBMS.

  • by zxSpectrum ( 129457 ) on Friday February 19, 2010 @11:45AM (#31199846) Homepage Journal

    Here:

    Since the inception of Opera Dragonfly, we planned for it to become an open source project. It has always been released under an open source BSD licence, but the source repositories were on Opera servers. Starting today, Opera Dragonfly is a fully open source project, hosted on BitBucket. Since the previous version of Opera Dragonfly, a lot of work has gone on behind the scenes replacing the existing architecture with a modern version of the Scope Protocol STP-1. Opera Dragonfly has been rewritten to use this faster and more efficient version of Scope. Now that we believe that the underlying protocol is stable and performant, and a public desktop build has been released with this included, it is time to put Opera Dragonfly on a public Mercurial repository.

    If you have a Mercurial client you can visit the Opera Dragonfly STP-1 repository and check out the source code. We have provided initial documentation in the Wiki to get you started. This is Operas first full open source project, so there will be a learning curve. We ask you to bear with us while we get everything up and running and policies in place. Coming from a closed source background there are some hurdles to overcome, such as the current bug tracking system being on a closed server. We hope to migrate to an open bug tracking system as the project gets on its feet.

    As well as the current and previous versions of the Opera Dragonfly source code, we have released a couple of tools to help with Opera Dragonfly development. The first is Dragonkeeper. This is a standalone proxy, which translates STP (Scope Transport Protocol) to HTTP. This can also be useful for remote debugging. The second tool is Hob. Hob is a utility to create code from Protocol Buffer descriptions. Protocol Buffers are one of the formats Scope STP-1 supports along with JSON and XML.

    The focus of the current release of Opera Dragonfly was stability and performance. As such you will not see a great deal of new features. We believe it was invaluable to build a strong foundation, so we can advance faster, with less issues in the future. Two new features you may notice since the previous desktop release are a new element highlight (first introduced in Opera Mobile), and a colour picker utility. The highlight has been optimised since the mobile release, and supports visualising the metrics of an element on the page, and multiple element selection. The colour picker is still in early development. It allows for the magnification and selection of colours from the Web page. The value of the colour is displayed in both HSL, RGB and hexadecimal formats. Work has also began behind the scenes to take advantage of HTML5 Web Storage to store users settings and preferences. This will eventually allow the application to be greatly customisable, and to remember layout and settings from a previous session. One of the biggest usability issues has also been solved, with inspect element being available from the Web page context menu. This reduces the steps needed to start debugging a Web page.

    The current focus for the Scope protocol is improving the JavaScript debugger. This work is nearing completion on the Scope side, and will provide functionality such as the Firebug Console API.

    We hope you enjoy this version of Opera Dragonfly, and that some of you will be inspired enough to help with the Opera Dragonfly project. If you like a challenge, this is a great place to start. Visit the Opera Dragonfly repository to find out more information.

  • by shutdown -p now ( 807394 ) on Friday February 19, 2010 @12:13PM (#31200210) Journal

    Dragonfly? Well, guess the FreeBSD fork by Matt Dillon (not the actor) that was named Dragonfly will now have to be referred to as Dragonfly BSD to avoid confusion.

    It already was for as long as I can remember.

    It boggles my mind why people pick project names that are not more original. You're basically shooting yourself in the foot as far as domain registration, marketability and search rankings are concerned.

    When introduced, Opera Dragonfly was not a separate product - more like a feature in Opera. It's something that comes out of the box, so it doesn't need any particular marketability apart from Opera itself.

  • by commodore64_love ( 1445365 ) on Friday February 19, 2010 @12:26PM (#31200426) Journal

    This is the second time in less than 24 hours you pushed Chrome. Hmmm. (shrug)

    Anyway I've heard that Opera is actually the #1 browser in Eastern Europe, Russia, and China. So if you live in those regions, it makes logical sense to use Opera as your development tool and target.

  • by Anonymous Coward on Friday February 19, 2010 @12:27PM (#31200434)

    After googling it (as TFA is slashdotted for me), the relevant information that is missing from the headline//blurb is:
     

    Opera Dragonfly is a cross device, cross platform debugging environment for the Opera browser

  • by Anonymous Coward on Friday February 19, 2010 @01:00PM (#31200880)

    Opera has released Dragonfly, their answer to Firebug

    I propose a new betting pool: How long until an Opera fanatic claims Opera developed Dragonfly first, and Firebug is just a ripoff.

    Actually before Dragonfly opera had a different set of developer tools, called Developer Console

    Opera Developer Console

    Opera now includes a developer console that can be added into the browser with many new features. The developer console includes new tools including DOM inspector, JavaScript inspector, CSS editor and HTTP header inspector.

    Which were released 15 Nov, 2006, and on my research that is a year or so before firefox.

    Link: http://dev.opera.com/tools/

  • by styrotech ( 136124 ) on Friday February 19, 2010 @05:08PM (#31204154)

    In the same way, using a debug tool to determine whether a webpage is working correctly is a crapshoot. Should I go with the best browser (Opera)? How about the most wide-spread browser (IE)? Or should I target the browser most likely to gain the most marketshare (Webkit, aka Chrome and Safari)? Or what about the old stalwart (Netscape)?

    They all purport to do the same thing, provide great debugging tools. But how can I trust them when they work so differently from each other and have such different levels of standards support?

    I think you're missing the point. These tools aren't entirely for debugging as such - there are validators for finding the actual bugs in your own HTML/CSS.

    These tools are more for inspecting how that particular browser is working with and interpreting your code, letting you manipulate that on the fly, and identifying the exact parts of your (hopefully already valid) code that the browser is having trouble with rendering or running. They need to work inside the browser as each browser has its own set of bugs or quirks you need to work around and/or learn to avoid in the first place.

    Whether a web page is working properly or not to an end user can't really be judged from outside that users browser - they are using their web browsers interpretation of the web page rather than some absolute objective measure.

"A car is just a big purse on wheels." -- Johanna Reynolds

Working...