Hi, After revisiting some of the changes I have made to the software while working on deployments I just wanted to post the list again as a refresher.
I have not had enough time to do the appropriate master-level QA on these, or to get them running on the latest Sugar versions. I hope that some people will consider taking on these tasks. Some of the items here are far from trivial and will require design and thought to fix properly. Some of the items below are not purely sugar tasks. But at the same time they are really big items for sugar deployments. (Just to throw in some opinion here too, I feel that all deployments would benefit from more time being spent working on deployment technologies and realities at the system level -- Sugar 0.82 reached a point where the biggest problems you find in the field are far outside of the UI/activities level, now we have to attack the others) Customizing browse homepage The procedure to do this is too complicated for most deployments, and is undocumented. Customizing which activities are in the favourites view by default You can do this just by editing a file, but that file is a part of the sugar distribution so it will be lost on upgrades. There is also no documentation for how to do this, as far as I can see. Automatic activity upgrading Activity updating is too difficult for young children to understand and is very hard to coordinate across a classroom. This one I have never had time to hack a fix into place. Also the "You should upgrade your activities" notice needs to die. Unregistering from an XSes / registering with multiple XSes A hack available here: http://dev.sugarlabs.org/ticket/362 Still no user-friendly or documented way of doing this. Full journal restore, and backup control http://dev.laptop.org/ticket/9250 We still don't have a good way of browsing backups or restoring multiple files (e.g. the whole journal) in 1 go. Another constant headache is with translations. How do you roll out new translations for old software? The best we have right now is language packs but they install files which conflict with both system packages and activity bundles. And they are difficult for deployments because you need Linux skills to execute them. Registration is a real headache in classrooms right now. It's just a bit of an alien concept for new computer users. And it's so difficult. If you try to register before connecting then a bug somewhere means that you can't even complete a successful registration after connecting -- you have to restart sugar. And then after you do register you have to restart sugar for it to take effect. http://dev.sugarlabs.org/ticket/1151 But why do we force users through the pains of registering at all? We control all the technical bits, lets automate it to hunt down the specific school server and register. http://dev.sugarlabs.org/ticket/1152 And once we're that far, why do users have to select which network to connect to? This is also a significant classroom challenge. But typically in deployments, networks are installed at the same time that the sugar systems are made available. It's all controlled by the same party. So we could have a way that deployers could make sugar automatically connect to specific networks, or something like that. During activity update, only download the parts that have changed http://dev.sugarlabs.org/ticket/1499 And speaking now from a "Sugar implementor" standpoint, here are 2 fully specced features which have yet too see much attention: http://wiki.sugarlabs.org/go/Features/Font_configuration http://wiki.sugarlabs.org/go/Features/Content_support Any takers? :) Daniel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel