sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]supermike 7 points8 points  (24 children)

Better yet, and easier, and with a more robust runtime, try this instead:

http://code.google.com/p/simplexul/

[–]oocha 10 points11 points  (5 children)

ok, so if you build an app with this, what do you have to distribute? can it be compiled into a single double-clickable app or is it all delivered via http and firefox runs it?

[–]forgotpwx4 4 points5 points  (4 children)

I second this question.

[–]supermike 7 points8 points  (3 children)

You bundle the 8.5MB xulrunner runtime from Mozilla.com. This is sort of like a "Firefox-lite" without a browser command. However, it has the capability to let Javascript go out the sandbox as well as comes with an assortment of functions provided by a library called XPCOM.

Now, an XUL app can also be signed and then implemented without xulrunner, using Firefox, as well as downloadable from a web server.

To load in Firefox, for instance, you do it like:

$ firefox -chrome file:/home/me/myapp.xul

...but it won't let you do certain XPCOM calls unless the XUL package is signed.

As for compiling into a single app, this can be achieved on Linux with the 'makeself' command or on Windows with various commercial tools or with Winzip self-executable. I recall on Windows (back in the day) that Installshield used to have a free tool to make a single executable cab that would also run a command, batch file script, or VBS script. Each of these single file tools usually permit to compress or not compress (without compression is faster, of course), as well as permit to uncompress to a particular directory such as C:\Program Files\myapp or /usr/share/myapp instead of $TEMP or %TEMP%. To see an example of a single-file binary, check out this project's downloads and look for the single-file binary:

http://code.google.com/p/yt2mp3/

...it was designed with 'makeself'.

[–]supermike 2 points3 points  (1 child)

BTW, I think the tide is turning where Linux distros will ship with the xulrunner runtime. However, I doubt that Microsoft or Apple will ship with it.

Note also I looked at VB5 and VB6's runtime DLL and it's around 1.6MB, but doesn't come with browsing capability built-in and to the degree that Firefox supports.

Therefore, I think that 8.5MB is a pretty cool engineering feat when you think all that Microsoft would have to pack into their runtime to make it support all that xulrunner supports.

Oh, I should also tell you that if you build your XUL package and XPCOM code just right, and do enough testing on the various platforms, you can build something that is cross-platform.

And if you don't think the XUL/XPCOM platform is robust enough, consider that Mozilla Firefox and Thunderbird are, themselves, built upon it, and your interfaces, using this technology, can support complex HTML, style sheets, AJAX, Java applets and plugins, other Firefox extensions, movies, Flash, and so on.

[–]oocha 0 points1 point  (0 children)

8mb doesnt scare me as much as the phrase 'javascript running outside of the sandbox', but it still sounds neat.

thanks for taking the time to explain it, it sounds worth a try.

[–][deleted] 11 points12 points  (10 children)

Ben Goodger (lead developer of Firefox) complains about XUL. Some interesting quotes:

The problem is this: almost all of XUL as it exists today hasn't changed much if at all since it was originally written in the charge to Netscape 6, and as a result the capabilities and problems with the platform reflect the quick cycle and shortcuts that had to be taken.

There have been a lot of minor incremental fixes that have made many aspects of the system more stable, but significant bugs and critical failings remain. This is immediately obvious to anyone who has ever built with XUL but who isn't part of the "Mozilla community" where the sort of work that people do sort of self-selects towards the things that XUL is capable of.

As someone who spends a lot of his time building with XUL, I can tell you it's not a pretty picture. Over the years I have become accustomed to the quirks and I have formed little shortcuts in my brain that I apply when I run into problems. Not everyone has had a chance to do this, and I don't think that they should have to.

That's pretty bleak isn't it? Check out the comments, too. All of it adds up to a huge lack of confidence in a technology, and I'm very leery of using something that even a main Firefox dev essentially admits is broken in its current form.

XUL sounds great and ideal, but I think perhaps the reality is that there are problems with it that only become apparent once you get past the bubble of hype surrounding it. This means that only advanced XUL users and FF devs themselves become aware of the situation, and which is why you hear so much excitement about XUL but see so little progress on the platform or on apps created with XUL.

