I read on Planet Gnome that there’s a plan to drop current theme engines to move to a CSS-like system. That’s really a great idea, and I was stoked to learn that Qt already has it.

This is the kind of change that can really make a difference in the number and quality of available themes. While the current system requires C programming to create an new engine and unleash the full power of GTK+ theming, a system based on CSS would only require knowledge that most designers today already have. Most people are working on web app, so let those people hack on desktop apps with more or less the knowledge set they already have is a great way to keep the desktop alive.

Hey, isn’t it why Firefox extensions and themes are so popular?

Update: Flock in Japanese has been released. You can download it here.

It’s been a long time, but we’re finally there: the release of Flock in Japanese is very close! You can read details (in Japanese) on the blog of one of the translators. It even includes a link to a pre-release of the Japanese version. As the translator says, it’s better to send feedback about the translation directly to the translators. If you use the “feedback” button, that get to our support guy who won’t understand much.

As good news always come by two, an other member of the JA translation team will make a seminar about Flock, in at OSC Kansai 2008 (Open Source Conference) on July 18th. If you’re in the region at that time, that’s a good opportunity to meet between Japanese Flock users/contributors.

And again, congrats to the JA localization team!

I’ve spent a day hacking on a new extension. It’s for gamers (like me!) who like to check reviews about new games before they buy. I’ve put Amazon customer reviews score, the mandatory Metacritic score. More to come - let me know what you think should be there.

Also, when you visit Metacritic, IGN or Gamespot, games get detected, so all you need when you’re viewing a page about a game is to click on the famicom icon, and the info will open on the left. Pretty cool, eh?

It’s in AMO sandbox now, so if you don’t have an AMO account with Sandbox access you can also download it here. And if you like it, don’t forget to write a review on AMO, so it can get out of the sandbox!

Update: a public beta of Flock 2.0 is available.

In order to minimize the wait between the release of Firefox 3 and a Flock version based on it, Manish and me started to work on porting Flock to FF3. The current stable version of Flock is based on Firefox 2, the latest stable release from Mozilla.

That’s today that we’re very glad to work on overlays, and keep our source modification away from Mozilla files as much as possible. Changes that were touching Mozilla files take way more time to merge/migrate. That’s also an opportunity for us to clean up some of our code. For example, the way we were changing entities in browser.xul was to replace the DTD file. Bad, because we were missing the new entities from Firefox 3. We fixed that to only override the entities we want to change (Firefox -> Flock, Bookmarks -> Favorites…)

So here is where we are after a few days.

What works

• The datastorage layer. The data layer of Flock consists in an RDF datasource accessible through a Javascript object mapper (Coop) and serialized on the disk in a mozstorage (sqlite) database. I don’t know if Manish had to do anything to make it work in Firefox 3, but it seems to be working great.
• The services backend. We had to migrate to the login manager because the password manager is deprecated. So long nsIPassword, the time of nsILoginInfo has come.
• The web clipboard. Not really a surprise, it’s simple enough not to break. Cherry on the cake: now when you drag a picture or a snippet, the whole picture moves with your cursor. That really looks great and make drag’n drop very clear and easy to understand.
• The blog editor. Still some bugs, but the basic functionality is there. Almost no work required!
• The people sidebar. I’m really impressed. This is a big piece of code, but as soon as the service backend was fixed it just worked out-of-the-box. Everything seems to be working.
• The star button. That one was easy. Mozilla is introducing a one-click bookmarking star button (just like the one we’ve been having in Flock for 2 years). So all I had to do is drop our own star, move Mozilla’s one from the right to the left and theme it correctly. Tada! No online bookmark yet and it’s not clear whether we’ll stick with Firefox’ behavior (that’s not yet clearly defined anyway), but it’s a start.

What’s broken

• The theme. I started to fix it, but there is still a lot of work to do. The background on toolbars is missing, tabs and the URL bar need to be styled…
• Full text history indexing. Manish did some work on the Lucene level, and I started to migrate from the History RDF to Places. Not quite working yet.
• The searchbar. I didn’t look at it yet, but as you can see on the screenshot it’s not pretty. Maybe it will just work after we fix the theme and the indexer?
• Online bookmarks (Delicious, Magnolia). They do get synchronized locally but don’t appear in the UI yet. With Places we’re basically throwing away most of our UI favorites code, but we need to reinject the code related to online bookmarks in the Places UI.
• Mediabar. It’s pretty much busted. We’ve been using hacks and non-standard techniques more than in any other modules; I suspect that most of the breakages are due to things we were not supposed to do even in Firefox 2, and we may have to redesign some pieces to do it “the right way”.
• Notifications. I reverted that change because it was preventing the browser to start (”can’t find the XBL for browser”: hard to use it when the browser window doesn’t appear!). Manish is going to take care of it, and that’ll probably end up being a simple change.

