Programmers: XUL?

[Foosinho]

Anybody here know how to program in XUL (specifically, write FireFox extensions)? I'm trying to learn how to author XUL documents, and it seems pretty straightforward, but my real problem is getting the extension to install properly into FireFox.

Bueller? Bueller?

[MikeLastort2]

Never even heard of it. Is it a new dialect of XML?

[Foosinho]

Yep. It's a user interface specification in XML. www.xulplanet.com

Of course, I'm familiar with XML - I write web pages in XHTML, and I have written a Java app or two that use XML file-based database structures, but this is a new one. It's pretty complex, and there are no basic "framework" applications out there to start from.

I'm getting there, but the biggest problem is debugging. I wish I could figure out how to get FireFox to dump the parse errors in my XML files to stdout.

[MikeLastort2]

Yep. It's a user interface specification in XML. www.xulplanet.com (http://www.xulplanet.com/)

Of course, I'm familiar with XML - I write web pages in XHTML, and I have written a Java app or two that use XML file-based database structures, but this is a new one. It's pretty complex, and there are no basic "framework" applications out there to start from.

I'm getting there, but the biggest problem is debugging. I wish I could figure out how to get FireFox to dump the parse errors in my XML files to stdout.
I don't know which is geekier. You writing that, or me reading it and understanding what you mean. :)

[Foosinho]

True.

Anyway, The entire FireFox interface is written in XUL (you use JavaScript to actually do things - the XUL just specifies the layout, etc). In fact, since it's an XUL tree, you can actually overlay your own stuff into the FireFox document at runtime - that's how all those extensions modify the UI. The engine takes the XUL files and sticks 'em at the right spot in the tree at loadtime.

[Foosinho]

I'm getting the hang of it now. Problem was, I was cutting and pasting some example code that didn't work because my localization code was busted.

I've now got a barebones working toolbar for FireFox that is hideable, the text can be turned on and off, and it has a few basic BigSoccer links (I'm writing a "BigSoccer" toolbar). The next step is to figure out how to change my avatar by dragging a file over a button on the toolbar.

[JeffS]

Foosihno, I haven't programmed with XUL yet (it's on my eventual "to do" list) but I've been hearing a lot about it lately. The Mozilla founation is starting to really push using Mozilla as a full development platform / environment, using C++, XPCOM, JavaScript, and XUL. In that vain, a couple of highly regarded books that are centerred on Mozilla development have been released. Here they are:

http://www.amazon.com/exec/obidos/ASIN/0131423436/qid=1093041340/sr=ka-1/ref=pd_ka_1/102-8563922-1080116

http://www.amazon.com/exec/obidos/ASIN/0471415804/qid=1093041340/sr=ka-3/ref=pd_ka_3/102-8563922-1080116

Personally, I'm a programming book geek. I find that a good tutorial/reference book gives me a good foundation upon which to build, as well as a reference and guideline with which I can be productive.

I think that the XUL concept is pretty cool - using XML based descriptors to design and implement GUI interfaces. What's also cool about it is that MS is using it's own XML based GUI descriptor, XAML, as a major selling point for the forth-coming Longhorn Windows version. Open Source, with Mozilla's XUL, already has it, and has beaten MS to the punch, by a couple of years (at least).

Anyway, good luck on your XUL excursion. Let us know how it goes and if you would recomend it. Thanks.

[JeffS]

I don't know which is geekier. You writing that, or me reading it and understanding what you mean. :)

You're both a couple of geeks!! :D

I guess it takes one to know one, namely me laping up this thread. :rolleyes:

[MikeLastort2]

You're both a couple of geeks!! :D

I guess it takes one to know one, namely me laping up this thread. :rolleyes:I may have to start a thread about .Net remoting. I'm going nuts trying to get a remote object to broadcast events to listeners when I put the remote object on a server. It all works fine when I run everything on my development box, but as soon as I put the damn thing on a server, my client, which acts as a listener, doesn't get the messages. And the server, which acts as a broadcaster, says there are no clients listening.

It's been driving me nuts since Wednesday.

[JeffS]

I may have to start a thread about .Net remoting. I'm going nuts trying to get a remote object to broadcast events to listeners when I put the remote object on a server. It all works fine when I run everything on my development box, but as soon as I put the damn thing on a server, my client, which acts as a listener, doesn't get the messages. And the server, which acts as a broadcaster, says there are no clients listening.

It's been driving me nuts since Wednesday.

I'm speaking from ignorance on how .Net works, but I might offer a pointer based on experience with other architectures.

First, with Win32 Windows programming (the straight C stuff going directly to the API), the application (the listener) has to go into a message loop, continually having to listen for messages from the OS (like a mouse click or something). Then the message loop grabs the message and disperses it to the message handler, which chooses how to handle the message/event. It only exits the loop when it receives a close message. Also, in the application, you have to declare an Hwnd variable, then make an API call to get the Hwnd variable (handle) of your app. Then there is another API call to get any messages in the message queue addressed either to all the apps or environment, or specific messages for that Hwnd value (the particular app).

Also, in J2EE, when you use EJBs (the event sender), the JSPs or Servlets can retrieve messages in a similar message loop / queue, using a unique identifier for the EJB (at least I remember it that way from my limited experience with JSPs, Servlets and EJBs).

In short, the listener is probably too dumb to look for the messages from the event sender automatically. You have to explicitly create a reference to the sender, then go into a loop/queue waiting for any message that comes in from the sender.

This theory might be way off with .Net, but I'm guessing that .Net has similar logic for remote objects.

