I think this is great. Typekit is really making an impact with the service provided, and Google hopping on board is a really great thing for the both of them… and all of us.

We’re happy to announce that we’ve teamed up with Google to make webfonts ubiquitous and more accessible. Starting today, we’re making our Typekit font events an open source project called WebFont Loader. Now you can have complete control over how fonts are loaded and what happens when they’re rendered. You can download the code and use it however you like, or link directly to the latest version via the Google Ajax APIs.

Over the past few weeks, we’ve worked very closely with developers from Google to ensure the code is as broadly usable as possible. You can use WebFont Loader with fonts on your own server, links to the just-announced Google Webfont API, or any Typekit account. We’ve also made sure the code is modular, so other font hosting services can add to it in the future. You’ll find full documentation, examples, and information on how you can contribute at our GitHub repository.

There’s even a collection of open source webfonts that you can use right now provided via Googles CDN. I’ll be shopping around to see if anything suits Monday By Noon over the next few weeks.

Type is a big deal to us all. Projects like this help make beautiful type more accessible and usable and I really welcome it. I also keep in mind, however, that a (completely supported) native implementation is something I’ll continually be waiting for. Until then, keep rocking it, Typekit (and Google).

Advertise here with BSA

One such product is WebKit, the open source Web browser rendering engine used by Safari (as well as a number of other products). It’s very important to keep in mind that Safari and WebKit are two very different things. Safari is a Web browser that uses WebKit as it’s rendering engine.

The WebKit developers put forth the effort to port WebKit to Qt, which is, as stated by the developers:

Qt is a comprehensive development framework that includes an extensive array of features, capabilities and tools that enable development of high-performance, cross-platform rich-client and server-side applications.

Qt is truly cross-platform and allows deployment on a wide range of hardware configurations, as opposed to other “cross-platform” products that are restricted to Windows and Mac OS X. The fact that the WebKit developers put forth the effort of porting to Qt4 gives users the ability to run their rendering engine on any platform. Thanks to their hard work, it’s quite easy to run a WebKit-based browser in Linux.

Preparing your Linux system for WebKit

I’d like to be explicit in saying that the following instructions are geared towards a fresh install of Ubuntu 7.04, but should be applicable to a wide variety of Linux distributions. First and foremost you’ll need to add extra repositories. After you have followed those steps we can begin.

There are a number of packages you’ll need to successfully build a Qt4 Web browser that uses WebKit.

sudo apt-get install libqt4-dev libxslt-dev gperf bison libsqlite3-dev flex build-essential subversion

There will be a lot of additional packages to install, so don’t be surprised if the list of packages for installation is significantly large.

Obtaining a nightly build of WebKit

Next, we’ll need to use Subversion to check out the WebKit source. The following command will check out files to a folder titled WebKit within your working directory, so be sure your working directory is appropriate (I used my home directory).

svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit

You will be able to monitor the checkout process as each file is listed in your terminal.

The checkout will take some time, as there are quite a few files to download. When the checkout is complete, you’ll see the following message:

Building your Qt4 WebKit browser

When the checkout is complete, you can initiate the build of your Qt4 WebKit browser using the following command:

QTDIR=/usr/share/qt4/ WebKit/WebKitTools/Scripts/build-webkit

The script will take a minute to prepare the build, and then the process will begin.

This step can take quite a bit of time depending on your hardware configuration, so take a few minutes to have a cup of coffee and relax while your browser is being built. Your terminal will scroll with hundreds of lines of build commands and more, so don’t feel the need to sit and watch it build (unless you’re interested — I was).

When your build is complete, you’ll see the following message:

Running the browser

A successful build means you can run your Qt4 WebKit browser using the following command:

WebKit/WebKitBuild/Release/WebKitQt/QtLauncher/QtLauncher about:blank

A very basic browser window will appear with limited controls and an address bar. There will be some information scrolling in your terminal, but it can generally be disregarded.

