Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
On Sun, Aug 07, 2011 at 10:40:28PM -0400, Chris Leonard wrote: All, There is a widely held belief that Pootle takes care of updating the POT files in git and updating the Templates on Poolte. This is not entirely accurate. The fact is that there is nothing in the Pootle code itself that does this automatically. This automagical updating used to occur, but it was handled by scripts that Sayamindu had created to make it occur. These scripts have not been functioning for some time, probably since the last Pootle upgrade. We will look at re-establishing this functionality in conjunction with an upcoming upgrade of the Pootle version, but for now, if a developer makes UI string changes it is necessary for them to regenerate the POT file and commit it to git and then notify the Translation Team (me) to pull the changes up to Pootle with a Template Upgrade from VCS where they can then be distributed to languages with an Update from templates. That might be too messy.. ie, if pootle was handling this sort of things in auto mode, then, for sometime, all activity devs need to take care on theirs own, then pootle will back to processing in auto mode.. It sounds more problematically especially for honey (fructose is more centralized but even there we might have problems with in-time .pot updates). What about handling these .pot updates out-of-pootle and do not bother activity devs? If you give me a list of repos (I guess some kind of pootle config), I can setup regular .pot updates for git repos. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
On Mon, Aug 8, 2011 at 5:52 AM, Aleksey Lim alsr...@activitycentral.org wrote: On Sun, Aug 07, 2011 at 10:40:28PM -0400, Chris Leonard wrote: All, There is a widely held belief that Pootle takes care of updating the POT files in git and updating the Templates on Poolte. This is not entirely accurate. The fact is that there is nothing in the Pootle code itself that does this automatically. This automagical updating used to occur, but it was handled by scripts that Sayamindu had created to make it occur. These scripts have not been functioning for some time, probably since the last Pootle upgrade. We will look at re-establishing this functionality in conjunction with an upcoming upgrade of the Pootle version, but for now, if a developer makes UI string changes it is necessary for them to regenerate the POT file and commit it to git and then notify the Translation Team (me) to pull the changes up to Pootle with a Template Upgrade from VCS where they can then be distributed to languages with an Update from templates. That might be too messy.. ie, if pootle was handling this sort of things in auto mode, then, for sometime, all activity devs need to take care on theirs own, then pootle will back to processing in auto mode.. It sounds more problematically especially for honey (fructose is more centralized but even there we might have problems with in-time .pot updates). What about handling these .pot updates out-of-pootle and do not bother activity devs? If you give me a list of repos (I guess some kind of pootle config), I can setup regular .pot updates for git repos. -- Aleksey Aleksey, Yes, the manual process is messy, which is why we intend to re-establish the automagical updates. This request for a round of updates from maintainers is intended to catch us up with UI changes madce since the POT update process stopped work so tha localizers have a solid baseline to work from *n the limited time until the 0.94 release. It is an interim measure, not a proposal for a permanently changed workflow. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
I have updated: Honey (needs refresh) finance-activity fototoon get_books typingturtle Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] NetworkManager 0.9 (was: Re: Sugar 0.94 - Schedule proposal)
Excerpts from Daniel Drake's message of Sat Aug 06 13:08:48 +0200 2011: The move represents a shift in design. Previously, Sugar had to implement a dbus service which managed network connections. Now NetworkManager does that for us. NetworkManager 0.8 and below already supported system connections, so it's not so much a shift as getting rid of one of two options. It might be a good intermediate step to switch to NM 0.8 + system connections (the original plan of SL#1884 [1]). Ubuntu currently ships v0.8, but their next release (Oneric, to be released in October, and which Sugar-0.94 schedule is indirectly based around) will have 0.9. I wouldn't take Ubuntu as a reference here because the last few Ubuntu releases didn't support Sugar too well. I've even stopped supporting Ubuntu in sugar-jhbuild (though I've heard Alekseys sweets supports Ubuntu, even including Browse). Debian Wheezy still has NM 0.8 (some 0.9 pre-release is available in experimental). There's a good chance it will have NM 0.9 before it freezes, though. With my Dextrose hat on, I'd like to see us move to NM 0.9 for the next release. With my Sugar hat on, I'm worried about large changes introducing a lot of regressions, like with Telepathy. While moving to system connections is large enough to be of concern itself, the additional changes required for NM 0.9 increase the risk (though I'm not sure by how much). Sascha [1] https://bugs.sugarlabs.org/ticket/1884 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NetworkManager 0.9 (was: Re: Sugar 0.94 - Schedule proposal)
On Mon, Aug 8, 2011 at 2:58 PM, Sascha Silbe si...@activitycentral.com wrote: NetworkManager 0.8 and below already supported system connections, so it's not so much a shift as getting rid of one of two options. It might be a good intermediate step to switch to NM 0.8 + system connections (the original plan of SL#1884 [1]). True, but Sugar never manipulated the system connections or displayed them (except for ethernet). You are right in saying that the changes aren't too invasive though. With my Dextrose hat on, I'd like to see us move to NM 0.9 for the next release. With my Sugar hat on, I'm worried about large changes introducing a lot of regressions, like with Telepathy. While moving to system connections is large enough to be of concern itself, the additional changes required for NM 0.9 increase the risk (though I'm not sure by how much). What do you mean by next release? Sugar 0.96? Also, which additional changes are you referring to? I made quite a lot of progress over the weekend in getting NM-0.9 supported. Like in 0.8 we do not take advantage of much of what NM can do, and we have some issues that get carried over from before, but in simply maintaining the existing functionality it seems quite low risk so far. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New Sugar Commander for review, creates Journal entry
Tony, Feel free to clone Sugar Commander and try to create this! I won't say it isn't a good idea, but I have no inclination to do something like that myself. James Simmons On Sun, Aug 7, 2011 at 8:26 PM, fors...@ozonline.com.au wrote: PS It would be fun if you could export the Journal as a text file. The Journal entry IS a text file. Sorry I should have explained myself better Not the journal entry, the journal itself, the whole journal then you could do an analysis of what you did when accross all Activities Tony ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NetworkManager 0.9 (was: Re: Sugar 0.94 - Schedule proposal)
On Mon, Aug 8, 2011 at 3:04 PM, Daniel Drake d...@laptop.org wrote: On Mon, Aug 8, 2011 at 2:58 PM, Sascha Silbe si...@activitycentral.com wrote: NetworkManager 0.8 and below already supported system connections, so it's not so much a shift as getting rid of one of two options. It might be a good intermediate step to switch to NM 0.8 + system connections (the original plan of SL#1884 [1]). True, but Sugar never manipulated the system connections or displayed them (except for ethernet). You are right in saying that the changes aren't too invasive though. With my Dextrose hat on, I'd like to see us move to NM 0.9 for the next release. With my Sugar hat on, I'm worried about large changes introducing a lot of regressions, like with Telepathy. While moving to system connections is large enough to be of concern itself, the additional changes required for NM 0.9 increase the risk (though I'm not sure by how much). What do you mean by next release? Sugar 0.96? Also, which additional changes are you referring to? I made quite a lot of progress over the weekend in getting NM-0.9 supported. Like in 0.8 we do not take advantage of much of what NM can do, and we have some issues that get carried over from before, but in simply maintaining the existing functionality it seems quite low risk so far. do you have a nm09 git branch somewhere? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Attn maintainers Re:Pootle and POT files
On Sun, Aug 7, 2011 at 10:40 PM, Chris Leonard cjlhomeaddr...@gmail.com wrote: All, There is a widely held belief that Pootle takes care of updating the POT files in git and updating the Templates on Poolte. This is not entirely accurate. The fact is that there is nothing in the Pootle code itself that does this automatically. This automagical updating used to occur, but it was handled by scripts that Sayamindu had created to make it occur. These scripts have not been functioning for some time, probably since the last Pootle upgrade. We will look at re-establishing this functionality in conjunction with an upcoming upgrade of the Pootle version, but for now, if a developer makes UI string changes it is necessary for them to regenerate the POT file and commit it to git and then notify the Translation Team (me) to pull the changes up to Pootle with a Template Upgrade from VCS where they can then be distributed to languages with an Update from templates. In order to catch up and establish a solid baseline for the upcoming 0.94 Sugar release, we have been asking activity maintainers to refresh and recommit their POT files. The follow list describes those completed and those that still need a refresh. If you are a maintainer of an activity on the needs refresh list, please regenerate the POT and commit it to git. Aleksey is going to work on putting hooks into git to regernerate the POT when UI changes have been made, so this request for maintainers to stay on top of POT recommits may be obsolete soon, cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NetworkManager 0.9
Excerpts from Daniel Drake's message of Mon Aug 08 16:04:08 +0200 2011: [...] I made quite a lot of progress over the weekend in getting NM-0.9 supported. For reference: Daniel and I continued the discussion on #sugar. His plan is to do only the minimal changes required for NM 0.9 support. Since there's not much to change beyond moving to system settings [1], NM 0.8 + system settings isn't providing a significant benefit. Sascha [1] http://projects.gnome.org/NetworkManager/developers/migrating-to-09/ref-migrating.html -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] NetworkManager 0.9 (was: Re: Sugar 0.94 - Schedule proposal)
DSD: Let me know when it's in an 11.3 (or later) build, and I'd be more than happy to test the avahi 169.x.x.x assignment to ethernet, and the USB modem dialling functions. Those were sometimes a little iffy for persistence in Sugar, and when swapping from Gnome to Sugar and back. Cheers, KG On Mon, Aug 8, 2011 at 10:58 AM, Peter Robinson pbrobin...@gmail.comwrote: On Mon, Aug 8, 2011 at 3:04 PM, Daniel Drake d...@laptop.org wrote: On Mon, Aug 8, 2011 at 2:58 PM, Sascha Silbe si...@activitycentral.com wrote: NetworkManager 0.8 and below already supported system connections, so it's not so much a shift as getting rid of one of two options. It might be a good intermediate step to switch to NM 0.8 + system connections (the original plan of SL#1884 [1]). True, but Sugar never manipulated the system connections or displayed them (except for ethernet). You are right in saying that the changes aren't too invasive though. With my Dextrose hat on, I'd like to see us move to NM 0.9 for the next release. With my Sugar hat on, I'm worried about large changes introducing a lot of regressions, like with Telepathy. While moving to system connections is large enough to be of concern itself, the additional changes required for NM 0.9 increase the risk (though I'm not sure by how much). What do you mean by next release? Sugar 0.96? Also, which additional changes are you referring to? I made quite a lot of progress over the weekend in getting NM-0.9 supported. Like in 0.8 we do not take advantage of much of what NM can do, and we have some issues that get carried over from before, but in simply maintaining the existing functionality it seems quite low risk so far. do you have a nm09 git branch somewhere? Peter ___ 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
[Sugar-devel] [ANNOUNCE] New doc.sugarlabs.org domain
Hi all, We had api.sugarlabs.org for (looks like) glucose API documentation, but it is really useful to host any sugar related autogenerated documentation as well. So, there is doc.sugarlabs.org accessible (the old api.sl.o is being redirected to doc.sl.o). Please, update your links. If there is a need to host sugar related documentation, create a ticked on bugs.sugarlabs.org for doc.sugarlabs.org component. All SL resources that have a bar with SL links are in the process of updating. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] New doc.sugarlabs.org domain
On Mon, August 8, 2011 1:33 pm, Aleksey Lim wrote: Hi all, We had api.sugarlabs.org for (looks like) glucose API documentation, but it is really useful to host any sugar related autogenerated documentation as well. Is anybody generating Python docs for Sugar activities? Note that manuals written about Sugar are at http://booki.flossmanuals.net/ , while e-learning materials using Sugar will be at our test server http://booki.treehouse.su/ until we move it to a sugarlabs.org subdomain. So, there is doc.sugarlabs.org accessible (the old api.sl.o is being redirected to doc.sl.o). Please, update your links. If there is a need to host sugar related documentation, create a ticked on bugs.sugarlabs.org for doc.sugarlabs.org component. All SL resources that have a bar with SL links are in the process of updating. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Edward Mokurai (#40664;#38647;/#2343;#2352;#2381;#2350;#2350;#2375;#2328;#2358;#2348;#2381;#2342;#2327;#2352;#2381;#2332;/#1583;#1726;#1585;#1605;#1605;#1740;#1711;#1726;#1588;#1576;#1583;#1711;#1585; #1580;) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://wiki.sugarlabs.org/go/Replacing_Textbooks ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Add duplicate functionality to the Journal and enhance copy functionality
Excerpts from Simon Schampijer's message of Fri Jul 29 18:35:41 +0200 2011:
This patch adds a duplicate option to the Journal entry palette and
the entry detail view.
You're doing two changes in functionally independent parts of the code
and the changes are not interdependent. It would make sense to split
them into separate patches.
This will replace the keep button from the activity toolbar.
This functionality? Or perhaps is intended to replace? After all
this patch doesn't actually remove the Keep button.
[src/jarabe/journal/journaltoolbox.py]
@@ -370,19 +372,24 @@ class EntryToolbar(gtk.Toolbar):
self.add(self._resume)
self._resume.show()
-self._copy = ToolButton()
-
client = gconf.client_get_default()
color = XoColor(client.get_string('/desktop/sugar/user/color'))
+self._copy = ToolButton()
icon = Icon(icon_name='edit-copy', xo_color=color)
self._copy.set_icon_widget(icon)
icon.show()
[...]
Is there a reason we use set_icon_widget() instead of passing the
keyword argument 'icon' to ToolButton()? (Mentioning this because you
add a copy of the above code for the Duplicate button)
@@ -395,6 +402,16 @@ class EntryToolbar(gtk.Toolbar):
def set_metadata(self, metadata):
self._metadata = metadata
+color = misc.get_icon_color(self._metadata)
+self._copy.get_icon_widget().props.xo_color = color
+if self._metadata['mountpoint'] == '/':
+self._duplicate.connect('clicked', self._duplicate_clicked_cb)
+self._duplicate.show()
+icon = self._duplicate.get_icon_widget()
+icon.props.xo_color = color
+icon.show()
+else:
+self._duplicate.hide()
self._refresh_copy_palette()
self._refresh_resume_palette()
Factoring out the new code into a method _refresh_duplicate_palette()
would fit the existing code better.
[...]
+file_path = model.get_file(self._metadata['uid'])
+try:
+model.copy(self._metadata, '/')
+except IOError, e:
+logging.exception('Error while copying the entry. %s',
e.strerror)
If we log the entire exception, we don't need to include the error
message in the format string.
+self.emit('volume-error',
+ _('Error while copying the entry. %s') % e.strerror,
+ _('Error'))
For consistency and robustness, please always use tuples with the
formatting operator, even if it's just a single parameter (= singleton
tuple).
[src/jarabe/journal/palettes.py]
[CopyMenu.__init__()]
[...]
+volume_monitor = gio.volume_monitor_get()
+icon_theme = gtk.icon_theme_get_default()
+for mount in volume_monitor.get_mounts():
[...]
I still don't like the code duplication, but hopefully we'll clean that
up later.
Sascha
--
http://sascha.silbe.org/
http://www.infra-silbe.de/
signature.asc
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Excerpts from Daniel Drake's message of Fri Aug 05 15:04:49 +0200 2011: No comments yet. The plan looks good in general, thanks for taking the time to draft and elaborate! It might be worth pointing out that the list in Proposed plan of action contains quite a few actions that can happen in parallel, not just in the particular order given. As mentioned in #sugar, I'd love to see a GTK 2 based version of Sugar without hippo-canvas (this seems to match your plan). Without hippo-canvas, we can finally do automated UI tests. I already have a few other missing pieces in my drawer, but they weren't too useful with the Home View still based on hippo-canvas. The value of the automated tests is that they can reduce the risk of the Gnome 3 port introducing regressions. I'd expect them to be quite limited at first (no simulation of external storage devices, no multiple instances collaborating, etc.) but still good as a band-aid. 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? I don't think that would be useful. AFAICT there need to be major textual changes anyway. 2. Are people happy with labelling components with version number 1.0 once they have a stable GTK3 port? The 1.0 tag was generally agreed upon when this was last discussed a while back, but it would be good to verify current opinion. If we make it clear that it's 1.0 of the technology preview / proof of concept and not of what Sugar wants to be (a learning platform with Collaboration and reflection etc.), that's fine with me. 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? I'd like us to work on other issue first. Topics that come to my mind include design changes for touch screen support and extending the Journal (e.g. finally adding the Action View). Of course that doesn't mean a Gnome 3 porting hack session wouldn't be welcome, just that it is less of a priority for me (because there's already one happening right now in Berlin). 4. Is a one year transition period OK? This would start when a GTK3 port of sugar-toolkit is declared stable and working, would freeze the GTK2 version of sugar-toolkit, and then after 1 year the GTK2 version would be deleted. Only time can tell. It will depend a lot on the details. However given the usual schedules (with a unit of school years) at deployments, I would expect that we need to keep the GTK 2 version of sugar-toolkit around for more than one year. But since you plan for it to be unmaintained, I wonder what would actually happen after that time. I don't think we should be removing git repositories or old release tarballs. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Excerpts from Samuel Greenfeld's message of Sun Aug 07 02:41:36 +0200 2011: The change I would like to see in the API (if we do not have it already) is to ensure that we have full ATK accessibility support for all Sugar controls. Not only would this allow screen readers, etc. to parse Sugar applications and the main window system, but it would make automated testing of Sugar easier as well. The only change we need to do for accessibility support that might touch APIs is removing hippo-canvas (there are a few places in sugar-toolkit that use it). We're building more or less directly on GTK, so I'd expect accessibility to just work in most cases or at least be fixable without API changes. I've been told in the past that automating Sugar was not possible apart from a point click approach because hippocanvas and similar did not expose any accessibility information. Since this may require developers to setup additional information inside of activities (alternate names/descriptions, focus tab order, etc.) it is better to get this in as early as possible so activities do not have to be retrofitted to support ATK after the fact. Activities can already be augmented with the necessary information today. Those parts that use hippo-canvas can't be augmented, but will need to be replaced soon anyway. We had a GSoC project for an automated activity testing framework [1] a while back. Unfortunately the student got confused by FUD about OLPC and lost interest [2]. Nobody else stepped up to work on this project. It uses a different technique than the accessibility based testing tools, so not sure whether it would continue to work in GTK 3 land. Sascha [1] http://gsoc-sugarbot.blogspot.com/ [2] http://lists.sugarlabs.org/archive/sugar-devel/2009-March/012687.html -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar-news] [IAEP] Sugar Digest 2011-08-07
On Sun, Aug 7, 2011 at 10:04 PM, Walter Bender walter.ben...@gmail.comwrote: == Sugar Digest == 2. Following up on a thread begun in mid July [http://lists.sugarlabs.org/archive/iaep/2011-July/013736.html] the Sugar oversight board passed a motion to empower Sugar Labs to award certificates to developers to acknowledge and celebrate their contributions to the Sugar Learning Platform. Several certificates will be made available, based upon the area of contribution. The certification mechanism is decentralized: the specific criteria for certification will be determined by the Sugar Labs team coordinators; in general, it will involve a repeated effort on behalf of the team's goals at a high level of quality. As an example, the Activity team may issue a Sugar Activity Developer certificate to an individual who develops at least one Sugar activity that is subsequently posted on the Sugar activity portal and be of sufficient quality to be approved for public release. The activity must also include internationalization, including the submission of a POT file to the Translation Team, and documentation, including the creation of a page in the wiki under the Activity category. As will the Contributor certificates, sign off will be made by the associated team coordinators, in this case the Activity team. Excellent news! :-) In this context it might also be worth keeping an eye on the Mozilla Open Badge Infrastructure (OBI) project which released its alpha version last week (http://erinknight.com/post/8650391369/obi-alpha). At least from the description on the site it sounds like a useful infrastructure effort which Sugar Labs might be able to build on somewhere down the road. Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Mon, Aug 8, 2011 at 9:15 PM, Sascha Silbe si...@activitycentral.com wrote: The plan looks good in general, thanks for taking the time to draft and elaborate! Thanks for reviewing. It might be worth pointing out that the list in Proposed plan of action contains quite a few actions that can happen in parallel, not just in the particular order given. It already says that, but I'll make it a bit clearer. As mentioned in #sugar, I'd love to see a GTK 2 based version of Sugar without hippo-canvas (this seems to match your plan). Without hippo-canvas, we can finally do automated UI tests. I already have a few other missing pieces in my drawer, but they weren't too useful with the Home View still based on hippo-canvas. It doesn't quite match my plan, as I'm proposing full speed ahead on porting sugar-toolkit which does not require Sugar itself to be GTK3-ported or de-hippoized. The hippo stuff accross the board could feasibly come earlier, and much of the work has already been done, but we need people to step up and polish it and post it for review. I wouldn't want to hold back the migration of sugar-toolkit based on this. Another consideration: I learned from Raul and Walter is that removing hippo from sugar-toolkit is not as simple as just changing some internals. Some public classes in the sugar API are subclasses of hippo, and these are used by activities (which pass in other subclasses of hippo stuff). So, removing hippo will break activities such as Chat. Just something to keep in mind as another API break, and potentially quite an invasive one. 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? I don't think that would be useful. AFAICT there need to be major textual changes anyway. Yes, there do. If we make it clear that it's 1.0 of the technology preview / proof of concept and not of what Sugar wants to be (a learning platform with Collaboration and reflection etc.), that's fine with me. Some people don't like the sound of this, and indeed, it would be less controversial just to stick with the existing numbering scheme. If we don't call this 1.0, do you have any other suggestions for the naming of sugar1, or does it change your opinion on the sugar vs sugar1 choice? 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? I'd like us to work on other issue first. Topics that come to my mind include design changes for touch screen support and extending the Journal (e.g. finally adding the Action View). Of course that doesn't mean a Gnome 3 porting hack session wouldn't be welcome, just that it is less of a priority for me (because there's already one happening right now in Berlin). Agreed. I'm mindful of this, and I've asked Bastien for his opinion, particularly about running GTK3 after the programmed schedule. However, we have some people who are key to these efforts (e.g. Raul and Benjamin Berg) who could only attend for the weekend, so I hope some balance can be found. If we go ahead with these ideas, I'll do what I can to keep the weekend GTK3 sessions small and not drawing anything from the other sessions. Only time can tell. It will depend a lot on the details. However given the usual schedules (with a unit of school years) at deployments, I would expect that we need to keep the GTK 2 version of sugar-toolkit around for more than one year. But since you plan for it to be unmaintained, I wonder what would actually happen after that time. I don't think we should be removing git repositories or old release tarballs. I'll clarify that to say what I really meant - the removal of the frozen GTK2 sugar-toolkit from the development tree (i.e. sugar-toolkit master) after 1 year. Of course, old versions will still be available (and not deleted!) and will probably stay in widespread field use for some time to come, just like Sugar-0.82 is today. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
