Thanks. I will try changing the signal in the activities.<br><br>Gonzalo<br><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 10:52 AM, Benjamin Berg <span dir="ltr"><<a href="mailto:benzea@sugarlabs.org">benzea@sugarlabs.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello,<br>
<div class="im"><br>
On Mon, 2010-12-06 at 11:28 +0100, Simon Schampijer wrote:<br>
> We do only set the color when the palette is popped down. This does<br>
> break the following case:<br>
><br>
> - select text you want to change the color of<br>
> - open the color chooser and change the color<br>
> - do click anywhere in the canvas (not the selected text) and don't wait<br>
> for the palette to popdown<br>
><br>
> ---> The text is not selected anymore when the palette pops down, hence<br>
> the new color will not be applied.<br>
><br>
> I think the reason why Benjamin decided to set the color when the<br>
> palette is closed is that when you would emit a color change on each<br>
> change in the selector using the sliders would end up in a lot of<br>
> signaling. That is why color selectors either have a fixed set of colors<br>
> the user can select from or the custom selector with sliders is a dialog<br>
> (ok, cancel) and therefore it is known when the user has made his decision.<br>
<br>
</div>The signalling is actually happening in some way. It is possible for the<br>
application to listen to notify::color instead of color-set to do a live<br>
update of the preview.<br>
<br>
I have to admit that the issue with the text selection is rather<br>
unfortunate. A workaround for this would be nice to have and the<br>
solution may be to use notify::color instead.<br>
<br>
However, I do think that the real underlying issue is that a click to<br>
the canvas should *not* have any effect. Unfortunately implementing this<br>
is non-trivial, as it requires grabbing the input while still keeping<br>
the rest of the toolbar working (much like menu navigation in normal<br>
GTK+ applications).<br>
<br>
<br>
About the patch itself. It is wrong to remove the self.notify('color').<br>
If anything the self.emit('color-set') could be added in (some) places.<br>
<font color="#888888"><br>
Benjamin<br>
</font><div class="im"><br>
> On 12/02/2010 03:27 PM, Gonzalo Odiard wrote:<br>
</div><div class="im">> > diff --git a/src/sugar/graphics/colorbutton.py b/src/sugar/graphics/colorbutton.py<br>
> > index 1fed96d..c36320a 100644<br>
> > --- a/src/sugar/graphics/colorbutton.py<br>
> > +++ b/src/sugar/graphics/colorbutton.py<br>
> > @@ -125,7 +125,7 @@ class _ColorButton(gtk.Button):<br>
> >           self._preview.fill_color = get_svg_color_string(self._color)<br>
> >           if self._palette:<br>
> >               self._palette.props.color = self._color<br>
> > -        self.notify('color')<br>
> > +        self.emit('color-set')<br>
> ><br>
> >       def get_color(self):<br>
> >           return self._color<br>
<br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</div></div></blockquote></div><br>