Is read_file() always called after an activity __init__?

[Gary C Martin]

Hi Tomeu,

On 28 Feb 2008, at 09:40, Tomeu Vizoso wrote:

> Well, __init__ is too soon.

Well before calling activity.Activity.__init__(self, handle) yes that  
would be a real bad idea for sure :-) but after that it 'should' be  
fine shouldn't it, as the activity class is all set up? I can  
certainly read the metadata in my main __int__ just after the call up  
to super, and all works well.

> AFAIK, the API docs say that you can
> safely access Activity.metadata in the read_file() and write_file()
> methods. read_file() is called when the user is resuming an existing
> activity and write_file() when sugar thinks it is a good time to save
> changes to the journal (probably several times during the life of an
> activity).

It does seem like read_file() is only triggered if you have previously  
saved an actual file to filesystem, if you just have metadata, no call  
is ever made to read_file() so it's a rather bad place to pick-up the  
metadata. At least this is what I'm seeing here – I've just created a  
0 size file in my write_file() and now a resume from that journal  
entry is triggering read_file() every time.

> Is very probable that the API documentation is lacking, can you point
> me to the docs you were following? Have you already read the HIG in
> the wiki?

Not an officially maintained page I know, but:
	http://wiki.laptop.org/go/Beyond_Hello_World

Same suggestion comes from the current pydocs:
	http://<xo_running_pydoc-p8080>:8080/ 
sugar.activity.activity.html#Activity-read_file
	http://www.vrplumber.com/sugar-docs/sugar.activity.activity.html#Activity-read_file 
  (an online version)

I also went through a number of activity sources in git looking for  
examples, but I didn't find one that ONLY used metadata. They all seem  
to either not bother storing any UI state (so resuming or from new  
makes no difference), or they save actual files.

BTW: I'm quite happy with read_file() not getting called in file-less  
cases, just a matter of documenting it somewhere (if that is indeed  
the correct behaviour intended).

Thanks for your input.