Loading screens are impossible

[bemasc]

If an activity author knows that read_file is going to take a long time, it would be great to be able to show a specific loading screen, rather than waiting at the pulsing activity icon. Unfortunately, this is impossible (at least in 0.82). The problem is that set_canvas() causes read_file to be invoked, if the activity is being resumed. read_file() is invoked before the screen is drawn, so there is no way to use set_canvas() to show a loading screen.

One reason this might be is: in activity.py, set_canvas() connects 'map' to canvas_map_cb(). canvas_map_cb() then calls read_file if there is a file to read. However, disabling this callback entirely does not solve the problem. There must be something more complicated going on that prevents the activity from showing a GUI until after read_file.

[walter]

Maybe this is why I could never get a custom loading screen to work with TA...

[bemasc]

So, I now understand what is going on. When an activity calls self.set_canvas() to display a GUI, this connects a handler for the "map" signal to the widget, canvas_map_cb(). This callback calls read_file, which in turn triggers whatever file-loading logic is required by the activity. The "map" signal is triggered after the widget is rendered, but before it is actually displayed, so all file-loading logic occurs before the GUI is actually visible.

Fixing this is easy, but determining the desired behavior is a bit trickier. For example:

1. We could make canvas_map_cb() use gobject.idle_add() to call read_file.
Pro: This would cause the canvas to be displayed before read_file is called.
Con: Existing activities, which could assume that read_file would be called before the GUI is displayed, would (very subtly) change their behavior. Also, this creates the potential for a race condition in which write_file is invoked before read_file has finished executing. We could add an interlock to make write_file wait for read_file to finish, if they occur out of order.

2. We could add a method like "set_canvas_early" (display, then call read_file) or "set_canvas_only" (display, don't call read_file), for Activities to use in new versions of Sugar.
Pro: Doesn't change behavior of existing activities.
Con: Makes activities that use this interface require 0.86 (non-backwards-compatible), or include yucky fallback code to check whether this function exists and do something else if it doesn't.

3. We could require Activities that want this behavior to call Window.set_canvas(self, widget) directly, bypassing the Activity.set_canvas method altogether.
Pro: Compatible with current Sugar. Requires no changes to activity.py.
Con: Commits a major abstraction violation. Activities must also invoke their own read_file methods if they do not call Activity.set_canvas()

At the moment, I think option 3 is the best, but it is not ideal. Suggestions welcome

[alsroot]

maybe it could be useful:
 http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line44

[tomeu]

Why activities that want this behavior doesn't do all the journal stuff by themselves instead of using the basic API?

The basic API is intended to make simple activities as easy as possible, but doesn't aim to be the best API for all kind of activities.

[bemasc]

Maybe so. Groupthink's GroupActivity class provides loading screens to all subclasses, so it is actually possible. It was necessary to override a few of activity.Activity's methods, but that's fine.

[tomeu]

Replying to bemasc:

Maybe so. Groupthink's GroupActivity class provides loading screens to all subclasses, so it is actually possible. It was necessary to override a few of activity.Activity's methods, but that's fine.

Are you using only information in the API? Or did you had to use any implementation details? If the latter, we should find a way so that activities can do this kind of things without risking to be broken by a bugfix release.

[tomeu]

Can we close this one then?