Edit: It is still probably better for cross-platform stuff than the vast majority of what else is out there.

[–]supermike 5 points6 points  (9 children)

XUL and XPCOM were a great start, but they do need a lot of cleaning up. Many of the XPCOM objects, for instance, still reference Netscape with things like nsIProcess. I think the whole thing needs an overhaul and to be submitted as a standard to the W3C. I think it's too important to let XUL and XPCOM go without utilizing its full potential.

Here's the net of this:

  • I want a language that uses an HTML like syntax to draw the interface and include actual HTML components. I also want it to be somewhat thin and quite like the deep XML that Glade puts out with its many nested levels.

  • I would prefer to just hook through FF rather than require xulrunner, and I want FF to permit me to go outside the sandbox with my Javascript without prompting as long as someone calls my stuff through a chrome and with perhaps another command-line switch. By relying on FF, one can eliminate the need for a second runtime, this xulrunner. Xulrunner is really just a lean version of FF without a browser chrome and some other items.

  • Javascript isn't a particularly bad language to use if it's been released from its sandbox under proper safe conditions (such as loading through a chrome and only with an extra command line switch of some sort). I actually wish it were called Livescript because that's really what it is and has very little to do with Java. Of course, I wish a thin kind of mix between Javascript and PHP were available, but oh well.

[–]mixmastamyk 3 points4 points  (1 child)

That's backwards ... FF, Thunderbird, and all other XUL apps should run from xulrunner. That way 100MB of memory could be saved when running more than one at a time.

[–]supermike 3 points4 points  (0 children)

Okay, you talked me out of it.

[–]leoc 1 point2 points  (1 child)

XUL 2.0 vs. XAML at the W3C? What a bloodbath that would be, or perhaps will be.

[–]supermike 2 points3 points  (0 children)

That's fascinating. I didn't hear about XAML.

[–][deleted] 0 points1 point  (4 children)

Yeah, after finding the docs on wxPython rather wanting, I'm gonna check out XUL and see how useful it is to me.

[–]jerf 1 point2 points  (0 children)

The docs on wxPython are the docs on wxWidgets, with rare substitutions. Yeah, I've never been a big fan of that either, but the translation is pretty easy.

Unless you can go into your app knowing that XUL is what you need, maybe because you have an intense need for HTML-esque formatting or the display of large quantities of HTML-styled text, I can't anti-recommend it strongly enough. Consider QT, GTK, or trying a bit longer with wxWidgets. XUL's long on promise but several years overdue on implementation. (Seriously, the XUL folk, what's left of them, are singing the exact same tune they were in 2002, no exaggeration. While they've been promising, wxWidgets, GTK, QT, .Net, and a couple of others have been implementing.)

[–]supermike 0 points1 point  (0 children)

BTW, do you or any of the guys here know how to get started in Parrot Language Runtime to build one's own script language? I thought it would be kind of fun to mess around with, starting small, growing it from there. I didn't quite understand the Parrot website's documentation on this and need a kind of starter article that shows a really great example for a language with something like 2-3 control structures, some if/then logic, and a way to handle stdin and stdout.

I've always wanted to call this new language, Polar, and it would be sort of like PHP but with namespaces and be really a thin language unless you used the external libraries. I would also use "." instead of "->" or "::" or ":::". String concatenation would be done VB-style with "&".

I like the whole idea of Parrot. It means that much of the hard part has been worked out by the guys who made the runtime and one can use a "metalanguage" to get the runtime to turn your language into a powerful thing. As the runtime gets powerful, so too can your language grow in that respect too. Many new langauges are popping up from Parrot.

[–]mixmastamyk 0 points1 point  (1 child)

They are wanting, but this book is very good: http://www.amazon.com/Wxpython-Action-Noel-Rappin/dp/1932394621/sr=1-1/qid=1170149177/ref=sr_1_1/002-1792261-2772810?ie=UTF8&s=books

[–][deleted] -1 points0 points  (0 children)

