Slashdot Mirror

Neil Deakin almost missed his own wedding because of the rock slide. He had to take a float plane to get out of there.

"Sometimes I think it might make more sense to make a browser-like framework for programs, but built from the ground up for applications instead of static pages."

That is/has been the promise of technologies like XAML and XUL.

Tom Caudron
http://tom.digitalelite.com/

What about XUL?

JavaScript 1.7 already has generators and iterators. Even if they don't become part of ECMAScript 4, JavaScript will probably keep them.

Anyway, there are many languages without native support for threads that do just fine with using libraries. See XPCOM's nsIThread.

• Clean up our APIs to be fewer, better, and "on the outside."
• Simplify the Mozilla codebase to make it smaller, faster,and easier to approach and maintain.
• Take advantage of standard language features and fast paths instead of XPCOM and ad hoc code.

We should instead focus on cleaning up things which are (broken, instead refering to RDF). Like removing all the XPCOM overhead, or why there are fifteen interfaces to desribe a window.
(Regarding undergoing API clean up:) Instead of writing twenty lines of code (...) use the WHATWG Drag and Drop API and just write two.

Check out XUL here (Mozilla's XUL project page) and here.

I've done some experimenting with XUL, and I've actually found it to be an incredibly powerful (but rarely used) platform. The biggest problem when I used it was that the only way you could actually "get stuff done" was via XPCOM, which is a rather clunky interface from JS to C++. If they were to make XPCOM components much easier to write and install (and maybe add seamless support for languages like Java and Python - I wouldn't be surprised if this has already happened, actually), it'd be unstoppable (apart from the fact that you need to have Gecko installed before you can use it).

Actually the XML is intented to be used for laying out the application and even in that case you can let the IDE write out the XML code for you behind the scenes. The methods in the application are written in ActionScript 3.0 and behave like the methods in many other object oriented languages. Creating layouts with XML has been adopted by several languages as an effective and quick way to declaratively create the User interface. Mozilla's XUL and several java tools and even c++ (entity-c) have all found this technique to be a rapid and effective way to get the layout done quickly.

XUL (pronounced "zool") is Mozilla's XML-based User interface Language that lets you build feature-rich cross platform applications that can run connected or disconnected from the Internet.

How powerful is it? Well, Mozilla Firefox and Thunderbird are two examples.

http://www.mozilla.org/xpfe/
http://www.mozilla.org/projects/xul/
http://www.xulplanet.com/

...when we've already got XUL?

For Mozilla-related things, there's a DOMParser constructor that may be useful. Use parseFromString() since you don't have access to nsIInputStream :)

(If you can, XPath is lovely for getting stuff out of DOM trees!)

Consider looking here: http://xulplanet.com/tutorials/mozsdk/sockets.php

Mozilla (and Firefox) gives you direct access to sockets. I don't know if UDP is supported. This is great because, in theory, you could implement whatever protocol you wanted to in some clientside javascript.

Should work with unprivileged (ie from a website) javascript. (Opening a listening socket requires privileged code, eg a Firefox extension.)

Wouldn't the web as application platform be better with a full programming language(s) on the client side, deployed in/by/with the browser?

Define "full programming language". Javascript is a modern, object-oriented programming language. I can think of no way in which it doesn't count as a "full programming language".

I've never understood why exactly one can't use SOAP calls to populate widgets' data, and I'd be interested to hear why this is?

You can in Gecko-based browsers. You can't elsewhere because the browser developers didn't choose to implement it.

If cookies are bad why do browser makers include them? Maybe there are not all the bad?

Why the client-side data storage is so popular that even Microsoft embraced it more with its User-Data
http://msdn.microsoft.com/workshop/author/behavior s/reference/behaviors/userdata.asp

And why Mozilla brings it's persistent attributes to the world-famous secure browser?
http://xulplanet.com/references/elemref/ref_XULEle ment.html#attr_persist

And I ensure you that these things are more evil then the most evil cookie monster :-) Because people seeking for cookies will not check this things that theoretically may do the job well... ;-)

But what if they are not so bad?

Ah yes, I remember reading about XUL and how it compares to XAML.

There have also be news stories about it.

Closer in the sense that adding central heating/air brings a mobile home closer to feeling like a modern 3 bedroom, two story house, sure.

Um, you act as if it's not already being done by Google, Yahoo, Microsoft, and others. Clearly, there are plenty of "smart enough" programmers out there. I also have no idea why you think server run MS Word would be positively frightening since you never say why. I also have no idea why you think HTML would limit you.

