[Bugs] #967 UNSP: Loading screens are impossible

SugarLabs Bugs bugtracker-noreply at sugarlabs.org
Mon Jun 22 16:31:21 EDT 2009

#967: Loading screens are impossible
    Reporter:  bemasc                     |          Owner:  tomeu                      
        Type:  defect                     |         Status:  new                        
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  sugar                      |        Version:  0.82.x                     
    Severity:  Unspecified                |     Resolution:                             
    Keywords:                             |   Distribution:  Unspecified                
Status_field:  Unconfirmed                |  

Comment(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
 Pro: This would cause the canvas to be displayed before read_file is
 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

Ticket URL: <http://dev.sugarlabs.org/ticket/967#comment:2>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system

More information about the Bugs mailing list