Re: [Sugar-devel] The quest for data
On 12.1.2014 10:12, Sameer Verma wrote: Has anyone created the wiki page as yet? Just created the wiki page: http://wiki.sugarlabs.org/go/Education_Team/Quest_for_Data Please help me expand it as you gather feedback from other deployments. Cheers, Martin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-13
Sounding like a broken record but can we have a tarball please :-) On Sun, Jan 12, 2014 at 3:57 PM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28875/physics-13.xo Release notes: 13 ENHANCEMENTS: * Added palettes to set density, bouciness, and friction (w/Sai Vineet) * Added palette to set motor speed, rotation (w/Sai Vineet) * Added chain tool (w/Sai Vineet) BUG FIX: * Updated Box2d version to eliminate some memory leaks (Sai Vineet) 12 ENHANCEMENTS: * Added option to joints to set collideConnected = False * Added clear_all (Sai Vineet) * Added tracking (Sai Vineet) * Added tracing (Sai Vineet) * Added erase traces (Sai Vineet) * Added save/restore of pens and traces (Sai Vineet) BUG FIXES: * Removed cjson dependency for elements * pep8 cleanup (Sai Vineet) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.1 (unstable)
On Thu, Jan 2, 2014 at 10:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, here is another unstable release. There are several bug fixes, many of them submitted by the Google Code In participants. The most invasive change is probably the long overdue port from GConf to GSettings. Awesome, is there some details about this somewhere in terms of changes for packagers? Do we support conversion of settings etc? Sources: http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.101.0.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.101.1.tar.xz http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.101.1.tar.xz Thanks to everyone that contributed! P.S. I have also released a new version of gwebsockets with very minor changes https://pypi.python.org/packages/source/g/gwebsockets/gwebsockets-0.4.tar.gz Updated the Fedora package, is this something I should be pushing back to other releases in Fedora? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Physics-13
Ooops. Sorry about that. Should be there now: http://download.sugarlabs.org/sources/honey/Physics/Physics-13.tar.bz2 -walter On Mon, Jan 13, 2014 at 6:26 AM, Peter Robinson pbrobin...@gmail.com wrote: Sounding like a broken record but can we have a tarball please :-) On Sun, Jan 12, 2014 at 3:57 PM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28875/physics-13.xo Release notes: 13 ENHANCEMENTS: * Added palettes to set density, bouciness, and friction (w/Sai Vineet) * Added palette to set motor speed, rotation (w/Sai Vineet) * Added chain tool (w/Sai Vineet) BUG FIX: * Updated Box2d version to eliminate some memory leaks (Sai Vineet) 12 ENHANCEMENTS: * Added option to joints to set collideConnected = False * Added clear_all (Sai Vineet) * Added tracking (Sai Vineet) * Added tracing (Sai Vineet) * Added erase traces (Sai Vineet) * Added save/restore of pens and traces (Sai Vineet) BUG FIXES: * Removed cjson dependency for elements * pep8 cleanup (Sai Vineet) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.1 (unstable)
On Mon, Jan 13, 2014 at 11:38 AM, Peter Robinson pbrobin...@gmail.com wrote: On Thu, Jan 2, 2014 at 10:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, here is another unstable release. There are several bug fixes, many of them submitted by the Google Code In participants. The most invasive change is probably the long overdue port from GConf to GSettings. Awesome, is there some details about this somewhere in terms of changes for packagers? Do we support conversion of settings etc? The configure script still looks for gconf Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Read-112
Activity Homepage: http://activities.sugarlabs.org/addon/4028 Sugar Platform: 0.96 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28876/read-112.xo Release notes: Remove show_launcher = no Updated translations Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
What should be used instead of icon_size? Gonzalo On Sat, Jan 11, 2014 at 12:43 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
And sorry to be slow with the search, but yes, we are using it in activities... a lot. Gonzalo On Mon, Jan 13, 2014 at 10:31 AM, Gonzalo Odiard godi...@sugarlabs.orgwrote: What should be used instead of icon_size? Gonzalo On Sat, Jan 11, 2014 at 12:43 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
pixel_size with style.STANDARD_ICON_SIZE (etc). On 13 January 2014 14:55, Daniel Narvaez dwnarv...@gmail.com wrote: For Icon pixel_size. On 13 January 2014 14:31, Gonzalo Odiard godi...@sugarlabs.org wrote: What should be used instead of icon_size? Gonzalo On Sat, Jan 11, 2014 at 12:43 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
Yeah, we searched Sunday and found that out :/ The proposal tries to be as backward compatible as possible because of that. On 13 January 2014 14:33, Gonzalo Odiard godi...@sugarlabs.org wrote: And sorry to be slow with the search, but yes, we are using it in activities... a lot. Gonzalo On Mon, Jan 13, 2014 at 10:31 AM, Gonzalo Odiard godi...@sugarlabs.orgwrote: What should be used instead of icon_size? Gonzalo On Sat, Jan 11, 2014 at 12:43 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.101.1 (unstable)
On 13 January 2014 12:38, Peter Robinson pbrobin...@gmail.com wrote: On Thu, Jan 2, 2014 at 10:41 PM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, here is another unstable release. There are several bug fixes, many of them submitted by the Google Code In participants. The most invasive change is probably the long overdue port from GConf to GSettings. Awesome, is there some details about this somewhere in terms of changes for packagers? Do we support conversion of settings etc? We support conversion but it shouldn't require anything on the packaging side. Packaging should be the same of other apps using gsettings, i.e. run glib-compile-schemas. What is probably unusual is that we will keep GConf around for a while, to not break activities. So the package will need to require and setup both gconf and gsettings. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] About show-launcher option
Recently, a change in sugar was made to not show a activity in the activities list, if the show_launcher == 'no' [1] As the activities list is the only way to uninstall a activity, or see the version installed, I would like to know what is the use case where this is needed. Probably, this option had sense in older versions of sugar, I don't know if is needed anymore. Regards, -- Gonzalo Odiard SugarLabs - Learning Software for children [1] https://github.com/sugarlabs/sugar/commit/f4638b5f481478e96195d55aa38c90fd33db9aee NOTE: The only activity I found using show_launcher = no was Read, and I modified it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
Sadly, have more sense set icon_size than pixel_size, right? (More in the context of multiple pixels resolutions, like we have with the xo and the desktop) I think is better fix Icon to get the parameter and set the pixel_size, and not do all the modifications Ignacio found. In fact, Icon is sugar toolkit code, and do other tricks, then we don't need deprecate the parameter. Gonzalo On Mon, Jan 13, 2014 at 10:56 AM, Daniel Narvaez dwnarv...@gmail.comwrote: pixel_size with style.STANDARD_ICON_SIZE (etc). On 13 January 2014 14:55, Daniel Narvaez dwnarv...@gmail.com wrote: For Icon pixel_size. On 13 January 2014 14:31, Gonzalo Odiard godi...@sugarlabs.org wrote: What should be used instead of icon_size? Gonzalo On Sat, Jan 11, 2014 at 12:43 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 13 January 2014 15:37, Gonzalo Odiard godi...@sugarlabs.org wrote: Sadly, have more sense set icon_size than pixel_size, right? (More in the context of multiple pixels resolutions, like we have with the xo and the desktop) Well, we should be using the new layout scaling stuff in gtk to deal with different resolutions. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ If on the top of that we need to set different pixel sizes for icons, it seems like a constant will probably enough. The IconSize stuff was designed to support runtime switching because it was user configurable, and it's now all being deprecated because they don't want the user configurability anymore. In any case gtk is moving away from it, so we will need our own constant or more complex thing. I think is better fix Icon to get the parameter and set the pixel_size, and not do all the modifications Ignacio found. Why? I think it's pretty clear that Gtk.IconSize will go away in gtk4. It seems a good idea to get rid of it at least in core (and suggest to do the same in activities). It will be less work when it goes away completely. In fact, Icon is sugar toolkit code, and do other tricks, then we don't need deprecate the parameter. But Gtk.IconSize is not sugar toolkit API. Use Gtk.IconSize with Icon but not with gtk.Image seems like a very very confusing thing to suggest to activity authors. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On Mon, Jan 13, 2014 at 11:56 AM, Daniel Narvaez dwnarv...@gmail.comwrote: On 13 January 2014 15:37, Gonzalo Odiard godi...@sugarlabs.org wrote: Sadly, have more sense set icon_size than pixel_size, right? (More in the context of multiple pixels resolutions, like we have with the xo and the desktop) Well, we should be using the new layout scaling stuff in gtk to deal with different resolutions. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ If on the top of that we need to set different pixel sizes for icons, it seems like a constant will probably enough. The IconSize stuff was designed to support runtime switching because it was user configurable, and it's now all being deprecated because they don't want the user configurability anymore. In any case gtk is moving away from it, so we will need our own constant or more complex thing. I think is better fix Icon to get the parameter and set the pixel_size, and not do all the modifications Ignacio found. Why? I think it's pretty clear that Gtk.IconSize will go away in gtk4. It seems a good idea to get rid of it at least in core (and suggest to do the same in activities). It will be less work when it goes away completely. Yes. I was talking about the parameter. I agree we will need our own size constants to replace Gtk.IconSize.* Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About show-launcher option
IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. On 13 January 2014 15:29, Gonzalo Odiard godi...@sugarlabs.org wrote: Recently, a change in sugar was made to not show a activity in the activities list, if the show_launcher == 'no' [1] As the activities list is the only way to uninstall a activity, or see the version installed, I would like to know what is the use case where this is needed. Probably, this option had sense in older versions of sugar, I don't know if is needed anymore. Regards, -- Gonzalo Odiard SugarLabs - Learning Software for children [1] https://github.com/sugarlabs/sugar/commit/f4638b5f481478e96195d55aa38c90fd33db9aee NOTE: The only activity I found using show_launcher = no was Read, and I modified it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About show-launcher option
Answering your question, this was used for activities that wouldn't make sense to be launched without a file. Think of Read without an object selector, for example. These days it seems like these activities should all provide a selector (with the usual UI). On 13 January 2014 15:29, Gonzalo Odiard godi...@sugarlabs.org wrote: Recently, a change in sugar was made to not show a activity in the activities list, if the show_launcher == 'no' [1] As the activities list is the only way to uninstall a activity, or see the version installed, I would like to know what is the use case where this is needed. Probably, this option had sense in older versions of sugar, I don't know if is needed anymore. Regards, -- Gonzalo Odiard SugarLabs - Learning Software for children [1] https://github.com/sugarlabs/sugar/commit/f4638b5f481478e96195d55aa38c90fd33db9aee NOTE: The only activity I found using show_launcher = no was Read, and I modified it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About show-launcher option
+1 to deprecate it. Gonzalo On Mon, Jan 13, 2014 at 12:09 PM, Daniel Narvaez dwnarv...@gmail.comwrote: Answering your question, this was used for activities that wouldn't make sense to be launched without a file. Think of Read without an object selector, for example. These days it seems like these activities should all provide a selector (with the usual UI). On 13 January 2014 15:29, Gonzalo Odiard godi...@sugarlabs.org wrote: Recently, a change in sugar was made to not show a activity in the activities list, if the show_launcher == 'no' [1] As the activities list is the only way to uninstall a activity, or see the version installed, I would like to know what is the use case where this is needed. Probably, this option had sense in older versions of sugar, I don't know if is needed anymore. Regards, -- Gonzalo Odiard SugarLabs - Learning Software for children [1] https://github.com/sugarlabs/sugar/commit/f4638b5f481478e96195d55aa38c90fd33db9aee NOTE: The only activity I found using show_launcher = no was Read, and I modified it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 13 January 2014 16:10, Gonzalo Odiard godi...@sugarlabs.org wrote: I think is better fix Icon to get the parameter and set the pixel_size, and not do all the modifications Ignacio found. Why? I think it's pretty clear that Gtk.IconSize will go away in gtk4. It seems a good idea to get rid of it at least in core (and suggest to do the same in activities). It will be less work when it goes away completely. Yes. I was talking about the parameter. I agree we will need our own size constants to replace Gtk.IconSize.* To make sure we are on the same page... I think the icon_size parameter should be supported (by converting internally to the appropriate pixel size) but deprecated. And thus patches that get rid of icon_size usage in core or activities are welcome. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
To make sure we are on the same page... I think the icon_size parameter should be supported (by converting internally to the appropriate pixel size) but deprecated. And thus patches that get rid of icon_size usage in core or activities are welcome. My point was about the naming of the parameter only, but I assume, we will be setting the size in pixels, and the constants defined in the toolkit will calculate the number of pixels needed according to screen resolution, then, do not have too much sense discuss about it. What we need is a way to publish these changes and what should be done, when is decided. (like with GCOnf to GSettings and other changes) -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
2014/1/11 Emil Dudev emildu...@gmail.com: 3) In my opinion, Web Collaboration without a server (XS Server or an Internet Server) has no sense. So I don't think we have to handle the complexity for a stand alone collaboration into web activities. Most of (if not all) of my work on the TogetherJS integration was done offline. The activities don't really need an Internet connection and I think that supporting web collaboration locally is needed. Yes! One of the best features of Sugar of all times is being able to collaborate through the mesh, without the need of a central server. 5) I'm thinking to integrate collaboration in my Sugarizer prototype [1]. If we could reproduce all presence features in our Sugar web collaboration API, I could fully reproduce network view, invitation/join in Sugarizer. So, when Sugar Web Activities will work in Sugarizer, users will have a full featured Sugar collaboration experience. It's why I think we should have a full control of collaboration implementation instead of depending of a tier API. Writing a low level API would not be hard. It's the high level stuff from TogetherJS that will be lost. Don't get this wrong, I'm not all for TogetherJS. It's just one of the many possibilities. I was given this library to work with and I liked for the things it gives. I took the simpler approach of using it, instead of rewriting it. I, too, don't like many of it's GUI stuff. But I think that they can be reworked. I agree. TogetherJS is great, and we should work with them to modularize their code in order to let us use our GUI. I think they will welcome our contributions. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 13 January 2014 16:19, Gonzalo Odiard godi...@sugarlabs.org wrote: To make sure we are on the same page... I think the icon_size parameter should be supported (by converting internally to the appropriate pixel size) but deprecated. And thus patches that get rid of icon_size usage in core or activities are welcome. My point was about the naming of the parameter only, but I assume, we will be setting the size in pixels, and the constants defined in the toolkit will calculate the number of pixels needed according to screen resolution, then, do not have too much sense discuss about it. If we was designing the API today I would just call the parameter size I think, but the documentation would say it is pixel. It's a bit of a complicated discussion because we have not agreed on a clear plan on resolution independence going forward. Though, as I see it, there are two things that will affect the physicall pixel size of an icon 1 The theme which is used. i.e. the value assigned to style.STANDARD_ICON_SIZE for example. 2 The ratio between the logical pixels and the physical pixels. For similar devices, say standard laptop screens, we don't even need 1. So I think it has to be possible to pass logical pixels to the API, not everything goes necessary through the theme. (I'm mostly bringing this up for the sake of starting a discussion about proper support for resolution independence) What we need is a way to publish these changes and what should be done, when is decided. (like with GCOnf to GSettings and other changes) Yes, maybe we need a page on sugar-docs where, for each major release, we list deprecated API's and suggest how to deal with it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
+1 On Mon, Jan 13, 2014 at 12:36 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 13 January 2014 16:19, Gonzalo Odiard godi...@sugarlabs.org wrote: To make sure we are on the same page... I think the icon_size parameter should be supported (by converting internally to the appropriate pixel size) but deprecated. And thus patches that get rid of icon_size usage in core or activities are welcome. My point was about the naming of the parameter only, but I assume, we will be setting the size in pixels, and the constants defined in the toolkit will calculate the number of pixels needed according to screen resolution, then, do not have too much sense discuss about it. If we was designing the API today I would just call the parameter size I think, but the documentation would say it is pixel. It's a bit of a complicated discussion because we have not agreed on a clear plan on resolution independence going forward. Though, as I see it, there are two things that will affect the physicall pixel size of an icon 1 The theme which is used. i.e. the value assigned to style.STANDARD_ICON_SIZE for example. 2 The ratio between the logical pixels and the physical pixels. For similar devices, say standard laptop screens, we don't even need 1. So I think it has to be possible to pass logical pixels to the API, not everything goes necessary through the theme. (I'm mostly bringing this up for the sake of starting a discussion about proper support for resolution independence) What we need is a way to publish these changes and what should be done, when is decided. (like with GCOnf to GSettings and other changes) Yes, maybe we need a page on sugar-docs where, for each major release, we list deprecated API's and suggest how to deal with it. -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
2014/1/12 Lionel Laské lio...@olpc-france.org: The only true peer-to-peer webRTC implementation we've found is from Chris Ball (an old OLPC guy !) [2] but it need to use a specific Firefox version and don't work on Chrome. [2] http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ There is valuable information in that post. His serverless-webrtc and the peer-to-peer project called P. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Deprecation policy - was: About show-launcher option
2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Inhibit suspend support on sugar toolkit
I am trying to upstream this patch https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/89 used in AU and in the dextrose images. Other than the code changes needed, would be good know if there are consensus about two topics: 1) Why is needed this patch? In the xo, while WOL (wake up on lan) is implemented, there are situations where traffic is lost while the xo is suspended [1] . That means sugar collaboration lost messages, and by example we don't see a user or a activity shared in the neighborhood or the collaboration in a activity is broken. This patch attempt to solve the problems in activities only, by inhibit the suspend while the activity is shared. This patch was proposed in the ticket [2] 2) Add a module for power management in the toolkit: In the patch review, dnarvaez suggested move the power management methods to a different module. I agree that have a lot of sense, even if now we have a single user, because: * make easier have a single implementation, if we later need make changes for other implementations. * we can add more uses in sugar, by example, inhibit suspend while the user is in the neighborhod view. * a few activities need inhibit suspend, like Clock, Distance or StopWatch. What other people think about this? I am happy to improve the patch according to feedback. -- Gonzalo Odiard SugarLabs - Learning Software for children [1] http://dev.laptop.org/ticket/10912 [2] http://dev.laptop.org/ticket/10363 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Inhibit suspend support on sugar toolkit
On Mon, Jan 13, 2014 at 12:29 PM, Gonzalo Odiard godi...@sugarlabs.org wrote: I am trying to upstream this patch https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/89 used in AU and in the dextrose images. Other than the code changes needed, would be good know if there are consensus about two topics: 1) Why is needed this patch? In the xo, while WOL (wake up on lan) is implemented, there are situations where traffic is lost while the xo is suspended [1] . That means sugar collaboration lost messages, and by example we don't see a user or a activity shared in the neighborhood or the collaboration in a activity is broken. This patch attempt to solve the problems in activities only, by inhibit the suspend while the activity is shared. This patch was proposed in the ticket [2] 2) Add a module for power management in the toolkit: In the patch review, dnarvaez suggested move the power management methods to a different module. I agree that have a lot of sense, even if now we have a single user, because: * make easier have a single implementation, if we later need make changes for other implementations. * we can add more uses in sugar, by example, inhibit suspend while the user is in the neighborhod view. * a few activities need inhibit suspend, like Clock, Distance or StopWatch. FWIW, Measure also uses inhibit suspend. What other people think about this? I am happy to improve the patch according to feedback. -- Gonzalo Odiard SugarLabs - Learning Software for children [1] http://dev.laptop.org/ticket/10912 [2] http://dev.laptop.org/ticket/10363 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New testing images for Australia (all xo models)
I have uploaded new images for testing to http://wiki.sugarlabs.org/go/0.100/Testing#Testing_images now, I managed to create images for all the xo models. This imaged, include almost all the changes in 0.100, and a few features in the work to be included in 0.102 [1] I didn't included the port from GConf to GSettings, because sadly, is too late in the AU development cycle to include it. I hope the new development rpms packaged by Daniel can be a better solution to testing of master branch. -- Gonzalo Odiard SugarLabs - Learning Software for children [1] http://wiki.sugarlabs.org/go/0.102/Feature_List ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
2014/1/11 Daniel Narvaez dwnarv...@gmail.com: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: I agree with the whole plan. - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. I'll fix sugar and sugar-toolkit-gtk3 basing on Ignacio work Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. I came up with this: https://github.com/manuq/sugar-toolkit-gtk3/pull/4/files Cleanup - Drop sizes from settings.ini - Deprecate Icon's icon_size property. - Suggest that activity authors never use Gtk.IconSize. I'm not sure this will fix everything, but should at least cover the large majority of the issues. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Inhibit suspend support on sugar toolkit
The patch should be libertas specific if it only impacts laptops with the libertas driver. If it also impacts laptops with the mwifiex driver, reference the ticket or update #10912? How prevalent is this patch in other deployments? What will be the power draw impact on deployments that adopt this next version of Sugar without being aware of the change? (e.g. how much time is spent in collaboration versus standalone activities across the laptop population?) Re: a module for power management. There is also code in the control panel for for power management. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Inhibit suspend support on sugar toolkit
On Mon, Jan 13, 2014 at 6:39 PM, James Cameron qu...@laptop.org wrote: The patch should be libertas specific if it only impacts laptops with the libertas driver. If it also impacts laptops with the mwifiex driver, reference the ticket or update #10912? Can you confirm if loosing packages is a problem only with libertas or affect also mwifiex? I am not sure neither how the drivers map to xo models. How prevalent is this patch in other deployments? What will be the power draw impact on deployments that adopt this next version of Sugar without being aware of the change? (e.g. how much time is spent in collaboration versus standalone activities across the laptop population?) I can't reply that questions with certain, but usually the proportion of use of collaboration is low. Re: a module for power management. There is also code in the control panel for for power management. Yes. -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Inhibit suspend support on sugar toolkit
On Mon, Jan 13, 2014 at 07:53:06PM -0200, Gonzalo Odiard wrote: Can you confirm if loosing packages is a problem only with libertas or affect also mwifiex? I am not sure neither how the drivers map to xo models. I don't know if packet loss over suspend is a problem with mwifiex. libertas is the driver for the Marvell 8686 wireless device, used in all XO-1.5, all XO-1.75, and some XO-4. This is a 2.4 GHz device. mwifiex is the driver for the Marvell 8787 wireless device, used in some XO-4. This is a 2.4 GHz, 5 GHz, and Bluetooth device. http://wiki.laptop.org/go/Firmware/Identifying_Wireless_LAN_Device describes how to identify the device using firmware. You can use other methods on Linux to identify the device. A deployment would generally be aware of the device requested in the manufacturing order. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
2014/1/13 Daniel Narvaez dwnarv...@gmail.com: On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. I agree. sugar-docs is the right place. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Yes, I think that's valid for old code too. If you can import a class, function or constant variable from the toolkit, its public. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. Agreed. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Maze Web-1
Also served at http://manuq.github.io/maze-web/ 2014/1/13 Sugar Labs Activities activit...@sugarlabs.org: Activity Homepage: http://activities.sugarlabs.org/addon/4727 Sugar Platform: 0.100 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28877/maze_web-1.xo Release notes: This is a remake of Maze activity using web technologies. It features small animations and sounds. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 13 January 2014 21:13, Manuel Quiñones ma...@laptop.org wrote: 2014/1/11 Daniel Narvaez dwnarv...@gmail.com: Ok, we looked more into this and it's an horrible, horrible mess. Several activities are using Gtk.IconSize, often just passing it to Gtk.Image. Here is the best possible plan I can think of: I agree with the whole plan. - Change sugar and sugar-toolkit-gtk3 to never use Gtk.IconSize explicitly. Just use pixels, the sizes stuff is half deprecated and of very little use. - Set the proper pixel_size on the toolbutton image. I'll fix sugar and sugar-toolkit-gtk3 basing on Ignacio work Hacks to help backward compatibility - Register sugar specific sizes (LARGE_TOOLBAR, MENU) with the deprecated Gtk.icon_size_register function. - Overwrite Gtk.IconSize.* with the sugar specific sizes. This will only work at python level, but should help a lot with activities that uses them. I came up with this: https://github.com/manuq/sugar-toolkit-gtk3/pull/4/files Thanks! I commented there. Not sure if it was intentional but this was a pull request to your own repo, not to upstream. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
what about something like this http://semver.org/? On Mon, Jan 13, 2014 at 8:32 PM, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
On 14 January 2014 00:44, Manuel Quiñones ma...@laptop.org wrote: We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Yes, I think that's valid for old code too. If you can import a class, function or constant variable from the toolkit, its public. Trying to make sure we are on the same page here, the devil is in details on this kind of stuff :) * I think stuff prefix with _ is private, even if you can import it. * I think it should be possible to mark stuff private by documentation. Maybe we should use a PRIVATE keyword so that it's more human and machine greppable. That's because sometimes you have modules that are only used internally, but you don't want to put _ everywhere. * I'm OK to consider existing code which doesn't follow the two rules above as public. It means that if we want to clean up we will probably have to deprecate some stuff, but it's fine if it keeps the policy simpler. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Maze Web-1
Activity Homepage: http://activities.sugarlabs.org/addon/4727 Sugar Platform: 0.100 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28877/maze_web-1.xo Release notes: This is a remake of Maze activity using web technologies. It features small animations and sounds. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
Gah, s/what is deprecated and what is not/what is dropped and what is not/ On 14 January 2014 01:15, Daniel Narvaez dwnarv...@gmail.com wrote: On top of Manuel proposal or in alternative? I mean, does bumping the major version imply that all the deprecated bits are dropped? Or do we just bump major whenever we make an API break but we decide case by case what is deprecated and what is not? On 14 January 2014 01:02, Code Raguet irag...@activitycentral.com wrote: what about something like this http://semver.org/? On Mon, Jan 13, 2014 at 8:32 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
On top of Manuel proposal or in alternative? I mean, does bumping the major version imply that all the deprecated bits are dropped? Or do we just bump major whenever we make an API break but we decide case by case what is deprecated and what is not? On 14 January 2014 01:02, Code Raguet irag...@activitycentral.com wrote: what about something like this http://semver.org/? On Mon, Jan 13, 2014 at 8:32 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
My thoughts about semantic versioning * I think we should be flexible on the deprecated API we drop. Bumping major doesn't necessarily mean we have to drop all deprecated API. * I'd really like to adopt it but I'm not sure how to apply it to our six months cycle. It seems to be thought for continuous development. (Can we please please switch to continuous development? :P). * I think we should adopt it for sugar-web. On 14 January 2014 01:15, Daniel Narvaez dwnarv...@gmail.com wrote: On top of Manuel proposal or in alternative? I mean, does bumping the major version imply that all the deprecated bits are dropped? Or do we just bump major whenever we make an API break but we decide case by case what is deprecated and what is not? On 14 January 2014 01:02, Code Raguet irag...@activitycentral.com wrote: what about something like this http://semver.org/? On Mon, Jan 13, 2014 at 8:32 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 13 January 2014 18:21, Manuel Quiñones ma...@laptop.org wrote: 2014/1/13 Daniel Narvaez dwnarv...@gmail.com: IMO it should be deprecated and then removed at some point. In general, I think our approach to API stability is way too ad hoc. We need some rules, even if very simple, to define what is public, how/when it is deprecated, and how/when it is removed. What about? - when an API change arises, we discuss a time range for activities to adapt the time range is measured in number of releases - we do the change in the code, leaving the old code - the deprecation is marked in the old code, adding a comment, logging a warning - the deprecation is announced in each release notes, asking activity developers to update their code mentioning for how many number of releases it will keep working I think we should have a section in sugar-docs where we note the deprecations (and the time range). So we add them as we go. - activity developers upload new versions to activities.sugarlabs.org, marking the corresponding Sugar version - after the aggreed time, the old code is removed This is more or less what we've been doing. I think when the toolbars API changed we gave about 1 year for adaptation. This sounds great to me. We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Also I think API is frozen on the day of the stable release, it's fine to make changes until then, otherwise it becomes really difficult to develop new API. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Daniel Narvaez -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
On 14 January 2014 01:33, Daniel Narvaez dwnarv...@gmail.com wrote: On 14 January 2014 01:06, Daniel Narvaez dwnarv...@gmail.com wrote: On 14 January 2014 00:44, Manuel Quiñones ma...@laptop.org wrote: We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Yes, I think that's valid for old code too. If you can import a class, function or constant variable from the toolkit, its public. Trying to make sure we are on the same page here, the devil is in details on this kind of stuff :) * I think stuff prefix with _ is private, even if you can import it. * I think it should be possible to mark stuff private by documentation. Maybe we should use a PRIVATE keyword so that it's more human and machine greppable. That's because sometimes you have modules that are only used internally, but you don't want to put _ everywhere. I suppose you could prefix the module with _, but I don't I've seen it done by other projects. This is the PEP8 suggestion http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces And I think it's also what python projects are usually doing. Problem is... we don't really write much documentation. I suppose we could enforce at least a single doc string explaining what the module does, for new code. But what about old code? If there is agreement to follow PEP8 on this, I guess I could volunteer to write a quick description doc string for existing modules (other volunteers to do that are very welcome though :P). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
On 14 January 2014 01:49, Daniel Narvaez dwnarv...@gmail.com wrote: On 14 January 2014 01:33, Daniel Narvaez dwnarv...@gmail.com wrote: On 14 January 2014 01:06, Daniel Narvaez dwnarv...@gmail.com wrote: On 14 January 2014 00:44, Manuel Quiñones ma...@laptop.org wrote: We just need a way to know what is public API and what is not. Maybe, for new code, everything is public unless it has the usual underscore or there are inline docs mentioning it's not public. For old code well... I guess we just decide case by case. Yes, I think that's valid for old code too. If you can import a class, function or constant variable from the toolkit, its public. Trying to make sure we are on the same page here, the devil is in details on this kind of stuff :) * I think stuff prefix with _ is private, even if you can import it. * I think it should be possible to mark stuff private by documentation. Maybe we should use a PRIVATE keyword so that it's more human and machine greppable. That's because sometimes you have modules that are only used internally, but you don't want to put _ everywhere. I suppose you could prefix the module with _, but I don't I've seen it done by other projects. This is the PEP8 suggestion http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces And I think it's also what python projects are usually doing. Problem is... we don't really write much documentation. I suppose we could enforce at least a single doc string explaining what the module does, for new code. But what about old code? If there is agreement to follow PEP8 on this, I guess I could volunteer to write a quick description doc string for existing modules (other volunteers to do that are very welcome though :P). Uff I read too quickly Even with __all__ set appropriately, internal interfaces (packages, modules, classes, functions, attributes or other names) should still be prefixed with a single leading underscore. So we could use underscored modules. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deprecation policy - was: About show-launcher option
So, to summarize what I'm proposing on top of what Manuel posted * All interfaces which are not prefixed with an underscore are public. * The authoritative source for deprecated interfaces and their timeframe is a page in sugar-docs. * sugar-web uses semantic versioning. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 13 January 2014 15:56, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 January 2014 15:37, Gonzalo Odiard godi...@sugarlabs.org wrote: Sadly, have more sense set icon_size than pixel_size, right? (More in the context of multiple pixels resolutions, like we have with the xo and the desktop) Well, we should be using the new layout scaling stuff in gtk to deal with different resolutions. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ Except that only scales by integers... Sigh, such a disappointment... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 14 January 2014 02:55, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 January 2014 15:56, Daniel Narvaez dwnarv...@gmail.com wrote: On 13 January 2014 15:37, Gonzalo Odiard godi...@sugarlabs.org wrote: Sadly, have more sense set icon_size than pixel_size, right? (More in the context of multiple pixels resolutions, like we have with the xo and the desktop) Well, we should be using the new layout scaling stuff in gtk to deal with different resolutions. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/ Except that only scales by integers... Sigh, such a disappointment... This is probably the solution (quoting from comments) Also, in a wayland compositor one could do the OSX style “render at 2x then downscale to x1.5 approach, but that will be hard in X (although it will be worth looking into). Pity it probably requires wayland, But we are going to have to port, at some point :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Inhibit suspend support on sugar toolkit
Thanks! On Mon, Jan 13, 2014 at 7:51 PM, James Cameron qu...@laptop.org wrote: On Mon, Jan 13, 2014 at 07:53:06PM -0200, Gonzalo Odiard wrote: Can you confirm if loosing packages is a problem only with libertas or affect also mwifiex? I am not sure neither how the drivers map to xo models. I don't know if packet loss over suspend is a problem with mwifiex. libertas is the driver for the Marvell 8686 wireless device, used in all XO-1.5, all XO-1.75, and some XO-4. This is a 2.4 GHz device. mwifiex is the driver for the Marvell 8787 wireless device, used in some XO-4. This is a 2.4 GHz, 5 GHz, and Bluetooth device. http://wiki.laptop.org/go/Firmware/Identifying_Wireless_LAN_Device describes how to identify the device using firmware. You can use other methods on Linux to identify the device. A deployment would generally be aware of the device requested in the manufacturing order. -- James Cameron http://quozl.linux.org.au/ -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Maze Web-1 (Manuel Qui?ones)
Hey great ! The animation at the end of the game (exploding dot !) is very cool. Will be include in the next version of Sugarizer ! Thanks for that Manuel. Lionel. 2014/1/14 sugar-devel-requ...@lists.sugarlabs.org Date: Mon, 13 Jan 2014 21:56:14 -0200 From: Manuel Qui?ones ma...@laptop.org To: Sugar-dev Devel sugar-devel@lists.sugarlabs.org Subject: Re: [Sugar-devel] [ASLO] Release Maze Web-1 Message-ID: CAPpV+OZ4jMq9DaP=46vkgP75ZXgwSLv+iqxzp=6= vqosofg...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Also served at http://manuq.github.io/maze-web/ 2014/1/13 Sugar Labs Activities activit...@sugarlabs.org: Activity Homepage: http://activities.sugarlabs.org/addon/4727 Sugar Platform: 0.100 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28877/maze_web-1.xo Release notes: This is a remake of Maze activity using web technologies. It features small animations and sounds. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
