Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#967 closed enhancement (fixed)

Loading screens are impossible

Reported by: bemasc Owned by: erikos
Priority: Normal Milestone:
Component: Sugar Version: 0.82.x
Severity: Unspecified Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Needinfo

Description

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.

Change History (10)

comment:1 Changed 12 years ago by walter

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

comment:2 Changed 12 years ago by 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.

  1. 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.

  1. 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

comment:4 Changed 12 years ago by 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.

comment:5 follow-up: Changed 12 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 12 years ago by 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.

comment:7 Changed 11 years ago by tomeu

  • Bug Status changed from Unconfirmed to Needinfo
  • Component changed from sugar to sugar-toolkit
  • Milestone changed from Unspecified by Release Team to 0.86
  • Owner changed from tomeu to erikos
  • Priority changed from Unspecified by Maintainer to Normal
  • Type changed from defect to enhancement

Can we close this one then?

comment:8 Changed 8 years ago by dnarvaez

  • Component changed from sugar-toolkit to Sugar

comment:9 Changed 8 years ago by godiard

  • Resolution set to fixed
  • Status changed from new to closed

Tomeu asked 4 years ago if can be closed...

Closing

comment:10 Changed 8 years ago by dnarvaez

  • Milestone 0.86 deleted

Milestone 0.86 deleted

Note: See TracTickets for help on using tickets.