[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
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
--
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