Blog entries for April, 2007

You say you "first learned" about our stuff "a few weeks ago" as if
that meant there was some secret conspiracy before that; but "a few
weeks ago" is pretty much when we started working on it. FUDCON was in
February, we made first design sketches right before that. That means
the first ideas were about 8 weeks ago. It's in the public record.

You say we worked "completely in private" but in fact we a) showed
brand new mockups and ideas at FUDCON and put them all on our public
wiki and have had all code in public SVN and b) Bryan personally
notified you when we started working on it in earnest, while we
continued to work completely in public.

The code used in BigBoard from Gimmie is perhaps 1% of both projects,
it sets the _NET_WM_STRUT hint from pygtk. This is just a trivial
piece of code that is not central to either project and bringing it up
as if it's significant is misleading. The rest of the code in the
projects does not overlap and in fact has little in common.

All our code is and always has been GPL, and it is perfectly
acceptable to include LGPL code in a GPL project. Moreover, if you
want to use any of our code under LGPL, you are welcome to do so, we
will relicense it.

I had no idea that Gimmie has web services stuff as an aspiration. I
don't know why I would have known.

You ask why I haven't supported Gimmie with some kind of public
statement; to be honest I just never thought to do that in my blog, or
saw a thread where it looked apropos to pile on. I have had multiple
conversations with Bryan and Jonathan of the form "Gimmie is one of
the only interesting things anyone is working on," though.

All in all, BigBoard is quite different from Gimmie, though yes it has
things in common (and with Google/Yahoo!/Vista sidebar, Apple dock and
dashboard, gnome-panel, Awn, and
so forth). There is nothing whatsoever wrong with having different
rapidly-developed prototypes as we try to understand what would be
awesome. The people you should flame are those people who are too
stuck in the mud to try anything new.

btw, I think Gimmie looks great and I do support it. Bryan liked the ideas
too which is why he contacted you weeks ago.

If you have a concrete set of ideas for how we can do what we're
trying to do while working in the same codebase as Gimmie, then get on
email and send them to us or the mailing list, and we'll talk about
it. Maybe mock up what the UI that merges the best of both would look
like, or tell us how our implementation would work into the Gimmie
codebase.

I think when you really try to draw the combined UI as a mockup, or
talk about which files from one project would go where in the other
source tree, then merging these projects starts to look impractical
and forced. Merging them may be a little "architecture astronaut" in
other words. But if you can spell out a concrete vision for how to do
it that preserves what we're both trying to accomplish, then we'll do
it. It's not a big deal.

The Mugshot team has been off learning what we can about all kinds of
not-traditionally-open-source technologies and audiences, but recently
we've started thinking about how to roll the knowledge back into the
Linux desktop. Here's an update (all heavily biased by my personal point of
view).

Neary says he thinks GNOME will either grow into different projects --
such as a One Laptop Per Child (OLPC) GNOME, a Home and Small Office
GNOME, and Enterprise GNOME -- or the project will shrink to the GNOME
development platform, "which will then be re-used by third parties to
build the interfaces they're interested in on top of it.

"We have already started to see this trend. Distributors cherry-pick
the applications they are interested in for their own desktop
projects, which are then themed and targeted for their core
audience. The variety of platforms and human interfaces being built
upon the GNOME platform is dazzling. These go from small-form-factor
interfaces like the Nokia N800 and the Maemo application framework and
OpenMoko and GPE through to innovative interfaces like Sugar from
OLPC, which is totally unfamiliar to someone used to the GNOME
desktop, but which is undeniably GNOME-based."

It isn't just the embedded or odd form-factor devices that are
customizing GNOME, says Neary. "Even the major distributions have
modified the GNOME interface to suit their needs. The openSUSE, Red
Hat Enterprise, and Ubuntu desktops all behave in different ways, and
have different target audiences."

Several of these specializations of GNOME technology for particular
audiences are happening at Red Hat; we're working on One Laptop Per
Child and of course the desktop for Enterprise Linux which focuses on
admins and programmers in part, and enterprise deployments of
various kinds (tech workstation, thin client, etc.) in part.

