Progress Update

Our "beta" due date is Monday the 4th, so in anticipation I have been working like a mad man to finish this widget. The main things that were needed to be done were transitioning to yet another renovated copy of xul-manager, implementing live icons (using a canvas), including stylesheets, and fixing a few bugs. As of now I have transitioned and implemented a live icon. Although Eric Slenk, has found a way to include the stylesheets.

Since our Xul-manager does not allow contain functionality to handle live icons itself, I had to get crafty. The most difficult part about implementing it was getting the live icon to appear in the chrome before on view showing was called. This is because only when onViewShowing is called is the document set in the widget. Meaning canvas and other elements that were needed could not be created before, meaning a page worker was needed to handle the processing. On top of this fact, the weather information is also retrieved via a page worker. So having everything be in sync has been a challenge.
Also problematic was the fact that the weather widget required two different sizes of icons, one for the window like images and one for the standard thunderbolt, if no city is selected.

Right now we are still having bugs with the navbar panel. It does not let a button's click or command event fire without closing the panel. Therefore trying to create an interactive application when the panel doesn't want to stay open is impossible. We have been looking for a solution but have not found one that works 100%.

XML Parsing

In the weather widget we need to be able to parse the Xml that is returned from the yahoo weather api. Unfortunately we cannot use jQuery and do not readily have access to the DOM through our DomHelper module. This complicates things tremendously. Eric S. mentioned the possibility of using an XmlHttpRequest in a worker to get around it, but I would rather find a cleaner way. I'm going to be experimenting with this and chrome url for the next day or two.

Xul-Manager and Other Topics

This morning I noticed a few issues with our xul-manager, specifically it's lack of error checking in some cases. I only noticed it due to the fact that the widget would act slightly different when the browser console was open. I added a little bit of error checking and it functions considerably better, as in it functions the same regardless of whether the console is open or closed. But I feel that this module of ours could still use a good looking over.

Now, regarding the stylesheets. We have not been able to use external stylesheets because we needed to use chrome urls in the bootstrapped extensions, something we had no idea how to do. However, Dave figured this out and we should be able to now include stylesheets directly in the xul.

We now are finding that using jQuery is impossible, so the weather widget's xml parsing functions will have to be rewritten to not use jQuery. I would absolutely love to be able to use jQuery. It would significantly influence how I feel about writing add-ons for Firefox.

Also the hamburger menu panel does not currently expand to accommodate the size of the subviews, making horizontal scrolling necessary. It would be great if it could match the size of the subview, or at least up to the size of the browsers main window.

Weather Widget Demo

The demo can be viewed at:
http://www.cse.msu.edu/~properer/videos/Demo.swf

Transition to Xul-Manager

The weather widget is now using the xul-manager that we have created for handling the xul-injection, handling of multiple windows, etc.. It's not going as well as I had hoped, but it isn't going horribly. It seems that every time a problem is solved two more take it's place. Currently the weather widget can add a city, delete a city, favorite a city, and all that. However we are still kind of looking for a way to use a stylesheet and make requests in a reasonable manner. The weather widget can send off requests to get the woeid and forecast for the woeid, but they are asynchronous and it is not as simple as calling output_display() after returning from the function that contains the request. That is something that I would absolutely love to be able to do. Another thing is the use of jQuery would make my life so much easier. I had currently used jQuery for xml parsing, however now I have to find some other way of doing the parsing.

Transition to Widget-Manager

Our groups is currently in the process of transitioning from the SDK's widget and panel to xul-injection. So far it has been extremely messy, even simple things like including a stylesheet or image takes a great deal of thought, considering we are using html inside a xul file. Not to mention the widget includes countless event handlers that all modify the html. We have been able to include a image for the widgets icon, and we have a good idea of how we can handle live icons. But referencing internal images or files from the xul seems to be giving me a problem, particularly relative paths. This seems to be solved in the firefox extensions by using the "chrome://......." path. However we don't share the same type of structure with an extension, so this doesn't work. I'm still investigating other methods.

Simple Preferences to Preferences/Service

This morning I switched over the weather widget to use the preferences/service module instead of the simple prefs. It works very well, and makes more of a difference than I had previously anticipated. When using simple preferences the constant updating combined with the listeners caused the widget to appear very glitchy. For instance, when hovering over an element it would almost "shake" as would any text fields. I believe this was the result of the asynchronous calls, that update the prefs, being delayed. Anyways, the preferences/service module has made it possible to have a clean onLoad function to load any preferences on installation or on startup. I tried doing the same with a "write to prefs" functionality in the exports.onUnload, but the asynchronous call to the content scripts to do so is delayed for too long. I simply made it save to the prefs on any city woeid change. This isn't as nice, but it will have to do.

IndexDB and Weather Widget

Right now we are using simple preferences in the weather widget and are finding it extremely hard to manage. It would probably work okay if simple preferences worked like a form submission and allowed for rules to be placed on the fields. By this I mean if we were allowed to validate the form before modifying the actual data that would be great. Also, Eric S. determined that exposing the WOEID for the cities to user isn't all that useful, since few would would use it. Since this isn't possible I feel moving to IndexDB would be a good move.

Simple-Prefs

I have figured out the problem to the simple-prefs appearing read only. I mistakenly had the preferences set as strings yet I was writing integers to them. Now the simple prefs seem to work reasonably well. I'm not a huge fan of allowing the users to modify the information from the add-on manager. I especially dislike the fact that the listener, that I have on the preferences, does not trigger until the user enters information. By this I mean that if the user erases information, by highlighting and pressing delete, the listener does not trigger my on-pref-change function. It would be great if the preferences menu appeared more like a submission form, having the user press a button to trigger the changes.

After dealing with simple-prefs, I think it is in the best interest of the widget to do some restructuring. Fixing some of the "hacks" now should hopefully make it easier when we fully figure out the XUL injection. Luckily the code base of the widget isn't large, so it shouldn't be a problem.

Browser Issues

I do not know what has happened to the most recent update for firefox (nightly). It seems really glitchy. For instance, every now and then when modifying add-ons preferences the top chrome goes crazy on shading leaving a shadow where tabs once were. Also all html elements in the add-ons appear really shaky. Weird.....