XULRunner Developer Preview Release Available 122
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.
Also worth mentioning (Score:3, Informative)
XuulRunner (Score:1)
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
Re:XuulRunner (Score:2)
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
Re:XuulRunner (Score:2)
And this is the problem. With XUL, you're entirely limited to whatever the Mozilla developers found necessary to build a web browser/mail client. Don't get me wrong, XUL has a hell of a lot more rich GUI power than HTML, but it doesn't quite have the robustness of other application development platforms. If I were teh XULRunner team, I would be looking to ditch Javascript
Re:XuulRunner (Score:2)
I don't think that's ever a direct problem. Javascript could certainly be a nicer language to work in, but it never prevents you from reaching your goal. It's not the scripting language that constrains you, but the underlying components.
However, it is actually possible to write your own components, even in C++, and distribute them along with the rest of your code. Obviously you lose some of the advantage of XUL at this point, but if it's just one small feature your missing you can code your own.
And of
Mozilla & Eclipse (Score:2)
XULRunner future. (Score:4, Informative)
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)
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.
Re:XULRunner future. (Score:2)
You're in luck :-) Python bindings are coming to XUL. [mozillazine.org]
Mozilla is working with ECMA on that too. See Brendan's comments about ECMAScript 4/JavaScript 2.
Re:XULRunner future. (Score:1)
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.
Re:XULRunner future. (Score:2)
Re:XULRunner future. (Score:2)
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...
Re:XULRunner future. (Score:2)
How so? There is nothing inherent about xul that makes dynamic document generation easier. In fact, it's the same, using the DOM.
Comparing AJAX to XUL is comparing apples to oranges.
Care to elaborate? What is it about javascr
Re:XULRunner future. (Score:2)
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
Re:XULRunner future. (Score:2)
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)
Re:XULRunner future. (Score:2)
Re:XULRunner future. (Score:2)
http://wiki.mozilla.org/Firefox2/Features [mozilla.org]
Re:XULRunner future. (Score:2)
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.
Re:XULRunner future. (Score:2)
For me, in order for something to qualify as a tool for rapid development, it must have (at least) the following:
Does anyone know how these XUL tools stack up along these dimen
Oblig. Ghostbusters (Score:5, Funny)
Or, as the Wikipedia points out:
"There is no data, only XUL"
Re:Oblig. Ghostbusters (Score:3, Interesting)
This is what lost the browser wars (Score:5, Interesting)
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.
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
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:2)
Re:This is what lost the browser wars (Score:4, Interesting)
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)
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.
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.
Richard Cornford wrote a decent explanation [jibbering.com].
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)
I suspect that I am feeding a troll, but here goes...
Your comment is much akin to the following:
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.
Re:This is what lost the browser wars (Score:2)
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:
Re:This is what lost the browser wars (Score:2)
I personally would not call Swing RAD. In my experience, it's one of the slowest ways to
Re:This is what lost the browser wars (Score:2)
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)
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?
Re:This is what lost the browser wars (Score:2)
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.
Re:This is what lost the browser wars (Score:1)
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).
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
Re:This is what lost the browser wars (Score:2)
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.
Re:This is what lost the browser wars (Score:2)
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.
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
Re:This is what lost the browser wars (Score:1)
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
Re:This is what lost the browser wars (Score:2)
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.
Re:This is what lost the browser wars (Score:2, Interesting)
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
Re:This is what lost the browser wars (Score:2)
Re:This is what lost the browser wars (Score:2)
Let's compare: which do you think is more difficult?
I don't know about you, but I'm tempted to say that #1 is easier.
Re:This is what lost the browser wars (Score:2)
"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
Re:This is what lost the browser wars (Score:2)
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)
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.
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
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
Re:This is what lost the browser wars (Score:2)
Re:This is what lost the browser wars (Score:2)
Please see my other comment [slashdot.org]. That choice is not necessary.
What is the language? (Score:2)
Re:What is the language? (Score:5, Informative)
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)
Mod parent down (Score:2)
Apologies (Score:2)
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
Re:Presentations (Score:2)
Huh!? (Score:3, Interesting)
Re:Huh!? (Score:2)
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.
Re:Huh!? (Score:1)
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.
Re:Huh!? (Score:2)
Re:Huh!? (Score:2)
API stability -- This allows you to distribute standalone XUL apps without worrying that the next
Download size (Score:2, Informative)
Standalone apps (Score:1)
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.
Re:Standalone apps (Score:2)
please no user installation (Score:2)
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...
Re:please no user installation (Score:1)
You don't need to be root to install software for the current user, even on Windows.
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?
Re:please no user installation (Score:2)
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
Re:please no user installation (Score:2)
Re:please no user installation (Score:2)
Re:please no user installation (Score:2)
Re:please no user installation (Score:2)
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)
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.
Re:Dev environment (Score:2)
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
Re:Dev environment (Score:2)
Welcome to the world of developing with scripted languages. - than
Re:Dev environment (Score:2, Informative)
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)
Re:OK (Score:1, Insightful)
Re:OK (Score:2)
"We're too l33t for GUI builders HUR HUR HUR!!!!11" (meanwhile 100 man-years of programming effort disappears into obscurity)
Re:OK (Score:3)
--- SER
XULRunner SDK is in the roadmap (Score:2, Informative)
Perhaps they could fix the installation methods (Score:3, Interesting)
Re:Perhaps they could fix the installation methods (Score:2)
> the world doesn't immediately twist itself to conform to you.
Why yes. If your application is as unfriendly as mozilla's plugin installation, you can be sure I am not going to use it. While it doesn't hurt me much, it will hurt you if you are selling it. In mozilla's case I'm only complaining because I can't just ditch it and use something else; there is nothing else.
> You make it sound like it's a randomly *changing* string. It'
Xoices (Score:1)
Re:Xoices (Score:1)
"Ex You Ell Runner".
Re:Xoices (Score:2)
The problem is not how hard it is to pronounce, but rather how hard it is to guess how to pronounce it. And "Ex Yoo El Runner" is fairly hard to pronounce, anyway.
Re:Xoices (Score:2)
It's "Zewlrunner". XUL = Zuul from Ghostbusters [wikipedia.org], that's why the namespace for XUL documents is "http://www.mozilla.org/keymaster/gatekeeper/there .is.only.xul [mozilla.org]".
Similarly "XPI" is "zippy" - the install technology used to distribute XUL apps.
Re:Xoices (Score:2)
Good preview edition (Score:2)
So what kinds of applications can one create? (Score:2, Interesting)
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
Re:So what kinds of applications can one create? (Score:2)
Re:So what kinds of applications can one create? (Score:2)
Yes. And the hope is that soon you will be able to use JavaScript _or_ Python as the programming language.
> 2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)
The idea is that it should not. Some things are still not easily (or at all) doable without using C++, of course. Writing device
Memory usage? (Score:2)
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?
Re:Cause of death of Nigel McFarlane? (Score:3, Funny)
For crying out loud guy, get a grip.
Cheers,
Ian
Re:Count the occurrences of XUL in that summary. (Score:1)
Re:Count the occurrences of XUL in that summary. (Score:1)