You’ve now got a native WebKit browser to play around with in Linux. I took a second to attach the launch command to an entry in an panel using the WebKit icon. It’s more convenient than keeping the command saved somewhere to copy and paste when I’d like to test in WebKit.

You can also add your WebKit browser as an entry in your Applications menu using the menu editor if you prefer.

Some quirks I’ve come across so far

There are a few things that will appear out of place. First and foremost, you’ll notice that form inputs will have, what seem to be, a random background-color. I may be completely mistaken, but I haven’t looked into things deep enough to find the rhyme or reason behind the discrepancy. From what I can tell, if the input is styled with CSS, the style takes precedence over any ‘default’ colorization.

The next issue I’ve come across is that you’re not able to work with xHttpRequest. This is another issue I have not researched in enough detail, but if anyone has any insight regarding an inability to make use of XHR, I’d be interested in reading about it.

Finally, the only other quirk I’ve come across so far is that you’ll need to include http:// in any URL you enter in the address bar. While this may seem like a small detail to write about, after my first successful build I spent a few minutes thinking that something went wrong.

Things to keep in mind

Perhaps the most important thing to keep in mind is that you’re running a nightly build of WebKit, not the build Safari is using. The nightly versions are much more advanced than Safari’s WebKit, so some of the quirks that appear in Safari may be handled in your Qt4 browser.

Due to the version discrepancy, you can’t depend on a nightly build of WebKit sufficing for a legitimate test in Safari. It is useful, however, to take a quick look at overall structural elements of your designs before making the effort of moving to an OS X machine.

Footnotes and inspiration

I was originally drawn to working with WebKit on Linux by a post on the same subject at as days pass by. I had followed his instructions and ran into a few issues. Going on his advice, I joined #webkit on irc.freenode.net and started discussing a few issues with one of the developers there. He (or she) was extremely helpful in assisting me to successfully build WebKit. I was also directed to a Wiki page which included similar instructions to the post on as days pass by. I felt compelled to write this post based on specific instructions surrounding Ubuntu Feisty but would like to give much credit to the hard work of others.

Advertise here with BSA

I’m generally not a fan of Apple/Mac/Jobs and I’ve grown to dislike Microsoft/Windows/Gates. I don’t say that to offend anyone, so please don’t take it the wrong way. We all have our reasons for the setups on our desks. This article is going to reflect my opinions of using Linux for Web development, not knock or support anything else.

Why I Choose Linux

I’ve always had an interest in Linux, and over the past few years I’ve become increasingly frustrated with Windows. My first Linux installations weren’t an absolute disaster but at the same time I had no idea what I was doing and found myself back on Windows in a matter of hours. Regardless, my interest was there.

Some months ago, I decided to give it another shot. I use both a laptop and a desktop at home and thought that since I only really used my laptop for minimal tasks, it would make a good test bed for Linux. My venture began with Fedora Core and to make a long story short, a bad update rendered my display useless and I had no idea how to fix it.

Enter Ubuntu. I don’t remember where I first read about Ubuntu Linux, but what struck me was all the ranting and raving about its out of the box compatibility with a wide range of hardware — especially laptops. I thought I’d give it a shot with the 5.04 release and I was delighted with the results. All of my hardware worked just fine, including my WiFi, which was a feat in itself using Fedora Core. I now run Ubuntu 6.06 on that same laptop, my main home machine, and most recently my setup at work. After working out all of the customizing issues at home over the course of eight months or so, I finally feel comfortable enough to be using Linux both personally and professionally. Using it for work will be my true test, and I’d like to record my findings here.

Getting Set Up

The only issue I was faced with using this particular distribution of Linux was setting up and managing dual monitors. I have grown to know and love a dual monitor setup and I’m not sure I would want to cope without.

nVidia Makes Life Easy

Luckily all of my video cards are nVidia based, which is a great thing because nVidia has taken the time and effort to publish video card drivers for their chipsets under Linux. Following the proper documentation you can have their drivers installed in minutes, which is a blessing compared to setups with other chipsets from what I’ve read.