HTML is meant for rendering documents and simple forms. If you can'tfigure out how that would limit you, I don't know what to tell you.If you've ever programmed in a real GUI environment with proper widgets, events, callbacks, etc, you'd understand.

I'm also still not clear as to why you would have a problem with a Word-type application running of an internet server.

Because it would be slow as molases, for one thing.

Huh? Have you used ANY AJAX apps? GMail, Google Maps, Microsoft Live, the new Yahoo Maps, the new Yahoo Mail, etc? Which one of these takes an agonizingly long time to load?

I've used all but Microsoft Live, and none feel much like a desktop application. They're basically just traditional web apps that don't reload as often. No menu bars, no key shortcuts, few proper UI widgets. The list goes on.

The web browser was PREVIOUSLY document "oriented" only because whoever designed the web browser said so. Not because it's inherently so. If Google, Microsoft, Firefox, or whoever decides to extend its functionality such that it's better optimized for applications, then that's precisely what it's designed to do.

It isn't a matter of "optimizing" for applications. A whole new language and rendering model is required. Mozilla has done this. It is called XUL. The whole Firefox UI itself is written in XUL. But even with this there are problems because XUL apps run in a sandbox and cannot interact with theOS to a significant degree... for security reasons. Also, the project is a bit stalled becase Mozillia developers only really work on theparts of XUL that Firefox and Mozilla use extensively.

I think that the real problem here is that you, my friend, lack imagination or vision. The limitations of today are NOT limitations of tomorrow.

I think the problem here is that you don't understand the technologies.

Again, huh? Correct me if I'm wrong, but when you open up Google Maps, it doesn't put the ENTIRE map onto your computer. Just the parts that you're looking at. And it does it asynchronously which is why it feels so smooth compared to previous map apps like MapQuest. Likewise, let's take an imaginary word processor designed by AJAX as an example. If you're not using the thesaurus, it simply won't download onto your computer.

But when you do want to use the thesaurus, are you going to want to wait 1 minute while it downloads? Loading just part of a map is different than loading just part of an application. I think you underestimate the value of having an entire application runningfrom a relatively fast local hard drive using proper UI elements.

As for short-cuts being difficult to implement in a web-app, I again recommend you try out some of the fine AJAX applications such as Gmail before you jump to such conclusions.

I've used Gmail. Good webmail application. But reallly not that much different than a traditional web app. I'd still prefer a local application running on my desktop independent of a web browser.

Let me ask you this: why are you so against AJAX applications?

i have no problem with AJAX at all. I use it in my own web

I'm not saying that a good web based application platform would not be a Good Thing(tm). I'm just saying that AJAX isn't it. AJAX give you one thing: the ability to talk to a server without refreshing the HTML. Great. But how exactly does this turn HTML into a proper application UI?

2) There is a rapidly increasing set of backend AJAX components that implement all the regular application controls. For example take a look at Blueshoes.

First of all, projects like Blueshoes have very little to do with AJAX. AJAX is JUST a method of communicating with a web server without refreshing the page. That's it. Second, technically it is a frontend, not a backend. Third, projects like Blueshoes are slow, ugly hacks. Every single one of them. What is need is something like XUL which works on all browsers.

-matthew

XUL provides both. AND you can use it with AJAX. But, alas, it only works with Mozilla based browers.

-matthew

I'm speaking as/for a commercial developer which already has a working port on Linux of a very large and powerful app but can't release because of the license mess the linux GUI/OS is in.

Licence mess? Hmmm...

Have you looked at projects like FLTK, wxWindows, Tk from Tcl/Tk, TIX, the Adobe Source Libraries, or Mozilla's XUL and XPFE etc? It's definitely possible to develop closed-source GUI software on X11 with a range of widget sets without violating licences.

And really, if you're developing closed-source software and want the KDE look-and-feel, you can always purchase a Qt developer licence instead of opensourcing your code.

There is no one-true-widget-set which forces you to open-source your code. The closest thing to a "one-true-widget-set-for-X11", it would be Motif - and even that is free if you're developing for Linux - see OpenMotif...

The problem with Ajax is precicely that it DOES interact with HTML and not, say, some sane GUI model. Easy to mix with a web page, hard to make a good desktop-style application with. Mind you, AJAX is not limited to HTML. You could, for example, use it with XUL. Unfortunately it only works with Mozilla based browsers.

-matthew

These are a few sites that I found helpful. Some are a little old but I got something out of all of them.

