[Bugs] #1592 UNSP: NEW FEATURE: enhanced color selector

Sugar Labs Bugs bugtracker-noreply at sugarlabs.org
Wed Aug 4 11:38:05 EDT 2010


#1592: NEW FEATURE: enhanced color selector
------------------------------------------+---------------------------------
    Reporter:  walter                     |          Owner:  tomeu      
        Type:  enhancement                |         Status:  new        
    Priority:  Unspecified by Maintainer  |      Milestone:  0.90       
   Component:  sugar                      |        Version:  Unspecified
    Severity:  Unspecified                |       Keywords:  r!         
Distribution:  Unspecified                |   Status_field:  Assigned   
------------------------------------------+---------------------------------
Changes (by erikos):

  * status_field:  Unconfirmed => Assigned


Comment:

 Like discussed on irc, we need to do the following for the toolkit part:

 - The logic about the next_color* calls should be put inside the module.
 As they are based on the color index of the module, I think the module
 level makes more sense. The problem is, that you can generate a color that
 is not in the index. We have to handle the cases where someone calls the
 method with a color that is not in the index:

 {{{
 <erikos> >>> a = xocolor.XoColor('#000000,#FFFFFF')
 <erikos> >>> a.get_next_color()
 <erikos> '#FF2B34,#B20008'
 <erikos> >>> a.get_prev_color()
 <erikos> '#BCCDFF,#AC32FF'
 <erikos> >>> a.get_next_fill_color()
 <erikos> walterbender: that call never returns
 }}}

 So, I think they should be on the module level, like get_random_color, if
 we want to expose them.
 And if we add API we should add comments, it would be great if you could
 add a comment to the public methods what they do (I will cleanup the rest
 of the module after we landed this feature).

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/1592#comment:25>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list