[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