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.
Sunday, November 30, 2008
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.
Subscribe to:
Posts (Atom)