Getting two displays up and running isn’t as easy as checking “Extend my Desktop to this monitor” in Linux. I had to manually edit a configuration file, but using the nVidia provided options, setup was painless and I now run a dual monitor system as I was in Windows.

What About Your Wacom?

I didn’t have to do a thing to get my Wacom tablet up and running in Linux. It was working out of the box for me using Ubuntu 6.06 so there really isn’t much to write about the setup. Support in applications is another issue I will touch upon in a bit.

Software for Web Development

The abundance of equivalent software for Linux for general tasks are heavily discussed in other areas of the net. I’m going to focus on the applications that I find essential for Web development.

Email and Web

I was already using Firefox and Thunderbird on other platforms, so using them required absolutely no change. All of my choice extensions work under Linux and I had no issues with the migration.

As a Web developer, I needed to have other browsers at my disposal for testing. I was able to install Opera with ease and my only real hurdle was Internet Explorer. Luckily after a bit of searching I came across IEs 4 Linux. This beautiful script will install a version of Internet Explorer 6 on top of WINE to allow me to test for IE6/Win.

Have you Heard of Beagle?

Something I’m really excited to write about after a few months of typical use on a Linux setup is using Beagle. For you Mac users, Beagle is most closely compared to Spotlight in OS X in that it keeps an archive of all files on your disks for easy searching. I think it’s going to be great to be able to search all files, Emails, even Gaim logs on the fly and instantly. If you haven’t heard of Beagle, check out these videos of Beagle in action — I’m very impressed with it so far.

Actual Development in Linux

Finding a good application for writing, editing, and managing your code is essential for anyone who develops. Whether it be on the Web or otherwise, if you aren’t using a proper application your life can become much more difficult than it should be. I’m not talking WYSIWYG here, because any serious developer would laugh at its mention.

Bluefish is King for Development

I fell in love with Bluefish the instant I ran it for the first time. It is by far my favorite editor and being able to use it daily at work is a great thing for me. Why do I like it so much? Apart from the things that most of the other editors do such as highlighting and auto line indent, it has the ability to create Projects, which some of the other editors I was using never had. I am a fan of this feature because I’m working on different projects throughout the day and it is an easy way to switch. The GUI is effective, nice looking, and everything seems to be in just the right spot. I’d like to devote an entire article to its benefits in the future, but for the sake of time I’ll leave it at that.

Aren’t Fonts an Issue?

I think it’s great not to have the Windows default fonts at my disposal. It really opened my eyes to taking more time in selecting a font family due to the fact that I didn’t have many of the typical fonts used on the Web. It is possible to install TrueType fonts using Linux and if that’s something you’re interested in, it can be done. I have since installed many of the fonts I was using under windows and don’t really notice any problems using the TrueType fonts.

Creating Site Mocks

More often than not a site design begins with a mock. A static image that’s shown to the client to see if it meets approval. From time to time I’ll be able to work on a mock, but they’re usually taken care of by the designers. This brings up two situations that need to be handled by a developer using Linux. First, which application is comprehensive enough to make the design? Secondly, how are you going to work with that PSD the designer sent over?

Pixel and GIMP

GIMP is an extremely powerful image editing application. It is very feature rich, but often confusing to use. Scott Moschella’s GIMPshop and editing the keyboard shortcuts can make GIMP a very Photoshop-like experience, and given some time and effort can be effective. After some time using it, I still found GIMP to be awkward to use exclusively.

That is, until I came across Pixel. Pixel has a much more Photoshop-like interface and can do many of the things Photoshop can, and in the way Photoshop does them. It has been in development for many years and is not OSS nor is it free to use (save the demo version). There are still a few bugs in the application as it is still in the beta stage, but Pixel has some definite promise and I was more than happy to pay the nominal fee to use it.

You Can’t Forget About Flash

Personally, I don’t develop in Flash at this time. There is a very talented coworker of mine that handles the Flash projects we get so developing in Flash isn’t an issue for me. Had it been, I probably wouldn’t be able to make the shift to Linux being that I wouldn’t have a way to work in Flash.