One more thing, since the remote object is on a different machine, perhaps a .Net WinSock object is needed in order to listen to and receive any TCP/IP packets.

Maybe these tips will point you in the right direction.

If you do figure it out, could you describe the solution here? I'm very curious.

[MikeLastort2]

I'm speaking from ignorance on how .Net works, but I might offer a pointer based on experience with other architectures.

First, with Win32 Windows programming (the straight C stuff going directly to the API), the application (the listener) has to go into a message loop, continually having to listen for messages from the OS (like a mouse click or something). Then the message loop grabs the message and disperses it to the message handler, which chooses how to handle the message/event. It only exits the loop when it receives a close message. Also, in the application, you have to declare an Hwnd variable, then make an API call to get the Hwnd variable (handle) of your app. Then there is another API call to get any messages in the message queue addressed either to all the apps or environment, or specific messages for that Hwnd value (the particular app).

Also, in J2EE, when you use EJBs (the event sender), the JSPs or Servlets can retrieve messages in a similar message loop / queue, using a unique identifier for the EJB (at least I remember it that way from my limited experience with JSPs, Servlets and EJBs).

In short, the listener is probably too dumb to look for the messages from the event sender automatically. You have to explicitly create a reference to the sender, then go into a loop/queue waiting for any message that comes in from the sender.

This theory might be way off with .Net, but I'm guessing that .Net has similar logic for remote objects.

One more thing, since the remote object is on a different machine, perhaps a .Net WinSock object is needed in order to listen to and receive any TCP/IP packets.

Maybe these tips will point you in the right direction.

If you do figure it out, could you describe the solution here? I'm very curious.
The framework is supposed to take care of all that for you. I'm hosting the remote object in IIS.

Basically, I read from a config file and point to a url that identifies where the remote object resides. When the client points to http:// (putting a space in so it won't look like a url)localhost/ArchitectNet/RemotingServer/Broadcaster.soap, it works fine. It also works fine when I change the name of localhost to the actual name of my machine, in this case. However, when I copy the binaries to the server, and change the configuration file on the client to point to the web server, in this case http:// servername/ArchitectNet/RemotingServer/Broadcaster.soap, it doesn't work.

However, when I actually open the obect in a browser when it's on the server, I can see all its function names. You do that by adding ?wsdl at the end, like http:// servername/ArchitectNet/RemotignServer/Broadcaster.soap?wsdl

My suspiscion at this point is that the problem is the way the network is configured. I'm going to experiment by bringing my laptop from home into work on Monday and trying to host the object there and see if it sees listeners and if the listeners see it.

I'll let you know what I find. I'm using this book http://www.thinktecture.com/Resources/books/default.html#ADR_CSHARP as my guideline to create this stuff. .Net Remoting is a powerful, but kind of unweildy beast.

[JeffS]

The framework is supposed to take care of all that for you. I'm hosting the remote object in IIS.


Could be a problem with IIS configuration.


.Net Remoting is a powerful, but kind of unweildy beast.

Kinda like C++ and J2EE. ;)

[Foosinho]

For those interested, I have a super-alpha version of the toolbar available over here (http://www.bigsoccer.com/forum/showthread.php?t=132766).

[Foosinho]

Anybody want to help test this thing? Offer suggestions. It shouldn't hose your FireFox installation - it's gone in (and been successfully uninstalled) cleanly on a number of different machines for me. Admittedly, it's got a long way to go, but I could use some feedback.

[MikeLastort2]

Could be a problem with IIS configuration.



Kinda like C++ and J2EE. ;)
Figured out what it was. Finally.

I wasn't really doing anything wrong apart from setting my configuration file from reading from the wrong alias. The network admins here have setup aliases to the web servers, but I did not know that. I was pointing to http://ServerName/RemotingServer/Broadcaster.soap when I should've been pointing to http://Aliasname/RemotingServer/Broadcaster.soap. The reason it took so long to figure out was that I could actually see the WSDL (Web Service Definition Language) of the remoting object when I entered http://ServerName/RemotingServer/Broadcaster.soap?wsdl. I finally figured it out yesterday, and it works like a champ. My broadcaster sends messages to all clients, and I filter them out based on the IP address of the web client that initiated the message.

One of these days I'm going to write a white paper about this configuration. I've got a Windows Service that acts as a DDE Server and Client (can receive and send messages) and as an remoting event listener that runs on a client PC.

Hmm, maybe I'll start another thread about what it does and why if any of you geeky types are interested.

[JeffS]

Figured out what it was. Finally.

I wasn't really doing anything wrong apart from setting my configuration file from reading from the wrong alias. The network admins here have setup aliases to the web servers, but I did not know that. I was pointing to http://ServerName/RemotingServer/Broadcaster.soap when I should've been pointing to http://Aliasname/RemotingServer/Broadcaster.soap. The reason it took so long to figure out was that I could actually see the WSDL (Web Service Definition Language) of the remoting object when I entered http://ServerName/RemotingServer/Broadcaster.soap?wsdl. I finally figured it out yesterday, and it works like a champ. My broadcaster sends messages to all clients, and I filter them out based on the IP address of the web client that initiated the message.

One of these days I'm going to write a white paper about this configuration. I've got a Windows Service that acts as a DDE Server and Client (can receive and send messages) and as an remoting event listener that runs on a client PC.

Hmm, maybe I'll start another thread about what it does and why if any of you geeky types are interested.

Those damn network admins and their stupid alias'! ;)

Quite often it's the simple answer that doesn't easily reveal itself, because your looking for something else. That's the way it is with programming sometimes.