We've been thinking about another flavor, which we might call GNOME
Online Desktop (purely for the acronym, of course).

Online Desktop

Many people now live online and use the computer largely as an
Internet frontend, with few or no "offline" applications. Webmail is
by far the most common mail application, for example. But think also
of Flickr, IM, MySpace, YouTube, Google Docs & Spreadsheets, and
so on. I count myself in this group; without an Internet connection I
don't even bother to turn on my laptop.

Meanwhile, my desktop is crammed with relics of stuff I don't use. The
clock applet only speaks Evolution calendar, instead of supporting
online calendars such as Google Calendar. The Recent Documents menu
has junk I don't care about in it, instead of my actual documents (at
Google Docs & Spreadsheets). My panel launchers are for apps I
don't use instead of shortcuts to the web apps I do use.

Target Audience

What if we started a desktop specialization aimed at a subset
of current Linux users who:

Are individuals who own their own computer (not using Linux as
part of an enterprise or organizational deployment).

Use Linux as a desktop, for things like web browsing and listening
to music (not using Linux purely as a server or purely for
workstation-type productivity).

People who avoid using online applications for whatever reason
(strong tendency to work offline, flaky net connection, enterprise
security, or whatever).

I say "current Linux users" for the target audience because we can get
them to try out Online Desktop first. But if we're successful, we
could then extend the target audience to include people who aren't
using Linux already, whether individuals or even small businesses.
At that point we'd have to start worrying about things like migration
path, marketing to these new audiences, and so forth.

Features!

If we make these assumptions about the audience, what kinds of changes
could we make in the desktop?

People