http://www.xulplanet.com/
http://kb.mozillazine.org/Dev_:_Extensions
http://roachfiend.com/archives/2004/12/08/how-to-c reate-firefox-extensions/
http://businesslogs.com/technology/firefox_extensi on_tutorial.php
http://www.bengoodger.com/software/mb/extensions/p ackaging/extensions.html
http://mozilla-firefox-extension-dev.blogspot.com/
http://books.mozdev.org/index.html
http://www.mozilla.org/xpfe/gettingstarted.html

Of course another good way to learn about extensions is to download a few and look at the code. That has probably been the biggest help to me once the tutorials, etc. gave me the basic idea of what is going on.

Well, imagine creating an application with nice 3D animation like that is a NO BRAINER. That's what Avalon + the new developer tools + .NET on Windows Vista will let you do, easier than a fart. Linux fan boys, enjoy your GCC.

Avalon? Avalon is supposed to be an XML descriptive language for GUI widgets, something like XUL or gladeXML. The only difference is that these tools exist right now while avalon is vaporware. So I'll go write a GUI in XML and finish it in a few minutes, while you still wait for avalon.

New developer tools? You really believe there are no developer tools on linux? Countless IDEs to choose from. From Anjuta to Kdevelop to Eclipse. Countless simple editors. Countless other tools like profilers, version control, etc etc. Detailed and thorough documentation on every tool you'll ever use. Please keep you uninformed opinions to yourself next time. Saves you the embarrassment.

.NET? .NET is BS. Read this very good article about .NET. It'll explain alot.
Now, If you're talking about managed programming languages like C# etc. there's mono. Pretty much everything .net has been transferred or will be soon, so your windows code will work on mono. Plus, mono has other extra subprojects you can use, not available on windows,

So yeah, you wait for your new tools MS fanboy, while we already have them.

But since this summer, developer.mozilla.org has gone live. They've got instructions for Building an extension. And a Javascript reference. There's also the Embedding API Reference with documentation on all the nsI* interfaces. And while not from mozilla.org, there's XULPlanet, which documents XUL.

The documentation has been lacking historically, but things are quite a bit better now.

There are plenty of solutions out there, sounds like you're not interested in googling for them.

Well, if you can find a way to create a custom tree model as described here (which is, BTW, the link I provided in my original post, which you apparently didn't read) in an untrusted XUL app, I'd *love* to hear about it.

Just plain "Ajax" (which in my mind still reeks of a cleaning agent more than a web technology) does not seem to be enough to displace desktop apps, as the interfaces built with it are still clearly web interfaces - albeit more responsive ones. However the combination of asynchronous javascript, XmlHttpRequest and XUL (tutorial can be found here) seems to have more of a chance to provide a native application look and feel to a web-based application. A well-known example of such an app is the Amazon.com browser, give it a try if you have not done so.

Firefox is built on xul, so any os that runs firefox can run your xul app.
http://www.mozilla.org/projects/xul/
http://www.xulplanet.com/

Also as to components you can use in your apps. There is the render engine:
http://www.mozilla.org/newlayout/
http://www.mozilla.org/projects/embedding/GRE.html
Or the script engine, rhino
http://www.mozilla.org/rhino/

Damnit, hit submit too soon:

Except, of course, that basic things like the <tree> element don't work properly when loaded from a website or even local file:// URLs. Just try to create a tree with a custom model and see what I mean (heck, just take the example here and try to load it from file://). :/

Now, some of these problems are due to the lack of testing, but Mozilla's security model also makes it very difficult to create powerful, remotely loaded XUL apps (for example, drag-and-drop and custom data sources aren't useable in this mode... you have to make a locally installed chrome app or extension). Of course, some of this is necessary, but IMHO, the security model hasn't been well thought out, and so they've made the platform *too* limited.

Uh, Firefox extensions are written in XUL, which is inherently cross-platform. So yes, you get to enjoy it as well...if you have GreaseMonkey installed. Which, judging by the fact that you didn't know that Firefox extensions were cross-platform, I'm guessing you don't.

Regarding JScript .Net, you're pretty damned right it isn't well documented, I spent my first month trying to learn .Net, and wanted to use JavaScript (my fav. language) ... spent a larger part of the time converting VB.Net and C# stuff, much of which didn't seem to work right (anything using dll/system/unmanaged calls, never did figure that out).. finally I broke down and learned C#, was much more neat as far as code goes, the VB-Like tie-in for declared objects kinda irked me.

'VB
Public MyObject As Object

//JS
public myObject as Object; //iirc

//C#
public Object myObject;