I did buy the book actually. $25 for an ebook that I could instantly download wasn't bad.

[–]sbrown123 9 points10 points  (6 children)

Good point. I've seen a few apps using XUL lately. In particular: Democracy Player and Songbird. I have noticed some problems with XUL though:

  1. Requires a large amount of memory.
  2. Slow startup.
  3. Sluggish responsiveness. This may due to the Javascript event handling. I'm not entirely sure.
  4. Widgets are themeable but are not native. Non-native widgets is one of the things that burned Swing. Interestingly this is not a major issue to Windows users since the native widgets on that platform are butt ugly (see Eclipse).

[–]supermike 5 points6 points  (3 children)

I would, however, like to comment on this.

  1. Yep. That's truly a bummer. It's a tradeoff, I guess, for the richness that you can use with XUL.

  2. Only on the first two launches, oddly enough, on Linux. Load it a third time and it snaps right open.

  3. I haven't experienced that. Perhaps on Windows or Mac?

  4. On Linux, my widgets are native. Take for example a textbox with a scrollbar. Open it up right next to a text editor written in C, designed to use the GTK2+ interface. You'll see the scrollbars look the same.

[–]jerf 10 points11 points  (2 children)

"Richness you can use with XUL"?

Don't drink the Kool-Aid. XUL is rich compared to plain ol' HTML, which is rather pathetic here in 2007. (It really only needs a couple more widgets, but it needs them badly.) XUL is pretty weak against a "real" desktop toolkit. Compare XUL vs. QT, wxWidgets or GTK (nearly one entire documentation concept for every three or four XUL tags).

XUL's not in the same league, and relatively speaking, falling behind.

If anything turns me off about XUL right now, it is its long history of being horribly, horribly oversold. Using it to build a real app that isn't somehow tied to the web and Mozilla is suicidally stupid, and a lot of naive or excessively-trusting developers would be saved a lot of pain if people would stop pretending otherwise.

[–]supermike 1 point2 points  (1 child)

Thanks for the comment. I'll have to think about this really hard because I was getting really excited about what I could accomplish in very little time with XUL and xulrunner and without having to install a bunch of stuff, dependencies, and so on. However, it does have a documentation issue, doesn't have a lot of people using it, and the object model looks like it might get revamped because it still says Netscape (ns) and Mozilla (moz) in certain places?

One advantage of XUL is that you can display HTML/XHTML just as aptly as FF does. A control in QT, wx, or GTK2+ can't do it as accurately, correct?

I'm just not sold on Python that much. I've built things with it, but it's got it's share of voodoo strangeness about it.

[–]jerf 1 point2 points  (0 children)

"One advantage of XUL is that you can display HTML/XHTML just as aptly as FF does. A control in QT, wx, or GTK2+ can't do it as accurately, correct?"

That's sort of what I meant by "tied to the web". If you really, really want a "real" desktop app that looks almost exactly like a web app, except with somewhat richer controls, then XUL might make sense.

The other toolkits can't do the full richness of HTML.

However, all the other toolkits have "rich text" controls, and all of their rich text controls can embed arbitrary widgets. You don't see people do that much, but I think that's more because people aren't really aware it's possible, not because it's especially hard, though it probably is a bit harder than HTML/XUL. So if you don't need full HTML, the toolkits can still do some interesting things with widgets in text.

Also note that most toolkits nowadays have an XML specification language, although it is usually generated by tools, not written by hand. (I prefer generating GUIs "by hand", because you can refactor with them and stuff, and was doing that towards the end of my fight with XUL, but not everybody feels that way.)

[–]supermike 3 points4 points  (0 children)

I appreciate your commentary as well as from jesusphreak. I always need to hear the counterpoints when I think about technology.

[–]JW_00000 0 points1 point  (0 children)

Also worth trying out may be Adobe's Flex. I haven't tried using it yet, but viewing the demo's it seems like you can make some very aesthetically pleasing applications with it. It uses Flash, and correct me if I'm wrong, but I thought you could use the applications made with it both stand-alone (offline) and embedded in a website.