A number of services maintain online contact lists ("people I
know"), including AIM, Google Talk, GMail, Facebook, MySpace and
Mugshot. Ideally, we would somehow collect "people I know" from these
places and have the desktop be smart about who I know and who I can
interact with in various contexts - sharing a file, writing a
document, sending an IM, or whatever it is.

In technical terms, we'll want to drop the Evolution contact
database stuff and instead have a more
free-form/aggregation-oriented/stored-online idea of who your contacts
are.

Applications

Yesterday I mentioned Mugshot applications, where
we're building a social concept of the "universe of applications."

Ideally, this effectively replaces
/usr/share/applications. /usr/share/applications becomes purely the
launch instructions (we're using it for the Exec= line).

In technical terms, this means replacing application launching (panel
menus, launchers, etc.) with a new interface, and replacing the
"package tool" with Install buttons contextually available as you
browse the universe of applications.

Our "universe of applications" should also include web apps as
first-class.

Documents

Documents are ideally kept online; this can take several forms. For
documents belonging to Google Docs & Spreadsheets, they are online
inherently. For more "native" documents, we might have online folders
that backend to something like S3 and are available in the file
manager. We might also look at the AbiWord Collaboration work that
people have been doing.

The "recent documents" list should include online documents, for sure.

Photos

We can just stick photos online by default, in Picasa or
Flickr. For example, if you plug in a camera, the default action is to
upload the photos, not copy to a local folder. We could also for
example maintain a local cache with F-Spot set up to stay in sync with
the online app. I think F-Spot already has some Flickr integration
even (?).

Calendar

We'd just use sites like Google Calendar as a calendar,
integrating it into the desktop clock/calendar applet or wherever, as
appropriate. There should be desktop notifications of upcoming events.

Preferences

We already have a simple way to store key-value pairs on mugshot.org
and a Python script that syncs gconf to the server dynamically, this
approach means that people's settings follow them around instead of
staying on a single computer. It needs to be productized, but this is
pretty simple to get going.

Search

Search should be nicely configured by default to include all my online
information (calendar, documents, etc.) in addition to local files.

Easy Sharing, Local or Internet

For some reason nobody has solved the problem of easily sharing a file
with someone else; email attachments remain the usual approach. But it
should be possible to simply drag a file onto someone's photo, whether
that person is sitting next to you at a conference or half a world away.

API

Right now, there's quite a bit of work if a desktop application wants
to integrate with online services. Typically, the app has to write a
bunch of code to talk to the service; and the app has to require the
user to configure some often-arcane parameters.

Instead, we could make this desktop-wide. Think of a simplified and
online-backed contacts API for example, so any app could easily
support getting a list of people to interact with and opening a
connection to one of them. Appropriate gvfs backends might be another
example of desktop API taking advantage of online services.

Another API goal is "pluggable services," for example to support
multiple calendar sites, we might build an abstraction API across them.

Live CD

One way to think about an "online desktop" is that you could put in
a Live CD, log in, and automatically get all your stuff and all your
preferences. I don't really see a live CD as the primary use-case, but
it's a useful way to think about the design.

More Ideas

It's easy to think of more new features to implement:

Integration of blogging; the Flock browser has many ideas to build
on for good blogging support, and a blog program could be on the panel
by default.

Mail notification for GMail and other web mail programs.

Make it easy to automatically chat with anyone using the protocol you
have in common with them.

Keep browser state such as bookmarks in del.icio.us or online in other
ways.

...

In short suddenly the desktop goes from "solved problem" to "whole
universe of useful new stuff we could do."

Getting Started: How to Proceed?

Putting everything immediately upstream into core GNOME has
problems; because the Online Desktop makes assumptions suitable for
its target audience but not for many GNOME users, maintainers would
frequently bounce the patches. More importantly, it isn't clear yet
what Online Desktop should look like or how it should work. We need to
prototype.

At the same time we should keep a low barrier to entry, so people can
easily try out Online Desktop.

Our thought, modeled on the Compiz approach, is to replace just one
component of the desktop - the panel. This way we can ship one
codebase, and to try it out you just run the new panel app.

In the short term we need not even replace the whole panel, we can do
a sidebar similar to the Yahoo!/Google/Vista sidebars on Windows. The
sidebar works fine with your existing panels.

Colin, Bryan, and I (mostly Colin and Bryan) have been working on such
a thing for a couple weeks, the code name is Big Board and you can
find more
information here.

Big Board uses Mugshot to "fill in gaps." That is, Mugshot is not
intended to replace services you already use (whether Flickr or
Facebook or whatever); but if we need to do something that no existing
service provides, we can stuff it in Mugshot. For example, Mugshot has
the applications browser
I mentioned, and it has prototype-quality storage for shared files and
for preferences. Mugshot in this context is an open source server
codebase that we can extend as we need to.

Mugshot also aggregates information on all the accounts and
addresses you and your friends have, so that information is available
to the desktop. In Big Board there's a "slideshow" feature that cycles
through thumbnails from your friends' Flickr, Picasa, and
YouTube. Mugshot means this works with zero configuration, while the
traditional alternative would be to manually type in all the friends'
accounts you wanted to include.

Big Board doesn't talk directly to the mugshot.org server, though; it
instead uses D-Bus APIs exported by the local Mugshot client.
Other apps could use these APIs as well.

Big Board is very much a prototype right now (for example, the search box is
just the GNOME deskbar applet, and embedding an applet in a
non-gnome-panel doesn't quite work). The hope of course is that we'll
evolve from prototype to something more robust as it makes sense.

We also see the goal as "online desktop" rather than only "panel/sidebar gizmo," but
as I mentioned Big Board is somewhere to start.

If you don't have the app installed, and Mugshot understands your
OS, there will be an "Install Now" link right on the web page.

If you do have the app installed, there will be a "Run It" link
right on the web page.

The application pages can be edited wiki-style to add a
description and so forth for each app (very basic and rough UI on this
right now).

You can probably imagine lots of interesting directions to evolve
this.

Right now, two things you might be interested in:

If your distribution isn't supported, you won't get Install and
Run links; look
here for more on how to help add support for your distribution.

If you maintain or have an interest in a particular application, you
might want to update the description and other information about it.
Go to the application's page on Mugshot and click on the link to edit
it (you must be logged in to Mugshot).