I recommend to anyone coding on the Flock browser to have a look at Mozilla’s page about porting extensions to Firefox 3. In particular, there are points about stuff that work in Firefox 2, but that we were not supposed to use and will stop working in Firefox 3. For exemple, event.preventBubble deprecated in favor of event.stopPropagation. If we start to be careful about these points in Flock’s trunk, the migration to Firefox 3 will be much smoother.

And if you want to play with a broken browser… Feel free to build the branch experimental/firefox3-merge.

Lloyd, your recent post about knowledge disappearing and Flock “destroying” documents was a bit harsh. Did you send an email to any of your ex-coworker to ask where all these articles went?

There was a lot of useful information on wiki.flock.com, but honestly it was a messing. People have been dumping articles in it since the creation of the company and there were no clear structure. Since you knew that article existed, you would certainly have found it on the wiki, but the chance that someone new to it stumble upon the article you were talking about was very small. Even worse, the wiki was full of outdated articles that could be misleading. So, we decided to start with a clean base on http://developer.flock.com. We didn’t destroy the articles from the old wiki. We all respect Vera and Eli, we don’t have any reason to do so.

The articles are archived internally, so we can pull relevant articles from it and re-publish them on http://developer.flock.com. I will have a look at the articles you mentioned and probably get them to dev.f.c.

Something people often ask is support for more services. And that’s what we do: in 1.1 we will be adding support for Picasa, currently the service most people are asking for. But we can not implement support for every single service in the world! We have to focus on the core of the browser, horizontal features, performances and stability. We can not implement the “long tail” of web services, simply because there are thousands out there.

This is why Ishika and me (helped by Marcus, Chris and others) have been working on an API that is easy enough for third party developers to pick up and use. We are currently writing documentation to explain how it can be done.

The API was more or less present, but a lot of cleanup had to be done and new interfaces and methods had to be written. Specifically, what we had to do is:

• Well, make sure it can be done. At Flock we have a tradition of writing services in a modular way, but sometimes we added hacks in the core to enable a specific feature for a service. Extension developers won’t be able to do that, so all that hacks had to go away. In each area, we designed a way to support specific features from the service itself.
• Remove cruft. Flock’s features set has evolved a lot in 2 years, and stuff that should no longer be there was remaining. The best example is the “photo” module. Since we traditionally supported only Flickr and Photobucket, it was called the photobar and everything in the backend was photo-something. Now that we support YouTube and AOL’s Truveo, we changed it to “media” in the UI, but we also had to change interfaces names to avoid confusion (”A YouTube photo?”). More important, in Flock 0.7 (Cardinal), the photo module had some kind of social aspects: there were people in the photobar in a way. In 1.0 this created a duplication with our People code, so for 1.1 we moved what was left of the people logic out of the media module.
• High-level methods to manipulate data. All the data we store locally (a cache of the friends list, your online favorites…) are stored in RDF, backed by a mozstorage database (sqlite), and accessed by an object layer. We were accessing that data directly, but that’s not the best way to deal with data! We wrote high-level methods to store and retrieve data such as getFriends to get the friends list or addFriend to insert a friend in the local store.

As I said we’re in documentation writing mode, but if you’re a Warrior Developer who only need the code to understand, here are some examples:

• A media service: Dailymotion
• A people service: Pownce

There is an other side of the API: one that let you access all supported services in a unified way, if you want to create your own people bar… But I keep details about that for the next time ;).

Still working on the Photo API, I created an XPCOM module to use Dailymotion (a video sharing website pretty popular in France) in Flock.

It’s in trunk only, and disabled by default. If you have a Flock tree, you can enable by de-commenting the line regarding Dailymotion in $c/services/Makefile.in. So far it just support the search functionality and channels. There is no account management and no media stream detection yet.

Blogged with Flock

Being a Linux user, I was very happy to see the release of Google Desktop for Linux. So I ditched Beagle and switched to Google Desktop.

As you probably know, Flock comes with full text indexing of your web history. It works very well, and is integrated with the search bar which is very cool. But if you want to have your web history indexed, you can do it thanks to Flock’s compatibility with Firefox. Just follow the instructions on Google’s help pages.

• Windows: replace “Mozilla Firefox” by “Flock”, “Mozilla” by “Flock” and “Firefox” by “Browser”
• Linux: just go to the directory where you untarred Flock and follow the instructions. You can also put the file desktop@google.com in your home directory, personally I prefer that

Most of the time, unless it’s related to bookmarks, what works for Firefox also works for Flock.

Blogged with Flock

• Maps, geodata
• Google Gears: get web app offline
  
• Google Mashup Editor: Google’s answer to Yahoo! Pipes
  

Blogged with Flock

Tags: facebook, google, api

• We have both a flockIPhotoAPI and a flockIMediaWebService where it should only be one. flockIPhotoAPI is for media queries while flockIMediaWebService is to detect streams in a page
• We still have a photoAPIManager that has a lot of logic that needs to be done by the webServiceManager
• We have a flockIPhotoPeopleService interface that I don’t understand the purpose very well

Blogged with Flock

Tags: flock, developer