Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

XULRunner Developer Preview Release Available 122

Posted by Hemos from the build-it-and-they-might-use-it dept.
TeachingMachines writes "A stable developer preview release of XULRunner 1.8.0.1 is now available. Based on the Firefox 1.5.0.1 codebase, it is available for Windows, Mac OS X, and Linux. From the Mozilla Developer Center (beta): "XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird. It will provide mechanisms for installing, upgrading, and uninstalling these applications. XULRunner will also provide libxul, a solution which allows the embedding of Mozilla technologies in other projects and products." Help with programming with XUL and its related technologies can be found at XULPlanet. Beginning programmers will benefit especially from the XUL Tutorial. Also check out the XUL Element Reference to get an idea of what's available. "


A couple of other resources are worth mentioning. First, there is the XUL Programmer's Reference Manual which covers interface elements for XUL version 1.0. "Rapid Application Development with Mozilla" is available for download at Bruce Perens' Open Source Series page. If you get the book, make sure to check out the errata. Unfortunately, the author Nigel McFarlane has passed away, so this is likely the final version. One final reference, "Creating Applications with Mozilla," is available here.

For those individuals who are looking for an extremely powerful application framework that is relatively easy to use, Mozilla is definitely worth a look.
This discussion has been archived. No new comments can be posted.

XULRunner Developer Preview Release Available More

XULRunner Developer Preview Release Available

