(nontechnical blog entry)
Ah, Wikipedia. A few minutes ago I was idly browsing the New York Times, reading an editorial which mentioned an event in Falluja in March 2004 which was supposedly a turning point. Idly curious what that would be, I search and end up on Wikipedia which pretty quickly tells me about the event. Another click or two I end up at the page describing what qualifies someone to be “notable” on Wikipedia.
What I find interesting is that in addition to People, one can find the notability guidelines for other categories like Films, Books and of course, Pornographic actors. Er, what?
It has been suggested that this page or section be merged into Notability (people). (Discuss)
Archive for September, 2007
(nontechnical blog entry)
So today, I decided to play around with pygtkmozembed to see how hard it would be to support Google Gadgets on Firefox/Linux. Personally, I am less interested in the random crack gadgets so much as the my data please gadgets.
Google widgets hack
The current state of things is that any gadget which is a “url” widget (i.e. no extra goo) obviously works; all you need is to have Firefox pointed at the url with the correct cookies from your main browser profile (This latter point I’m still working on doing more robustly). Most other gadgets which are hosted externally we can just point at
gmodules.com, which basically returns us pre-rendered HTML. What isn’t supported – and this was actually my main goal – is gadgets which depend on some sort of internal Google gadget authentication like reader and docs. I might see if I can figure out how to compute
One other thing I wanted to mention is the new Files stock for the online desktop sidebar. Basically it started out as a monitor of your recently used files, then Marina added support for pulling in your recently modified Google Docs using the brand new Docs API.
I think longer term I want to just add support for Google Widgets to Jackfield, once I add the patch to use the workaround for gtkmozembed so Jackfield doesn’t segfault too.
Update: Turns out
__ENV_google_apps_auth_path is used to differentiate between gadgets for regular consumer Google and Google Apps For Your Domain; replacing it out makes it show consumer Docs, whereas replacing it with say
a/verbum.org shows my verbum.org docs. Cool.
I was going to write a longish blog entry, but Bryan blogged it quite well. It is in fact as awesome as he says. If you’re willing to run bleeding edge Firefox, you should try it.
It’s kind of funny just how strongly most applications reflect the underlying APIs they use. I think it’s just a manifestation of the path of least resistance principle for programmers. For example, pretty much every editor I’ve seen includes a save button, which maps strongly to the underlying write()/close() APIs. But…there’s no reason to have a save button. Changes I make should be automatically saved (like how GMail does it). Then, allow me to view history and undo. The best example of this is the Eclipse local history. Eclipse still has a save button, but I think they could fairly easily delete it; they just probably don’t have the will to face down the vocal minority.
Yesterday I got motivated by this post on the Hotwire Google Group, so I sat down and hacked for a while to fix some issues that had been bugging me in my day-to-day usage, and add some cool new features.
Hotwire 0.595 announcement.
What I actually want to talk about today is a feature that’s been around for a while in Hotwire, related to the idea of automatic saves:
Remembering what directories you actually use, automatically
Searching for firefox
Quick background: A week or so ago when Bryan and I decided to base the Firefox Journal on Firefox 3, I downloaded the latest Firefox CVS source and built it myself. This is in fact very easy to do, by the way, if you’re interested in joining the Firefox development community too.
Now, when I log into my desktop, I need to start the development version of Firefox, not my system one. This involves changing to my Firefox build tree and executing MOZ_NO_REMOTE=1 ./firefox -P default. Hotwire makes this experience significantly nicer than gnome-terminal+bash.
Whappening in the above screenshot is that I’m in my home directory, and I typed cd firefo. One thing you can notice immediately is that I have a real firefox directory as an immediate subdirectory (this is an older binary distribution). Hotwire offers that to me as the first completion, for compatibility with TAB mashing.
But what about those other completions? How does Hotwire know to offer me a completion all the way to src/mozilla/build-firefox/dist/firefox, instead of some subdirectory? The algorithm is actually very simple. Hotwire remembers how often you execute commands in each directory, and the cd command is actually a search over your “hot” directories, ordered by frequency of command execution.
I’ll be honest. Hotwire has its bugs. You probably wouldn’t believe me if I told you how Rube Goldberg the process of displaying output from shell commands is internally, for example. But it’s small features like the above that make me never want to back to terminal+bash. Longer term, we can fix bugs that make Hotwire different (as opposed to purely better) than term+bash, but I don’t see the competition evolving the way we are. I doubt bash even has a hash table internally, much less a slick interface to SQLite.
My long term goal is to get to the point where people think of Hotwire as the “Firefox of development shells”. We have a ways to go to get there, but all Hotwire needs is a few skilled Python hackers to really help bring it to the next level. If you’re interested, jump into development!
So Microsoft has released an initial version of their Windows Live integration. If you can’t be bothered to read the article, here’s the summary interesting to tech folks:
Microsoft’s new Windows Live software suite includes an updated electronic mail program, a photo-sharing application and a writing tool designed for people who keep Web logs.
Taking this point by point:
- Better integration with Hotmail – Presumably things like mail notification. Ok, we have that in the most part; there’s notifiers e.g. GMail in Pidgin and the sidebar. I’ll talk more about this in a minute.
- Photo sharing – Here we fail currently. The default in GNOME when you plug in a camera is that the photos sit on your hard drive, viewable only by you and just waiting to be lost when you drop your laptop. We need someone to fix this – I had some suggestions for part of that. Conduit looks useful for transferring bits, but doesn’t look like it is attempting to solve the problem of helping a normal person get started putting photos online by default.
- Blog tool – eh, we have tons of those. The web editors for most of them are basically good enough anyways. Not important.
Ok, so overall, they win on photos. Now, we have a vision for the Online Desktop (as relates to GNOME/Firefox/Linux/Free Software). Part of that vision is:
Open source doesn’t have an agenda like this; our online desktop will be integrated with anything and everything users want to use.
In other words, it’s easy for Microsoft to do photo integration because they can just hardcode the OS to integrate with Windows Live Mail or Windows Live Photos, not everything else. A problem we’re running into now is that we just haven’t yet defined what the framework is for integrating with different kinds of online services. Havoc says:
a) add separate APIs to list, watch changes in, and get named
properties of each type of object; this can be merged into the Online
Desktop data model perhaps. For each type of object the implementation
will be different, since we’ll have to talk to or scrape a different
Yes, we need to do this. This API question is an instance of the larger problem I see, which is how do we make the desktop integrate in a generic way with the websites you use, and if you don’t yet have a service, how do we make finding one possible?
The mailto: handler we have is basically a perfect example of an application waiting for this integration API. The mailto handler has no way to know whether you use Yahoo! Mail, Hotmail, GMail, or whatever.
Of course, it isn’t just the mailto handler. To get the experience right for photos, it’s crucial, as I talked about above. Another example is the IM client. What I would love is that on a new account, if I log into GMail, the IM client automatically appears, configured to use Google Talk. It must likewise work for Yahoo! Mail.
What I would really like to do from this point on in the Online Desktop effort is to for each feature we add, try to integrate with at least 2 services in the feature category. As most programmers know, there usually isn’t a big difference in effort between supporting the case of 2 versus an arbitrary (but reasonable) N.
So, back to the API. Actually first, let’s think about what the user experience should be instead of starting by coding the D-BUS API we made up in our head. Here’s a screenshot from a related application, Mugshot:
Now, Mugshot’s list of “websites I use” is subtly different in that right now it’s really “websites I use that my friends will be interested in”. For example, the desktop should have E-Bay integration (bid watching apps) but I’m dubious about the value of stacking things I’m bidding on to my friend’s desktops. There is also the technical issue in that honestly right now it’s a lot of work to add a service to Mugshot; a lot of that work is in the stacking support.
However, the more I think about it, the more I do think it makes sense to ultimately have a UI similar to the Mugshot one. From this flows some technical decisions such as that we’re storing it online, we can use the data model to retrieve it. We do need to figure out the problems I mentioned above – how do we have private services? And how do we scale the UI to support a long tail of services? The current list is already fairly big, and if we added even a few more photo sites and such it’d be unwieldy. Also, how do we encourage the user to list (and maintain!) their infos? It needs to be a key part of the experience. They need to understand why we want say their EBay or Last.fm username.
One other detail – passwords – some people thought Mugshot stores your passwords to retrieve data. It never has, and likely never will. Though if we wanted to do social network importing from other sites, we’d probably need to do that. Sigh. Anyways, ignoring that: In my opinion, we should concentrate on unifying the logins outside of Firefox first. As Alan Cox mentioned, there are some gotchas in doing syncing to the web browser. If we can fix the few key programs (mail,IM,photos) to share your Google and Yahoo! logins, we’ll be doing pretty well.
So the executive summary is here – I don’t feel we have a coherent answer yet for this problem. Responses welcome if you have other ideas – it’s actually a complex and hairy problem, involving a big cross between desktop apps, the web browser, and web sites, which is why it isn’t solved yet.