Desktop-Wide Data Model Objects

[Jeff Waugh <jdub perkypants org>]

Hey gang,

First, I apologise for spewing forth codeless crackrock ideas. They're here
if you care for them, I'm not going to harp on it. I've attempted to avoid
musing on the specific technology issues for your convenience. :-)

Some Blabber
------------

You can blame Havoc, James Willcox and iCal for the inspiration behind this
email. Havoc brought us GConf, a cunningly dynamic storage system and API
for desktop application preferences. James brought us a desktop-wide recent
files architecture, as seen in GNOME 2.1.x. iCal [1] showed me how easy and
clever calendaring can be.

The quick blurb to describe why I've been thinking about this stuff: We have
the fundamentals of the desktop environment pretty much done (work remains
to polish what we have), and are pretty much at a Win95/98ish stage in
competitive feature/integration terms. We now have our 2.x platform port,
and soon our first iterative release based on that work. So, we're rapidly
getting to a "what next?" stage in the grand scheme of things. Or at least
that's what I reckon. Grains of salt available at your local supermarket.

The Meat
--------

It's cool to see lots of MVC (model/view/controller) action going on at the
moment; very nice to work with. The GTK+ List/TreeView bits, James Willcox's
recent files stuff, and James Henstridge's EggMenu/ToolBar stand out as
great (recent) examples.

I think that desktop-wide data models for common user data would really
crank up our integration and capacity for "cool end-user features". This
concept covers storage of, and an API to provide access to desktop-wide
useful data. (It should probably cover some utility GUI stuff too.)

Here are a few examples to clarify:

  * Address Book

    This is pretty straight-forward data, and useful in many applications
    from email clients to mail-merge printing functions. In the wild, OS X
    has a standard user address book that applications hook into, which
    includes directory services.

  * Recent Files

    James has already given us a cool recent files implementation - desktop
    wide, and potentially a freedesktop standard! One of the clever features
    that takes advantage of the desktop-wide assumption is the central repo,
    and ability to pull in recent files by mime type. Instead of each app
    having its own recent file data storage, it can pull in all of the
    recent files of the mime types it handles. Open an image in Nautilus,
    and it will appear in your image editor's recent file menu! We also have
    a cool panel menu that lists the recent files of any mime type. Thanks
    to James for all of this cool stuff.

  * Bookmarks

    James has mentioned bookmarks as a possible extension of his recent
    files work, but rightly noted that they need a bit of special treatment.
    Having desktop wide bookmarks in Nautilus, web browsers, panel menus,
    etc. would rock way hard.

  * Calendar

    Lots of people would argue that most users don't use/need calendar data.
    I would argue that they would if they could, and if it were seamless. :)
    This ought to be desktop wide available data - from a simple task such
    as adding an alarm from the panel clock, to categorised, syndicated and
    multi-source calendar info [2]. Imagine the possibilities (if you can't,
    I'll blabber about this some more).

Some other things that could be standardised data models: user information,
keyring management (API for apps to add/remove auth details to the keyring,
UI for user to modify it -> the keyring in OS X even pops up a dialogue to
let you allow or deny application access to the keyring!)... This doesn't
take into account things like the authentication daemon, though it would
certainly use this infrastructure.

There are some interesting benefits that come with this strategy - syncing
with PDAs and other computers becomes simpler, etc.

We have pretty solid implementations of some of these things already. :) It
will be an interesting challenge to convince developers to 'commoditise'
these features, but ultimately worth it, IMO. I haven't really talked up the
integration possibilities here - don't want to prattle on too much. I hope
it will provoke some discussion or cluebatting. :-)

Thanks,

- Jeff

[1] http://www.apple.com/ical/

[2] categorised: rather than having a single calendar, you have many - kind
    of like categories. Funny analogy, but this works remarkably similarly
    to GIMP/Photoshop layers. See iCal for excellent example of this (note
    the list in the top left corner, and colour of items in calendar view).
    
    multi-source: Exchange, personal, syndicated calendars from friends,
    co-workers, or publically available sources (such as public holiday
    info, tv guides, GNOME release schedules, etc).

    syndicated: the ability to pull in calendar info the same way a news
    site pulls in rss feeds and the like. Download an iCal (the calendar
    data standard format) file every day or whatever, and display as
    appropriate. In Apple's iCal software, syndicated calendars are just
    additional calendars (read: categories or layers).

-- 
             make: *** No rule to make target `whoopee'.  Stop.