Comments Filter:

  • Also worth mentioning (Score:3, Informative)

    by Anonymous Coward on Monday February 20, 2006 @09:33AM (#14760478)
    PyXPCOM [activestate.com], for Python-scriptable XUL applications, should be available shortly.
  • The platformisation of a web browser's interface libraries.

    Good work - a true cross-platform API with full interface features and themability. Windows, Linux, Mac OS X, Solaris, ...

    I should have a look at it someday, it might be an interesting platform for writing mediumly complex GUI applications. How is the development tool environment though? Whilst I like a terminal and build scripts, not everyone does, and mass uptake would be restricted greatly if there was no Eclipse/etc plugin.

    As a platform, or part
    • I should have a look at it someday, it might be an interesting platform for writing mediumly complex GUI applications. How is the development tool environment though? Whilst I like a terminal and build scripts, not everyone does, and mass uptake would be restricted greatly if there was no Eclipse/etc plugin.

      You don't build it it. It is all Javascript and XML. So whatever tools you would use for that. What's an Eclipse plugin going to give you beyond syntax highlighting? What more would you need? I hardly se
    • Using Eclipse for Mozilla develpment http://developer.mozilla.org/en/docs/Eclipse [mozilla.org]

  • XULRunner future. (Score:4, Informative)

    by Tei ( 520358 ) on Monday February 20, 2006 @09:47AM (#14760532) Journal
    Even if Mozilla evolve to XForms base, will be posible to continue XULRunner as a separate project. So XUL is here to stay.

    XUL is very good RAD tool. Much.. much much better than HTML. Because with HTML you sould care about styles and other miscelanea problemas, and becasue with HTML you badly emulate OS widgets, with XUL you use OS widgets.

    Also good bonuses are easy to code with javascript, and the integration with XML (indeed!).

    • Re:XULRunner future. (Score:5, Interesting)

      by ObsessiveMathsFreak ( 773371 ) <obsessivemathsfreak.eircom@net> on Monday February 20, 2006 @10:31AM (#14760736) Homepage Journal
      XUL is very good RAD tool. Much.. much much better than HTML.

      I would classify XUL as a good GUI development tool. It's rapidity is quickly lost if one delves into any XPCOM backends.

      However, for simple, client side, frontend GUI operations, XUL is a very, very useful tool. It gives you the ability of DHTML in a way that isn't a hack.

      Here's a good example [hevanet.com] of XUL's layout capabilities. IN terms of pure layout, there not really that much here that is different from HTML. However when you get dynamic [faser.net], XUL really shines. People go on about AJAX, but XUL offers a huge amount of potential.

      Personally, I feels XUL's only achilles heel is javascript. That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

      As a GUI application development tool, I would expect XUL and XAML to replace older methods such as GTK and *shudder* Windows "Visual" code. It's faster, cleaner, makes more sense, and you don't need 300 lines of code plus libraries to draw a hello world window.

      • Personally, I feels XUL's only achilles heel is javascript.

        You're in luck :-) Python bindings are coming to XUL. [mozillazine.org]

        That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

        Mozilla is working with ECMA on that too. See Brendan's comments about ECMAScript 4/JavaScript 2.

      • Personally, I feels XUL's only achilles heel is javascript.

        Be honest with yourself here, how much of your experience with javascript involves those craptacular "this is how you do a rollover" tutorials? There are a lot of examples of people trying to use it like a real language, and when treated that way it is much nicer to work with.

      • However when you get dynamic, XUL really shines. People go on about AJAX, but XUL offers a huge amount of potential.

        The MAB is the only non-Mozilla.org XUL-based tool anyone seems to mention. Are there many others? I also think it has great potential from what I've seen, but the lack of applications after all of this time seems odd...

      • However when you get dynamic, XUL really shines.

        How so? There is nothing inherent about xul that makes dynamic document generation easier. In fact, it's the same, using the DOM.

        People go on about AJAX, but XUL offers a huge amount of potential.

        Comparing AJAX to XUL is comparing apples to oranges.

        Personally, I feels XUL's only achilles heel is javascript. That language needs a serious overhawl if anyone is to be able to use it without all that hassle.

        Care to elaborate? What is it about javascr

        • How so? There is nothing inherent about xul that makes dynamic document generation easier. In fact, it's the same, using the DOM.

          XUL, unlike DHTML, is build from the ground up to be dynamic. Working with XUL button tags is a lot handier than essentially hacking HTML input tags to be buttons.

          Comparing AJAX to XUL is comparing apples to oranges.
          Because? XUL is just AJAX with DHTML replaced by something saner.

          Care to elaborate? What is it about javascript that is so bad? What hassle? I find it to be one of the

          • XUL, unlike DHTML, is build from the ground up to be dynamic. Working with XUL button tags is a lot handier than essentially hacking HTML input tags to be buttons.

            Again, care to quantify this? If i want a button in HTML I use the HTML button tag. To handle the click event you either describe onclick as an attribute or add an onclick handler via the DOM. What's the difference?

            The only things i can see making dynamic document generation easier are the stack tag (although only slightly, HTML has layers)

    • XulRunner is what FF2 and TB2 are going to be based on, you'll have 1 XulRunner app and will install FF and Tbird, so XulRunner is here to stay. XForms will also be an extension [mozilla.org] available later.
    • you badly emulate OS widgets, with XUL you use OS widgets.

      Well stated. I wish people who keep trying to create these faux css-based widgets would understand this. Compared to something like XUL, they look, and behave like cheap hacks.

    • XUL is very good RAD tool. Much.. much much better than HTML.

      For me, in order for something to qualify as a tool for rapid development, it must have (at least) the following:

      1. An interpreter, allowing you to experiment with code snippets by typing them and seeing their effect immediately.
      2. A debugger. The importance of this can be minimized by the presence of an interpreter, if the interpreter can access important parts of internal state.

      Does anyone know how these XUL tools stack up along these dimen

  • Oblig. Ghostbusters (Score:5, Funny)

    by shepmaster ( 319234 ) on Monday February 20, 2006 @09:48AM (#14760537) Homepage Journal
    "There is no Dana, only Zuul."

    Or, as the Wikipedia points out:

    "There is no data, only XUL"

  • This is what lost the browser wars (Score:5, Interesting)

    by Bogtha ( 906264 ) on Monday February 20, 2006 @10:03AM (#14760608)

    Back when the browser wars were in full swing and the Netscape source was just released, Netscape was at a huge disadvantage - they were fighting against Internet Explorer, which was bundled on every new desktop. However, they had an ace card - they were the browser of choice for ISPs.

    Back when everybody was on dial-up, the usual way to get on the Internet was to get disks or CDs from ISPs, and run their installer. Typically, that also included Netscape, which was subsequently set to be the default. So while Microsoft had a browser installed by default on every desktop, Netscape was installed over the top of that for most people who signed up for dial-up service.

    Then the Netscape source was released, and Netscape 5 was overdue. There was missing code, so it didn't build. Instead of filling in the bits that were missing, fixing the most prominent bugs, and releasing Netscape 5, practically everything was thrown away and they started again - to build a new platform based on Javascript and XML (and, oh yeah, with a browser I guess). XULRunner is the culmination of that process.

    However, this came at a cost. Throwing everything away and starting again set back the development by a huge amount - it took over four years to go from the public release of Netscape's code to the first release of Mozilla. In the meantime, Microsoft released three new versions of Internet Explorer.

    So what choice did ISPs have? Ship the outdated Netscape 4 to all their new customers? Ship a buggy prerelease Mozilla build to all their new customers? Pay Opera for every new customer? Or just bundle Internet Explorer? Of course they did the latter. The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.

    So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough. But when I think of the stranglehold Internet Explorer has had on the market for so many years, and the pain that has caused me as a web developer, I can't help but think that the price was way, way too high for what is essentially just another cross-platform toolkit. Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

    • So what choice did ISPs have? Ship the outdated Netscape 4 to all their new customers? Ship a buggy prerelease Mozilla build to all their new customers? Pay Opera for every new customer? Or just bundle Internet Explorer? Of course they did the latter.

      OK, you correctly point out the fact that tactics matter more than strategy when we live and die by the quarterly report.

      Now that the strategic investments in good infrastructure pay dividends, is it really necessary to force-feed any closed, OS-centric solutio

      • OK, you correctly point out the fact that tactics matter more than strategy when we live and die by the quarterly report.

        That would almost be as dramatic as you were hoping, if only "tactics" and "strategy" weren't synonyms [reference.com].

        Seriously though, I don't see why you're trying to make this about open and closed source software. Mozilla basically said to Microsoft: "Here, do what you want with our market share while we go do something else for a while." If Redhat stopped all development on their OS for a

    • Re:This is what lost the browser wars (Score:4, Interesting)

      by Anonymous Coward on Monday February 20, 2006 @10:33AM (#14760746)
      So yeah, it's a nice platform, and I'm sure I'll use it in the future. I'm already building one Firefox extension with the same tech. It's decent enough.

      No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

      First off, JavaScript. It doesn't matter if you can use XUL from other languages because parts of it are implemented in JavaScript. JavaScript is a horrible, horrible language. I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure. Lisp/Scheme developers know what a closure is. JavaScript developers probably don't. (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)

      Unfortunately for me, I've never figured out exactly WHAT the closure takes with it. I know of no way to check the current environment to find out what your function accidently wound up keeping. However it does explain the "delete" keyword that had always confused me. Why do you need delete in a GCed language? Well, because without it, you can wind up with pointless variables that were supposed to be local that are accidently kept in a closure!

      Next we have XUL and CSS. XUL isn't native - I think everyone's noticed that by now. Firefox manages to goof up the scrollbars, so they don't match my theme. They also goof up form controls, so that they don't match my theme. Under Windows, certain controls don't act like Windows controls. I'm told the situation is even worse under OS X, but I've yet to convince management that I need an OS X machine to test on.

      Like you said, XUL was a horrible, horrible, horrible mistake. It should never have been made. They should have released Netscape 5 and worked on making a usable browser. Firefox is an interesting tech demo, but it's not something I'd want to support indefinitely. Quite literally the only reason people use Firefox at all over Opera is because it's open source. Were Firefox closed source, Opera would be the clear victor.

      Yes, I know: XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms. Because of XUL, the entire core browser is a giant mess of CSS, JavaScript, XML, and XPCOM. XUL is an interesting concept, but it just fails in implementation. The insane hacks required to make XUL appear to be native are proof enough that it just isn't a smart design.

      People often joke that Emacs is practially an operating system. With the release of XULRunner, Firefox has proved that it literally IS a complete operating environment. It contains all the libraries you need to write full applications. In a sane world, that would be called "bloat".

      • Re:This is what lost the browser wars (Score:5, Informative)

        by Bogtha ( 906264 ) on Monday February 20, 2006 @10:47AM (#14760835)

        No, it's not a nice platform. I can assume you've noticed this based on your "it's decent enough" comment. It's a horrible platform.

        Decent enough for browser plugins. Decent enough if you are building an application that is very closely related to browsing. I wouldn't choose it for building general-purpose applications, no.

        I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure.

        Well no, you might expect it to leave scope, if you assumed Javascript worked like some other language that doesn't support closures, but that's not the way Javascript works, so it's not supposed to leave scope.

        Unfortunately for me, I've never figured out exactly WHAT the closure takes with it.

        Richard Cornford wrote a decent explanation [jibbering.com].

        XUL is supposed to make cross-platform support easier. Instead it ensures that Firefox just feels wrong on all platforms.

        I think that's an implementation detail rather than anything intrinsic to XUL itself. There was an experimental "KaXUL" to implement XUL within KDE and Konqueror a few years back, but I don't think anything came of it. As far as I know, there's nothing stopping a XUL implementation from rendering XUL applications with native widgets, it's just the people who built the only functional implementation chose not to.

      • Re:This is what lost the browser wars (Score:5, Insightful)

        by tetromino ( 807969 ) on Monday February 20, 2006 @11:33AM (#14761102)
        First off, JavaScript. It doesn't matter if you can use XUL from other languages because parts of it are implemented in JavaScript. JavaScript is a horrible, horrible language. I recently discovered that JavaScript supports closures - which helped explain the horrible memory leaks I was experiencing with JavaScript. Stuff that was supposed to leave scope didn't because it wound up in a closure. Lisp/Scheme developers know what a closure is. JavaScript developers probably don't.

        I suspect that I am feeding a troll, but here goes...
        Your comment is much akin to the following:
        • C is a horrible language -- pointers are too hard
        • Java is a horrible language -- I can't wrap my mind around object-oriented programming
        • Perl is a horrible langauge -- regular expressions confuse my poor brain
        • Lisp is a horrible language -- parentheses terrify me
        • Python is a horrible language -- I keep on messing up the indentation


        Bottom line: if you can't be bothered to learn the grammar of the language you are using -- hell, if you don't find learning new languages and grammatical concepts positively exciting -- perhaps software development is really not for you. You might want to look into becoming a manager.
        • That was a typical slashdot substance-free reply.

          If you look at XUL from a competitive standpoint, it maps most closely against Java/Swing, where one generally does not have to be overly concerned with object lifecycles and 'native objects' and memory leaks (not that you can completely ignore it, but in general there's less "gotchas" than there is with JS.)

          I'm a big fan of Javascript as a language, but can totally understand why someone from an RAD app-programming POV would see it as a drawback.

          Bottom line:
          • If you want to look at XUL from a RAD programming point of view... it closely corresponds to things like Python (with tkinter, PyQt, or pygtk), TCL/TK, Perl (with Gtk2::*) etc. Which is to say, languages and environments which have many of the same issues as Javascript (closures, forgiving syntax, various aspects of functional programming bolted on, and memory leaks galore if you don't know how to use weak references).

            I personally would not call Swing RAD. In my experience, it's one of the slowest ways to
            • it closely corresponds to things like Python (with tkinter, PyQt, or pygtk), TCL/TK, Perl (with Gtk2::*) etc

              Not to mention VB6 [which lacks the functional elements but was plauged with the same reference-counting issues.] Of course, you didn't add "VB is a horrible language" to your list because, well, people have actually used it and agree totally. :)

              I'm not a Swing programmer, so I can't comment on efficiency. Just competitively, if someone is creating something for "cross-platform", "network-delivered"

        • Re:This is what lost the browser wars (Score:1, Interesting)

          by Anonymous Coward
          Oh, please. JavaScript is just a horrible language, the discovery of the poorly-documented closures (how many people here knew JavaScript supposed closures?) was just the latest annoyance. JavaScript seems to be built from the ground-up to allow as many stupid errors as possible.

          Let's start off with "var". WTF does "var" do?!

          Well, it makes future variable references local to that execution context. Try this:

          function foo() { i = 1; };
          function bar() { i = 2; foo(); return i; };

          What does bar() evaluate to?

          • Unfortunately, there's no JavaScript equivilent to "use strict" - I really wish there was.

            There is, in a way. Everything you say in the first half of your comment can be mitigated by setting the javascript.options.strict Gecko option to true, which throws up warnings when you make those kinds of mistakes. Unfortunately, it can't just stop processing when it hits bad code like this because absolutely loads of pages out there make these kinds of mistakes in ways that don't actually cause problems.

          • You might want to try JSLint [jslint.com](documentation [jslint.com]) by Douglas Crockford. It checks that variables are defined before use, and also checks for other common mistakes (you can read about them in the documentation).

          • Oh, please. JavaScript is just a horrible language, the discovery of the poorly-documented closures (how many people here knew JavaScript supposed closures?) was just the latest annoyance. JavaScript seems to be built from the ground-up to allow as many stupid errors as possible.

            Let's start off with "var". WTF does "var" do?!

            Dude, I figured out what "var" meant back in 1995/1996. Coincidentally, that was around the time I first learned JavaScript. Where have you been?

            You might as well write about the bugs

        • The major problem with JavaScript is that it's basically a Lisp/Scheme-like language with C-like syntax, making it prone to human misunderstanding. Add the fact that it was developed in what could only be described as "a rush", stopping only briefly to be quickly standardised (probably the only large step forward in the language's history), and you can see what's wrong with it. It was an admirable attempt, and it can be made to work in great, but the fact is that was just thrown together too hastily, and no

          • Even the guy who created it admits [mozillazine.org] it was created too quickly. ^_^

            JS, unlike Python, was a rushed little hack for Netscape 2 that was then frozen prematurely during the browser wars, and evolved significantly only once by ECMA. So its early flaws were never fixed, and worse, no virtuous cycle of fine-grained community feedback in the form of standard library code construction, and revision of the foundational parts of the language to better support the standard library and its common use-cases, ever occu

          • C-like syntax with C avoids human misunderstanding? Tell that to all the buffer overflow exploits out there.

            I know C. I know JavaScript. You know what helped me avoid human misunderstanding? Learning the languages. Everything else is personal bias and hot air.

            • I'm not so convinced. I realise that one needs to learn any language to be able to use it, but looking like one while acting like another is just plain misleading.

              • It's not like C was the first language to use curly braces. Also, Perl does the exact same thing as JavaScript in that you must scope your variables ('my' as opposed to 'var') and yet people still find time to complain specifically that JavaScript is not acting enough like C. At this point, C is in the minority.

                Come to think of it, there are more things different between C and JavaScript than features in common. But if it makes you feel any better, just think of "var" as JavaScript's version of C's typed va

                • I'm not sure what post you're replying to, but somewhere in here I was complaining that I hated C. It's the fact that JS has C-like (by which I mean Java-like, C#-like, C++-like, etc.) syntax. I just feel there's implications of semantics (or lack of semantics) that just don't hold from using a similar syntax.

                  My personal preferred languages are ML, Python, or C#/Java (yeah, sorry about that last "double trouble" pair, but I got used to them and they're very good for large-scale stuff). I'm not sure I consi

      • "Quite literally the only reason people use Firefox at all over Opera is because it's open source. Were Firefox closed source, Opera would be the clear victor."

        Sorry but that sounds like sour grapes to me from an Opera supporter. Most firefox users could care less about open source. They use firefox because its Free, its more secure than IE, and it has a fantastic extension system. You'll note that Mozilla only enjoyed limited success and that things only really took off when Firefox was developed. Bloat, m
      • Well, I have always been reluctant to criticize XUL because Firefox runs very decently, even on MacOS X. There are some GUI glitches on OS X, but roughly, it performs better than.. let's say QT apps in general.

        Although XUL looks like a flawn design, it works decently enough to run Firefox despite the hacks you describe... And it has also a great advantage: plugins written for Firefox are platform-less. You would not care about this if you use windows or linux x86, but I let you imagine what a relief it is f
      • > (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)

        I'm sorry, but you have no clue what you're talking about. This bug was fixed on the Gecko trunk back in September 2005 (as in, 4 months ago). The fix will be in Gecko 1.9 (and Firefox 3). It _might_ end up in Gecko 1.8.1 (and Firefox 2) if the remaining regressions are resolved fast enough.

        On a more general level, "IE sucks and has this bug" is not necessarily a reason not to fix the bug.
      • JavaScript is a horrible, horrible language.

        Slow down and take a deap breath. There are no horrible languages, only horrible developers (or implementations). I happen to find ECMAScript to be a very powerful language. It includes dynamic prototypical inheritance, which is considerably more flexible and powerful than classical inheritance. It is fully object oriented, as everything is an object. True it is losely type, which can be both a benifit and a detriment, but that and the fact that it is inter
    • Drama queen, you make it sound like WWII. No one died, and Firefox has come about finally. Before it was a code nightmare, want to add a button? Edit 15 files in several repositories just to get it to work. We'd have Netscape 4.2(You can call it Netscape 5 but that means nada), not the greatest thing ever. The tides are waning from IE now, things are returning to normal, and people are developing Ajax and (ugh, hate to say it) Web2 apps that are cross compatible. Things are far better now than when they wer

      • Before it was a code nightmare, want to add a button? Edit 15 files in several repositories just to get it to work.

        Let's compare: which do you think is more difficult?

        1. Editing 15 files in several repositories to add a button.
        2. Rewriting the whole damn thing, over the course of four years... and then adding the button in a few lines of code.

        I don't know about you, but I'm tempted to say that #1 is easier.

        We'd have Netscape 4.2(You can call it Netscape 5 but that means nada), not the greatest t

        • #1 is easier? Then you're stuck, there's no future, and you've reached end line. #2 sounds much easier when you mention this project is going to last for more than a few years, and at some point #2 becomes the only option after years of code-rot.

          "but we'd have it six or seven years ago."

          And IE 7 would have already been out, code rot would have destroyed Netscape/Moz, and IE would have their current market share, and Netscape/Moz would have 0%, instead of the 10%+ (depend on which figures you look at, 10% is

          • #1 is easier? Then you're stuck, there's no future, and you've reached end line.

            That's a false dichotomy. You simply don't have to choose between being stuck with bad code forever and a complete rewrite from the ground up. If you have a crappy code base, you can rewrite it a bit at a time without giving up your entire market share in the process.

    • Re:This is what lost the browser wars (Score:5, Insightful)

      by NutscrapeSucks ( 446616 ) on Monday February 20, 2006 @12:27PM (#14761467)
      The Mozilla developers threw away the only thing that could stop Internet Explorer from winning the browser wars... to build XULRunner.
      Good job on building a GUI toolkit, Mozilla guys! I just wish you'd focused on building a web browser instead.

      I'm sure many people remember the line from mozilla.org -- "It's not a Browser, it's a Development Platform!!" Urg.

      Unfortunately, Mozilla (aka AOL) did not understand the fundamentals of what they were getting into. "Development Platforms" are far less about capabilities and a lot more about Tools. It's just confounding that they sunk soo much effort into developing XUL, and then never released documentation, never released a GUI builder, never really built a community.

      Even ignoring the overall irrationality of the AOL building their own GUI Toolkit, it's just totally bewildering that they only went 80% of the way there. If one wants to compete directly with Microsoft and Sun in the devtools market, you really have follow through, not just throw a bunch of code out on a FTP site and then wonder why nobody's using it. They really did throw away 50% marketshare with nothing to show for it.
    • So you'd rather have kept on having a choice between two crappy browsers than take the time to actually create something that doesn't suck? To make a leap sometimes you have to take a step back.

      The real problem was that AOL bought Netscape and they didn't understand the market or the technology. They should have kept a team working on current-gen technology to keep up the fight with IE while letting Mozilla grow in the background with another team. They certainly had the money to do it - just not the brains
      • The real problem was that AOL bought Netscape and they didn't understand the market or the technology. They should have kept a team working on current-gen technology to keep up the fight with IE while letting Mozilla grow in the background with another team.

        Didn't AOL buy Netscape to get this expetise? And Netscape told them "Oh, Screw Communicator v5. Eric Raymond told us that with Open Source(TM), this Gecko/XUL stuff will be ready in a year, and Microsoft is going down!!"

        Honestly, I think AOL realized Nu

      • So you'd rather have kept on having a choice between two crappy browsers than take the time to actually create something that doesn't suck?

        Please see my other comment [slashdot.org]. That choice is not necessary.

  • I have always been confused about XUL, is it a language in its own right or is it just a library/package for javascript or some other language?

    • Re:What is the language? (Score:5, Informative)

      by Bogtha ( 906264 ) on Monday February 20, 2006 @10:27AM (#14760716)

      XUL is an XML-based language that lets you define a user interface for a program. You hook it all together with lots of things web developers already know - it uses Javascript, the DOM 2 Event model, extensions to CSS, etc. You can use it to build stand-alone applications with XULRunner, or extend existing XUL applications like Firefox.

      Frequently when people talk about XUL, they mean the whole system that makes XUL work - which includes the Javascript, CSS etc. "XULRunner" doesn't "run" XUL, it takes the user interface definition files defined in XUL, and executes the Javascript, renders the CSS, etc, to make it all work properly. XUL is just one component in the grand scheme of things.

  • XUL: WIkipedia (Score:5, Informative)

    by eltoyoboyo ( 750015 ) on Monday February 20, 2006 @10:12AM (#14760637) Journal
    Here is the Wikipedia article on XUL [wikipedia.org]. I could have used this link on the PERL 6 [perl.org] web site since the documentation on PARROT and PUGS are composed in XUL. This was my first introduction to the format. The documents opened in Mozilla, but not in IE. While the arguement has been made here that you should only use Mozilla, why alienate a huge chunk of users without helping them along? Also, if you are going to publish in XUL, do not assume the casual user knows what the format and reader is. The Filext.com [filext.com] site did not yet have a listing or recommended reader for the XUL files.
    • The parent comment makes no sense. Perl, Parrot and PUGS are documented in POD, not XUL. POD is short for "Plain Old Documentation" which is a Perl standard for marking up prose. XUL is a standard for laying out user interfaces. POD and XUL have nothing to do with each other.
      • ChrisDolan,

        I apologize for my unintentionally misleading statement. Parrot Does not have a XUL document. The intro to PUGS [pugscode.org] and HASKELL [pugscode.org] slides are XUL documents. They are both referenced from the PERL6 site. In my quest to find out more about PUGS and HASKELL I was thrown off course and had to learn about XUL first. There is no good purpose for that. A user should not be surprised by a new document format while on a quest for other information. And a fair question would be, where is the POD Perl 6 documen

  • Huh!? (Score:3, Interesting)

    by blkros ( 304521 ) <blkros@COWyahoo.com minus herbivore> on Monday February 20, 2006 @10:20AM (#14760677)
    I thought "sweet!!!" now we don't need to have Firefox, or Mozilla on a system to run XUL-based programs (not that I don't love Firefox), but the download for XULRunner is bigger than the Firefox download. Why is that, is there extra stuff in the archive that actually isn't needed to use this, or what? I haven't really looked at it, but if all this is needed, what's the advantage over just putting Firefox on your system?
    • I thought "sweet!!!" now we don't need to have Firefox, or Mozilla on a system to run XUL-based programs (not that I don't love Firefox), but the download for XULRunner is bigger than the Firefox download.

      I don't think XUL apps should really be used outside the browser. XUL is really designed to be an easy to program javascript frontend enviornment for clients. It should be a slim-client connecting to your main application on the server.
      • I don't think XUL apps should really be used outside the browser.

        But the browser is a XUL app. So is the mail client. That's one of the main points of XULrunner - to make it easier to make stand alone apps that use XUL for the GUI.
      • If you don't configure to be run outside of the browser, then you're locked into only being able to use Firefox. That kind of defeats the portability aspect of it, since many Windows users just use IE and Mac users only use Safari.
    • > what's the advantage over just putting Firefox on your system?

      API stability -- This allows you to distribute standalone XUL apps without worrying that the next .01 rev of Firefox will change the API and break things.

    • Download size (Score:2, Informative)

      by Anonymous Coward
      The download size of XULRunner is larger than Firefox because firefox currently has an installer with optimal 7zip compression and the XULRunner developer preview is just packed in a ZIP. The installed size of XULRunner is smaller than Firefox and the future installer work for XULRunner should compress the archive comparably.
  • I've been waiting for something like this for a loooong time. I've been searching for a way to build my own apps with XUL but I havent found crap on how to set up something like that yourself. If anyone knows then please tell me. I wouldnt need that now though with XULRunner.
    It would be better if Firefox and all the rest would use XULRunner too so there would be some consistance between the projects so it doesnt result in several versions of XUL and I have to have all of them installed at the same time.
  • Don't know much about xul, but the mention of automatic install gives me shivers. That little thing of most windows users having administrator rights by default does not need a rerun on other platforms that are more secure by default.
    there should only be one way how software gets installed on a linux system, and that is through it's package manager.

    And now, on to TFM...

    • That little thing of most windows users having administrator rights by default does not need a rerun on other platforms that are more secure by default.

      You don't need to be root to install software for the current user, even on Windows.

      there should only be one way how software gets installed on a linux system, and that is through it's package manager.

      XULRunner is a package manager of sorts.

      Does anybody know if there are any plans for (eg) gentoo devs hook it into portage's build system?

      • XULRunner is a package manager of sorts.

        Which is something that Linux and the wider FOSS community really doesn't need - yet another way to manage packages of software. You've got several distro level package manegment systems (deb, rpm, ports etc), language level package systems (perl, python, etc) and now platform level packages. Why can't XULRunner just tap into the base package management system instead of doing it it's own way?

        It's hard to see how yet more package management is going to make things eas
        • It's more along the lines of JAR/EAR/WAR files for Java web applications, not for Linux apps typically installed by tar/rpm/deb/whatever. Thus, the *cross platform* talk about XULRunner, because the same install file, like a JAR file, should be as droppable and runnable into a Windows/Moz platform as a ZSeries/Linux/Moz server, just like a good generic JAR'd app is droppable into Tomcat, JBoss, Weblogic, Websphere, etc.
      • You don't need to be root to install software for the current user, even on Windows.

        Actually, on Windows XP (SP2?), if you are in the wrong user permission group (i.e., Power Users), you can't properly install most software. It won't let you install apps in X:\Program Files, for example, because you won't be able to create directories or manipulate files in that tree. IT won't let you load stuff into X:\Windows or X:\Windows\System32, either. Yes, I was able to "install" some of the GNU utilities for Win32

  • Dev environment (Score:4, Insightful)

    by roman_mir ( 125474 ) on Monday February 20, 2006 @10:37AM (#14760770) Homepage Journal
    I am working on a couple of extensions and I wish there was a dev studio, possibly an Eclipse plugin for xul/xbl/xpcom/javascript/css/rdf integration. With my extensions, which have a very small codebase, debuging is a completely manual process (not counting venkman [mozilla.org], which is a good tool but still not powerful enough for my needs.) Certainly having a good design helps a lot, because most of the time it is clear, which component should be looked at. When I just started on the first extension, I didn't understand javascript enough to componentize, so after a while, I completely rewrote the code, because the single file with functions grew too much and any debugging became extremely painful.

    I am also looking for a way to 'run' xul components without doing a full build, a visual studio perhaps, that could help with layouts and avoid all the annoying syntax errors. XUL itself is a markup language that is XML based and allows building visual components - dialogs, menues, buttons, tabs, grids, textboxes, etc. While you can open a half done HTML page in your browser and see what is going on, with XUL you have to build the package first and then you can see what's going on (an incorrect XML structure in this case will give you an error, XUL must be well-formed and valid.)

    XPCOM brings other challenges. It is a native library of services/components that can be accessed from javascript (or possibly other scripts) and that extend the functionality of the script to include things like file management, access to preference storage, window manipulation, etc. But you can't just run a compiler to see if you are doing everything correctly, you will only get errors in runtime.

    Actually, I think this is the biggest problem - all errors must be caught in run-time. Javascript, XUL, XPCOM work, XBL, everything can be built (there is nothing to building anyway, just packaging really,) but after the packaging errors have to be caught in runtime, and I think this is always the biggest problem for a programmer who is used to rely on compiler to quickly catch some of the problems before even starting the application.

    Maybe there needs to be a unit-testing framework created, that can help running unit tests on portions of the code without building the entire application and catching unit errors during execution of the entire application. Yes, actually, to think about it this could be a big help, especially for the new developers, who can be put off this entire platform because of lack of these tools.
    • I am also looking for a way to 'run' xul components without doing a full build, a,

      Why can't you edit the installed plugin directly and just restart the browser to test changes? When i was writing my XUL plugin, I just used Mozilla to test and kept firefox running for actual web browsing?

      XPCOM brings other challenges. It is a native library of services/components that can be accessed from javascript (or possibly other scripts) and that extend the functionality of the script to include things like file manage
      • Why can't you edit the installed plugin directly and just restart the browser to test changes? When i was writing my XUL plugin, I just used Mozilla to test and kept firefox running for actual web browsing? - there all kinds of hacks, that one can do for this, but they are still hacks and not a substitute for a well thought out dev solution. It is possible to create various tools like syntax checkers, that could be run during 'compile' time.

        Welcome to the world of developing with scripted languages. - than

        • Re:Dev environment (Score:2, Informative)

          by Myen ( 734499 )
          You might be interested in XPCShell (err, not sure if comes with the Gecko SDK and/or the suite; all I know is building Firefox yourself seems to make it). It's basically a XPCOM enabled JS shell. Of course, that means things like window are still undefined... that doesn't make sense unless you actually have a window :)

          As for making up small bits of XUL, the extension developer's extension has a editor (it basically has a frame that loads whatever you type into a textbox in). Doesn't work too well with d

  • OK (Score:1)

    by sabit666 ( 457634 )
    But where are the IDE's/GUI builders for XUL? Those `tutorials' sure don't help newbies.

    • Re:OK (Score:1, Insightful)

      by Anonymous Coward
      The GUI builders are the same place where good HTML builders are: emacs or a good text editor! Good web developers don't use wysiwyg HTML/XML editors. It is easier and more reliable to just know the markup language, CSS and preview in a browser.
      • And that explains perfectly why there are 1,000,000 VB applications in the world, and only 7 XUL applications.

        "We're too l33t for GUI builders HUR HUR HUR!!!!11" (meanwhile 100 man-years of programming effort disappears into obscurity)
        • And that explains perfectly why there are 1,000,000 VB applications in the world, and only 7 XUL applications.
          It also explains why all of those 1,000,000 VB applications suck ass.

          --- SER

    • I'd like to remind readers that this is preview release, and there are many aspects of this platform that are not complete, including a set of tools which will be packaged up as the XULRunner SDK [mozilla.org]. I am fully aware that you can't have a platform without excellent developer tools and documentation, and we're working to get all of those resources in place in the next year.

  • Perhaps they could fix the installation methods (Score:3, Interesting)

    by Chemisor ( 97276 ) on Monday February 20, 2006 @11:11AM (#14760961)
    My nightmare story about trying to install mozilla plugins [slashdot.org] suddenly comes to mind. Until somebody things good and hard about these problems I wouldn't recommend anyone to write anything in XUL.
  • Whose idea was it to name "XULRunner"? Picking a name that's a new word, hard for most people to guess how to pronounce, is a bad way to get people to talk about it.
  • This is definately a good preview edition, we've been able to push through a release based off of this instead of using it as a firefox extension by using Advanced Installer [advancedinstaller.com] which made MSIs easy for me. I'm sure any platform specific installer would be able to work as well, and we'll probably hang on to this for later MSI packaging once XulRunner has it's own installer(but once it does have it's own installer/upgrader we'll switch to that so we can run our stuff on Mac's again(and *nix, but that hasn't come
  • This sounds very promising and interesting--a robust cross-platform GUI-development platform. However, I've always been a bit baffled by the idea of Mozilla/XUL as a "development platform." It is so unlike the environments I'm used to (Tcl/Tk, AppleScript/Cocoa, Python/wxPython) that I'm not clear what one does with it. So here are some questions:

    1. Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language? (i.e. is
  • How much memory is chewed up by this to just diaplsy, say a 3"x3" square window, with a table and some text? For Mozilla/Seamonkey, it's something like 15MB. Same, less, more?

    Also, like a browser, if you open a second "window", you only have a small memory hit to add the extra page (plus rendered objects). Is this the same here?

Slashdot Top Deals

E = MC ** 2 +- 3db

Close