Viewing Flash documents is another issue entirely. While Adobe provides a download for a Linux Flash player, but it’s obvious that effort was lacking in it’s development. Flash video is a bit choppy and more often than not will lag over time and the audio will desync. When it isn’t video, a Flash movie will behave more or less normally which is a good thing, I suppose. After a bit of reading I’ve found that version 9 will be releasing for Linux in the coming months and it should behave much better than the current version.

File Transfers

FTP is nothing but essential when developing for the Web. This is where my first and one of my only issues with Linux arises. The application I’m currently using for file transfers is gFTP. gFTP is great in that it works and has a GUI interface, but from a usability standpoint I’m not a big fan. The interface closely resembles the WS_FTP of 1998 and you have to use the right and left arrow buttons to make transfers. There’s no dragging from your local view to your remote view to make the transfer. That’s really irritating to me. Another problem I have with the application is that it doesn’t remember your site logins. Security risk or not, I liked it when FileZilla remembered my past few logins so I didn’t have to enter them every day. Lastly, gFTP won’t keep your connection alive, so if you’re editing code for more than about a minute, you’ll have to reconnect to the server to upload your changes. If there’s a way to change any of that, I haven’t found it and would love to hear what I’m doing wrong. Luckily, FileZilla 3 is on the way and with it being cross platform, I’ll be able to return to my old habits.

Audio is Essential

If you’re anything like me, you have music playing the majority of the time you’re working. There were many audio solutions for Linux, but my favorite by far has to be Amarok. It will organize your entire collection into a searchable database as many other audio players will do, but what I like about Amarok is that it takes things to the next level. If you’re a member of last.fm, you’re able to enter your account information from the start which is great. Other features I like are integrated lyric lookup and incorporating the MusicBrainz service to provide you a list of recommended songs based on what you’re listening to. I just really like the way it functions and if you get the chance, take a second to check it out. As a side note, you don’t need to be running KDE for it to work, I’m using it in Gnome.

So Can it Work?

After a week of using Linux at work I have to say that I’m very pleased so far. I’m mostly ecstatic about using Bluefish exclusively for writing code and I can’t wait to make more use of its features now that I’ll have the time and place to really give it a go. So far working with Web mocks has been the biggest obstacle, and I think the only solution for that will be a Linux port of Photoshop. Unfortunately I don’t see that happening any time soon as it is not in the best interest of Adobe to put any resources into such a thing.

Browser testing is completely transparent as to which operating system I’m using. With IEs 4 Linux I’m able to see the faults of Internet Explorer in all their glory, and also able to test in Opera. Not being on a Mac I’m still forced to use a coworkers machine to check out Safari and the associated Mac browsers, but that is nothing new.

Using Beagle has already become useful. It’s great to be able to type in the name of a client and have all of their associated files, emails, Gaim logs, and anything else related to them put on display right in front of me.

I think completely migrating to Linux will be a positive move for me. I mainly develop at work so I will be able to deal with the image editing shortcomings I’ve discovered. I may find that it will only take some time to learn the ins and outs of Pixel and GIMP and Photoshop can be a temporary memory until ported to Linux. I haven’t received a complicated PSD from the designers yet but I’m sure that will provide an interesting morning or afternoon. The only drawback I’ve found is that Wacom pressure sensitivity works only in GIMP, not Pixel. The Pixel developer has indicated, however, that he is working on including Wacom support in a future build which is great. I’ll be sure to include my findings in a future article.

I’m going to enjoy not having to worry about hard drive fragmentation, WGA and the garbage it brings, Vista, spyware, viruses, and the other problems I came across from using Windows. Linux is becoming better by the day and I’ll be excited to see how much further it reaches by the time Vista hits the shelves.

The next few months will be really interesting as I’ll be able to find out whether or not Linux is the solution for me when it comes to my work environment. I’d like to write again giving updates as to my findings specifically having to do with Web Development as opposed to average use.

Advertise here with BSA