[sugar] frame redesign

[Simon Schampijer]

Hi Tomeu, Eben,

I went through the last commits until 'Remove activities.defaults, not 
used any more'. I will go through the rest as well. Here are my thoughts:

*** Pulse activity icons in the ring during launch
commit 3670fda59103c32fcbe8b28a9f8e77a75ac15d31

pylint:
  - src/model/homemodel.py: Unused import dbus (maybe you can remove 
that when you fix something in that file)
  - 139: Line too long (81/80)
  - 198: Line too long (81/80)

_get_color() could be a function since it does not access the actual 
object. Probably ok in this case.

W:211:ActivityIcon: Use of "property" on an old style class
W:215:ActivityIcon: Use of "property" on an old style class
Why do we 'wrap' the get_version method here with the property construct?

*** Made background colors of zoom spheres white, for consistency
commit c5b776bcf27b4f6e638fac3658437a3c194e7ddd
  - src/view/BuddyIcon.py
      - no semicolon

*** Fixed scale and placement of a single icon in the ring
commit ef75cabea665c436fc40cee887462931462d6bbf
  - what do the '**' instead of '*' mean ?

*** Store favorite activities in the profile dir.
commit 3b5131e4b16eb5a83278de3787a5b1f4763ae566
  - no need to import os.path as well we import os already

*** General Errors
src.view.home.activitiesring:
E: 75:ActivitiesRing.__activity_added_cb: Undefined variable 'info'
     - should probably be activity_info

src.view.home.activitieslist
W: 20: Unused import gtk

* General Thoughts
What is the advantage from simplejson over json. The home page says: 
simplejson is API compatible with json-py, but is more easily 
extensible, has better unicode support, is probably also faster, and is 
MIT licensed (json-py is LGPL/GPL). Should we recommend people using 
simplejson?

Nice work,
    Simon



Marco Pesenti Gritti wrote:
> On Sat, Mar 1, 2008 at 5:32 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>  >  0ad5327f664e49ce7e32fee4deb307165c5e7732
>>  >
>>  >  +        if new_level == ShellModel.ZOOM_MESH:
>>  >  +            self._mesh_button.props.active = True
>>  >  +        elif new_level == ShellModel.ZOOM_FRIENDS:
>>  >  +            self._groups_button.props.active = True
>>  >  +        elif new_level == ShellModel.ZOOM_HOME:
>>  >  +            self._home_button.props.active = True
>>  >  +        elif new_level == ShellModel.ZOOM_ACTIVITY:
>>  >  +            self._activity_button.props.active = True
>>  >
>>  >  I think we should start using the new style gobject properties in new code.
>>
>>  You mean 'self._activity_button.active = True' should work? It doesn't
>>  work here with 2.14.0.
> 
> Hmmm we should take a closer look at this then, i.e. see what is
> supposed to work and if it actually does.
> 
>>  >  There will be conflicts with the Tray vs Toolbar thing in the previous one.
>>  >
>>  >  af16fc5b4c2b15bee68656867355883146f07030
>>  >  d61258768b33d8bb646c6bdf159ad46bc9059f19
>>  >
>>  >  What problems do you have there? I'll just note that sometimes it's easier
>>  >  to use toggle buttons then radio, not sure if this is the case.
>>
>>  The problem is that shell_model.props.zoom_level is saying
>>  ShellModel.ZOOM_ACTIVITY when it is really ShellModel.ZOOM_HOME, so
>>  the radio button is wrong at start time.
>>
>>  I don't like much how the model stores the zoom level and the view has
>>  a setter that does something else when changing levels. Perhaps we
>>  should set and get from the model, and the view could listen for a
>>  signal and take screenshots, etc.
> 
> 
> The problem is that part of the zoom logic is handled by the window
> manager, part by sugar. I don't remember the details but I know I was
> not very happy with that logic and that it was buggy in some cases.
> 
> 
>>  +        # TODO: setting box_width and hippo.PACK_EXPAND looks like a
>>  hack to me.
>>  +        # Why hippo cannot respect the request size of these controls?
>>  +
>>          zoom_toolbar = ZoomToolbar(self._shell)
>>  -        panel.append(hippo.CanvasWidget(widget=zoom_toolbar),
>>  hippo.PACK_EXPAND)
>>  +        panel.append(hippo.CanvasWidget(widget=zoom_toolbar,
>>  +                box_width=4*style.GRID_CELL_SIZE))
>>          zoom_toolbar.show()
>>
>>  +        activities_tray = ActivitiesTray(self._shell)
>>
>> +        panel.append(hippo.CanvasWidget(widget=activities_tray),
>>  +                hippo.PACK_EXPAND)
>>  +        activities_tray.show()
>>
>>  If I don't set box_width and hippo.PACK_EXPAND, both the toolbar and
>>  the tray appear with their minimum sizes (the toolbar shows a drop
>>  down arrow and the tray shoes the two arrows). Why is hippo just
>>  respecting the minimum size for the widgets and not using all the
>>  available space?
> 
> Because of this and your note about pack_end below, I think it's
> probably easier to just get rid of hippo in the frame than debugging
> it, since that's on the plan anyway.
> 
>>  Thanks a lot for the review. I'm about to commit the home view work,
>>  can you give it a look as well?
> 
> I will.
> 
> Marco
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar