My OperaThe making of the widget
By Magnus KristiansenDashiva. Monday, July 31, 2006 4:48:01 PM
Here's how we make the widgets at widgetize.
This step may seem obvious, but the first and most important step is actually creating a working widget. As a matter of fact, it's even more work than creating a regular widget, since you need to make sure it works on any site, any feed, any crazy username, etc etc.
This usually means making an easily skinned widget. A popular approach is to make a 'base' CSS file with all the positioning and layout, and a second 'skin' CSS file with colors and other skin-specific styling. You're doing it right if you can just delete the old skin folder and copy in a new one, and the widget still works.
Of course, the real work is creating the images to be used. Unless you have apet designer reliable designer comrade, that is. But few people have that luxury.
Now that we have a working widget, we need to make it flexible. A feed reader needs to be able to take any feed URL as input, and we don't want to go messing around in the JS files for every instance of something that should be changed.
Instead, we have a file called config.js. This contains a single JS object, called SkeletonConfig. The object has properties for all the variable variables, so to say. Below is a copy of the config.js from this blog's feed reader widget.
We have the feed URL, the widget title, the feed type and the maximum number of feed entries to present. 'generic' in this case means the feed parser should detect whether it's getting Atom or RSS.
This means finding all the places you used that feed URL and replacing them with skeletonConfig['feedURL'] -- or you can just set the variable you were using equal to skeletonConfig['feedURL'] during the widget initiation. Do the same for other input from config.js.
Another important point here is that we set document.title = skeletonConfig['feedTitle']. This may seem odd at first, since widgets don't have any chrome to show the title in. However, this is also the name used for the widget's taskbar text. And what about the widgetname in the widget list (config.xml entry)? Well, we actually change that on the fly while creating the widget zip since it's not possible to modify after the widget is installed.
If you're saving data between uses, you also have to make sure you don't accidentally override your stored preferences with the defaults, or override the defaults with the initially undefined preferences. Lots of fun to be had for all.
A final touch is needed to make it all come together. But that's another story.
1. Make a widget
This step may seem obvious, but the first and most important step is actually creating a working widget. As a matter of fact, it's even more work than creating a regular widget, since you need to make sure it works on any site, any feed, any crazy username, etc etc.
2. Make several independent skins
This usually means making an easily skinned widget. A popular approach is to make a 'base' CSS file with all the positioning and layout, and a second 'skin' CSS file with colors and other skin-specific styling. You're doing it right if you can just delete the old skin folder and copy in a new one, and the widget still works.
Of course, the real work is creating the images to be used. Unless you have a
3. Create a config.js
Now that we have a working widget, we need to make it flexible. A feed reader needs to be able to take any feed URL as input, and we don't want to go messing around in the JS files for every instance of something that should be changed.
Instead, we have a file called config.js. This contains a single JS object, called SkeletonConfig. The object has properties for all the variable variables, so to say. Below is a copy of the config.js from this blog's feed reader widget.
var skeletonConfig = {
feedURL : "http://my.opera.com/widgetize/xml/atom/blog/",
feedTitle : "Widgetize! blog",
feedVersion : "generic",
maxItems : 9
};
We have the feed URL, the widget title, the feed type and the maximum number of feed entries to present. 'generic' in this case means the feed parser should detect whether it's getting Atom or RSS.
4. Use the config.js
This means finding all the places you used that feed URL and replacing them with skeletonConfig['feedURL'] -- or you can just set the variable you were using equal to skeletonConfig['feedURL'] during the widget initiation. Do the same for other input from config.js.
Another important point here is that we set document.title = skeletonConfig['feedTitle']. This may seem odd at first, since widgets don't have any chrome to show the title in. However, this is also the name used for the widget's taskbar text. And what about the widgetname in the widget list (config.xml entry)? Well, we actually change that on the fly while creating the widget zip since it's not possible to modify after the widget is installed.
If you're saving data between uses, you also have to make sure you don't accidentally override your stored preferences with the defaults, or override the defaults with the initially undefined preferences. Lots of fun to be had for all.
... and then the magic
A final touch is needed to make it all come together. But that's another story.
images have been appearing in address bars all over My Opera. This is the first part of the Widgetize! project. We won't reveal the next steps yet, but stay tuned...
