On Sun, Mar 23, 2008 at 9:01 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: > On 23 Mar 2008, at 18:32, Tomeu Vizoso wrote: > > > The idea is that, instead of waiting 5 seconds for the full UI to > > appear, the activity window would appear after, say, 3 seconds, half a > > second later the document will get loaded, and half a second later the > > user will be able to share the activity or invite somebody. > > > > Can your activities do something about this? > > I have just one activity at the moment, Moon, the difficulty I'd face > is that I really don't want multiple redraws at start-up for what > you're calling the document area, it's quite cpu expensive in my case > (at least a second or so per refresh). And I have a planned activity > where it may be even worse (a lon/lat tag sharable 3D Earth view). > > Currently there is no way an activity can know (in its __init__) if > read_file() is going to be called
handle.object_id is not enough? If no value is in there, the activity was started anew. If there's a value, that's the object id of the journal entry that the activity should be resuming. > so with your proposed changes, yes > I can (and do) set-up the default tool bar, a black screen and my text > panel early, but I'd then need to have my __init__ set-up a timer to > arbitrarily ~0.5 or more sec, just incase a read_file() call arrives. > So every fresh launch will twiddle it's fingers for an extra > unnecessary ~0.5 sec, and if after a Journal launch and the ~0.5 sec > was not long enough, the user will get a nasty double redraw of the > main cpu expensive widget refresh, slowing things down even more (and > looking bad as well). > > Letting the activity know data is, or isn't, expected from the Journal > is the missing feature here. Always having a read_file() xor a > clean_start() call would resolve this. Other options could be to just > always call read_file() data or no data and let the activity deal with > perhaps a file_name = None, but that will likely break some existing > activities. > > Regards, > Gary > > P.S. clean_start() is just a stand-in name, sure you'd have a better > name for it, maybe no_file()? On OS X under Cocoa we have the usual > init method to get the base things going, and then later an > awakeFromNib method is called so that an application knows its > resource files have been dealt with by the runtime – that's when we > can start parsing preference settings etc and tweaking the UI to > match. There's even then a final applicationDidFinishLaunching method > you override to kick things off once the set-up is all over. This Mikus' post explains much better what I was trying to: http://lists.laptop.org/pipermail/devel/2008-March/012094.html Tomeu _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel