[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