I just like the C# syntax a bit better.. just a personal view though. I like JavaScript in and of itself, I think the way it handles say regular expressions should be added into C#, it imho is about the biggest point that JS has over C#, since the syntax outside of declarations is about the same.

As for .Net development, with the SDK installed, can always use SharpDevelop as a free, opensource ide for .Net ... MonoDevelop is based on an earlier fork of #dev.

Beyond all this, javascript can be used in conjunction with XUL as another RAD environment, iirc the TheOpenCD uses it for it's menu/installer front end..

Oh, shit, I wish I knew. I hated the way that you seemed to have to be a firefox hacker to know how to do this shit. But you don't -- there are lots of examples to learn from now.

Plus, I learned with help from da intarweb:

• XUL Reference
• DOM Ref
• XmlHttpRequest

And an out-of-date but still informative book (got cheap!).

Some Firefox extensions like venkman (JS Debugger) and one called "Extension Developer" which has a real-time graphical XUL eval thingy that's worth its weight in gold.

Toss in reading about how to create closures in JS (imperative for developing useful OO libraries). And about two serious weeks of sweat equity to get started.

It exists and it's called XUL, used on the Mozilla platform.

Mozilla/Firefox browser uses a XML interface that is better than HTML called XUL. All the extensions for Firefox use XUL and Javascript. But signed XUL&Javascript Apps can be server over the web also. Why not use a better interface language than HTML? Yes it is not compatible with IE, but for better specialized applications it would be work.

the best places for xul reference:
http://www.xulplanet.com/references/elemref/ref_XU LElement.html
http://mb.eschew.org/
http://www.mozilla.org/xpfe/xulref/
http://mozref.com/reference/
http://xulmaker.mozdev.org/xpath-evaluator/no_wrap /xul.xml
http://books.mozdev.org/html/index.html
http://ask.slashdot.org/askslashdot/04/12/28/21442 49.shtml

Schema Definition for xul (xsd)
http://xulmaker.mozdev.org/xpath-evaluator/no_wrap /xul.xsd

For live help you can try channel #xul on irc.mozilla.org. but please patient when asking questions, since most developers are probably very busy managing multiple xul projects.

Does firefox listen on a particular port while it is running?

If this bug were exploitable, then it could very easily install an extension (which is what this bug was all about after all). Once installed, it has access to all of XPCOM, including the networking stuff

http://www.xulplanet.com/references/xpcomref/xpcom ref1.0/nsIProcess.html

If one can call file.launch(), it's one extra step to call process.run().

And Gnome & KDE provide the same "braindead" launch features as Windows. FF would take advantage if it wasn't for the dis-integrated nature of the Linux desktop.

Unfortunately, the exploit could have just as easily created a file starting with #!/bin/sh, and passed 555 as the 'permissions' argument to createUnique.

Why on earth the browser thinks it's necessary to allow scripts to create executeable files is beyond me.

it was wrote as a full application runtime enviroment instead of just a browser, with much of the XUL stuff being useless with the advent of xmlhttprequest and good DOM support in major browsers.

What does ActiveX do that XPCOM and Java are incapable of performing?

I think the correct answer is marketing. The gecko browsers are packed full of some really cool toys for developers. But it's very very hard to sort through it all. Every so often I start playing with various features common to Mozillaish browsers like XPI, XSLT, and Javascript. It always strikes me how much potential there is to make some very cool applications using these. One pet project of mine is to see if I could create a set of XSLT documents that would transform glade projects into XUL applications, which could be themed via css.

It's coming along pretty well, but I find it very difficult to wade through the developer documentation. XULplanet is a great resource, and there's a few others like the DOM ref on moz.org, but it seems pretty scattered, and sometimes out dated, and sometimes it just completely disappears like DevEdge (which there was some talk about being resurrected). In some cases, the only reliable documentation is the moz source itself, which is very hard to navigate without a fair bit of research.

I've never done anything with ActiveX at all, or dealt with Microsoft API's very often at all, but I've seen their documentation, and it seems like its quite a bit more focused, and easy to find things.

Having had to go looking for documentation myself, I think I can see why companies would be reluctant to use Mozilla technologies in house. Is there anybody at the Mozilla foundation that deals strictly with promoting moz as a developer platform, rather than focusing on the browser itself?

> It's the thing Microsoft fears the most - that
> Javascript will evolve into something powerful
> enough to be able to right [ahem] a
> Microsoft Office clone in.

But it already is powerful enough -- it's just that it's either supported badly or not at all in Internet Explorer.

