gtg-contributors team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Tue, Jun 01, 2010 at 10:22:54AM -0400, Paul Natsuo Kishimoto wrote:
>   Some thoughts: Any "transforms" of task data should be REVERSIBLE and
> BACKEND-AGNOSTIC. By REVERSIBLE I mean that:
>         Task A (Backend X) -> Task A (Local File) -> Task A (Backend X)
> ...should result in an identical object in Backend X.
> 
>   Obviously this only applies where Backend X has a *less* sophisticated
> task model than GTG—but there are lots of such cases (RTM, iCalendar...
> did everyone see my spreadsheet?
> http://spreadsheets.google.com/ccc?key=0AhRkDXhnjLt8dHM3MmZ0YmJnMm1UM1hySFNlaDBVc1E&hl=en_GB)
> 
>   By BACKEND-AGNOSTIC, I mean that if you have Backend X and Backend Y
> that both support the same subset of the GTG data model, then:
>         Task A (Local File) -> Task A (Backend X)
>         Task A (Local File) -> Task A (Backend Y)
> ...should produce the same result, *unless* there is some very good
> reason to do otherwise.

This does seem quite wise.  Looking at your spreadsheet, I wonder if one
simple solution would be for gtg to retain any data items it does not
recognize itself as "dark matter" (i.e. a dict stored with the task,
that backends are welcomed to get/set stuff in, but that gtg just
ignores.)

In Inkscape early on there were a bunch of SVG properties we knew
existed but that we had no GUI support for, so we just had a popup
dialog with a dictionary list of these items so even though Inkscape
didn't know what they were, the user could still access and tinker with
them by hand.

I think it would be pretty straightforward to generate a dialog like
that in gtg that just programmatically generates a dialog with a list of
label / text-input widgets for all the items in the dict.  That might
give a pretty good user experience for these cases for a minimum of
effort on our part.