[Bugs] #267 UNSP: Explicitly inherited method to (re)construct activity GUI after loading(possible) journal entity in sugar-toolkit
SugarLabs Bugs
bugtracker-noreply at sugarlabs.org
Sun Feb 1 06:06:38 EST 2009
#267: Explicitly inherited method to (re)construct activity GUI after
loading(possible) journal entity in sugar-toolkit
------------------------------------------+---------------------------------
Reporter: alsroot | Owner: marcopg
Type: enhancement | Status: new
Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team
Component: sugar | Version: Unspecified
Severity: Minor | Resolution:
Keywords: tomeu | Distribution: Unspecified
Status_field: Unconfimed |
------------------------------------------+---------------------------------
Comment(by tomeu):
Replying to [comment:3 alsroot]:
> Replying to [comment:2 alsroot]:
> > Replying to [comment:1 tomeu]:
> > > Why don't you update your UI in read_file()?
> > sometime there is differences between "just construct" and
"reconstruct existed"
> moreover in case of having new method there is only one place to collect
logic (otherwise in init() and in read_file())
I'm a bit concerned about making the Activity class more complicated. It's
already quite messy and that is confusing activity authors.
Cannot we say that activity authors that find themselves in this situation
can construct their UI by calling a single function from __init__ and
read_file?
--
Ticket URL: <http://dev.sugarlabs.org/ticket/267#comment:4>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system
More information about the Bugs
mailing list