Re: Patch for Result Sets

[<nat ximian com>]

Hola,

I'm in Buenos Aires on vacation for three weeks, so a release won't happen
until I get back.  Therefore if you think the backends can get updated in
that time, this level of destablization is okay with me.

One thing we need to be careful about is generalizing the visualizations
too much.  Each type of data in each context requires its own specific,
tuned visualization.  Therefore I think we do need to provide pluggable
renderers for the various Result types.  Separating the renderers from the
result finders is a good move, for sure.  We should be careful to document
the various types of result objects, so that new backend authors can get
some visualizations for free.

One of the conclusions of the Vandevar Bush paper was that users need
multiple visualizations of their data; this premise is corroborated by a
large body of user interaction research.

Also, I hope that those of you who have been modifying the HTML rendering
to add frames and tables will read Edward Tufte's books.  Data should not
be imprisoned in visual distractions like borders, when the borders don't
serve a specific and useful semantic purpose.  Though the matches look
more uniform nowadays, this is actually a disadvantage for the user:
different types of data should not look the same.

I'm eager to get back and get a release out, but the three weeks of
decompression are pretty welcome as well.

Best,
Nat

> Hi,
>    Following on from an earlier email I've had a few responses from
> people who were interested in this patch so I figured I might as well
> post it to the list with a bit of explanation around it.
>
>    The patch was initially designed to remove HTML from backend output
> and return it in something a bit more flexible.  As I added this
> functionality it rippled a bit, so that a few more bits and pieces that
> had been mentioned on IRC as desirables came in to play.  To summarise,
> the patch:
>
>    - returns data from backends in a structured format, as a set of
> objects
>    - standardises on HTML output in the current GUI
>    - provides a way to return 'sub-results' (e.g. the GAIM backend
> returns a given user as a result, with a set of recent conversations as
> subresults)
>    - tags each field returned, paving the way for allowing users to
> define which fields they want to display from a given backend
>    - separates the backend from the GUI to allow future GUIs to be
> written without touching backend code
>    - timestamps results sets to provide a way of 'fading' data as it
> ages
>    - provides categorisations for backend data to allow for grouping
> (e.g. the 4 different bookmark backends all have the same category)
>
>    Now for the bad news.  I haven't updated all of the backends to work
> with the new output format, so they aren't all going to work
> immediately.  The backends that have not been updated are:
> regexpchainer, rhythmboxlibrary, ephybookmarks, addressbook, evomail,
> and ephyhistory.  It doesn't take much to get them working, but I don't
> have the required data to test these with so left them alone.
>
>    If you do attempt to use this patch then please ensure that you clear
> out all of your backend .dlls from your dashboard installation
> directory, as older .dlls will cause problems.
>
>    I do not suggest that this patch gets applied to CVS as it's a
> relatively major change and if a 0.1 release is desired soon then this
> is a bad patch, as it destabilises more than it stabilises.  That said,
> I'd love to get some feedback from people on the patch, and think that
> it would be great to hit CVS after 0.1 is out of the door.
>
>    The patch is available at
> http://www.devzero.net/downloads/resultsets.patch
>
> Cheers,
> Jim.
> --
> Jim McDonald - Jim mcdee net
>
> _______________________________________________
> Dashboard-hackers mailing list
> Dashboard-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/dashboard-hackers