The lab today is to pick a feature of Firefox's UI, and find the source code snippet that controls its behaviour. We were given a list of features to choose from, or we could pick our own.
The feature that bugs me most is that the back button in FF3 no longer has a dropdown option, like it did in FF2. The forward button has the drop-down, so I suspect the functionality is buried in there somewhere. I start my search by looking for the string "back button"...
I ended up finding several entries, listed here. NS_THEME_TOOLBAR_DUAL_BUTTON is defined as a macro for buttons that trigger drop-downs, like the back button used to.
At this point, I recall that Firefox offers theme customization. Within minutes of searching, I've found themes for FF3 that offer drop-down support for the back button. From this, I would assume that the back button must be called by the theme in order to appear...
From this, I learned that the back button's drop-down menu should be configured by editing the UI theme. It had nothing to do with the source code directly. However, I've definitely learned how to find out where such features of Firefox might be configured, and future searches will be much faster.
It was an awesome lab that quickly introduced a wide range of skills which are essential for working with Firefox, or any other large project.
Tuesday, September 23, 2008
Sunday, September 21, 2008
Minefield build!
Building Firefox was... not as mysterious as I had first expected.
I always knew FF was open source, and that the source code was out there somewhere. It would require a strange compiler setup and more symbolic links than pebbles at a beach. Since writing large amounts of source code was always an ordeal and linkers have rendered some projects dead for me, compiling browsers fits into the "arcane magic" category.
I was quite pleased to find that the compiler configuration was well-documented and largely automated. I also discovered the true advantages of utilities like "make".
The one quirk I ran into was this:
If my computer's specific configuration is an exception, I could understand. I suspect that other Windows users may run into similar problems. I'm curious to see if this command failed for anyone else.
It feels like the documentation is too fragmented. They'll link to several different setup processes for different OS's, and expect all of them to work exactly the same. "One size fits all" code (like that "make -f client.mk build") is just too good to be true, but the documentation buys into it anyways.
Full details on my adventure can be found here.
Special thanks to Zghansar, who made my experience magically easy.
I always knew FF was open source, and that the source code was out there somewhere. It would require a strange compiler setup and more symbolic links than pebbles at a beach. Since writing large amounts of source code was always an ordeal and linkers have rendered some projects dead for me, compiling browsers fits into the "arcane magic" category.
I was quite pleased to find that the compiler configuration was well-documented and largely automated. I also discovered the true advantages of utilities like "make".
The one quirk I ran into was this:
$ make -f client.mk buildIf you follow the online documentation exactly, they will ask you to run this code. For me, it failed to start compiling. They didn't even suggest that there'd be other options, like running "make" without any arguments.
If my computer's specific configuration is an exception, I could understand. I suspect that other Windows users may run into similar problems. I'm curious to see if this command failed for anyone else.
It feels like the documentation is too fragmented. They'll link to several different setup processes for different OS's, and expect all of them to work exactly the same. "One size fits all" code (like that "make -f client.mk build") is just too good to be true, but the documentation buys into it anyways.
Full details on my adventure can be found here.
Special thanks to Zghansar, who made my experience magically easy.
Friday, September 12, 2008
One Crazy Ride
The object of this lab was to complete a task that none of use knew how to do; in short, to do the previously impossible. The specific example was writing commands for Ubiquity. You can find the lab here:
http://zenit.senecac.on.ca/wiki/index.php/Learning_Collaborative_Development_Lab_Fall_2008
Instead of writing one of the four suggested commands like everyone else, I dug around to see what the community was looking for. I found it: the URL noun.
They have a prototype for the URL noun (at bottom of this page), but it was missing a couple items. It would've been awesome if it could hook into awesomebar's data resources asynchronously, but async data transfer isn't simple enough for a novice to complete over a week.
Instead, I chose to improve on the regexp by allowing other protocols (instead of just http, https, and ftp), and adding syntax for subfolders. Here's my current work:
var noun_type_url = {
_name: "Valid URL",
suggest: function( text, html ) {
if (!text)
return [ CmdUtils.makeSugg("http://") ];
if(/^[A-Za-z0-9]+:\/\/([A-Za-z0-9_-]+)(\.([A-Za-z0-9_-]+))*(\/([A-Za-z0-9_-~#=]*))*(\/[A-Za-z0-9_]*\.[A-Za-z0-9_]+)?$/.test(text)){
return [ CmdUtils.makeSugg("valid! " + text) ];
}
else if(/^([A-Za-z0-9_-]+)(\.([A-Za-z0-9_-]+))*(\/([A-Za-z0-9_-~#=]*))*(\/[A-Za-z0-9_]*\.[A-Za-z0-9_]+)?$/.test(text)){
return [ CmdUtils.makeSugg("valid! " + "http://" + text) ];
}
return [ CmdUtils.makeSugg("What are you thinking. :V") ];
}
};
CmdUtils.CreateCommand({
name: "url",
takes: {"your shout": noun_type_url},
preview: function( pblock, theShout ) {
pblock.innerHTML = "Will verify: " + theShout.text;
},
execute: function( theShout ) {
var msg = theShout.text;
displayMessage( msg );
}
})
jono from #ubiquity on irc.mozilla.org was very helpful in this learning process. From the first few minutes of chat, I found out that I wasn't working alone on this noun type and that there are coders willing to review my work.
There's just a little more polish I can put into this code before considering my limits reached. Asynchronous data calls seems to deal with the Ubiquity source code, and compiling is a task for next week!
http://zenit.senecac.on.ca/wiki/index.php/Learning_Collaborative_Development_Lab_Fall_2008
Instead of writing one of the four suggested commands like everyone else, I dug around to see what the community was looking for. I found it: the URL noun.
They have a prototype for the URL noun (at bottom of this page), but it was missing a couple items. It would've been awesome if it could hook into awesomebar's data resources asynchronously, but async data transfer isn't simple enough for a novice to complete over a week.
Instead, I chose to improve on the regexp by allowing other protocols (instead of just http, https, and ftp), and adding syntax for subfolders. Here's my current work:
var noun_type_url = {
_name: "Valid URL",
suggest: function( text, html ) {
if (!text)
return [ CmdUtils.makeSugg("http://") ];
if(/^[A-Za-z0-9]+:\/\/([A-Za-z0-9_-]+)(\.([A-Za-z0-9_-]+))*(\/([A-Za-z0-9_-~#=]*))*(\/[A-Za-z0-9_]*\.[A-Za-z0-9_]+)?$/.test(text)){
return [ CmdUtils.makeSugg("valid! " + text) ];
}
else if(/^([A-Za-z0-9_-]+)(\.([A-Za-z0-9_-]+))*(\/([A-Za-z0-9_-~#=]*))*(\/[A-Za-z0-9_]*\.[A-Za-z0-9_]+)?$/.test(text)){
return [ CmdUtils.makeSugg("valid! " + "http://" + text) ];
}
return [ CmdUtils.makeSugg("What are you thinking. :V") ];
}
};
CmdUtils.CreateCommand({
name: "url",
takes: {"your shout": noun_type_url},
preview: function( pblock, theShout ) {
pblock.innerHTML = "Will verify: " + theShout.text;
},
execute: function( theShout ) {
var msg = theShout.text;
displayMessage( msg );
}
})
jono from #ubiquity on irc.mozilla.org was very helpful in this learning process. From the first few minutes of chat, I found out that I wasn't working alone on this noun type and that there are coders willing to review my work.
There's just a little more polish I can put into this code before considering my limits reached. Asynchronous data calls seems to deal with the Ubiquity source code, and compiling is a task for next week!
Wednesday, September 3, 2008
The Cathedral Crumbles
My inspiration in coding came from cathedrals.
Not literally.
I grew up alongside the early video game consoles and their 16-bit glory. The games were elegant and brilliantly built, much like the Notre Dame. Their almost infinite depth could be realized if you spent just a little time to look closer, and there was always something new to discover.
At that point my life's goal was to build the biggest and prettiest cathedral I could and see how many people I could impress. It was an innocent wish.
I stepped into this course, DPS 909, with the hope that I would figure out what this "Open Source" business was by the time I finished. After reading Eric Raymond's "The Cathedral and the Bazaar", I think I've gotten a solid idea of what "Open Source" means before the second class of the semester; much sooner than I had expected. The paper can be found here:
http://www.firstmonday.org/issues/issue3_3/raymond/
Traditional proprietary software is likened to a cathedral, where the masses it is designed to serve are kept ignorant until the grand opening. When it does open, the audience is awed and amazed at all the work and beauty thrust upon them. The architects hope dearly that the users don't notice any of the major flaws, lest they be chased out of the country.
Open source software is likened to a bazaar where the users influence most of its existence, from available products to daily price changes. No regular customers are surprised when they stop to shop; the bazaar just works. Whatever didn't work was cut out countless versions ago by the demands of the masses.
Rather than sit and wait for your users to (hopefully) enjoy the software upon a big release, Raymond suggests that the users be actively involved in evolving the software. It's an efficient way to gather a large pool of genius without high organization overhead. It is also efficient for ensuring that your software's scope will please the target.
The most modern example of a bazaar is alluded to near the end, when Raymond mentions a revolutionary leap by the Netscape company. Netscape takes a big gamble by releasing their source code, an unprecedented action for such a large player in the industry, in hopes of continuing competition against a free Internet Explorer. Sadly, the paper (and the Revolutionary OS video) stops there and leaves us hanging on the results. It didn't take long for me to realize that this was the seed from which Firefox would emerge and dominate the market.
The fact that this Bazaar model has produced a strong competing operating system (Linux) and one of the most popular browsers on the planet (Firefox) is enough to convince me that the Bazaar model really has something to offer. It will be taken into serious consideration as I contemplate the path of my future career.
If I ever achieve that life goal of mine, I will definitely share my source code; but perhaps only a header file or two.
～
Not literally.
I grew up alongside the early video game consoles and their 16-bit glory. The games were elegant and brilliantly built, much like the Notre Dame. Their almost infinite depth could be realized if you spent just a little time to look closer, and there was always something new to discover.
At that point my life's goal was to build the biggest and prettiest cathedral I could and see how many people I could impress. It was an innocent wish.
I stepped into this course, DPS 909, with the hope that I would figure out what this "Open Source" business was by the time I finished. After reading Eric Raymond's "The Cathedral and the Bazaar", I think I've gotten a solid idea of what "Open Source" means before the second class of the semester; much sooner than I had expected. The paper can be found here:
http://www.firstmonday.org/issues/issue3_3/raymond/
Traditional proprietary software is likened to a cathedral, where the masses it is designed to serve are kept ignorant until the grand opening. When it does open, the audience is awed and amazed at all the work and beauty thrust upon them. The architects hope dearly that the users don't notice any of the major flaws, lest they be chased out of the country.
Open source software is likened to a bazaar where the users influence most of its existence, from available products to daily price changes. No regular customers are surprised when they stop to shop; the bazaar just works. Whatever didn't work was cut out countless versions ago by the demands of the masses.
Rather than sit and wait for your users to (hopefully) enjoy the software upon a big release, Raymond suggests that the users be actively involved in evolving the software. It's an efficient way to gather a large pool of genius without high organization overhead. It is also efficient for ensuring that your software's scope will please the target.
The most modern example of a bazaar is alluded to near the end, when Raymond mentions a revolutionary leap by the Netscape company. Netscape takes a big gamble by releasing their source code, an unprecedented action for such a large player in the industry, in hopes of continuing competition against a free Internet Explorer. Sadly, the paper (and the Revolutionary OS video) stops there and leaves us hanging on the results. It didn't take long for me to realize that this was the seed from which Firefox would emerge and dominate the market.
The fact that this Bazaar model has produced a strong competing operating system (Linux) and one of the most popular browsers on the planet (Firefox) is enough to convince me that the Bazaar model really has something to offer. It will be taken into serious consideration as I contemplate the path of my future career.
If I ever achieve that life goal of mine, I will definitely share my source code; but perhaps only a header file or two.
～
First post!!
Hello all!!
Here marks the beginning of a blog which will be very active for the next 4 months.
As a student of the DPS 909 course at Seneca College, I've been tossed head-first into the open source community. Who knows, I might actually land on my feet and enjoy my stay there.
～
Here marks the beginning of a blog which will be very active for the next 4 months.
As a student of the DPS 909 course at Seneca College, I've been tossed head-first into the open source community. Who knows, I might actually land on my feet and enjoy my stay there.
～
Subscribe to:
Posts (Atom)