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.
Narrowed down my search!
I've finally managed to narrow down what files need to be changed in order to get our TB version of Ubiquity to launch in Firefox again. The following files we have that need to be replaced by the Firefox versions are:
/chrome.manifest
/defaults/preferences/preferences.js
/chrome/content/browser.xul
/chrome/content/builtinfactories.js
/chrome/content/cmdutils.js
/chrome/content/nlparser/parser.js
/chrome/content/nlparser/verbtypes.js
Now, if you only include:
/chrome.manifest
/chrome/content/browser.xul
/chrome/content/builtinfactories.js
The window will show up but commands won't work at all. So ultimately I want to get all of the files working eventually. So I have at minimum 3 files to worry about, and after that 4 more (a total of 7 files that need modification). Naturally, even after editing all 7 files, there's still going to be errors popping up in Firefox (a big one with the map command), but at the very least, I know how to "reverse engineer" what we've done to the point that I can get Ubiquity popping up in Firefox again. If I can just change the code to create/manage variables and functions based upon the environment Ubiquity is running under, I'm sure I can get Ubiquity to pop up in both Firefox and TB.
/chrome.manifest
/defaults/preferences/preferences.js
/chrome/content/browser.xul
/chrome/content/builtinfactories.js
/chrome/content/cmdutils.js
/chrome/content/nlparser/parser.js
/chrome/content/nlparser/verbtypes.js
Now, if you only include:
/chrome.manifest
/chrome/content/browser.xul
/chrome/content/builtinfactories.js
The window will show up but commands won't work at all. So ultimately I want to get all of the files working eventually. So I have at minimum 3 files to worry about, and after that 4 more (a total of 7 files that need modification). Naturally, even after editing all 7 files, there's still going to be errors popping up in Firefox (a big one with the map command), but at the very least, I know how to "reverse engineer" what we've done to the point that I can get Ubiquity popping up in Firefox again. If I can just change the code to create/manage variables and functions based upon the environment Ubiquity is running under, I'm sure I can get Ubiquity to pop up in both Firefox and TB.
Monday, November 3, 2008
Ubiquity in TB once again...
Alright, I finally have some time to put some more effort into the Ubiquity to Thunderbird project. Been swamped with other things recently, but I should be good to go at it some more now.
I'm considering making something along the lines of this my goal for 0.2 http://labs.toolness.com/trac/ticket/389 . Now... I don't intend to get the entire thing working. I think that's going to be extremely difficult to do, considering Justin Foong has informed me that http://labs.toolness.com/trac/ticket/325 is a pre-requisite to 389.
I've been checking out the code that's been changed recently and I think I'm going to attempt to simply get Ubiquity to pop up in Firefox again. The Thunderbird version that pops up in Thunderbird is broken in Firefox and won't show up there.
I played around with our current TB extension build to see if I could get Ubiquity to show in Firefox. Naturally, I wasn't able to do it. So I did the next best thing, process of elimination. I figure, if I can figure out which folders I need to work with to get Ubiquity to show up in Firefox, that's a good start. Our Ub-TB (calling it this to make it shorter) directory structure looks like this at the moment:
/Ubiquity
/Ubiquity/chrome
/Ubiquity/components
/Ubiquity/defaults
/Ubiquity/modules
/Ubiquity/scripts
/Ubiquity/standard-feeds
Of course there's sub directories inside of those sub directories but that's not important for now. So, I make a back up copy of the Ub-TB extension for quick/easy access. First thing I try, copy the ENTIRE Firefox Ubiquity root folder on top of Ub-TB's. Load it into Firefox, it works (but with some errors). Ok, at least it shows. Now I recopy Ub-TB over top of the modified Ub-TB and start over. I start by copying each directory over top of one another until I find a pattern that makes Ubiquity show up in Firefox.
I found out that I need to work with the following:
/Ubiquity/chrome
/Ubiquity/defaults
/Ubiquity/chrom.manifest (file)
If I copy those over, all is well. If one thing is not copied, it doesn't show up.
/Ubiquity/defaults is small, I shouldn't have a problem working with that.
Our manifest file is small, no problem there either.
/Ubiquity/chrome is massive. God help me there.
I think my next process of elimination is to simply work with /Ubiquity/chrome using the Firefox manifest file and defaults directory. Once I can get it to show up in Firefox altering chrome, I'll modify manifest and defaults to get something that works in both Firefox and TB.
At least... that's my plan. God knows if it will work, and I'm kind of short on time to do it. If it fails, I'm doomed. Oh well, I like being pressured, makes things interesting!
Thankfully, someone was kind enough to create a function that determines whether or not we're running in Firefox or Thunderbird. If worse comes to worse, I'll just litter the code with comparisons. (if app is Firefox do stuff, otherwise do Thunderbird stuff).
I'm sure this may all explode in my face and I might realize that doing everything this way is insane, but I'm not quite sure what else to do about getting Ubiquity to show in Firefox. On the other hand, someone might tell me that I'm crazy and shouldn't do it this way, so I might do something else for my 0.2... who knows. Oh well, until next time...
I'm considering making something along the lines of this my goal for 0.2 http://labs.toolness.com/trac/ticket/389 . Now... I don't intend to get the entire thing working. I think that's going to be extremely difficult to do, considering Justin Foong has informed me that http://labs.toolness.com/trac/ticket/325 is a pre-requisite to 389.
I've been checking out the code that's been changed recently and I think I'm going to attempt to simply get Ubiquity to pop up in Firefox again. The Thunderbird version that pops up in Thunderbird is broken in Firefox and won't show up there.
I played around with our current TB extension build to see if I could get Ubiquity to show in Firefox. Naturally, I wasn't able to do it. So I did the next best thing, process of elimination. I figure, if I can figure out which folders I need to work with to get Ubiquity to show up in Firefox, that's a good start. Our Ub-TB (calling it this to make it shorter) directory structure looks like this at the moment:
/Ubiquity
/Ubiquity/chrome
/Ubiquity/components
/Ubiquity/defaults
/Ubiquity/modules
/Ubiquity/scripts
/Ubiquity/standard-feeds
Of course there's sub directories inside of those sub directories but that's not important for now. So, I make a back up copy of the Ub-TB extension for quick/easy access. First thing I try, copy the ENTIRE Firefox Ubiquity root folder on top of Ub-TB's. Load it into Firefox, it works (but with some errors). Ok, at least it shows. Now I recopy Ub-TB over top of the modified Ub-TB and start over. I start by copying each directory over top of one another until I find a pattern that makes Ubiquity show up in Firefox.
I found out that I need to work with the following:
/Ubiquity/chrome
/Ubiquity/defaults
/Ubiquity/chrom.manifest (file)
If I copy those over, all is well. If one thing is not copied, it doesn't show up.
/Ubiquity/defaults is small, I shouldn't have a problem working with that.
Our manifest file is small, no problem there either.
/Ubiquity/chrome is massive. God help me there.
I think my next process of elimination is to simply work with /Ubiquity/chrome using the Firefox manifest file and defaults directory. Once I can get it to show up in Firefox altering chrome, I'll modify manifest and defaults to get something that works in both Firefox and TB.
At least... that's my plan. God knows if it will work, and I'm kind of short on time to do it. If it fails, I'm doomed. Oh well, I like being pressured, makes things interesting!
Thankfully, someone was kind enough to create a function that determines whether or not we're running in Firefox or Thunderbird. If worse comes to worse, I'll just litter the code with comparisons. (if app is Firefox do stuff, otherwise do Thunderbird stuff).
I'm sure this may all explode in my face and I might realize that doing everything this way is insane, but I'm not quite sure what else to do about getting Ubiquity to show in Firefox. On the other hand, someone might tell me that I'm crazy and shouldn't do it this way, so I might do something else for my 0.2... who knows. Oh well, until next time...
Sunday, November 2, 2008
FSOSS
I've finally managed to get some free time to write about my FSOSS experience. David Humphrey informed our class at the beginning of the semester that we'd have to attend the FSOSS event and write a blog about it.
First thing I have to mention is, quite a few topics at FSOSS really didn't grab my attention. There's only two topics at FSOSS that interested me, so I'll suppose I'll talk about those. For “Open Source Designe” we got some bits and pieces about gimp, inkspace, blender3d, and how designers use CSS, PHP, and JS. I found the talk very interesting and I’m glad that I went.
The "Open Source Design" presentation was held by two speakers, Brendan Sera-Shriar and Geoff Palini. Now forgive me if my memory is off, but I believe Geoff was the main speaker. With the entire conference not really being about design put aside, the man did quite a good job trying to get his point across. He introduced us to quite a few open source art software packages. Gave us a demonstration of how well they could compete against closed source software packages, and gave us a little 3d demo at the end. He also informed us about Red5, an alternative flash resource to the conventional, "Pay $1 for every user that uses our flash server." Now this is useful information because flash is expensive. This seems to be a very nice way for companies to save money when they run a flash based website.
Geoff mentioned something during his presentation that caught my attention. He said that he believes that design and programming shouldn't be treated like separate entities. Instead they should be treated as one or at the very least combined in some way. Now keep in mind, this isn't his exact wording, just my interpretation of what he said. Well, I've felt this way ever since I started learning to become a programmer. You can have the best code in the world, but if your application looks like crap, it's not going to go anywhere (unless your program is pure functionality only of course). On the other side, you can have the most beautifully designed program in the world, but if it doesn't do anything it's practically worthless (unless your users like looking at pretty things and will sit there for hours on end staring at it and mindlessly send you money). I'm glad there's more people out there that feel the same way about this that I do. Reason being, I personally suck horribly when it comes to design. I couldn't design my way out of a paper bag and I feel that's a really big handicap. A handicap that I'd like to get rid of.
Over all I'd say that the "Open Source Design" was a good talk and they did a great job presenting it. I was expecting something a little different... more along the lines of a complete look at all of the design aspects behind Open Source using these tools. It was still a good presentation that kept me interested. Most importantly, it kept me awake, which is a tough task to manage in itself. Oh yes... and for those of you that went to this presentation... you will join PHUG.... you will join PHUG.... you WILL join PHUG....
The other talk that interested me was the, "The Most Important Thing - How Mozilla Does Security." Now this talk was about exactly what the title says. It's about Mozilla security. Too bad I didn't really understand everything he was talking about. I got the basic idea, but not much beyond that.
So, did I learn anything going to FSOSS? Yep. Would I have gone if I wasn't forced to? Maybe not. After experiencing FSOSS, would I go to another one if I wasn't forced to? Maybe, as long as there's food again. Oh yeah... those raisin cookies were amazingly good. I only had one, and when I went back for more they were all GONE. GONE!!! I think that was the most depressing moment of the day. It wasn't sitting through a seminar that I felt SHOULD interest me but didn't, it was the disappearance of some of the most beautiful, and delicious raisin cookies I've had this year. Whoever baked those, I seriously love you and would love to attend your seminar next FSOSS.
For anyone that actually reads my blog posts, hope to see you when I have something to write about again.
First thing I have to mention is, quite a few topics at FSOSS really didn't grab my attention. There's only two topics at FSOSS that interested me, so I'll suppose I'll talk about those. For “Open Source Designe” we got some bits and pieces about gimp, inkspace, blender3d, and how designers use CSS, PHP, and JS. I found the talk very interesting and I’m glad that I went.
The "Open Source Design" presentation was held by two speakers, Brendan Sera-Shriar and Geoff Palini. Now forgive me if my memory is off, but I believe Geoff was the main speaker. With the entire conference not really being about design put aside, the man did quite a good job trying to get his point across. He introduced us to quite a few open source art software packages. Gave us a demonstration of how well they could compete against closed source software packages, and gave us a little 3d demo at the end. He also informed us about Red5, an alternative flash resource to the conventional, "Pay $1 for every user that uses our flash server." Now this is useful information because flash is expensive. This seems to be a very nice way for companies to save money when they run a flash based website.
Geoff mentioned something during his presentation that caught my attention. He said that he believes that design and programming shouldn't be treated like separate entities. Instead they should be treated as one or at the very least combined in some way. Now keep in mind, this isn't his exact wording, just my interpretation of what he said. Well, I've felt this way ever since I started learning to become a programmer. You can have the best code in the world, but if your application looks like crap, it's not going to go anywhere (unless your program is pure functionality only of course). On the other side, you can have the most beautifully designed program in the world, but if it doesn't do anything it's practically worthless (unless your users like looking at pretty things and will sit there for hours on end staring at it and mindlessly send you money). I'm glad there's more people out there that feel the same way about this that I do. Reason being, I personally suck horribly when it comes to design. I couldn't design my way out of a paper bag and I feel that's a really big handicap. A handicap that I'd like to get rid of.
Over all I'd say that the "Open Source Design" was a good talk and they did a great job presenting it. I was expecting something a little different... more along the lines of a complete look at all of the design aspects behind Open Source using these tools. It was still a good presentation that kept me interested. Most importantly, it kept me awake, which is a tough task to manage in itself. Oh yes... and for those of you that went to this presentation... you will join PHUG.... you will join PHUG.... you WILL join PHUG....
The other talk that interested me was the, "The Most Important Thing - How Mozilla Does Security." Now this talk was about exactly what the title says. It's about Mozilla security. Too bad I didn't really understand everything he was talking about. I got the basic idea, but not much beyond that.
So, did I learn anything going to FSOSS? Yep. Would I have gone if I wasn't forced to? Maybe not. After experiencing FSOSS, would I go to another one if I wasn't forced to? Maybe, as long as there's food again. Oh yeah... those raisin cookies were amazingly good. I only had one, and when I went back for more they were all GONE. GONE!!! I think that was the most depressing moment of the day. It wasn't sitting through a seminar that I felt SHOULD interest me but didn't, it was the disappearance of some of the most beautiful, and delicious raisin cookies I've had this year. Whoever baked those, I seriously love you and would love to attend your seminar next FSOSS.
For anyone that actually reads my blog posts, hope to see you when I have something to write about again.
Friday, October 17, 2008
Ubiquity in Thunderbird 0.1 is UP!
Note: 0.1 is the release version only for my zenit wiki page. It is not the official release number.
If you don’t want to read my blog post just go here for the 0.1 release:
http://zenit.senecac.on.ca/wiki/index.php/Make_Ubiquity_Work_In_Thunderbird
Alright, where to begin talking about this goliath. Well, when I first decided to take this thing on, I knew it would be big. I knew there would be tons of code. I knew there would be TONS of things I didn’t understand. What I didn’t expect was such a vast difference between Firefox and Thunderbird.
Simple things like opening a URL completely broke in Thunderbird. Ubiquity runs using an annotation service, sadly that doesn’t exist in Thunderbird. What are you to do when half the code you’re working with is exploding on you? Well, everyone in our group did the most logical thing to start off with. If something is breaking, just comment it out!
Setting up the error console to spit out javascript errors was a process we first learned when we all started on this project. I managed to get the majority of errors to stop popping up, but I still had a few that just wouldn’t go away. A lot of stuff about “services” not wanting to work and certain blocks containing no data (being NULL) simply wouldn’t go away. Thankfully, two other students (Vladamir and Justin) got a past some of the errors I was struggling with, and got Ubiquity to pop up. Hurray!
Unfortunately, when I pulled their build down the previewBlock seemed to crap out on me. Well, there went another solid week of fighting with the code to get preview commands to work properly. I finally got that up and running but it wasn’t doing entirely everything I wanted it to do. For example, the map display from the map command wouldn’t even show up. I got a nice little preview block with text stating what the command did, but no map window.
Well, a few days of asking questions and looking for direction, Vladamir sent his latest build up to the repository. The map window was popping up, but it wasn’t displaying properly. Oh well, I figured I’ll just leave that for later and get commands that need access to new windows creating windows properly first. By this time we had a page to file tickets strictly for Ubiquity Thunderbird. http://labs.toolness.com/trac/ticket/326 I’m considering completing that as part of my 0.2. We’ll see if anyone else claims it by the time I get around to it.
Figuring out how to get windows to pop up in Thunderbird was fairly easy. I spent about an hour playing around with a few functions in the Ubiquity source to see if I could do anything with them. At this point in time, for some strange reason... don’t ask me why, I was thinking that Utils was coming from either Firefox or Thunderbird. I think around this point, I managed to confuse myself (which happens often). There was just so much source to keep track of, I simply made a mistake assuming this wasn’t a built in Ubiquity command. So I ran around throughout the entire source code finding every Utils.openURLInBrowser that I could and replacing it with my 1 liner that popped up the appropriate page the command was trying to generate.
No problems! Command windows were firing up here and there, and I was happy. I figured I did a good job, and I’d just have to start editing some external commands to get them to pop up windows as well. However, instead of going off on that route (thank god I didn’t) I decided to tackle the newly popping up windows and figure out what wasn’t working, and why. Well, I managed to figure out that even though windows were popping up, they still needed Firefox to function properly (which really is a no brainer considering the second I clicked on a tab that needed Firefox it would explode and throw an exception). Almost every tab within the command window requires you to link it to a browser in order for it to work properly. Even then, commands that executed local URLs still exploded, but remote URLs worked fine. Normally I would think it would be the other way around.
Around this time I came to the conclusion that there needed to be some way to tell if Ubiquity was running under Firefox or Ubiquity. I mean, if we’re going to completely alter Ubiquity code to run under Thunderbird, it would suck if someone has to rewrite an entire function just to get it running under Firefox or vice versa. Having one command pop up a window in Firefox but not Thunderbird would be kind of silly. I mentioned this to jono and told him about the whole issue having to replace every Utils command so that a Thunderbird window would load instead of exceptions being thrown. Jono said to me, “Why don’t you just edit Utils and put your code in there?” Well this is one of those... “...” moments. You kind sit there going “I can do that?” First thing I naturally do is ask where I can find Utils, but before anyone can answer, I see a little file called Utils.js. “Nevermind”, I say.
Ok so Utils is a Ubiquity command. Great... thank god I didn’t go altering external commands to get their windows to pop up. That would have been a massive waste of time. So I look at Utils.openUrlinBrowser, comment out EVERYTHING, and put my line of code in to pop up a window. I remove every line that I had replaced Utils.openUrlinBrowser with and put Utils.openUrlinBrowser back in. Ok well... now I have ONE line of code that pops up windows for Thunderbird commands. Great... fantastic... I wasted so much time going through the source finding every command I could and “fixing” it so that a window pops up. I could have just done it here. This is just one of those moments where I feel like a supreme idiot. Not just any kind of supreme idiot mind you... the kind that you’d lock away in a crazy house and your cell mate would say, “Man you’re dumb.” Oh well, I’m over it already.
Despite being able to plop a window pop up command in one spot and have it work for all existing code, chances are we’d still need to know what environment Ubiquity is running over. It’s great that I commented out all that code to get Thunderbird windows to pop up when a command needs one, but if it’s commented out and it’s in Firefox... well... it won’t work. Well it seems that jono felt the same way, and this was created http://labs.toolness.com/trac/ticket/353. Hey, there’s something else for me to do!
Over all I feel the entire experience was worthwhile. Working on this project was completely different than any school assignment I’ve ever done. Usually with those, you’re on your own. If you can’t get something to work, you struggle with it until someone from class or your professor has time to sit down with you and help. Exchanging code through IRC, pastebin, and the repository is a breeze, and there’s no plagiarism to boot. Throughout the entire process, I’ve felt like a child that’s first learning to walk. Or rather... a child that grew up a little bit but didn’t pay attention to anything anyone said. Totally should have paid more attention to Javascript when we were learning it. Relearning it was definitely a pain.
Of course, things breaking without knowing why was pretty frustrating. However, I find that a good, healthy nerd rage usually relieves all stress and makes me ready to go at it once again. Nerd raging usually consists of saying, “Screw it!”, getting up, watching some TV and eating some food.
Oh on another note, I spent a lot of time trying to make a XPI file out of this Ubiquity build (about a days worth of time) only to have it keep crapping out on me. Well, it appears that I needed to use python to create the XPI build, and couldn’t do it manually. Should have asked about why my XPI was failing earlier.
Stupid things I did while working on this project:
- Installed the wrong version of Thunderbird on my XP machine. I installed the right version on my Vista box! That gave me errors for a long time.
- COMPLETELY wasted the repository. I was using an editor that used Windows end lines. If you want to merge with Linux end lines you need to use a text editor that will use Linux end lines in files. I’ve been using EditPad Lite. Just a couple of clicks and you can start using Linux end lines. On that note, doing a hg merge, seeing a ton of errors, going “Meh whatever” and doing a hg push isn’t exactly the brightest thing to do. It trashes the entire repository.
- Didn’t ask enough questions. I thought I was being a pain and asked a lot of questions, but at this point I think I actually didn’t ask enough questions. If I had asked more questions, chances are I would have found out about Utils much sooner and wouldn’t have wasted a day trying to make a XPI file from my current Ubiquity build.
If you don’t want to read my blog post just go here for the 0.1 release:
http://zenit.senecac.on.ca/wiki/index.php/Make_Ubiquity_Work_In_Thunderbird
Alright, where to begin talking about this goliath. Well, when I first decided to take this thing on, I knew it would be big. I knew there would be tons of code. I knew there would be TONS of things I didn’t understand. What I didn’t expect was such a vast difference between Firefox and Thunderbird.
Simple things like opening a URL completely broke in Thunderbird. Ubiquity runs using an annotation service, sadly that doesn’t exist in Thunderbird. What are you to do when half the code you’re working with is exploding on you? Well, everyone in our group did the most logical thing to start off with. If something is breaking, just comment it out!
Setting up the error console to spit out javascript errors was a process we first learned when we all started on this project. I managed to get the majority of errors to stop popping up, but I still had a few that just wouldn’t go away. A lot of stuff about “services” not wanting to work and certain blocks containing no data (being NULL) simply wouldn’t go away. Thankfully, two other students (Vladamir and Justin) got a past some of the errors I was struggling with, and got Ubiquity to pop up. Hurray!
Unfortunately, when I pulled their build down the previewBlock seemed to crap out on me. Well, there went another solid week of fighting with the code to get preview commands to work properly. I finally got that up and running but it wasn’t doing entirely everything I wanted it to do. For example, the map display from the map command wouldn’t even show up. I got a nice little preview block with text stating what the command did, but no map window.
Well, a few days of asking questions and looking for direction, Vladamir sent his latest build up to the repository. The map window was popping up, but it wasn’t displaying properly. Oh well, I figured I’ll just leave that for later and get commands that need access to new windows creating windows properly first. By this time we had a page to file tickets strictly for Ubiquity Thunderbird. http://labs.toolness.com/trac/ticket/326 I’m considering completing that as part of my 0.2. We’ll see if anyone else claims it by the time I get around to it.
Figuring out how to get windows to pop up in Thunderbird was fairly easy. I spent about an hour playing around with a few functions in the Ubiquity source to see if I could do anything with them. At this point in time, for some strange reason... don’t ask me why, I was thinking that Utils was coming from either Firefox or Thunderbird. I think around this point, I managed to confuse myself (which happens often). There was just so much source to keep track of, I simply made a mistake assuming this wasn’t a built in Ubiquity command. So I ran around throughout the entire source code finding every Utils.openURLInBrowser that I could and replacing it with my 1 liner that popped up the appropriate page the command was trying to generate.
No problems! Command windows were firing up here and there, and I was happy. I figured I did a good job, and I’d just have to start editing some external commands to get them to pop up windows as well. However, instead of going off on that route (thank god I didn’t) I decided to tackle the newly popping up windows and figure out what wasn’t working, and why. Well, I managed to figure out that even though windows were popping up, they still needed Firefox to function properly (which really is a no brainer considering the second I clicked on a tab that needed Firefox it would explode and throw an exception). Almost every tab within the command window requires you to link it to a browser in order for it to work properly. Even then, commands that executed local URLs still exploded, but remote URLs worked fine. Normally I would think it would be the other way around.
Around this time I came to the conclusion that there needed to be some way to tell if Ubiquity was running under Firefox or Ubiquity. I mean, if we’re going to completely alter Ubiquity code to run under Thunderbird, it would suck if someone has to rewrite an entire function just to get it running under Firefox or vice versa. Having one command pop up a window in Firefox but not Thunderbird would be kind of silly. I mentioned this to jono and told him about the whole issue having to replace every Utils command so that a Thunderbird window would load instead of exceptions being thrown. Jono said to me, “Why don’t you just edit Utils and put your code in there?” Well this is one of those... “...” moments. You kind sit there going “I can do that?” First thing I naturally do is ask where I can find Utils, but before anyone can answer, I see a little file called Utils.js. “Nevermind”, I say.
Ok so Utils is a Ubiquity command. Great... thank god I didn’t go altering external commands to get their windows to pop up. That would have been a massive waste of time. So I look at Utils.openUrlinBrowser, comment out EVERYTHING, and put my line of code in to pop up a window. I remove every line that I had replaced Utils.openUrlinBrowser with and put Utils.openUrlinBrowser back in. Ok well... now I have ONE line of code that pops up windows for Thunderbird commands. Great... fantastic... I wasted so much time going through the source finding every command I could and “fixing” it so that a window pops up. I could have just done it here. This is just one of those moments where I feel like a supreme idiot. Not just any kind of supreme idiot mind you... the kind that you’d lock away in a crazy house and your cell mate would say, “Man you’re dumb.” Oh well, I’m over it already.
Despite being able to plop a window pop up command in one spot and have it work for all existing code, chances are we’d still need to know what environment Ubiquity is running over. It’s great that I commented out all that code to get Thunderbird windows to pop up when a command needs one, but if it’s commented out and it’s in Firefox... well... it won’t work. Well it seems that jono felt the same way, and this was created http://labs.toolness.com/trac/ticket/353. Hey, there’s something else for me to do!
Over all I feel the entire experience was worthwhile. Working on this project was completely different than any school assignment I’ve ever done. Usually with those, you’re on your own. If you can’t get something to work, you struggle with it until someone from class or your professor has time to sit down with you and help. Exchanging code through IRC, pastebin, and the repository is a breeze, and there’s no plagiarism to boot. Throughout the entire process, I’ve felt like a child that’s first learning to walk. Or rather... a child that grew up a little bit but didn’t pay attention to anything anyone said. Totally should have paid more attention to Javascript when we were learning it. Relearning it was definitely a pain.
Of course, things breaking without knowing why was pretty frustrating. However, I find that a good, healthy nerd rage usually relieves all stress and makes me ready to go at it once again. Nerd raging usually consists of saying, “Screw it!”, getting up, watching some TV and eating some food.
Oh on another note, I spent a lot of time trying to make a XPI file out of this Ubiquity build (about a days worth of time) only to have it keep crapping out on me. Well, it appears that I needed to use python to create the XPI build, and couldn’t do it manually. Should have asked about why my XPI was failing earlier.
Stupid things I did while working on this project:
- Installed the wrong version of Thunderbird on my XP machine. I installed the right version on my Vista box! That gave me errors for a long time.
- COMPLETELY wasted the repository. I was using an editor that used Windows end lines. If you want to merge with Linux end lines you need to use a text editor that will use Linux end lines in files. I’ve been using EditPad Lite. Just a couple of clicks and you can start using Linux end lines. On that note, doing a hg merge, seeing a ton of errors, going “Meh whatever” and doing a hg push isn’t exactly the brightest thing to do. It trashes the entire repository.
- Didn’t ask enough questions. I thought I was being a pain and asked a lot of questions, but at this point I think I actually didn’t ask enough questions. If I had asked more questions, chances are I would have found out about Utils much sooner and wouldn’t have wasted a day trying to make a XPI file from my current Ubiquity build.
Sunday, October 12, 2008
OSD600 Week 6 Lab
Alright, I've finally gotten around to doing the OSD600 lab for this week. My patch can be found here...
https://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=6838
Code changes are as follows:
if (inString.FindChar('.', pos) != kNotFound
&& inString.CharAt(0) != '.'
&& inString.CharAt(inString.Length() - 1) != '.'
&& inString.Find("..", 0) == kNotFound)
{
aOutString.AssignLiteral("mailto:");
aOutString += aInString;
}
I left in the check for a "." after the @ symbol. I then check to see if there's no "." after the @. Don't really want someone typing in a@.com. Then I check to see if there's a "." at the end of the string. Finally, a check is made to see if there's any duplicate "."'s side by side. For example: "a@a..b".
If all of those things check out then it's a mailing address.
The hint given for this lab made everything easy. I just opened the CPP file listed, and looked for mailto:. Once I found it, I just made the changes that I thought were appropriate, rebuilt, and tested it.
Filing a bugzilla bug was pretty straight forward and easy as well.
https://landfill.bugzilla.org/bugzilla-3.0-branch/show_bug.cgi?id=6838
Code changes are as follows:
if (inString.FindChar('.', pos) != kNotFound
&& inString.CharAt(0) != '.'
&& inString.CharAt(inString.Length() - 1) != '.'
&& inString.Find("..", 0) == kNotFound)
{
aOutString.AssignLiteral("mailto:");
aOutString += aInString;
}
I left in the check for a "." after the @ symbol. I then check to see if there's no "." after the @. Don't really want someone typing in a@.com. Then I check to see if there's a "." at the end of the string. Finally, a check is made to see if there's any duplicate "."'s side by side. For example: "a@a..b".
If all of those things check out then it's a mailing address.
The hint given for this lab made everything easy. I just opened the CPP file listed, and looked for mailto:. Once I found it, I just made the changes that I thought were appropriate, rebuilt, and tested it.
Filing a bugzilla bug was pretty straight forward and easy as well.
Thursday, October 9, 2008
Ubiquity command-editor pops up!
Just got the Ubiquity command-editor function to pop up. Whether or not any of the functions inside of the command editor work is another issue. I'm probably going to have to write an extra function for Ubiquity that determines whether or not it is being run under Firefox or Thunderbird, that way it can determine what functions to call depending on the program its running under.
Either that or there will have to be a stand alone Ubiquity extension. I'm not sure what route everyone wants to go, but I'm not opposed to spending my time trying to get one extension to work in both Firefox and Thunderbird. I'm not sure if something like this is entirely possible, and could be way off base... but this is probably the direction I'm going to try to go unless I'm told it's not a good idea.
Either that or there will have to be a stand alone Ubiquity extension. I'm not sure what route everyone wants to go, but I'm not opposed to spending my time trying to get one extension to work in both Firefox and Thunderbird. I'm not sure if something like this is entirely possible, and could be way off base... but this is probably the direction I'm going to try to go unless I'm told it's not a good idea.
Wednesday, October 8, 2008
Need Testers!
In light of my Ubiquity extension not wanting to pop up in TB for jono I've decided I need some testers. If you want to test my Ubiquity extension, hit me up in the #seneca channel on irc.mozilla.org and I'll send you my latest build.
If you're a Seneca student, I'll add you as a contributor to the projects page!
If you're a Seneca student, I'll add you as a contributor to the projects page!
Happy Birthday!
Alright lots of stuff to talk about.
Thanks to the efforts of Vladamir and Justin, Ubiquity is now popping up in Thunderbird. I've been poking around in the Ubiquity source getting a few things to work here and there, and removing errors from the error console. So far so good, cleaned up a few things (I think).
Now I've moved on to getting command previews to properly show up in the Ubiquity console. Attempting to debug my code, I've added a series of dumps to the console that just refuse to show up. I've added in the appropriate dump.enable property in TB so that's not an issue. It's almost like none of the functions are being called to pop up the preview window. Either that or my dump just isn't working at all (which would be strange because it's working else where).
If it is a case of certain functions being called, I'm sure I'm going to have tons of fun getting event handlers to work. My original plan for my project's 0.1 release was to get a few commands to work in TB. I'm starting to realize that getting remote commands to work might be a stretch, and I'm considering dumbing down my 0.1 to simply getting the preview window to operate properly. Currently the Annotation Service that Ubiquity uses to get commands to operate in Firefox isn't available in TB. Writing a "fake" annotation service to work around this problem is going to be hard and take lots of time. In fact, I suspect that it's out of my personal scope, but that still remains to be seen.
Oh yeah, as far as getting TB to pop up Ubiquity is concerned. When I sent my rebuilt extension to jono, it decided it didn't want to work. Instead TB feels like saying that jQuery is undefined. Well, that's wonderful. You'd think that considering today is my birthday, things would go smoothly. Oh well, spending my time on this was exactly how I pictured spending my bday anyways. Happy bday Scott! ;)
Thanks to the efforts of Vladamir and Justin, Ubiquity is now popping up in Thunderbird. I've been poking around in the Ubiquity source getting a few things to work here and there, and removing errors from the error console. So far so good, cleaned up a few things (I think).
Now I've moved on to getting command previews to properly show up in the Ubiquity console. Attempting to debug my code, I've added a series of dumps to the console that just refuse to show up. I've added in the appropriate dump.enable property in TB so that's not an issue. It's almost like none of the functions are being called to pop up the preview window. Either that or my dump just isn't working at all (which would be strange because it's working else where).
If it is a case of certain functions being called, I'm sure I'm going to have tons of fun getting event handlers to work. My original plan for my project's 0.1 release was to get a few commands to work in TB. I'm starting to realize that getting remote commands to work might be a stretch, and I'm considering dumbing down my 0.1 to simply getting the preview window to operate properly. Currently the Annotation Service that Ubiquity uses to get commands to operate in Firefox isn't available in TB. Writing a "fake" annotation service to work around this problem is going to be hard and take lots of time. In fact, I suspect that it's out of my personal scope, but that still remains to be seen.
Oh yeah, as far as getting TB to pop up Ubiquity is concerned. When I sent my rebuilt extension to jono, it decided it didn't want to work. Instead TB feels like saying that jQuery is undefined. Well, that's wonderful. You'd think that considering today is my birthday, things would go smoothly. Oh well, spending my time on this was exactly how I pictured spending my bday anyways. Happy bday Scott! ;)
Wednesday, October 1, 2008
World's Worst Programmer
Yep, that's me. You'd think that after spending an entire day going through Ubiquity's source code, that I'd at least be able to do something with it. Curse you Thunderbird!
So I managed to figure out where the function is that initiates Ubiquity when the user presses the appropriate key binding. I've also managed to figure out how commands are called upon, where they're stored, and how they're written. On top of all of this I've even managed to figure out where the key binding to pop up the Ubiquity window is located. So what's the problem then?
I CAN'T GET IT TO DO ANYTHING! From what I've seen, Ubiquity activates by listening for an incoming key binding. If it receives the correct key binding (which is defaulted to CTRL+Space) it will pop up. Ok so I tried porting it over to Thunderbird and using the key binding to pop up the window. Well... I guess Thunderbird is already making use of the CTRL+Space key binding. It's a binding in Thunderbird that allows you to select and unselect a highlighted e-mail.
Ok so NO PROBLEM! I think to myself. Naturally, if I can't get it to pop up using that key binding, I suppose I'll just change the binding. So I find one that I like that isn't currently being used by Thunderbird. No dice. Still doesn't want to pop up. At this point I'm kind of thinking that there's more to it than simply having the Javascript create the Ubiquity window after hitting the binding. Incase you're wondering, I did change the appropriate layout files in the manifest files, so that's not the problem (at least I don't think so).
So, there is the possibility that the event handler listening for the key binding isn't even operating. Alright, I'll just add a function to Ubiquity that immediately pops up the window when a menu item is clicked, and I'll add that menu item under the Thunderbird Tools tab. I've done it with several test extensions I've written so far. Shouldn't be too hard to add this menu item for Ubiquity. I know where the function is that pops up the window, so I create my own function that calls upon that function in Ubiquity's browser.js file. To add the Tool bar menu item, I just copy my code from my good old "Hello World!" extension and change the appropriate fields and point it to the Ubiquity function that I wrote. Thunderbird spits out an error on my menuitem id=. Nice, it doesn't do that for my crappy little extension. Guess I'm probably missing something. I double checked the code and there's no difference in the characters declaring the variable name at all.
It's just one of these times where I feel like a cave man that's come across a car. It looks nice and shiney, and I know it probably does something cool. I just don't know what it does, how it does it, or where to begin finding out. What I'm trying to do with Ubiquity right now is like a cave man trying to use the car's exhaust as a club. Unfortunately, I don't even know how to detach the exhaust pipe. I know that the club isn't the real purpose of the car, but if I have something nice and shiney infront of me, I might as well make use of it somehow. Who knows, I might even learn how to use a wheel next if I can get this exhaust club thing going.
Despite figuring out how everything begins between Ubiquity and Firefox, I'm still the worst programmer ever. Not that I honestly thought I'd even make it as far as I did doing what I was doing. However, one thing's for sure, I probably should have listened more closely when we were learning Javascript rather than dozing off. Javascript... pfft... who will EVER need that? Oh wait...
So I managed to figure out where the function is that initiates Ubiquity when the user presses the appropriate key binding. I've also managed to figure out how commands are called upon, where they're stored, and how they're written. On top of all of this I've even managed to figure out where the key binding to pop up the Ubiquity window is located. So what's the problem then?
I CAN'T GET IT TO DO ANYTHING! From what I've seen, Ubiquity activates by listening for an incoming key binding. If it receives the correct key binding (which is defaulted to CTRL+Space) it will pop up. Ok so I tried porting it over to Thunderbird and using the key binding to pop up the window. Well... I guess Thunderbird is already making use of the CTRL+Space key binding. It's a binding in Thunderbird that allows you to select and unselect a highlighted e-mail.
Ok so NO PROBLEM! I think to myself. Naturally, if I can't get it to pop up using that key binding, I suppose I'll just change the binding. So I find one that I like that isn't currently being used by Thunderbird. No dice. Still doesn't want to pop up. At this point I'm kind of thinking that there's more to it than simply having the Javascript create the Ubiquity window after hitting the binding. Incase you're wondering, I did change the appropriate layout files in the manifest files, so that's not the problem (at least I don't think so).
So, there is the possibility that the event handler listening for the key binding isn't even operating. Alright, I'll just add a function to Ubiquity that immediately pops up the window when a menu item is clicked, and I'll add that menu item under the Thunderbird Tools tab. I've done it with several test extensions I've written so far. Shouldn't be too hard to add this menu item for Ubiquity. I know where the function is that pops up the window, so I create my own function that calls upon that function in Ubiquity's browser.js file. To add the Tool bar menu item, I just copy my code from my good old "Hello World!" extension and change the appropriate fields and point it to the Ubiquity function that I wrote. Thunderbird spits out an error on my menuitem id=. Nice, it doesn't do that for my crappy little extension. Guess I'm probably missing something. I double checked the code and there's no difference in the characters declaring the variable name at all.
It's just one of these times where I feel like a cave man that's come across a car. It looks nice and shiney, and I know it probably does something cool. I just don't know what it does, how it does it, or where to begin finding out. What I'm trying to do with Ubiquity right now is like a cave man trying to use the car's exhaust as a club. Unfortunately, I don't even know how to detach the exhaust pipe. I know that the club isn't the real purpose of the car, but if I have something nice and shiney infront of me, I might as well make use of it somehow. Who knows, I might even learn how to use a wheel next if I can get this exhaust club thing going.
Despite figuring out how everything begins between Ubiquity and Firefox, I'm still the worst programmer ever. Not that I honestly thought I'd even make it as far as I did doing what I was doing. However, one thing's for sure, I probably should have listened more closely when we were learning Javascript rather than dozing off. Javascript... pfft... who will EVER need that? Oh wait...
Tuesday, September 30, 2008
Extension Progress
So, I talked to Jono earlier today. He's decided to lead the porting Ubiquity to Thunderbird project himself, which is a good thing for me. There's now an experienced Mozilla developer at my disposal that's willing to help everyone involved with the project get it done.
In order to help steer everyone in the right direction, Jono told us to write a small extension for Thunderbird that displays a message box showing the infamous "Hello World!" message. Well, after following his links and reading a tutorial on how to create Firefox extensions, I have to say... it's not nearly as intimidating as I thought it would be. Creating the extension for Firefox was a breeze. After that, I decided it was time to "port" it over to Thunderbird. Well, porting it over was simple enough, but there were definitely some differences between some of the information in my Firefox version and my Thunderbird version.
Ok, so I had to change the following in my chrome.manifest:
chrome://browser/content/browser.xul
To:
chrome://messenger/content/messenger.xul
That's a no brainer.
This is the part that stumped me for a little while. I didn't understand why my extension wasn't showing up in the Tool menu. Well, I should have guessed right off the bat that menupopup ids are different in Firefox than they are in Thunderbird. So I used:
menupopup id="taskPopup"
Instead of:
menupopup id="menu_ToolsPopup"
In my overlay.xul.
Now I just need to play around with my extension and make it do something "fancier" than displaying "Hello World!"
In order to help steer everyone in the right direction, Jono told us to write a small extension for Thunderbird that displays a message box showing the infamous "Hello World!" message. Well, after following his links and reading a tutorial on how to create Firefox extensions, I have to say... it's not nearly as intimidating as I thought it would be. Creating the extension for Firefox was a breeze. After that, I decided it was time to "port" it over to Thunderbird. Well, porting it over was simple enough, but there were definitely some differences between some of the information in my Firefox version and my Thunderbird version.
Ok, so I had to change the following in my chrome.manifest:
chrome://browser/content/browser.xul
To:
chrome://messenger/content/messenger.xul
That's a no brainer.
This is the part that stumped me for a little while. I didn't understand why my extension wasn't showing up in the Tool menu. Well, I should have guessed right off the bat that menupopup ids are different in Firefox than they are in Thunderbird. So I used:
Instead of:
In my overlay.xul.
Now I just need to play around with my extension and make it do something "fancier" than displaying "Hello World!"
Sunday, September 28, 2008
Project Update
There's really not too much to say at this point. So far for this week I've been exploring both Thunderbird and Firefox to determine where extensions are installed. With the help of a classmate, Jason Tarka, I was able to get a head start on doing this. Unfortunately, with other things on the go for this week, I haven't been able to do too much beyond playing around with extensions.
I'm hoping to make this up coming week a solid work week for this project once I get some kinks worked out with Thomas Brown. Hopefully my Blog next week will be a little longer than this.
I'm hoping to make this up coming week a solid work week for this project once I get some kinks worked out with Thomas Brown. Hopefully my Blog next week will be a little longer than this.
OSD600 Week 4 Labs
So our task for this week in OSD600 was to find out how a functionality worked in Firefox searching through the source code, and to apply a patch to Firefox. Applying a patch was very simply and straight forward, however, I found searching through the Firefox code slightly annoying.
To start off, I'll talk about patching. Patching was very simple and straight forward. I simply followed Mozilla's instructions to patch Firefox, and everything worked magically. There were very little problems using their commands to apply patches. One thing I did run into was my hg command wouldn't work when attempting to create a diff. The error message I received was "abort: There is no Mercurial repository here (.hg not found)!" I'm going to assume that's because I never downloaded my Firefox source using mercurial. Oh well, cvs worked... so that's fine. My main focus for this semester isn't Firefox anyways, it's Thunderbird. The hg command seems to work fine there.
All in all, patching was a breeze.
Now, I decided to search for source code based upon the back button. Despite hearing that it's usually not a good idea to post source code in a Blog, I'm going to completely ignore that and do it anyways. These were some of the "interesting" findings I found when searching through the source code for the Back Button:
/toolkit/content/widgets/browser.xml || webNavigation.canGoBack
/browser/base/content/tabbrowser.xml || this.mCurrentBrowser.goBack()
/browser/base/content/browser.js
1410 function BrowserBack(aEvent) {
1411 var where = whereToOpenLink(aEvent, false, true);
1412
1413 if (where == "current") {
1414 try {
1415 gBrowser.goBack();
1416 }
1417 catch(ex) {
1418 }
1419 }
1420 else {
1421 var sessionHistory = getWebNavigation().sessionHistory;
1422 var currentIndex = sessionHistory.index;
1423 var entry = sessionHistory.getEntryAtIndex(currentIndex - 1, false);
1424 var url = entry.URI.spec;
1425 openUILinkIn(url, where);
1426 }
1427 }
/docshell/base/nsIWebNavigation.idl
/**
48 * The nsIWebNavigation interface defines an interface for navigating the web.
49 * It provides methods and attributes to direct an object to navigate to a new
50 * location, stop or restart an in process load, or determine where the object
51 * has previously gone.
52 *
53 * @status UNDER_REVIEW
54 */
[scriptable, uuid(F5D9E7B0-D930-11d3-B057-00A024FFC08C)]
56 interface nsIWebNavigation : nsISupports
57 {
58 /**
59 * Indicates if the object can go back. If true this indicates that
60 * there is back session history available for navigation.
61 */
62 readonly attribute boolean canGoBack;
/**
71 * Tells the object to navigate to the previous session history item. When a
72 * page is loaded from session history, all content is loaded from the cache
73 * (if available) and page state (such as form values and scroll position) is
74 * restored.
75 *
76 * @throw NS_ERROR_UNEXPECTED
77 * Indicates that the call was unexpected at this time, which implies
78 * that canGoBack is false.
79 */
80 void goBack();
/browser/locales/en-US/chrome/browser/browser.dtd (View Hg log or Hg annotations)
* line 72 --
The interesting thing that I noticed is that there doesn't seem to be one place where "GoBack" is defined. It seems that the page back functionality is defined multiple times throughout the source code, which seems a bit messy to me. Perhaps there is one specific place that GoBack is defined absolutely, but I just couldn't seem to find it.
One other interesting thing I did find was there seemed to be two different back functionalities for "Browser" and "Browser Tabs". It makes more sense to me that "Browser Tabs" GoBack was what I was mainly looking for, because the majority of my browsing is done through Firefox tabs. Also, if you take a look at some of the source code I posted above, example here:
[scriptable, uuid(F5D9E7B0-D930-11d3-B057-00A024FFC08C)]
56 interface nsIWebNavigation : nsISupports
57 {
58 /**
59 * Indicates if the object can go back. If true this indicates that
60 * there is back session history available for navigation.
61 */
62 readonly attribute boolean canGoBack;
Throughout the Mozilla source code there's continuous checks on the GoBack functions to determine whether or not the tab in question can actually go back. Naturally, this just makes sense.
All in all, searching through the Firefox source code seemed to be time consuming, as well as confusing at times. The hardest part was determining where the "Beginning" and "End" of the GoBack function actually occurred. Right now, I'm still not too sure where it actually "begins". However, finding everything in between was fairly simple.
To start off, I'll talk about patching. Patching was very simple and straight forward. I simply followed Mozilla's instructions to patch Firefox, and everything worked magically. There were very little problems using their commands to apply patches. One thing I did run into was my hg command wouldn't work when attempting to create a diff. The error message I received was "abort: There is no Mercurial repository here (.hg not found)!" I'm going to assume that's because I never downloaded my Firefox source using mercurial. Oh well, cvs worked... so that's fine. My main focus for this semester isn't Firefox anyways, it's Thunderbird. The hg command seems to work fine there.
All in all, patching was a breeze.
Now, I decided to search for source code based upon the back button. Despite hearing that it's usually not a good idea to post source code in a Blog, I'm going to completely ignore that and do it anyways. These were some of the "interesting" findings I found when searching through the source code for the Back Button:
/toolkit/content/widgets/browser.xml || webNavigation.canGoBack
/browser/base/content/tabbrowser.xml || this.mCurrentBrowser.goBack()
/browser/base/content/browser.js
1410 function BrowserBack(aEvent) {
1411 var where = whereToOpenLink(aEvent, false, true);
1412
1413 if (where == "current") {
1414 try {
1415 gBrowser.goBack();
1416 }
1417 catch(ex) {
1418 }
1419 }
1420 else {
1421 var sessionHistory = getWebNavigation().sessionHistory;
1422 var currentIndex = sessionHistory.index;
1423 var entry = sessionHistory.getEntryAtIndex(currentIndex - 1, false);
1424 var url = entry.URI.spec;
1425 openUILinkIn(url, where);
1426 }
1427 }
/docshell/base/nsIWebNavigation.idl
/**
48 * The nsIWebNavigation interface defines an interface for navigating the web.
49 * It provides methods and attributes to direct an object to navigate to a new
50 * location, stop or restart an in process load, or determine where the object
51 * has previously gone.
52 *
53 * @status UNDER_REVIEW
54 */
[scriptable, uuid(F5D9E7B0-D930-11d3-B057-00A024FFC08C)]
56 interface nsIWebNavigation : nsISupports
57 {
58 /**
59 * Indicates if the object can go back. If true this indicates that
60 * there is back session history available for navigation.
61 */
62 readonly attribute boolean canGoBack;
/**
71 * Tells the object to navigate to the previous session history item. When a
72 * page is loaded from session history, all content is loaded from the cache
73 * (if available) and page state (such as form values and scroll position) is
74 * restored.
75 *
76 * @throw NS_ERROR_UNEXPECTED
77 * Indicates that the call was unexpected at this time, which implies
78 * that canGoBack is false.
79 */
80 void goBack();
/browser/locales/en-US/chrome/browser/browser.dtd (View Hg log or Hg annotations)
* line 72 --
The interesting thing that I noticed is that there doesn't seem to be one place where "GoBack" is defined. It seems that the page back functionality is defined multiple times throughout the source code, which seems a bit messy to me. Perhaps there is one specific place that GoBack is defined absolutely, but I just couldn't seem to find it.
One other interesting thing I did find was there seemed to be two different back functionalities for "Browser" and "Browser Tabs". It makes more sense to me that "Browser Tabs" GoBack was what I was mainly looking for, because the majority of my browsing is done through Firefox tabs. Also, if you take a look at some of the source code I posted above, example here:
[scriptable, uuid(F5D9E7B0-D930-11d3-B057-00A024FFC08C)]
56 interface nsIWebNavigation : nsISupports
57 {
58 /**
59 * Indicates if the object can go back. If true this indicates that
60 * there is back session history available for navigation.
61 */
62 readonly attribute boolean canGoBack;
Throughout the Mozilla source code there's continuous checks on the GoBack functions to determine whether or not the tab in question can actually go back. Naturally, this just makes sense.
All in all, searching through the Firefox source code seemed to be time consuming, as well as confusing at times. The hardest part was determining where the "Beginning" and "End" of the GoBack function actually occurred. Right now, I'm still not too sure where it actually "begins". However, finding everything in between was fairly simple.
Sunday, September 21, 2008
Building Firefox
Where to begin...
Suppose I'll start off by saying that building Firefox wasn't an overly challenging experience. The majority of my problems building it for the first time came from the Mozilla Build failing to work properly on Windows Vista. To put things simply, after installing all of the required addons (mainly the required SDKs), the Mozilla Build start batch files could not find Visual Studio.
I decided to do some probing in my registry and found that the entries Mozilla Build was looking for simply weren't there. Ok that's no problem, I'll just add them in. I start up the start batch file again, everything startings working great, but then I get this error:
"Unexpected \Microsoft"
Around this time, I've been fighting with the Mozilla Build and Windows Vista for about 3 days trying to figure out exactly what was going wrong. I started to think to myself, "I bet it's Vista." I had the suspicion that Mozilla Build just wasn't working properly with Vista, so I decided to try it out on Windows XP.
So I look at all the extras I need to install for Mozilla Build to work once again. I look at one of the required packages, and it's listed by Microsoft as a Vista package. Well, I'm on Windows XP, so I probably won't need it. I run Mozilla Build's start batch file, and it fails. So I figure, I'll just install the package and see what happens. I download and install, run the Mozilla Build start batch file, everything runs perfectly.
After that point, unpacking and building Firefox with my own mozconfig was a breeze. I did run into one strange anomoly while attempting to run my build of Firefox. I received an exception saying something in a cpp file on line 811 (didn't document this error so I'm not sure of the exact message) was not handled. At the same time this happened, a window from McAfee anti-virus popped up asking me if I wanted to enable secure browsing. I clicked on the Ignore button in the error dialog and told McAfee no I don't want this feature. Each time I loaded my Firefox build the exact same thing would happen every time. Same error message would appear, McAfee would pop up.
Well I'm sure you'll never guess what happened when I disabled McAfee. The error message went away. Ok so apparently running my build of Firefox doesn't like it when McAfee interferes during start up. That's fine, I don't need McAfee running anyways when I start up my build of Firefox.
So after many days of frustration struggling with Vista, I caved in and did my build on XP. After a little bit of poking with my build, all runs well. I might attempt to build on Vista at a later point, but right now I just can't be bothered. It's more frustration than what it's worth at this point in time. I'll probably tackle Vista again in another week.
Suppose I'll start off by saying that building Firefox wasn't an overly challenging experience. The majority of my problems building it for the first time came from the Mozilla Build failing to work properly on Windows Vista. To put things simply, after installing all of the required addons (mainly the required SDKs), the Mozilla Build start batch files could not find Visual Studio.
I decided to do some probing in my registry and found that the entries Mozilla Build was looking for simply weren't there. Ok that's no problem, I'll just add them in. I start up the start batch file again, everything startings working great, but then I get this error:
"Unexpected \Microsoft"
Around this time, I've been fighting with the Mozilla Build and Windows Vista for about 3 days trying to figure out exactly what was going wrong. I started to think to myself, "I bet it's Vista." I had the suspicion that Mozilla Build just wasn't working properly with Vista, so I decided to try it out on Windows XP.
So I look at all the extras I need to install for Mozilla Build to work once again. I look at one of the required packages, and it's listed by Microsoft as a Vista package. Well, I'm on Windows XP, so I probably won't need it. I run Mozilla Build's start batch file, and it fails. So I figure, I'll just install the package and see what happens. I download and install, run the Mozilla Build start batch file, everything runs perfectly.
After that point, unpacking and building Firefox with my own mozconfig was a breeze. I did run into one strange anomoly while attempting to run my build of Firefox. I received an exception saying something in a cpp file on line 811 (didn't document this error so I'm not sure of the exact message) was not handled. At the same time this happened, a window from McAfee anti-virus popped up asking me if I wanted to enable secure browsing. I clicked on the Ignore button in the error dialog and told McAfee no I don't want this feature. Each time I loaded my Firefox build the exact same thing would happen every time. Same error message would appear, McAfee would pop up.
Well I'm sure you'll never guess what happened when I disabled McAfee. The error message went away. Ok so apparently running my build of Firefox doesn't like it when McAfee interferes during start up. That's fine, I don't need McAfee running anyways when I start up my build of Firefox.
So after many days of frustration struggling with Vista, I caved in and did my build on XP. After a little bit of poking with my build, all runs well. I might attempt to build on Vista at a later point, but right now I just can't be bothered. It's more frustration than what it's worth at this point in time. I'll probably tackle Vista again in another week.
Friday, September 19, 2008
Making Ubiquity Work In Thunderbird
So a little while back I commented on our OSD600 class being introduced to Ubiquity. I went through our class' potential project list, and decided that "porting" Ubiquity over to Thunderbird sounded like it would be a fun challenge. I'm sure at present it's probably completely out of my scope of knowledge, but I'll do my best to try to best this challenge.
Thankfully, I'm not alone. I'm partnering up with a classmate named Thomas Brown, who seems to be quite enthusiastic about the project. Once we get moving on this, I'll be sure to keep the project page updated at least twice a week.
Until then... I'm off to attempt to make this work and learn a lot from it.
Thankfully, I'm not alone. I'm partnering up with a classmate named Thomas Brown, who seems to be quite enthusiastic about the project. Once we get moving on this, I'll be sure to keep the project page updated at least twice a week.
Until then... I'm off to attempt to make this work and learn a lot from it.
Thursday, September 11, 2008
My First Experience With Firefox's Ubiquity
So, our OSD600 class was introduced to a Firefox addon called Ubiquity. It's an interesting addon that allows users to create their own scripting commands, or download and use scripting commands written by others. It also appears that you have to be extremely cautious when you add another person's Ubiquity command, as the scripts have enough power to harm your system. Fortunately, every time before you download a new script, a warning message is displayed and you can view the source code for the script to check whether or not the script may be doing something malicious.
I wrote a very simple command that adds in a delay before sending a message to the user. Here is the code:
CmdUtils.CreateCommand({
name: "Timer",
author: "Scott Lunel",
takes: {"Time": noun_arb_text},
preview: "A simple timer that executes a message to the user after the entered time period.",
execute: function(directObj) {
Utils.setTimeout(function() { displayMessage("Time's Up!"); }, parseInt(directObj.text));
}
})
Nothing fancy. However, without knowing anything about Ubiquity, and being extremely rusty at Javascript (Ubiquity scripting is very similar to Javascripting) I was able to figure out how to write a simple display command within a couple of minutes. Finding the best command to use for the delay time took a bit longer, but over all it appears that writing simple commands is very easy to learn.
Personally, I don't think I'll be using Ubiquity very much. I use my browser to browse. I don't usually write scripts or commands for my browser. However, that might change as I progress in OSD600. There's quite a lot I need to learn about Firefox, and it could just be my limited knowledge that's preventing me from using the browser beyond it's basic function.
I wrote a very simple command that adds in a delay before sending a message to the user. Here is the code:
CmdUtils.CreateCommand({
name: "Timer",
author: "Scott Lunel",
takes: {"Time": noun_arb_text},
preview: "A simple timer that executes a message to the user after the entered time period.",
execute: function(directObj) {
Utils.setTimeout(function() { displayMessage("Time's Up!"); }, parseInt(directObj.text));
}
})
Nothing fancy. However, without knowing anything about Ubiquity, and being extremely rusty at Javascript (Ubiquity scripting is very similar to Javascripting) I was able to figure out how to write a simple display command within a couple of minutes. Finding the best command to use for the delay time took a bit longer, but over all it appears that writing simple commands is very easy to learn.
Personally, I don't think I'll be using Ubiquity very much. I use my browser to browse. I don't usually write scripts or commands for my browser. However, that might change as I progress in OSD600. There's quite a lot I need to learn about Firefox, and it could just be my limited knowledge that's preventing me from using the browser beyond it's basic function.
Wednesday, September 3, 2008
Open Source exploration.
Open source is a topic I've been aware of for quite some time, but I never really took a look at it closely. When I first heard about the OSD600 course, I thought it would be interesting to work on something someone else has developed and help expand upon it. I was first introduced to this in my JAC444 course with Peter Lui. We did a small project on an open source Java project called Robocode. I enjoyed working on Robocode, however, I found that searching through the source code to find what I wanted to be quite a pain. I'm sure reading another program's source code to find out where to begin or what you want to get from it to be the hardest part of writing for an open source project. Once I accomplished this, I did find the project enjoyable.
I have to commend Richard Stallman for founding the free software movement. Providing free software, getting people to build upon it, and evolving a community out of it can definitely create a strong bond between people. If his feelings are genuine I'd have to say that what he really wants is a society that interacts in this manner, not just from a software development perspective. While it would be nice if all software created could be maintained, updated, and distributed for free by the very users that use the software, this does not make sense from a corporate perspective. Unfortunately, a large portion of people believe that living in society is all about the size of your wallet. If you're looking to live in luxury, this is definitely true.
One thing I didn't realize was that there was a difference between "free software" and "open source". I always associated distributing a software application's source code as being the equivalent of making it free. After receiving a detailed explanation of the open source movement, I must say that it does make sense. Allow the users, or co-developers as it was put, help maintain and update the software they like to use. With a much larger "development" and tester base, it's easier to find and squash bugs, effectively making bugs that would appear to be huge problems into shallow nothings. While this does defy the very foundation upon which software engineering is built upon, I never believed there was a definite method for anything. There's always bound to be something that proves an absolute dictated by someone else to be false.
Also, I found the history behind Mozilla to be quite interesting. I wasn't aware that Mozilla originated from Netscape releasing their source code to their browser. I must say, that's quite the bold business move on their behalf.
Considering the amount of material that was thrown at me through these readings and documentaries, I could probably sit here and write about my thoughts all day. Instead I think I'll end things now and possibly expand upon my thoughts in future blogs. What I have written about here were the main points that caught my attention.
Will definitely be writing more later...
I have to commend Richard Stallman for founding the free software movement. Providing free software, getting people to build upon it, and evolving a community out of it can definitely create a strong bond between people. If his feelings are genuine I'd have to say that what he really wants is a society that interacts in this manner, not just from a software development perspective. While it would be nice if all software created could be maintained, updated, and distributed for free by the very users that use the software, this does not make sense from a corporate perspective. Unfortunately, a large portion of people believe that living in society is all about the size of your wallet. If you're looking to live in luxury, this is definitely true.
One thing I didn't realize was that there was a difference between "free software" and "open source". I always associated distributing a software application's source code as being the equivalent of making it free. After receiving a detailed explanation of the open source movement, I must say that it does make sense. Allow the users, or co-developers as it was put, help maintain and update the software they like to use. With a much larger "development" and tester base, it's easier to find and squash bugs, effectively making bugs that would appear to be huge problems into shallow nothings. While this does defy the very foundation upon which software engineering is built upon, I never believed there was a definite method for anything. There's always bound to be something that proves an absolute dictated by someone else to be false.
Also, I found the history behind Mozilla to be quite interesting. I wasn't aware that Mozilla originated from Netscape releasing their source code to their browser. I must say, that's quite the bold business move on their behalf.
Considering the amount of material that was thrown at me through these readings and documentaries, I could probably sit here and write about my thoughts all day. Instead I think I'll end things now and possibly expand upon my thoughts in future blogs. What I have written about here were the main points that caught my attention.
Will definitely be writing more later...
Tuesday, September 2, 2008
Created my first blog page.
I created this Blog for the OSD course I'm currently enrolled in at Seneca College. I will add more Blogs when I have time.
Subscribe to:
Posts (Atom)