Re: [Sugar-devel] datastore situation (was Re: Hypothetical sugar-0.90 material, draft 1.)
Dear Tomeu and other Gentle Readers, Thanks for bringing this thread to my direct attention by CC'ing me. Since, I'm not exactly sure what feedback you'd like from me, I've tried to respond in a way that will lead to a fun and productive discussion on where do we want to go over the next few years and, concretely, what might we do to get there? I hope this is helpful. Therefore, if it's not, please let me know and we can try something else. Finally, please note that, in the interests of perspicacity and getting at least a few hours of sleep tonight, I've left out the background of /why/ I think we want the things that I claim we want below. If you'd like me to fill this in, please speak up. Regards, Michael ... On Mon, Jun 21, 2010 at 12:06:49PM +0200, Tomeu Vizoso wrote: On Thu, Jun 10, 2010 at 17:48, Martin Langhoff martin.langh...@gmail.com wrote: I think this is an unfair recount of my work, so I'm going to put some light on it and ask that my frankness is excused. - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ Not sure how you are counting, only 2 datastore implementations have ever been released as part of a Sugar release (more details below). Agreed. they get little testing and I've seen extremely light thinking about what is _actually_ needed. ... What should I have done instead, limit myself to publish papers and give talks about my prototype and just re-release the old implementation in every Sugar release? You did good work in your rewrite. We need _a good, polished DS that covers many aspects sanely_... a new DS is unlikely to do so. IOWs the barrier to merge a new DS should be high. It just triggers my CADT alarms http://www.jwz.org/doc/cadt.html Martin: CADT doesn't accurately describe the DS situation so please either recalibrate your alarms or be more specific about what immortal bugs concern you. Not sure how we can agree on rewriting or not rewriting if we haven't agreed yet on what features should have the future releases of the DS? So let's talk about what we might want to see in later 0.9x releases... For me, the three biggies concern the data model, the compatibility story, and the safety story. Here are my thoughts on each: On the data model: model v0.8x: in the grammar of sugar-0.8x, the journal records one-word sentences in which instances simultaneously represent both nouns and verbs. claim: in the short term, we want to get to a Journal that looks like Eben's slideshow and that works like Scott's journal2 mockup. model v0.9x: in the grammar of sugar-0.9x, the journal records multiword sentences in which instances are verbs and objects are nouns. Walter's paraphrased claim: in the long run, we're going to want a richer data model that includes grammatical features like adverbs and adjectives. however, it seems likely that we're not going to be able to get a richer model right before first gaining some experience with the simpler model described above. On the compatibility story: we need to maintain compatibility with a) the current D-Bus API and b) the ability to loselessly import older DS data. however, to grow our universe of apps, we need to create compatibility with existing software based on hierarchically structured files and directories. to do merge this with the v0.9x data model, we should create a new 0.9x activity API which specifies the interpretation of top-level files, directories, and file metadata in the activity root. as a simple, hypothetical, example: activity sessions are identified by session dirs with extension .xos. activity sessions are resumed by executing ./resume in the session dir. bespoke resume-related data are stored in hidden files or subdirs in the session dir. the reusable objects of an activity session are non-hidden files in standard formats in the session dir or its subdirs. activity metadata is stored in ./metadata.json in the session dir. (alternate design: metadata is stored as xattrs on whatever files or dirs it applies to) limited versioning is enabled when we find a top-level hidden dir with supported vcs state. for 0.9x, this would mean basic support for .git dirs. On the safety story: * the overriding themes of DS safety are undoability and limited isolation: a) session-level undo (versioning) b) system-level undo (backup/restore) c) isolation (sandboxing + ACLs) the session-level undo I'm thinking of is adequately provided by the current keep button and an additional toolbar that, when opened, displays an MRU-sorted list of previous commits. (The keep button should record a commit message, then call something like git add *; printf msg | git commit -F - * I don't yet
[Sugar-devel] A Tale of Sugar and Pippy
Last Friday, I visited the MIT Science Fiction Society's library to pick up some books. While visiting, I spoke with a friend about our recently discovered mutual interest in Python in education. Upon hearing that he was unfamiliar with our work, I opened my XO, started Pippy, and left him to play for a few minutes. +1: This experience *rocked*: I can think of no other operating system which so directly brought his interest from theory to reality. Now, after playing with several Pippy examples, my friend stumbled onto XOlympics. In honor of the World Cup, I challenged him to game. After playing for some time -- perhaps 10 rounds -- we discovered that we had lost track of which ball was currently contested. We looked at one another for a moment and simultaneously exclaimed: we can fix this! +1: I can think of no other operating system and application which so directly exposes us to the possibility and desirability of making small changes. We sat down to fix the problem. Since no example was available for how to set the color of an already constructed ball, I had to go behind the scenes by grepping the Pippy source code. Then I was able to work out exactly what to do by several small experiments with dir() and with raise. -1: I think there's an important missing stepping stone here -- I'm not convinced that most people would have been able to figure out how to set the ball color from the currently available view-source interface and Pippy training materials. The final change consisted of six insertions to the XOlympics example. It was this long only because I decided to try something fancy -- smoothly interpolating the contested ball between two colors over time -- instead of something simpler. Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? Regards, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: After playing for some time -- perhaps 10 rounds -- we discovered that we had lost track of which ball was currently contested. Yes, I discovered that also in my testing of the example. We sat down to fix the problem. Since no example was available for how to set the color of an already constructed ball, I had to go behind the scenes by grepping the Pippy source code. Then I was able to work out exactly what to do by several small experiments with dir() and with raise. You discovered what I had discovered ... the example depends heavily on the Physics library bundled with Pippy. I got lost looking at the problem and gave up. But I did almost manage to convert the code to be screen resolution independent. See 4a50004 ... the winning round position check code has a FIXME attached, and I welcome input. -1: I think there's an important missing stepping stone here -- I'm not convinced that most people would have been able to figure out how to set the ball color from the currently available view-source interface and Pippy training materials. I agree. Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? Quandry: we'd want subsequent users of the examples to be challenged by the same problem, so why would we want to fix it for everybody? When editing the examples recently I saw several improvements that I could make but decided not to make them because I wanted the reader of the example to make the same mistake as part of their learning. Sharing in class context ... does this work? Can the journal entry be passed around? For merging the improvements as part of the Infinite_monkey_theorem, we would need to bring the change back from the user into the development community, and provide feedback to the user. We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org that would provide these features: 1. submission of example improvements, which are inserted into a branch in a git repository, where the branch is named for the user, 2. status view of their submission branch, using a journal entry of a Browse bookmark, 3. download of other submission branches by users, 4. scoring and voting by other users. Is there a web application that does this kind of thing already? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RD vs Product Support
On Mon, Jun 21, 2010 at 10:06:48AM -0400, Martin Langhoff wrote: we're too small to split people into clubs +1 cheers, m Martin pgpYgACxKm4wh.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote: On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org Both an email and a POST request could be tried - saving the entry to the journal might be good, which then opens up a whole other set of routes (and confusions) for submission/sharing (and its resultant UI challenges). To bikeshed a bit, perhaps share via email and/or share via web could become part of Activities' sharing options. Martin pgpFZI2UKznqp.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
I think all activities should have Report bug on the toolbar somewhere. And of course a system in place on the other end, perhaps email-to-trac? On 22 June 2010 14:25, Martin Dengler mar...@martindengler.com wrote: On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote: On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org Both an email and a POST request could be tried - saving the entry to the journal might be good, which then opens up a whole other set of routes (and confusions) for submission/sharing (and its resultant UI challenges). To bikeshed a bit, perhaps share via email and/or share via web could become part of Activities' sharing options. Martin ___ 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] A Tale of Sugar and Pippy
On Tue, Jun 22, 2010 at 02:36:42PM +0100, Lucian Branescu wrote: I think all activities should have Report bug on the toolbar somewhere. And of course a system in place on the other end, perhaps email-to-trac? Good idea, but why make every activity implement this? I think a bikeshed icon in the frame would be better. I plan to release one on April 1, 2011. Martin pgpMBmHLA8eLG.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
On Tue, Jun 22, 2010 at 02:41:04PM +0100, Martin Dengler wrote: On Tue, Jun 22, 2010 at 02:36:42PM +0100, Lucian Branescu wrote: I think all activities should have Report bug on the toolbar somewhere. And of course a system in place on the other end, perhaps email-to-trac? Good idea, but why make every activity implement this? I think a bikeshed icon in the frame would be better. I plan to release one on April 1, 2011. HHOS. And I'm not sure what colour the icon should be. pgpQQ1u3Zzgcm.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
I can think of no other operating system which so directly brought his interest from theory to reality. +1: I can think of no other operating system and application which so directly exposes us to the possibility and desirability of making small changes. I agree (as well) Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. Ok, I'm a little confused here. There are two perspectives to this. One perspective is experienced developers hacking pippy/python examples and submitting suggestions/improvements and the other is concerning people (primarily students) learning python; experimenting, learning and sharing. Am I correct in assuming that we're discussing the latter here? For merging the improvements as part of the Infinite_monkey_theorem, we would need to bring the change back from the user into the development community, and provide feedback to the user. We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org that would provide these features: 1. submission of example improvements, which are inserted into a branch in a git repository, where the branch is named for the user, 2. status view of their submission branch, using a journal entry of a Browse bookmark, 3. download of other submission branches by users, 4. scoring and voting by other users. Excellent suggestion. I'd go one step further and suggest developing a simple interface within Pippy that can communicate with the web server/application and implement the features listed above. -- Anish Mangal On Tue, Jun 22, 2010 at 1:37 PM, James Cameron qu...@laptop.org wrote: On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: After playing for some time -- perhaps 10 rounds -- we discovered that we had lost track of which ball was currently contested. Yes, I discovered that also in my testing of the example. We sat down to fix the problem. Since no example was available for how to set the color of an already constructed ball, I had to go behind the scenes by grepping the Pippy source code. Then I was able to work out exactly what to do by several small experiments with dir() and with raise. You discovered what I had discovered ... the example depends heavily on the Physics library bundled with Pippy. I got lost looking at the problem and gave up. But I did almost manage to convert the code to be screen resolution independent. See 4a50004 ... the winning round position check code has a FIXME attached, and I welcome input. -1: I think there's an important missing stepping stone here -- I'm not convinced that most people would have been able to figure out how to set the ball color from the currently available view-source interface and Pippy training materials. I agree. Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? Quandry: we'd want subsequent users of the examples to be challenged by the same problem, so why would we want to fix it for everybody? When editing the examples recently I saw several improvements that I could make but decided not to make them because I wanted the reader of the example to make the same mistake as part of their learning. Sharing in class context ... does this work? Can the journal entry be passed around? For merging the improvements as part of the Infinite_monkey_theorem, we would need to bring the change back from the user into the development community, and provide feedback to the user. We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org that would provide these features: 1. submission of example improvements, which are inserted into a branch in a git repository, where the branch is named for the user, 2. status view of their submission branch, using a journal entry of a Browse bookmark, 3. download of other submission branches by users, 4. scoring and voting by other users. Is there a web application that does this kind of thing already? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
[Sugar-devel] [ASLO] Release Kandid-7
Activity Homepage: http://activities.sugarlabs.org/addon/4254 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26953/kandid-7.xo Release notes: Removing Glade from Kandid to make it more compatible with the Sugar Platform. Bug fixing the rendering engine. This release is NOT backward compatible. Some images created with former releases may be rendered different now. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
On Tue, Jun 22, 2010 at 02:25:06PM +0100, Martin Dengler wrote: On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote: On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org Both an email and a POST request could be tried - saving the entry to the journal might be good, which then opens up a whole other set of routes (and confusions) for submission/sharing (and its resultant UI challenges). To bikeshed a bit, perhaps share via email and/or share via web could become part of Activities' sharing options. Martin There is presently a peer-to-(multiple)peer sharing app from SL called FileShare. One person starts it, makes a public session in the Neighboorhood, share a document, then others can join this and then download that document to the Journal. -- | .''`. == Debian GNU/Linux ==.| http://kevix.myopenid.com..| | : :' : The Universal OS| mysite.verizon.net/kevin.mark/.| | `. `' http://www.debian.org/.| http://counter.li.org [#238656]| |___`-Unless I ask to be CCd,.assume I am subscribed._| ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
On 22 Jun 2010, at 14:36, Lucian Branescu lucian.brane...@gmail.com wrote: I think all activities should have Report bug on the toolbar somewhere. And of course a system in place on the other end, perhaps email-to-trac? Would be great if the Log functionality for uploading log files to a server could be fleshed out and brought back to life (though I never got to see it working originally). We could then direct testers there to get more actionable bug data rather than cluttering up every activity with an additional tool. Regards, --Gary On 22 June 2010 14:25, Martin Dengler mar...@martindengler.com wrote: On Tue, Jun 22, 2010 at 06:07:50PM +1000, James Cameron wrote: On Tue, Jun 22, 2010 at 03:39:46AM -0400, Michael Stone wrote: Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. Anyone have thoughts on what stepping stones Sugar and Pippy ought to provide to make this act of reflection and sharing feel as natural as the act of starting Pippy or of making the change that we want to describe and to share? We might not be able to depend on an e-mail path. So I envisage a small web application on sugarlabs.org Both an email and a POST request could be tried - saving the entry to the journal might be good, which then opens up a whole other set of routes (and confusions) for submission/sharing (and its resultant UI challenges). To bikeshed a bit, perhaps share via email and/or share via web could become part of Activities' sharing options. Martin ___ 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Quickly for Sugar
I was looking at Jono Bacon's article (cc'd) in the latest Linux Journal (http://www.linuxjournal.com) and was wondering if anyone has looked into Quickly in the Sugar context. Quickly essentially ties in various tools to allow for an easier workflow for opportunistic programmers. It pulls in Glade, Python, gedit etc. Quickly: https://wiki.ubuntu.com/Quickly cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Campus Business Solutions San Francisco State University http://verma.sfsu.edu/ http://opensource.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
Here, we reach the end of my tale. You see, my friend and I agreed that our desired next step would be to send our change to sugar-devel@ along with, well, this story. -1: Unfortunately, there's no obvious way to do this with Sugar and Pippy today. I don't want to spoil the party, but what are you going to do if that works and kids from around the world start bombarding sugar-devel with their changes? I've heard the term success disaster used for problems like this. The idea is that you can ignore a potential problem for now because if something like that really does become a serious problem, that's because the project as a whole was successful and (somehow) it will have picked up adequate resources to fix the problem. Still, I'd be happier if we avoided scaling problems as much as possible. -- These are my opinions, not necessarily my employer's. I hate spam. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] API documentation.
It looks like we are starting to make progress on the API documentation project. As you may be aware, Seeta.in is working on sphynix based api documentation for the core Sugar modules. Initial work can be seen at http://seeta.in/sugar/api/documentation/dest8/ and http://seeta.in/sugar/api/documentation/dest9/ . But there are also significant advantages to maintaining the existing epydocs at api.sugarlabs.org. I would like to propose that: 1. Manu identify a seeta sysadmin for whom we create an account on sunjammer, 2. Seeta move their proof of concept spynix documentation to sunjamer. 3. The Seeta documentation team continue to maintain the existing epydocs documentation. I can do the required tasks to make this happen. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
It might also be worth thinking about how this would play out in Squeak/Etoys. See in particular: http://wiki.laptop.org/go/Smalltalk_Development_on_XO#Submit_your_changes --scott attempting to learn from the community ps. as bert's doing the only multitouch work (that I know of) I've given some thought recently to what Sugar II would look like if it were totally implemented in Squeak/Etoys. Why not? --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A Tale of Sugar and Pippy
Hi, I don't want to spoil the party, but what are you going to do if that works and kids from around the world start bombarding sugar-devel with their changes? I should think some kind of party would be in order. :) - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On Fri, Jun 18, 2010 at 9:04 AM, Gary Martin garycmar...@googlemail.com wrote: Hi Sayamindu, On 17 Jun 2010, at 13:16, Sayamindu Dasgupta wrote: [Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso Wow, big thanks for launching into this. For anyone not sure how to try the iso, I'm on a Mac and just used Virtual Box to create a new empty Fedora VM, no HD, and just point to the iso as the boot CD. Started up just fine, keyboard is already open to type in your user name (of course this is all read only, any changes you make will be gone after a reboot). Thanks for the feedback - this is really helpful :-) I'll try and spend some time in the next few days using it via iPad HW and send some feedback, just been playing via mouse so far today. Apart from the modified FVKBD, I have added a default keyboard definition file which is for English + Bengali, and I've also included a sugar device-icon on the frame to control the appearance of the keyboard. I realize that more needs to be done to support non Latin scripts, and here are some of the issues I faced while converting the existing XKB Bengali layout: * Many scripts do not have a concept of upper case/lower case - so we need some other script specific way to divide the characters * In the current XKB configurations, non-symbol characters from other scripts are often placed in the position of what normally is symbols for QWERTY keyboards * Numerals pose an interesting problem, since in some places, native numerals/digits are quickly being obsoleted, and latin numerals (1,2,3..) are becoming the de-facto standard. In these cases, it may make sense to provide only _one_ layout/state for numerals, and allow users to input native numerals by hovering (touch + hold) on the virtual key for the latin digit. Among the general issues, I'm not sure how to deal with the keyboard taking up half of the screen real estate - it may be worthwhile to see if we can have a split screen sort of configuration while the keyboard is active. It didn't bother me too much, and this was in an 800x600 session, though ideally we would want the text insertion point to be visible above the keyboard (FWIW various iPad apps have different success in dealing with this, all of Apple's are fine, but it seems 3rd parties do need to do some work on the app side to keep this behaviour working at all times). Transparency is something which comes to mind. Another possibility might be to make the keyboard move up to the top half of the screen after a certain point - but that may be too annoying. Thoughts, feedback, etc would be appreciated :-). Yes, lot's of interesting items to cover :-) I'll try to start to put together a list. Some quick item that struck me right away: - the Meego keyboard design is clearly for casual typing/text entry, no way of typing commands or many symbols needed for basic programming work – diving into terminal to use vi, or worse emacs, is pretty much a dead end (unless ctrl and alt keys are hidden somewhere I couldn't find). Is it flexible enough to allow different activities to trigger different keyboards (or an extra row of custom keys)? Something like Pippy, or Terminal would need that kind of extra flexibility. Yes - it can be possible to load an extended layout (with for example, an extra panel on the top for extra characters). It may be a bit tricky, but sugar can probably provide an API to do this - and it would be easier if we can wrap libfvkbd in python or extend the library to use introspection. - z layering issues with frame, should it be over, under, part of? Currently it can be a mix depending on the sequence things are triggered. I suppose the frame should always come on top. I'm not sure how the window manager would deal with this - the window type of the keyboard panel is currently set to dock, which can be changed to a window, and that may work. - Ideally something (Gnome I assume?) should trigger the keyboard overlay when you focus on a text field, perhaps with some hints about what the 'return' key behaviour
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi Esteban, On Thu, Jun 17, 2010 at 7:19 PM, Esteban Arias ear...@plan.ceibal.edu.uy wrote: Hi, FVKBD support spanish keyboard? Could be added an system scanning buttons to write. for example: https://desarrollo.ceibal.edu.uy/projects/tecladoenpantalla/files http://wiki.sugarlabs.org/go/Features/Accessibility_virtualkeyboard http://bugs.sugarlabs.org/ticket/1686 I don't think this particular on-screen keyboard is something that you would use for accessibility stuff (it does not have support for scanning buttons). However, I did a Spanish version of the layout - here's a screenshot of the Spanish mode - http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-es-onscreen.png Let me know if you want to test the layout. Thanks, Sayamindu 2010/6/17 Sayamindu Dasgupta sayami...@gmail.com On Thu, Jun 17, 2010 at 5:46 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: [Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso For those who do not want to download the ISO, there's a screencast at http://dev.laptop.org/~sayamindu/sugar_vkbd_multi.ogv Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Esteban Arias Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : ear...@plan.ceibal.edu.uy -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On Fri, Jun 18, 2010 at 12:35 PM, Jonas Smedegaard jo...@jones.dk wrote: Hi Sayamindu (and others), On Thu, Jun 17, 2010 at 05:46:43PM +0530, Sayamindu Dasgupta wrote: [Apologies for the cross-posting] Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. Thoughts, feedback, etc would be appreciated :-). I am not familiar with these details, so just shooting in the dark here: Perhaps looking at (i.e. get interface inspiration or steal code from) the alternative virtual keyboard implementation Literki, which seems to have happy followers among Debian OpenMoko users: http://git.senfdax.de/?p=literki Thanks for the pointer to this. It seems however that it's written directly using Xlib, and hence would be unusable for complex scripts like Arabic, Indic, etc. Best, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] API documentation.
El Tue, 22-06-2010 a las 13:45 -0500, David Farning escribió: It looks like we are starting to make progress on the API documentation project. As you may be aware, Seeta.in is working on sphynix based api documentation for the core Sugar modules. Initial work can be seen at http://seeta.in/sugar/api/documentation/dest8/ and http://seeta.in/sugar/api/documentation/dest9/ . But there are also significant advantages to maintaining the existing epydocs at api.sugarlabs.org. I would like to propose that: 1. Manu identify a seeta sysadmin for whom we create an account on sunjammer, 2. Seeta move their proof of concept spynix documentation to sunjamer. 3. The Seeta documentation team continue to maintain the existing epydocs documentation. I can do the required tasks to make this happen. Thanks, go for it! Rather than using root, please create a group for the service and add admins to it. Do you need a virtual host for this service? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RD vs Product Support
El Mon, 21-06-2010 a las 10:06 -0400, Martin Langhoff escribió: On Mon, Jun 21, 2010 at 3:46 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Sorry, I was asking about splitting the staff. Here I agree with Tomeu. A subtext of my experimental branches post is that we're too small to split people into clubs (and it's counterproductive anyway). In any given open source community, there will always be a certain number of people who are interested in building their own thing rather than working on the central project. The choice is between enabling these people to be productive on their parallel project, or loosing their contribution altogether. One obvious example is the live Sugar distros: SoaS, Ubuntu Sugar Remix (USR) and Trisquel Sugar. It might be better to concentrate our scarce resources on just one distro... but I don't see how those involved with the other two projects would ever want to join in. SIGs and experimental branches are a great way to leverage extra talent that would otherwise go wasted. Sometimes, an experimental project turns into something very useful... It's hard to tell before someone tries. But we all have experimental / controversial / not quite mergeable patches :-) I certainly have a bunch :-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