1. MoFo doesn't want to have to fully support two differant projects; they don't have the resources to do that. So it's proposed that there won't be a 1.8 final release, as that would take a lot of QA work and entail still more work later on to keep up with security patches.
2. Obviously some people don't like this. Oddly enough most of them are users of the suite.
3. Several developers have stated that mofo shouldn't continue suite releases, at least not in the same way. None of them have suggested spinning firefox off into a seperate foundation.
4. Slashdot has posted an inflammatory article about the issue; very few people commenting have bothered to go to the primary sources to see whats going on. (Surprise! :))

Here's a couple of people who are happy about the possiblity of Mozilla being discontinued.

earlier I did post story on this subject and get rejected , then I submitted the same story at OSNews here , it's on front page there hours ago, wtf slashdot?
anyway, this is text of story:
In sad news for people who prefer Mozilla Suite over Firefox, seems will be there no Mozilla Suite 1.8 Final while developers already start talking about fork , others are just happy over the situation. More here.

That's just a view on the source. That's not architecture documentation.

From what i've seen, there is a fair bit on extension making, one of my favorite sites is xulplanet.

The problem is with the architecture documentation. Sure you can work out what XPCOM is, easily enough. But if you look at the mailing lists there are a plethora of people working on writing plugins that utilise the javascript interface to XPCOM, and they don't know the difference between invoking an interface and queryInterface.

For the browser market share that firefox has, it should have a lot more plugins being written for it. But many developers are simply putting it in the too hard basket.

Further to the sibling post, Mozillazine's Extensions Dev page has a wealth of fantastic resources for creating stuff. Once you get into the nitty-gritty, XULPlanet is mighty handy (and probably constitutes a lot of the "documentation" you require. Also, O'Reilly's Mozilla book is available free online.

I think it was further expanding on your joke.

http://www.xulplanet.com/

We need to add an xml language to invoke java inside browsers to balance the XAML features IE will provide.

I think what you are describing is already here, has been for a year or 2 now... XUL

I tried designing an XML-based programming language long ago and failed miserably. It just doesn't work out well.

XUL, or something like (lib)Glade is about as far as XML should be taken as a programming language IMHO. It's great for laying out widgets, and defining callbacks, that kind of thing. Beyond that, it just gets in the way.

One of Mozilla's greatest strengths is not as just a web-browser but as a cross-platform application development platform.
Just try playing around with XUL a little. It's surprising what it can do. I'm just starting out with it, but having worked my way through MFC, QT, TCL/TK, WTL, GTK++, FLTK, wxWidgets etc. etc. in search of the One True UI Library, I'm liking what I've seen so far.

I've done a few projects using Smarty. It's pretty nifty, keeps all your markup separate from your code... It has some simple flow control stuff in it that makes the code nice and clean too.

Recently, I've been using this to serve up XUL and it works remarkably well.

If you have never used anything but IE before, I can imagine you somehow feeling that IE served users' needs.

A short list that is more than a year old is found here.

Anyone with a lot of knowledge of both products or the products of other browser makers could come up with many more significant differences. It is horrible to have a Windows user telling of all his problems pleading you to come help and then you are forced to stumble through the web with IE for him because he is too short-sighted to use anything else. That is why he is on Windows with all the problems in the first place, because he was incapable of good analysis.

If IE had never existed, the World Wide Web experience of the user would be just as universal and far richer. If Netscape or others had never existed, it would be far poorer. That is the bottom line, however you want to define the success or failure of technology that has nothing to do with solid technology. What did Microsoft contribute... Active X? There is a real winner. Broken/incompetent standards support to make pages only work in IE if written by IE users? Security holes galore, generally not present in the other browsers? A monoculture (even if the technology had been good, this is a bad thing). Declaring IE a technological success is a statement about you. At Microsoft, the only real success is something that can be abused to dominate, and a rusty, infected blade seems to be of more use to them in surgury to threaten the patient than a good one, so define success in their terms if you like.

Why 'alas'?

Yes, if you are referring strictly to toolbar menus, then menupopup , as well as menu, menubar, etc... are the elements you need. These also have a nice list of Javascript methods that can be called, including 'insertBefore' and 'insertAfter', while many more methods such as 'appendChild' can be called on individual menuitem elements in the menu.

I personally shy away from RDF and the use of mozilla datasources, because they don't really offer that much of use to me. Their performance is not very good, and they really overcomplicate the whole idea of data management. I would much rather simply interact with a regular database and use Javascript to populate menu and list items. If I need to maintain simple lists in memory, Javascript arrays do the job quite well.