Can I use the keep or title_set_by_user key of metadata to store info about my activity

Tomeu Vizoso tomeu at
Tue Aug 4 03:55:35 EDT 2009

On Tue, Aug 4, 2009 at 03:09, sumit singh<sumit.coder at> wrote:
> Hi Tomeu,
> This is in continuation with our chat yesterday. The write/report
> activity would be having 3 states , I mean whether the user is working
> on a blank document , designing a new template or using a previously
> designed template. So, what I wanted was to save this state as well
> while saving the activity using the write_file method, so that when I
> resume my activity from the journal , i should switch over directly to
> that state where the user closed the activity.
> The only idea I was getting to achieve that was to save the state as a
> number in the metadata file and then retrieving it from read_file fn ,
>  however as I cannot add new keys in 0.82 version as they are lost
> over restarts of xo, so I was planning to use the keep or the
> title_set_by_user key of the metadata as I didn't find them getting
> used anywhere. However, I am not sure whether these are used for some
> important work internally by sugar. What do you think would it be safe
> to use any of these 2 key values.

Unfortunately, the Journal uses both of them.

> Is there any other way to achieve
> this other than this on 0.82.

See here about which property names are available in 0.82:

What about (ab)using the description or tags field? It has the
downside that users can modify it, but at least won't have secondary

> I think I can use the hasattr fn to distinguish b/w 0.82 and 0.84 and
> do so only if it is a 0.82 version while adding a new key instead in
> 0.84 version. Kindly give your suggestions.

But then, when a laptop is updated to 0.84, there would be problems anyway.

Perhaps a better solution to this and other problems you have found
would be to use plain Write to edit a new document based on a
template, and a different activity for creating and editing templates.
Would this work in your case?



> Regards,
> sumit.

More information about the Devel mailing list