#3807 LOW Update.: TrayScrollButton not same color as Tray

[Zarro Boogs per Child]

#3807: TrayScrollButton not same color as Tray
---------------------+------------------------------------------------------
  Reporter:  erikb   |       Owner:  marco                            
      Type:  defect  |      Status:  new                              
  Priority:  low     |   Milestone:  Update.1                         
 Component:  sugar   |     Version:  Development build as of this date
Resolution:          |    Keywords:  review-                          
  Verified:  0       |  
---------------------+------------------------------------------------------

Comment(by benzea):

 Replying to [comment:10 marco]:
 > {{{
 > +        'can-scroll'      : (bool, None, None, False,
 > +                             gobject.PARAM_READABLE),
 > +        'can-scroll-prev' : (bool, None, None, False,
 > +                             gobject.PARAM_READABLE),
 > +        'can-scroll-next' : (bool, None, None, False,
 > +                             gobject.PARAM_READABLE),
 > }}}
 >
 > Maybe we can simplify things by removing can-scroll?

 Hm, the naming is bad. "can-scroll" means whether the scroll buttons
 should be visible. So maybe "needs-scroll-buttons" or something similar
 makes more sense.
 (We need visible/invisible and normal/insensitive.)

 > {{{
 > +        # The alignment is a hack to work around gtk.ToolButton code
 > +        # that sets the icon_size when the icon_widget is a gtk.Image
 > }}}
 >
 > Can we just set the toolbar icon size?

 Hm, yes that should work. I had not realized that the activity (or other)
 buttons are not on the same toolbar widget, but in another container.

 > {{{
 > +            self.set_sensitive(self._viewport.get_property('can-scroll-
 next')
 > }}}
 >
 > We are generally using self._viewport.props.can_scroll_next

 Ok, that should be changed then.

 > {{{
 > -        gobject.GObject.__init__(self, **kwargs)
 > +        gtk.HBox.__init__(self, **kwargs)
 > }}}
 >
 > What is the reason of this change? Calling the GObject constructor makes
 gobject properties to work correctly. (there might not be properties in
 that code but still...)

 Shouldn't have changed that. But thanks for the explanation of why the
 calling the gobject constructor makes sense.

-- 
Ticket URL: <http://dev.laptop.org/ticket/3807#comment:11>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system