Link to my 0.3 XPI file:
http://zenit.senecac.on.ca/wiki/imgs/Ubiquity-0.1.2pre03.zip
Link to project page:
http://zenit.senecac.on.ca/wiki/index.php/Make_Ubiquity_Work_In_Thunderbird
Well... OSD600 has finally come to a close as far as projects are concerned. I must say, this has definitely been my heaviest course this semester. It’s kind of surprising too. When I first looked at the requirements for completing this course, I was kind of like, “No tests? No exam? Wow... that’s awesome.” Well, OSD600 took a complete 180 on me and showed me that it’s not really tests or exams that make a course difficult. It’s the steep learning curve, and amount of work that needs to get done. This course has definitely prevailed in the learning curve and workload department. If it wasn’t for OSD600, I would have been able to do so much more in my GAM666 course and I would have also been able to go outside more than a couple hours a week.
Ok the last part was a joke. I’m a nerd, I don’t go outside... ever. If I wasn’t cursing at Javascript, asking God why Ubiquity hates me, and asking people for direction... I’d be sitting in front of the computer doing something else anyways. One thing I can say for sure, out of all of the courses I’ve taken this semester, OSD600 has taught me the most. This is the first time I’ve ever had to delve through someone else’s code and try to change things. Not just change things mind you, change them to work under a completely different application. At first this was nothing but a complete annoyance. Thank god we had so much time to get our 0.1 done. Fortunately, once I got some momentum, that annoyance gradually disappeared, and turned into a sense of accomplishment. I’ve managed to make a small contribution to an amazing project, and I feel good about that. I’ve also been able to dive right into a community that I’ve never been a part of. I must say, the Mozilla Open Source community is really great and helpful. Without them I couldn’t have completed nearly as much as I currently have.
Anyways, with all that stuff out of the way. It came to my attention that implementing JS Inheritance into Ubiquity to fork the application between Firefox and Thunderbird wasn’t the best direction to go at this point in time. There were too many pre-requisites to getting the ticket done. The best way to go about getting Ubiquity to run in both Firefox and Thunderbird at this point in time was to simply combine parts of code that should work under both applications, and anything that can’t work under both applications, split them using our Utils.getApplicationName() function until they can be dealt with at a later point in time (Most of which are tickets that currently need to be resolved).
As I mentioned in an earlier Blog, when you’re editing out code, I personally feel that it’s a good idea to just comment it out with a comment saying why the code was removed, rather than just out right deleting it. At some points I found code that we had ripped out could just be put back in with no effect what so ever on the current Thunderbird version of Ubiquity. I spent a large portion of my time re-adding code, as well as modifying existing code back to its original state that didn’t touch any of the new changes that were made. This isn’t a bad thing mind you, considering it wasn’t very difficult to rebuild everything. Now I’m sure you’re about to ask... “Hey Scott, did you comment anything?” My answer to you is... “Nope...” Yeah, I know, practice what you preach. I’m bad, very very bad. One of my other professors lectured the class about commenting our code on a regular basis and updating comments if you modify someone else’s code. I’m sure I’ll listen to that stuff one day...
Well, if you load up my XPI you’ll notice that there’s still some console errors showing up in Firefox. Yep... some bugs aren’t totally ironed out yet. I honestly didn’t expect it to actually run as well as it currently is, considering I have no file forks left (ie: duplicate files). So if there’s a console error here and there, at this point I’d have to say I feel pretty good about what I’ve done. Getting those nailed will probably happen some point when the team decides to tackle them. For now, everyone seems to be hitting different things, so we’ll just have to see where everything takes us. In due time everything will get done. I’m also sure someone will get back to me and tell me that even though I’ve managed to get Ubiquity running under both apps, I’ve blown something up somewhere. =)
I would also like to thank David Humphrey for taking time to listen to both my whining and project direction ideas. Even though the final result wasn’t using everything he recommended, he was still a great help when it came to getting me started and pushing me forward. (TOTALLY NOT SUCKING UP HERE! BELIEVE ME!)
I’d like to close off by saying that I believe the hardest part of this course wasn’t relearning my Javascript or the work load OSD600 presented me with. It was simply trying to figure out how Ubiquity worked. I’d say 70% of my total time was just doing that, the rest was spent coding and finding a direction to take. Ubiquity is a wonderful application, and I’m sure a lot of people would be surprised how massive this extension actually is. I'd love to work on this some more... but sadly... exams are upon me and I have to start studying. :(
Friday, December 5, 2008
Sunday, November 30, 2008
OSD600 Lab 11 and 0.3 Update
Alright, first thing's first...
OSD600 Lab:
Another "Create an extension" lab. Been doing this stuff for a while, so it was fairly easy. Got it working quite quickly. Link to my XPI file:
http://zenit.senecac.on.ca/wiki/imgs/Firstxpcomchrome.xpi
I must say, this was another good extensions lab. The walk through was straight forward, the basics were explained quite thoroughly, and reference guides were littered through out the explanation. If only we had done this lab at the beginning of the course... sigh... oh well... :(
0.3 Update:
Sadly I didn't make a legion of blog posts like I said I was going to do this week. Reason being is simply because I was making good progress and really didn't have too many things to complain about. Chances are I shouldn't really be complaining in my blog posts, but let's face it... it's what I do. Just ask David Humphrey, he'll back me up on this.
One thing I would like to mention though is that I've completely scrapped javascript inheritance for this. It was mentioned to me that I should be taking another route to get Ubiquity to work under both Firefox and Thunderbird. I decided to take that advice and move in another direction.
Good news though! I'm really close to eliminating all of the duplicate files. I just have one left. Once that one's eliminated my 0.3 is pretty much coming to a close. If I finish this final file up early this week, I'll probably take the remainder of my time to clean things up a bit.
Until I post next week...
Good luck to everyone else on their 0.3s.
OSD600 Lab:
Another "Create an extension" lab. Been doing this stuff for a while, so it was fairly easy. Got it working quite quickly. Link to my XPI file:
http://zenit.senecac.on.ca/wiki/imgs/Firstxpcomchrome.xpi
I must say, this was another good extensions lab. The walk through was straight forward, the basics were explained quite thoroughly, and reference guides were littered through out the explanation. If only we had done this lab at the beginning of the course... sigh... oh well... :(
0.3 Update:
Sadly I didn't make a legion of blog posts like I said I was going to do this week. Reason being is simply because I was making good progress and really didn't have too many things to complain about. Chances are I shouldn't really be complaining in my blog posts, but let's face it... it's what I do. Just ask David Humphrey, he'll back me up on this.
One thing I would like to mention though is that I've completely scrapped javascript inheritance for this. It was mentioned to me that I should be taking another route to get Ubiquity to work under both Firefox and Thunderbird. I decided to take that advice and move in another direction.
Good news though! I'm really close to eliminating all of the duplicate files. I just have one left. Once that one's eliminated my 0.3 is pretty much coming to a close. If I finish this final file up early this week, I'll probably take the remainder of my time to clean things up a bit.
Until I post next week...
Good luck to everyone else on their 0.3s.
Sunday, November 23, 2008
OSD600 Lab 10 XPCOM
Well, I guess I'll start off by saying that getting this lab to work was slightly annoying. I had a space in the wrong spot and Firefox didn't feel like building with my XPCOM extension because of that. Completely my fault, but annoying none the less.
With that aside, I really liked this lab simply because I like DLLs and COM objects. I've been dealing with COM objects in DirectX and creating my own DLLs for my GUI546 assignment. I didn't learn a whole lot from this lab aside from how Mozilla runs XPCOM. Even then, I can see I still have a LOT to learn about XPCOM beyond what was shown in this lab. The way Mozilla structures their code base is pretty interesting. Sometimes I wish my code was this organized. One day it will be... one day...
Well here's my lab...
http://zenit.senecac.on.ca/wiki/imgs/Firstxpcom.zip
Suppose I'll use this blog to talk about what I've done for my 0.3 (instead of creating a new blog to do it). Sadly I haven't gotten too far in it. Have a few assignments due this coming week that I've been trying to wrap up before I make a serious attempt at completing a 0.3. I've tinkered around with a few things here and there. Been forced to go back to the drawing board as far as getting files merged goes.
Going to try something different for file merges... if that fails me I'm sure you'll all hear about it. Next week is when I start my, "Work on OSD600 assignment 6 hours a day or more" time period once again. Last week it was "Work on OSD600 assignment for 6 hours in total for that week".
I'm sure I'll be cursing at the javascript gods soon enough :)
Until then...
With that aside, I really liked this lab simply because I like DLLs and COM objects. I've been dealing with COM objects in DirectX and creating my own DLLs for my GUI546 assignment. I didn't learn a whole lot from this lab aside from how Mozilla runs XPCOM. Even then, I can see I still have a LOT to learn about XPCOM beyond what was shown in this lab. The way Mozilla structures their code base is pretty interesting. Sometimes I wish my code was this organized. One day it will be... one day...
Well here's my lab...
http://zenit.senecac.on.ca/wiki/imgs/Firstxpcom.zip
Suppose I'll use this blog to talk about what I've done for my 0.3 (instead of creating a new blog to do it). Sadly I haven't gotten too far in it. Have a few assignments due this coming week that I've been trying to wrap up before I make a serious attempt at completing a 0.3. I've tinkered around with a few things here and there. Been forced to go back to the drawing board as far as getting files merged goes.
Going to try something different for file merges... if that fails me I'm sure you'll all hear about it. Next week is when I start my, "Work on OSD600 assignment 6 hours a day or more" time period once again. Last week it was "Work on OSD600 assignment for 6 hours in total for that week".
I'm sure I'll be cursing at the javascript gods soon enough :)
Until then...
Friday, November 14, 2008
0.2 Ubiquity in Thunderbird is up.
Link to 0.2 release:
http://zenit.senecac.on.ca/wiki/imgs/Ubiquity-0.1.2pre.zip
Link to project page:
http://zenit.senecac.on.ca/wiki/index.php/Make_Ubiquity_Work_In_Thunderbird
Well... I sort of had big plans for 0.2. Thankfully, one of those plans came through. I was really hoping that I could get what I was planning to do for my 0.3 into my 0.2 instead, but I’m having too many problems getting it to work properly.
Oh well no worries. What my 0.2 essentially does, is it allows Ubiquity to pop up in both Firefox and Thunderbird using the same XPI file. That means, you can install Ubiquity in either application using the same extension. There’s no need to create two separate extensions and maintain them both. In my eyes, that’s a huge hassle, and I can see why everyone wants it done this way. To be quite honest, getting it to run in two separate applications wasn’t too difficult, especially after I David Humphrey gave me some tips on a direction to take. What IS hard is finding a way to get EVERYTHING to work properly without bloating the code.
** Rant about my experience on the project. Skip this if you don’t want to read! **
What do parts of the code do I bloat, and what don’t I? Sadly, I think that if I want to get Ubiquity working in both Firefox and Thunderbird, one way or another I’m going to have to add lots of code. I don’t think there’s really a way around it. I’ve been making an attempt to use Javascript’s inheritance feature to help Ubiquity manage itself depending on its environment. But you know... sometimes I just look at things I’m doing and say to myself, “It would be a lot easier if I just used an if / else if here to do things, but it’s easier here to inherit things.” Of course, if I go ahead and slap ifs everywhere, I have to be careful. What if this thing gets ported to another program? That means someone will have to go through all the code and manage any ifs I put in. That’s not cool, especially considering that there’s almost NO COMMENTING throughout the Ubiquity code.
I can’t stand uncommented code. We’ve been taught that it’s a standard to comment your code and keep your comments up to date every time you change something. Sadly, in an open source environment, you probably have a hard time forcing people to comment things. Another problem I’m having with separating the Ubiquity code is that I have to learn everything that Ubiquity does. If I screw something up it breaks the program. Fortunately, I’m not as lost as I was when I first started. I’m to the point now where I can figure out what does what without asking a ton of questions. In fact, sometimes I find myself editing my old code and saying to myself, “Why did I do this? It’s stupid. It works but it’s still dumb.”
I think at this point my biggest problem is fighting against the code that we created. As I mentioned above, this includes my own code. We cut out so much of the code just to get Ubiquity to fire up in Thunderbird, it’s very hard to figure out what was removed. In a lot of cases what I would consider important code was just ripped out of the program. I’m guilty of this too. I did a lot of code ripping. “If Ubiquity works without this code, and this code is making it break, get rid of it!” That was my philosophy while getting this to work in TB. I should have just commented things out.
I have a pretty good example of why I wish we had just commented out (with comments saying WHY we were removing something). Last week one of our team members, Justin, couldn’t get previewBlock to work properly for the map command. It kept returning null and he couldn’t figure out what was wrong. I checked out the Thunderbird code, and it looked like previewBlock WAS getting set properly. I then decided to check out the Firefox code and compare the two. Well, the line that previewBlock used to set itself to the browser’s current window was ripped out. That’s why it was null, and why it wouldn’t work.
Sadly, despite my rant on commenting, I still haven’t added a single comment. I really need to get around to doing that, but I’ve been caught up in the “rush to release” momentum.
** END RANT. **
In a few cases, I haven’t been able to get some things to stop throwing errors up in Firefox. It’s not a big deal though, they still run with the errors. I’m just going to leave them for now and work on “organizing” things. I’d really like to eliminate the last few TB_ files I added. Just completely merge everything.
Ok so what can you expect from this build? It runs in both Firefox and Thunderbird. Is it fully functional in Firefox? Close. Is it fully functional in Thunderbird? Nah, not really. It’s getting a lot better though. I’m not sure how complete our new annotation service is for Thunderbird. I do know one thing though, it blows up in Firefox. Not sure what I’m going to do about that. Currently I’m making Firefox use its built in annotation service (what Ubiquity did originally). So that works fine as long as I keep that functionality separate.
At this point someone has made Ubiquity force Thunderbird to choose a web browser whenever you want to use a command that requires a tab. I’m not too keen on this idea but I’m not touching it unless everyone wants it changed. So it’s going to stay this way for a while unless everyone decides they want to change it. The biggest problem I have with this method is that if you don’t have Ubiquity installed in Firefox, any commands that require you to choose to run Firefox will blow up. Firefox won’t be able to find the internal URL and will say it is invalid. So if you want your command-editor from Thunderbird to pop up in Firefox using this method, make sure Firefox has Ubiquity installed.
As far as what’s inside the code in this release, I’m not releasing any code with my attempts at using JS inheritance. There’s just way too many problems, and removing things that break just to get a release out is kind of pointless (and a monumental waste of time), considering the inheritance won’t actually DO anything if I go that route. So I’m releasing our “cleanest” build, straight off of our repository.
If I manage to get my structure worked out without bloating our code too much within the next week or two, I might just release a 0.2.1 for anyone that’s interested.
http://zenit.senecac.on.ca/wiki/imgs/Ubiquity-0.1.2pre.zip
Link to project page:
http://zenit.senecac.on.ca/wiki/index.php/Make_Ubiquity_Work_In_Thunderbird
Well... I sort of had big plans for 0.2. Thankfully, one of those plans came through. I was really hoping that I could get what I was planning to do for my 0.3 into my 0.2 instead, but I’m having too many problems getting it to work properly.
Oh well no worries. What my 0.2 essentially does, is it allows Ubiquity to pop up in both Firefox and Thunderbird using the same XPI file. That means, you can install Ubiquity in either application using the same extension. There’s no need to create two separate extensions and maintain them both. In my eyes, that’s a huge hassle, and I can see why everyone wants it done this way. To be quite honest, getting it to run in two separate applications wasn’t too difficult, especially after I David Humphrey gave me some tips on a direction to take. What IS hard is finding a way to get EVERYTHING to work properly without bloating the code.
** Rant about my experience on the project. Skip this if you don’t want to read! **
What do parts of the code do I bloat, and what don’t I? Sadly, I think that if I want to get Ubiquity working in both Firefox and Thunderbird, one way or another I’m going to have to add lots of code. I don’t think there’s really a way around it. I’ve been making an attempt to use Javascript’s inheritance feature to help Ubiquity manage itself depending on its environment. But you know... sometimes I just look at things I’m doing and say to myself, “It would be a lot easier if I just used an if / else if here to do things, but it’s easier here to inherit things.” Of course, if I go ahead and slap ifs everywhere, I have to be careful. What if this thing gets ported to another program? That means someone will have to go through all the code and manage any ifs I put in. That’s not cool, especially considering that there’s almost NO COMMENTING throughout the Ubiquity code.
I can’t stand uncommented code. We’ve been taught that it’s a standard to comment your code and keep your comments up to date every time you change something. Sadly, in an open source environment, you probably have a hard time forcing people to comment things. Another problem I’m having with separating the Ubiquity code is that I have to learn everything that Ubiquity does. If I screw something up it breaks the program. Fortunately, I’m not as lost as I was when I first started. I’m to the point now where I can figure out what does what without asking a ton of questions. In fact, sometimes I find myself editing my old code and saying to myself, “Why did I do this? It’s stupid. It works but it’s still dumb.”
I think at this point my biggest problem is fighting against the code that we created. As I mentioned above, this includes my own code. We cut out so much of the code just to get Ubiquity to fire up in Thunderbird, it’s very hard to figure out what was removed. In a lot of cases what I would consider important code was just ripped out of the program. I’m guilty of this too. I did a lot of code ripping. “If Ubiquity works without this code, and this code is making it break, get rid of it!” That was my philosophy while getting this to work in TB. I should have just commented things out.
I have a pretty good example of why I wish we had just commented out (with comments saying WHY we were removing something). Last week one of our team members, Justin, couldn’t get previewBlock to work properly for the map command. It kept returning null and he couldn’t figure out what was wrong. I checked out the Thunderbird code, and it looked like previewBlock WAS getting set properly. I then decided to check out the Firefox code and compare the two. Well, the line that previewBlock used to set itself to the browser’s current window was ripped out. That’s why it was null, and why it wouldn’t work.
Sadly, despite my rant on commenting, I still haven’t added a single comment. I really need to get around to doing that, but I’ve been caught up in the “rush to release” momentum.
** END RANT. **
In a few cases, I haven’t been able to get some things to stop throwing errors up in Firefox. It’s not a big deal though, they still run with the errors. I’m just going to leave them for now and work on “organizing” things. I’d really like to eliminate the last few TB_ files I added. Just completely merge everything.
Ok so what can you expect from this build? It runs in both Firefox and Thunderbird. Is it fully functional in Firefox? Close. Is it fully functional in Thunderbird? Nah, not really. It’s getting a lot better though. I’m not sure how complete our new annotation service is for Thunderbird. I do know one thing though, it blows up in Firefox. Not sure what I’m going to do about that. Currently I’m making Firefox use its built in annotation service (what Ubiquity did originally). So that works fine as long as I keep that functionality separate.
At this point someone has made Ubiquity force Thunderbird to choose a web browser whenever you want to use a command that requires a tab. I’m not too keen on this idea but I’m not touching it unless everyone wants it changed. So it’s going to stay this way for a while unless everyone decides they want to change it. The biggest problem I have with this method is that if you don’t have Ubiquity installed in Firefox, any commands that require you to choose to run Firefox will blow up. Firefox won’t be able to find the internal URL and will say it is invalid. So if you want your command-editor from Thunderbird to pop up in Firefox using this method, make sure Firefox has Ubiquity installed.
As far as what’s inside the code in this release, I’m not releasing any code with my attempts at using JS inheritance. There’s just way too many problems, and removing things that break just to get a release out is kind of pointless (and a monumental waste of time), considering the inheritance won’t actually DO anything if I go that route. So I’m releasing our “cleanest” build, straight off of our repository.
If I manage to get my structure worked out without bloating our code too much within the next week or two, I might just release a 0.2.1 for anyone that’s interested.
Sunday, November 9, 2008
My late OSD600 Lab 7...
Sadly I when we started this lab, I didn't finish it. I then lost the link for the build of Firefox we were supposed to use and have fell behind in doing this lab since then. Well, I got some free time today so I decided to use my own back up build of Firefox. Played around with it for a bit (2 hours) then decided to use the "guide" for some help. I'm not ashamed, I needed a bit of guidance.
Here's my patch:
http://zenit.senecac.on.ca/wiki/imgs/Tabpatch.zip
Not a bad lab. Very time consuming if you don't know where to look or what to change. Extension lab was much easier. I haven't dove into the Firefox code at all, so creating an extension out of this (lab 8) was a ton easier for me.
Well... that was a nice "break" from my 0.2 for a few hours.
Here's my patch:
http://zenit.senecac.on.ca/wiki/imgs/Tabpatch.zip
Not a bad lab. Very time consuming if you don't know where to look or what to change. Extension lab was much easier. I haven't dove into the Firefox code at all, so creating an extension out of this (lab 8) was a ton easier for me.
Well... that was a nice "break" from my 0.2 for a few hours.
Wednesday, November 5, 2008
Ubiquity runs in TB and Firefox!
Alright, finally got Ubiquity to run in both Firefox and TB using the same extension. I did it a lot faster than I had originally anticipated thanks to some pointers from David Humphrey.
Now it's just a matter of brushing up on my javascript and figuring out how I want to go about merging some of the files I wasn't able to completely merge. On top of that I have some bugs to fix that's causing Firefox to spit out some console errors when Ubiquity first loads (fortunately it doesn't affect Firefox's ability to run Ubiquity).
I'm pretty sure at this point that I won't be able to get the remaining Firefox and TB stand alone files merged by the time I need to hand in my 0.2, but at least I can get started on it. I probably won't be committing anything to the repository until I get something in that "works". I wouldn't want to add in some functionality to merge the files that didn't work properly and send it out.
Also, jono asked me to write up some documentation outlining the changes that I've made. That's going to take quite some time. I'll probably work on this primarily so that others can see what I've done and work with everything that I've changed (or help me make it better).
Now it's just a matter of brushing up on my javascript and figuring out how I want to go about merging some of the files I wasn't able to completely merge. On top of that I have some bugs to fix that's causing Firefox to spit out some console errors when Ubiquity first loads (fortunately it doesn't affect Firefox's ability to run Ubiquity).
I'm pretty sure at this point that I won't be able to get the remaining Firefox and TB stand alone files merged by the time I need to hand in my 0.2, but at least I can get started on it. I probably won't be committing anything to the repository until I get something in that "works". I wouldn't want to add in some functionality to merge the files that didn't work properly and send it out.
Also, jono asked me to write up some documentation outlining the changes that I've made. That's going to take quite some time. I'll probably work on this primarily so that others can see what I've done and work with everything that I've changed (or help me make it better).
Tuesday, November 4, 2008
OSD600 Lab 8
Well, considering my project for OSD600 has been to port Ubiquity over to Thunderbird, needless to say, I didn't get very much out of a lab that was meant to teach us how to build a simple extension. Link to my XPI file:
http://zenit.senecac.on.ca/wiki/imgs/Addtabbeside.xpi
For those that haven't been working on an extension related project so far, I'd say that this was a great lab to go through. I read through the walk through David Humphrey posted and it did a great job of out lying the very basics needed to create an extension for Firefox.
After reading through the lab, I decided that I'd just go ahead and make the directory structure and files, then copy paste the code he wanted us to use into those files. I already have a handle on how install.rdf and chrome.manifest operate, so creating the directory structure was a no brainer.
If you haven't completed the lab, your directory structure should look like this:
\addtabbeside\
\addtabbeside\chrome
\addtabbeside\chrome\content
Then you should have the following files in these locations:
\addtabbeside\install.rdf
\addtabbeside\chrome.manifest
\addtabbeside\chrome\content\addtabbeside.js
\addtabbeside\chrome\content\overlay.xul
I noticed a few people in the lab were trying to create addtabbeside@senecac.on.ca as as a directory. That's supposed to be a simple text file that has a link to your extension. So just open a text editor and save the file as that name but make sure there's no .txt at the end. Then put the path to your extension inside the file and save it.
As a final note, if anyone needs help with this lab I'll be on irc.mozilla.org in #seneca as slunel. If I don't respond to you right away there's a big possibility that I might be afk but I'll get back to you when I have time.
http://zenit.senecac.on.ca/wiki/imgs/Addtabbeside.xpi
For those that haven't been working on an extension related project so far, I'd say that this was a great lab to go through. I read through the walk through David Humphrey posted and it did a great job of out lying the very basics needed to create an extension for Firefox.
After reading through the lab, I decided that I'd just go ahead and make the directory structure and files, then copy paste the code he wanted us to use into those files. I already have a handle on how install.rdf and chrome.manifest operate, so creating the directory structure was a no brainer.
If you haven't completed the lab, your directory structure should look like this:
\addtabbeside\
\addtabbeside\chrome
\addtabbeside\chrome\content
Then you should have the following files in these locations:
\addtabbeside\install.rdf
\addtabbeside\chrome.manifest
\addtabbeside\chrome\content\addtabbeside.js
\addtabbeside\chrome\content\overlay.xul
I noticed a few people in the lab were trying to create addtabbeside@senecac.on.ca as as a directory. That's supposed to be a simple text file that has a link to your extension. So just open a text editor and save the file as that name but make sure there's no .txt at the end. Then put the path to your extension inside the file and save it.
As a final note, if anyone needs help with this lab I'll be on irc.mozilla.org in #seneca as slunel. If I don't respond to you right away there's a big possibility that I might be afk but I'll get back to you when I have time.
Subscribe to:
Posts (Atom)