Re: [Sugar-devel] modified Home View
On Sun, Aug 8, 2010 at 4:51 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.com wrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already used for identity. It's bad enough that the GC activities, and a few others, break the colour metaphor by not bothering with the fill_color and stroke_color variables — adding even more colour metaphors would not help! ;) --Gary -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___ Sugar-devel mailing list
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On Sun, Aug 8, 2010 at 02:20, Marco Pesenti Gritti ma...@marcopg.org wrote: On 6 Aug 2010, at 13:35, Tomeu Vizoso to...@sugarlabs.org wrote: I was just throwing in the idea here. I will bother you further only once I have a realistic plan in mind (and confidence in the ability to execute it with our limited resources) :) Sorry if I sounded harsh, I wanted to explain why some reforms are not going forward yet even if people agree are necessary. Oh, no worries, I don't think you sounded harsh at all. That's actually the other thing I'm planning to look into. Maybe I'm mistake but I feel we are stuck with a review process most of the existing contributors are unhappy with. I can work on a formal proposal and try to reach consensus, if that's what is missing... Sounds great, though I have felt that there was a bit of misdirected frustration during that conversation. As in the real problem not being the process but the slow response due to the lack of maintainers? The real problem being that contributing to FOSS can be very frustrating if you are not an expert already and there isn't a big effort in place to support new contributors. Maintainers are in a very good position to help new contributors but that doesn't mean that nobody else can do something about it. See for example the recent trend on sending patches to the mailing list for reviews and comments, then submitting for acceptance. It should have improved a lot the experience for new contributors and we didn't had to wait for any maintainer to do anything. Similarly, if creating trac tickets is so hard for a significant segment of our contributors, then we can create simplified forms or establish some sort of aggregator that submits those reports aftert some consolidation, translation and triaging, as is being discussed in another thread. If putting patches in a queue is too much of a hassle, we could have the figure of the Patch Manager, or write a tool similar to git-bz. http://producingoss.com/en/producingoss.html#patch-manager http://git.fishsoup.net/man/git-bz.html (it's python and git, we just need to replace bugzilla with trac) If having the queue in trac is too obscure because making a query is hard, we could make the automated report you wrote to point to bugs.sugarlabs.org and this mailing list. http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/report.py#line12 But there are apparently no resources to do any of this, so we turn to discuss about the process in the hope that we find one that allows us to do more without having to work more. If distros drop a platform dependency in the same release where the replacement lands (what happens with gnome-python2-desktop in Fedora 14), it means that everybody needs to build that dependency until they update to that release. Moreover, if some distros only include the new dependency at a later release (as with Ubuntu Maverick and Gtk3), contributors running one of those distros need to build more stuff for longer. My feeling is that these are a bit of special situations due to the dynamic bindings migration and gtk 3, I don't see they happening normally. Also it seems like they will hurt in the same way when we actually get to package Sugar on these distributions. Agreed, but if we keep Sugar aligned with the GNOME platform, then we need to worry mostly about these transition phases. We can reduce the harm by keeping PPA-like repos for the distros that need it (what the telepathy guys do for Ubuntu), but then someone needs to do that work. I wouldn't spend resources on this, it's error prone and time consuming. In summary, I'm able to see the importance of making as easy as possible running latest sugar on all distros, but I'm afraid it's one more goal we want to attain but don't know how to resource. To be clear, my goal is not to support all distro. I think it would be reasonable to say that you need the latest Fedora/Debian/Ubuntu to be able to build Sugar without messing with dependencies. I think there is a bit of a chicken and egg problem here. Making it easy to start developing Sugar is probably one of the best ways to increase the resources we can spend on user visible improvements. I'm afraid for the next 2-3 release cycles Fedora is going to force us to make some changes in our dependencies that will make that more difficult on Debian and Ubuntu. Regards, Tomeu Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH] Remove nbsp chars from the html string before parsing)
On Mon, Aug 9, 2010 at 07:19, James Cameron qu...@laptop.org wrote: On Fri, Aug 06, 2010 at 09:05:24AM +0200, Tomeu Vizoso wrote: On Fri, Aug 6, 2010 at 01:47, Marco Pesenti Gritti ma...@marcopg.org wrote: On 6 Aug 2010, at 00:20, James Cameron qu...@laptop.org wrote: On Thu, Aug 05, 2010 at 09:06:03AM +0200, Tomeu Vizoso wrote: Another option is having some script that adds committers to all sugar core modules in one go, that would be similar to what GNOME does. There are too many core modules, in my opinion (and Michael Stone's). ?I see no good reason why there isn't just one git repository for the whole of Sugar. Yeah, I think we need to look into merging core in a single repository. At the end it's basically the same problem we find again and again: we spend days-person discussing some big changes, eventually may reach an agreement (or not), then nobody finds time to actually do the work. Michael Stone did it. I tested it on an XO. It worked. Our software doesn't get into hands of children in that way. It requires the work of individuals such as Jonas, Peter, Aleksey and many others and any discussion on such a change should have included their point of view. It happened with the code review process and I see very well it happening here because it would require coordination with packagers, updating lots of wiki pages, etc. Well, apart from the actual code and git repository changes, there's nothing obvious that needs fixing. It's the code that counts. I don't go looking for trouble in Wiki pages or packagers. Wiki pages that document code should be in the code repository, not in the Wiki. Packagers can be told what the changes are and they will adjust wonderfully. Are you suggesting to just leave the wiki pointing to obsolete repos because you personally don't care about any documentation that is in the wiki? Guess not, but then I don't understand what you are proposing. You seem to think something else is required to complete this task, but I knew nothing of those things. Perhaps that is why things are not completed? Such a change requires that somebody presents a serious plan. As things are now, as a maintainer I would need to do quite a bit of work to make sure that the change can be made without serious negative consequences. I appreciate that it's very important to make it easier to install our development environment, but if you expect me to do that work now, you are asking from me more than what I can give. Regards, Tomeu -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Journal Migration
I found and fixed a bug in the dextrose journal migration. http://bugs.sugarlabs.org/ticket/2149 Could someone who knows what the are doing please look it over. In particular, I'm concerned that the migration steps between version 1 and version 5 are missing. I'm about to migrate the Samoan deployment from 767 to os300py. Thanks Tom ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 11:25, Bert Freudenberg b...@freudenbergs.de wrote: On 09.08.2010, at 01:21, John Gilmore wrote: As long as activities are saving and restoring properly it could be made pretty much transparent to the user. Of course that's easier said then done... Android has a whole mechanism for this: http://blog.rlove.org/2010/04/why-ipad-and-iphone-dont-support.html That explains the problem, but doesn't explain the Android answer to it, which is here: http://developer.android.com/guide/topics/fundamentals.html The section Component Lifecycles gives the summary. They call each app's onPause() method when it is obscured from visibility on the screen, and that method is responsible for recording everything the app needs to restart itself and get back to the same screen display (what file it was working on, how far down the file it was, etc). Then, any process whose onPause() method has been called is considered a cache, and can be killed without warning by the kernel. (I'm not advocating using this system -- I've only barely been exposed to it. But it's useful to see how others have solved the problem you're facing, before making your own solutions.) Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. - Bert - (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. On Android, all (good) apps always save their state. There may be some bad ones, but all the ones I've used do it properly. Since apps are made out of activities (views) connected by intents, all the activities in an app save state. When starting an app, the main activity decides what to show (saved or new state) or it can switch to another activity that was active when the app was killed. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH]Remove nbsp chars from the html string before parsing)
Once you discover *where* to go to file a bug report, it is rather easy to file one IMO. My observation is that the filing procedure is somewhat hidden in arcane terminology. Less technically astute persons of interest such as myself can get lost and discouraged when the path is not made plain - and as direct as possible. Art Hunkins - Original Message - From: Tomeu Vizoso to...@sugarlabs.org To: Marco Pesenti Gritti ma...@marcopg.org Cc: sugar-devel@lists.sugarlabs.org; James Cameron qu...@laptop.org Sent: Monday, August 09, 2010 4:16 AM Subject: Re: [Sugar-devel] Adding committers on gitorious (was: Re: [PATCH]Remove nbsp chars from the html string before parsing) On Sun, Aug 8, 2010 at 02:20, Marco Pesenti Gritti ma...@marcopg.org wrote: On 6 Aug 2010, at 13:35, Tomeu Vizoso to...@sugarlabs.org wrote: I was just throwing in the idea here. I will bother you further only once I have a realistic plan in mind (and confidence in the ability to execute it with our limited resources) :) Sorry if I sounded harsh, I wanted to explain why some reforms are not going forward yet even if people agree are necessary. Oh, no worries, I don't think you sounded harsh at all. That's actually the other thing I'm planning to look into. Maybe I'm mistake but I feel we are stuck with a review process most of the existing contributors are unhappy with. I can work on a formal proposal and try to reach consensus, if that's what is missing... Sounds great, though I have felt that there was a bit of misdirected frustration during that conversation. As in the real problem not being the process but the slow response due to the lack of maintainers? The real problem being that contributing to FOSS can be very frustrating if you are not an expert already and there isn't a big effort in place to support new contributors. Maintainers are in a very good position to help new contributors but that doesn't mean that nobody else can do something about it. See for example the recent trend on sending patches to the mailing list for reviews and comments, then submitting for acceptance. It should have improved a lot the experience for new contributors and we didn't had to wait for any maintainer to do anything. Similarly, if creating trac tickets is so hard for a significant segment of our contributors, then we can create simplified forms or establish some sort of aggregator that submits those reports aftert some consolidation, translation and triaging, as is being discussed in another thread. If putting patches in a queue is too much of a hassle, we could have the figure of the Patch Manager, or write a tool similar to git-bz. http://producingoss.com/en/producingoss.html#patch-manager http://git.fishsoup.net/man/git-bz.html (it's python and git, we just need to replace bugzilla with trac) If having the queue in trac is too obscure because making a query is hard, we could make the automated report you wrote to point to bugs.sugarlabs.org and this mailing list. http://git.sugarlabs.org/projects/sugar-jhbuild/repos/mainline/blobs/master/scripts/report.py#line12 But there are apparently no resources to do any of this, so we turn to discuss about the process in the hope that we find one that allows us to do more without having to work more. If distros drop a platform dependency in the same release where the replacement lands (what happens with gnome-python2-desktop in Fedora 14), it means that everybody needs to build that dependency until they update to that release. Moreover, if some distros only include the new dependency at a later release (as with Ubuntu Maverick and Gtk3), contributors running one of those distros need to build more stuff for longer. My feeling is that these are a bit of special situations due to the dynamic bindings migration and gtk 3, I don't see they happening normally. Also it seems like they will hurt in the same way when we actually get to package Sugar on these distributions. Agreed, but if we keep Sugar aligned with the GNOME platform, then we need to worry mostly about these transition phases. We can reduce the harm by keeping PPA-like repos for the distros that need it (what the telepathy guys do for Ubuntu), but then someone needs to do that work. I wouldn't spend resources on this, it's error prone and time consuming. In summary, I'm able to see the importance of making as easy as possible running latest sugar on all distros, but I'm afraid it's one more goal we want to attain but don't know how to resource. To be clear, my goal is not to support all distro. I think it would be reasonable to say that you need the latest Fedora/Debian/Ubuntu to be able to build Sugar without messing with dependencies. I think there is a bit of a chicken and egg problem here. Making it easy to start developing Sugar is probably one of the best ways to increase the resources we can spend on user visible
Re: [Sugar-devel] Killing activities when memory gets short
Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Mon, Aug 9, 2010 at 15:47, Lucian Branescu lucian.brane...@gmail.com wrote: On 9 August 2010 14:44, NoiseEHC noise...@freemail.hu wrote: Sugar has a similar mechanism. From the Low-level Activity API docs: org.laptop.Activity.SetActive(b: active) Activate or passivate an activity. This is sent when switching activities, there is only one active activity at a time, all others are passive. A passive activity must immediately release resources like sound, camera etc. Also it should prepare for being killed without warning at any time in the future (see OOM) by auto-saving to the datastore. The issue is that it's hard to estimate how many Sugar activities actually do this, because until now they usually have not been killed (*). Might be an interesting test - just randomly kill activities from Terminal and see if they resume correctly ... Maybe good activities could volunteer to be shut down first. Or bad activities would have to beg to live a little longer. Might just take an entry in the activity.info file. It will not work, because the application startup time is horrible on the XO. The Dalvik VM goes a lng way to have fast application startup and to share most of the memory among applications (the Zygote process does this). Actually that was the exact thing I tried to do with the Python VM. Just at the exact time when I started to hack Python I have seen the Google I/O video about the Dalvik VM and thought that duplicating that work would have been a waste of time. So if you wanna fix the Python VM, good luck, but you know it is already been coded... :) Without fast activity startup, killing activities will be a horrible user experience. Maybe not that bad as a totally unresponsive XO though. It wouldn't be a duplication of efforts since Dalvik does not run Python and it is unlikely that it ever will. Perhaps a simple fork zygote for python wouldn't be that hard to accomplish in the sugar shell. We used to do that, the problem is that we don't control our platform as Google controls Android and you need to make sure that resources that need to be specific of each child process aren't shared (dbus and X connections, etc). I'm personally more interested in reducing the amount of resources we need to start activities (which is quite insane right now), but sharing more of those resources sounds like a good idea to me. Regards, Tomeu (*) Apple seems to have foreseen this developer psychology issue and actually killed all apps in the first three iterations of its iOS. So apps had to implement this state saving if the user was to be able to continue after leaving an app. Would be interesting to know how many Android apps actually implement it. All of them. If an Android application does not implement it correctly then there will be big problems while switching apps and while navigating among application screens. ___ 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] modified Home View
Comments inline... On Mon, Aug 9, 2010 at 2:58 AM, Walter Bender walter.ben...@gmail.comwrote: On Sun, Aug 8, 2010 at 4:51 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.com wrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already used for identity. It's bad enough that the GC activities, and a few others, break the colour metaphor by not bothering with the fill_color and stroke_color variables — adding even more colour metaphors would not help! ;) --Gary --
Re: [Sugar-devel] modified Home View
On Mon, Aug 9, 2010 at 10:37 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Comments inline... On Mon, Aug 9, 2010 at 2:58 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:51 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.com wrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already used for identity. It's bad enough that the GC activities, and a few others, break the colour metaphor by not bothering with the fill_color and
[Sugar-devel] Fwd: Speak.Activity v16 on Build 802 - Problem
Forwarding this to sugar-devel -- Forwarded message -- From: Tony Rizos tri...@pacbell.net Date: Sun, Aug 8, 2010 at 9:44 PM Subject: Speak.Activity v16 on Build 802 - Problem To: de...@lists.laptop.org Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it. All works well except the Speak activity. After running correctly the first time, it will not start up on subsequent attempts. I thought this may have been caused by my attempt to install Skype when the problem seemed to have started. I erased Speak and reinstalled it with no luck. I first tried going back to 656 and upgrading again to 802. No luck. I should say I also tried Speak v9 which worked with no problems whatsoever. The problem is associated with the Speak v16 activity that comes with 802. I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Is there a problem with Speak v16? Have you seen this problem before? Is there any more information I can provide? Can this be fixed? Thanx, Tony ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Speak.Activity v16 on Build 802 - Problem
I have this exact problem as well. Any ideas? On Mon, Aug 9, 2010 at 11:19 AM, Rafael Enrique Ortiz Guerrero raf...@sugarlabs.org wrote: Forwarding this to sugar-devel -- Forwarded message -- From: Tony Rizos tri...@pacbell.net Date: Sun, Aug 8, 2010 at 9:44 PM Subject: Speak.Activity v16 on Build 802 - Problem To: de...@lists.laptop.org Hi, I upgraded my OLPC XO from Build 656 to 802. Having not used the XO for the last 2 years, I was pleased with the changes. I am planning to give it to my niece who asked if she could have it.All works well except the Speak activity. After running correctly the first time, it will not start up on subsequent attempts. I thought this may have been caused by my attempt to install Skype when the problem seemed to have started. I erased Speak and reinstalled it with no luck. I first tried going back to 656 and upgrading again to 802. No luck. I should say I also tried Speak v9 which worked with no problems whatsoever. The problem is associated with the Speak v16 activity that comes with 802. I asked the forums if anyone had seen this problem and was recommended to do a no-fail update. After wiping the XO clean and installing 802, Speak v16 seemed to work again with no problems. However, when I closed it and restarted it, I got an error and would not start. I then erased it and reinstalled it. It started up okay with no problems but I get the same result when I close it and restart it. The error detail included the following messages: gst-plugins-based failed to resolve due to Unknown gstreamer failed to resolve due to Unknown gst-plugins-good failed to resolve due to Unknown Processed: 1; skipped: 0 Cancelled Is there a problem with Speak v16? Have you seen this problem before?Is there any more information I can provide?Can this be fixed? Thanx, Tony ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ 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] modified Home View
On 9 Aug 2010, at 15:37, Christian Marc Schmidt christianm...@gmail.com wrote: (1) Can we reach consensus re spiraling in from the MAXIMUM radius once the Ring is full or spiraling out from the MINIMUM radius once the Ring is full? I would say spiraling in from max radius. That way we can maximize the efficiency of the ring, before transitioning to the spiral. Oh well I guess I just got out voted (think max inwards looks ugly, backwards, unexpected for a spiral) ;) Walter, looking at your mockups I'd try to come up with an algorithm that gives us a looser spiral with more space between each segment of the spiral, more along the lines of what Gary mocked up. The screenshots on the wiki look very dense. Gary's mockup really proved to me that this can work! Yes, maybe that will help remove all the dead inner white space when using the max inward spiral. (2) Is is OK to add an INTERMEDIATE icon size between STANDARD and SMALL? I'd even go further and suggest that we could have icons scale dynamically within the ring/spiral, to achieve maximum balance between the available space and icon legibility. FWIW I was testing Walters latest patch today and noted that the existing original ring code did much more with icon scaling than the current patch. In the low icon number count, icons start large and then gradually reduce in size before filling the minimum radius. Roughly the first 13 icons form the min radius ring are at their largest size, then up to about 19 icons the they slowly reduce in size down to the next preset standard, at which point the ring starts growing in radius. Once the radius hits max, I believe that's when the icons start to scale down further (not sure if this is a sudden size change to another small default or some gradual reduction). Walter, your latest patch does show a big visual jump once the large icons reach the maximum radius, as that point it triggers a large icon size step down and the ring goes from full height to about half height with on extra icon. Am I correct in assuming that the style.STANDARD_ICON_SIZE, MEDIUM, and SMALL are there to improve icon rendering/cache efficiency? I vaguely remember some pre-rendering to set sizes discussion/work some time back. Not sure if we mess that up by using arbitrary values? My only concern here is that we'd need to find the right balance so as not to interrupt the general zoom metaphor, going from large to small icons (home to neighborhood). This means we probably need to put a cap on the bottom end of the scale, not allowing icons to become too small so that they could reach the size of icons in the groups view... All this will take lots of exploration I think before getting it right. I can work on mockups if that would help... I'd say apply the patch and/or tinker with the current code (it's a single file, and just one short method* that pretty much fits in one page of source), I found trying to layout icons accurately in a spiral for a mockup quite an art in itself ;) * _calculate_radius_and_icon_size is the method, and it's in /usr/lib/python2.6/site-packages/jarabe/desktop/favoriteslayout.py (3) In regard to Q1, I could trigger the spiral before the Ring hits the MAXIMUM radius, perhaps at MAXIMUM-icon_size? (I've not illustrated this yet.) Yes, I think that probably makes sense. We should play through all the possibilities and then make a decision based on what works best... I was looking into growing the ring up from the min radius (large icons) up to the half way point between max and min radius. Icons would then smoothly reduce to the next standard size down. The spiral would then trigger, and grow both outwards and inwards. Once max/min are reached, icons are then gradually down sized again to fit. Might just be easier/close enough to use the old ring code and trigger something close to Walter's v1 spiral code at the halfway between max and min radius. --Gary -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org -- anyth...@christianmarcschmidt.com 917/ 575 0013 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
Comments below: On Mon, Aug 9, 2010 at 11:42 AM, Gary Martin garycmar...@googlemail.comwrote: On 9 Aug 2010, at 15:37, Christian Marc Schmidt christianm...@gmail.com wrote: (1) Can we reach consensus re spiraling in from the MAXIMUM radius once the Ring is full or spiraling out from the MINIMUM radius once the Ring is full? I would say spiraling in from max radius. That way we can maximize the efficiency of the ring, before transitioning to the spiral. Oh well I guess I just got out voted (think max inwards looks ugly, backwards, unexpected for a spiral) ;) Sorry, maybe I'm not fully clear on the behavior. I DO think that the spiral should start from within and spiral out. In my last comment, I was more thinking along the lines of first having the ring expand to max size, THEN switching to spiral when more activities are added. Gary, I thought your mockup looked great, where the spiral begins above the XO and spirals out with enough padding between segments to not make it feel too dense. I think we should do whatever we can to achieve this look. Walter, looking at your mockups I'd try to come up with an algorithm that gives us a looser spiral with more space between each segment of the spiral, more along the lines of what Gary mocked up. The screenshots on the wiki look very dense. Gary's mockup really proved to me that this can work! Yes, maybe that will help remove all the dead inner white space when using the max inward spiral. (2) Is is OK to add an INTERMEDIATE icon size between STANDARD and SMALL? I'd even go further and suggest that we could have icons scale dynamically within the ring/spiral, to achieve maximum balance between the available space and icon legibility. FWIW I was testing Walters latest patch today and noted that the existing original ring code did much more with icon scaling than the current patch. In the low icon number count, icons start large and then gradually reduce in size before filling the minimum radius. Roughly the first 13 icons form the min radius ring are at their largest size, then up to about 19 icons the they slowly reduce in size down to the next preset standard, at which point the ring starts growing in radius. Once the radius hits max, I believe that's when the icons start to scale down further (not sure if this is a sudden size change to another small default or some gradual reduction). Walter, your latest patch does show a big visual jump once the large icons reach the maximum radius, as that point it triggers a large icon size step down and the ring goes from full height to about half height with on extra icon. Am I correct in assuming that the style.STANDARD_ICON_SIZE, MEDIUM, and SMALL are there to improve icon rendering/cache efficiency? I vaguely remember some pre-rendering to set sizes discussion/work some time back. Not sure if we mess that up by using arbitrary values? My only concern here is that we'd need to find the right balance so as not to interrupt the general zoom metaphor, going from large to small icons (home to neighborhood). This means we probably need to put a cap on the bottom end of the scale, not allowing icons to become too small so that they could reach the size of icons in the groups view... All this will take lots of exploration I think before getting it right. I can work on mockups if that would help... I'd say apply the patch and/or tinker with the current code (it's a single file, and just one short method* that pretty much fits in one page of source), I found trying to layout icons accurately in a spiral for a mockup quite an art in itself ;) * _calculate_radius_and_icon_size is the method, and it's in /usr/lib/python2.6/site-packages/jarabe/desktop/favoriteslayout.py (3) In regard to Q1, I could trigger the spiral before the Ring hits the MAXIMUM radius, perhaps at MAXIMUM-icon_size? (I've not illustrated this yet.) Yes, I think that probably makes sense. We should play through all the possibilities and then make a decision based on what works best... I was looking into growing the ring up from the min radius (large icons) up to the half way point between max and min radius. Icons would then smoothly reduce to the next standard size down. The spiral would then trigger, and grow both outwards and inwards. Once max/min are reached, icons are then gradually down sized again to fit. Might just be easier/close enough to use the old ring code and trigger something close to Walter's v1 spiral code at the halfway between max and min radius. --Gary -walter -- Walter Bender Sugar Labs http://www.sugarlabs.orghttp://www.sugarlabs.org -- anyth...@christianmarcschmidt.comanyth...@christianmarcschmidt.com 917/ 575 0013 -- anyth...@christianmarcschmidt.com 917/ 575 0013 http://www.christianmarcschmidt.com http://www.linkedin.com/in/christianmarcschmidt http://twitter.com/cms_ ___
Re: [Sugar-devel] modified Home View
On Mon, Aug 9, 2010 at 10:48 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Aug 9, 2010 at 10:37 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Comments inline... On Mon, Aug 9, 2010 at 2:58 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:51 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.com wrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already used for identity. It's bad enough that the GC activities, and a few
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.12
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.12.tar.bz2 Create activity profile directory if it doesn't exist, fixes http://dev.laptop.org/ticket/10218 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] modified Home View
On Mon, Aug 9, 2010 at 12:32 PM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Aug 9, 2010 at 10:48 AM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Aug 9, 2010 at 10:37 AM, Christian Marc Schmidt christianm...@gmail.com wrote: Comments inline... On Mon, Aug 9, 2010 at 2:58 AM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:51 PM, Christian Marc Schmidt christianm...@gmail.com wrote: Hi Gary--thanks for the interesting mockup! My feedback: The spiral is interesting and worth exploring. But I would continue to focus the view on a single organizational system, whether ring, spiral, freeform, list, etc. This preserves the integrity and extensibility of the UI views metaphor, and doesn't overload the screen. Because the iconographic language is already very abstract and pared down, we need to make sure that the interaction paradigm is clear and focused. Based on your rendering I think that the spiral in itself is definitely worth exploring further, and I like Walter's idea that it could start as a ring and grow into a spiral when more activities are added. That seems like an elegant and scalable solution. Favoriting could happen in the Journal, or we could opt to always display all activities--either seems like a potentially workable solution... We should also come back to the resume/start new proposal and figure out if we want to adopt any of the proposals. Christian On Sun, Aug 8, 2010 at 4:38 PM, Gary Martin garycmar...@googlemail.com wrote: On 8 Aug 2010, at 14:54, Gary Martin wrote: On 8 Aug 2010, at 13:42, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Le 08/08/2010 13:59, Walter Bender a écrit : See http://wiki.sugarlabs.org/go/Features/Spiral_Home_View#Detailed_Description for the latest screen shots. I made some changes to the way I generate the Spiral -- I start from the outside rather than the inside to minimize the visual disruption between the Ring and the Spiral. I don't ever shrink the icon size in the Ring, but do so in the Spiral once the minimum radius is reached. Perhaps most controversial, I introduce an intermediate icon size between standard and small along the way. Gary: I'll post a new patch to the ticket momentarily. (http://bugs.sugarlabs.org/ticket/2143) Comments/suggestions? Don't you need a way to recreate a taxonomy when the numbers of activities grows? Search (ghost out non matches, as per neighbourhood view design) in the fav. view would seem an ideal next step here when dealing with many activities. Allowing drag and drop that would trigger a switch from a fixed layout pattern to random mode (with the layout initially intact), and/or reordering the sequence by drag'n'drop insertions would allow some flexibility. Ideally icons would be either snapped to the shape (dragging N units close to a snapped icon or the XO) or freeform positioned (by dragging N units away from their/a set position). With different icons in either state for a single view (I.e. a spiral with a few frequent icons dragged out into empty space). The current random view could then go away (as each view could be as random or not as desired). Just as a follow up to my above comment, attached is a quick home view vector mockup. It assumes the list view is gone, with Journal stars being used to indicate (arbitrary entry) home favourites. It shows a 'snap to spiral' pattern, with several random clusters of activities/objects previously dragged out of the pattern by the user. Coloured icons would resume specific activity id objects, grey icons would be used to launch new instances (with the usual resume drop down palette of N most recent activities of that type). The spiral would re-flow once an icon is dragged out and dropped (in empty space), or dragged in and dropped (on an already snapped icon). If all icons were dragged out you would have what would look like the random layout, dragging an icon back onto the central XO would start reflowing a snapped pattern design again, as would adding new activity favourites. Again, just a future possible approach. Definitely no need to try and land something like this all in one go. --Gary But Walters spirals, without any of the above type extras, is still a huge improvement for those that want to fav many activities. I'm already hard-pressed to find new activities to fill up the view for testing, really scrapping the barrel. For those of you involved in deployments — roughly how many activities do you think kids/teachers currently commonly have? For example grouping related activities in spiral segments and reinforcing this with common icon color scheme in these segments. -1 No to a color scheme here. Colour is already
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 12:46 AM, Neil Graham l...@screamingduck.com wrote: Perhaps what is needed is a KDE to olpc's gnome in order to lift the game of both. We do a ton of things in relationship with our 'community' (or perhaps our different 'communities'). For example, we engage in this thread with you. As with most projects, it's up to you to help, participate positively, or not. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable (was: Re: OLPC 10.1.2 Release Candidate 1)
On Sun, Aug 8, 2010 at 5:09 PM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: I know I'm repeating myself here but I find the attitude expressed in these instructions and particularly point 3 troublesome and a continued source of frustration for me as well as other people I've talked to. Even more so I think it's a very clear symptom of the much-discussed disconnect between developers and end-users in the OLPC and Sugar Labs context. Not really. There is a lot of glue people that can help bridge the gap between teachers / nontechie deployers and developers. I am one of them. I am sure you are one too. Deployments need to have a (small) technical team that also fits this role. Such bridge people are needed to boil down end users' reports into something that looks like a usable bugreport. Being a bridge person, a translator between the two worlds is sometimes frustrating (can't these people talk to eachother directly?) but the barriers are real. Rejoice in being able to do it (at least I do). And sure -- we need to get more hands (ears/eyes) into this role. It is essential social glue. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Making OLPC / Sugar Labs more approachable
On Mon, Aug 9, 2010 at 4:17 PM, Neil Graham l...@screamingduck.com wrote: And yet, Developers on this list [olpc-devel] have complained when people have done that, because this is not the place for it. Of course, there isn't any other place for it. Don't take every complaint seriously ;-) I really don't want to get combative here. This may come off as You guys all suck but what I want is for things to improve. We all do. But we are damned swamped with things, and we do a ton with the community. You might not see it right now but we do. ... but a friend of mine who attended PyCon came back and said he was amazed with just how many people he met who felt burned by OLPC. Having been an external volunteer first, I can attest that it is hard to contribute to OLPC. A lot of that is because OLPC has chosen to do hard things. OLPC requires a lot of time investment. All the other open proects I know that have similarly hard goals are known to burn people out. Don't know if there's a fix for that overall problem :-/ Are there specific issues you are hoping for support with, what are they? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
