Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Wed, Jun 16, 2010 at 9:47 PM, James Cameron qu...@laptop.org wrote: Could you briefly explain what bundling forces means? How about rowing in sync? From LWN's coverage: For a while now, Mark has been pushing the idea of a coordinated cadence across multiple projects. http://lwn.net/Articles/392016/ (will be free soon -- freebie link to be had to read Right Now if you ping me in private) 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] Hypothetical sugar-0.90 material, draft 1.
On 06/14/2010 08:03 PM, Tomeu Vizoso wrote: On Sat, Jun 12, 2010 at 16:15, Bernie Innocentiber...@codewiz.org wrote: El Sat, 12-06-2010 a las 10:26 +0200, Simon Schampijer escribió: PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. +1. I would also very much like our next RM to preserve our 6-months release cycle and keep it synchronized with the major Linux distros, like GNOME and other high-profile projects do. FWIW, I think that keeping Sugar aligned with GNOME and other downstreams of the GNOME platform will be key for putting a limit to the growing maintenance costs. This does not imply that we cannot ever do very large restructuring of our codebase, if needed. This kind of work just needs to happen in a development trees and be merged when it's sufficiently stable. Right, other projects keep the 6 month cycle and do radical revampings from time to time. We can also do it if it's really worth it. Regards, Tomeu Ideally there should be short term and long term planning. That is why I drafted the 0.90 schedule already at the beginning of the 0.88 cycle. Other projects, for example Ubuntu, are doing the same. This allows to do long term planning and gives bigger features or changes a way to developed accordingly and landed. I saw the talk from Mark Shuttleworth at Linuxtag and he said a few words on Releases, and why is makes sense to bundle forces. Basically, bundling forces is a powerful idea behind open source. We are a small project, if we keep being aligned with all the bigger projects especially gnome we will profit from this joined efforts a lot. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Wed, Jun 16, 2010 at 06:27:55PM +0200, Simon Schampijer wrote: I saw the talk from Mark Shuttleworth at Linuxtag and he said a few words on Releases, and why is makes sense to bundle forces. Basically, bundling forces is a powerful idea behind open source. We are a small project, if we keep being aligned with all the bigger projects especially gnome we will profit from this joined efforts a lot. Could you briefly explain what bundling forces means? Or refer us to a recording of Mark's talk? -- 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] Hypothetical sugar-0.90 material, draft 1.
On Sat, Jun 12, 2010 at 16:15, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 12-06-2010 a las 10:26 +0200, Simon Schampijer escribió: PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. +1. I would also very much like our next RM to preserve our 6-months release cycle and keep it synchronized with the major Linux distros, like GNOME and other high-profile projects do. FWIW, I think that keeping Sugar aligned with GNOME and other downstreams of the GNOME platform will be key for putting a limit to the growing maintenance costs. This does not imply that we cannot ever do very large restructuring of our codebase, if needed. This kind of work just needs to happen in a development trees and be merged when it's sufficiently stable. Right, other projects keep the 6 month cycle and do radical revampings from time to time. We can also do it if it's really worth it. Regards, Tomeu -- // 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. Whatever you do for the DS, it needs to be (very) easy to understand and (very) easy to explain, both to implementers and to users. Compression/delta schemes add another concept to the chain. Who is going to explain how it works to the end users? Sure, it's easy after you understand it, but there are lots of opportunities for things to fall through the cracks and the results can be nasty. Perhaps I'm overly sensitive to this area. 30+ years ago, I deleted a critical file. It was large and I needed the space and it wasn't obvious (to me) that the file was needed after step X. Things worked for a long long time. Then they broke with an obscure error message. (which was a lot better than it could have been) In hindsight, it only took a few seconds to explain what was going on. But that was after I got the right guy on the phone, stepped through the debugger for a while, and then gave him the critical piece of info about deleting the file. [Insert standard joke about fools being so ingenious.] How many ingenious fools will be using Sugar? I hope there will be a lot of them. -- 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
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On 06/11/2010 03:30 PM, Peter Robinson wrote: On Tue, Jun 8, 2010 at 5:54 AM, Michael Stonemich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15.you:your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 10:26 +0200, Simon Schampijer escribió: PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. +1. I would also very much like our next RM to preserve our 6-months release cycle and keep it synchronized with the major Linux distros, like GNOME and other high-profile projects do. This does not imply that we cannot ever do very large restructuring of our codebase, if needed. This kind of work just needs to happen in a development trees and be merged when it's sufficiently stable. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On Sat, Jun 12, 2010 at 9:26 AM, Simon Schampijer si...@schampijer.de wrote: On 06/11/2010 03:30 PM, Peter Robinson wrote: On Tue, Jun 8, 2010 at 5:54 AM, Michael Stonemich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15.you:your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. No, that was my bad. Not a change but me stuffing up the title name. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 01:15 -0400, Chris Ball escribió: Hi, Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Linux memory management shares identical pages between processes. This has been discussed at length on the FUDbus to Toronto with some hard-core Fedora folks. The general opinion is that it won't work in the case of Python, because pages will containing Python objects will: - often contain pointers with slightly different values across processes - As the program accesses the shared objects, even for read-only operations, the intepreter will often increment and decrement reference counts to objects, breaking the sharing This are the very same reasons why the parent process approach was not buying us much. David Malcolm, the the maintainer of Python in Fedora, proposed a strategy which would, sadly, require changes to the on-disk pyc format: http://dmalcolm.livejournal.com/4183.html -- // 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] Hypothetical sugar-0.90 material, draft 1.
El Thu, 10-06-2010 a las 14:24 -0400, Martin Langhoff escribió: On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for No. _It says exactly what it says_. People have been thinking lots about the fun part of the problem, thinking superficially about what they'll have fun implementing. Not about the complete problem space. Not about what hits users. Not about what we need for a saner implementation. I would tend to agree with Martin here. Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. A design working in real-world scenarios would probably require ad-hoc deltifiers for each file format, making it very complex, slow and fragile. Whether a generic versioned filesystem could ever become feasible, remains a fascinating research subject for the next decade. Perhaps we could slightly enhance the current datastore design to store full copies of each version without any attempt to deltify them. This is also how git started. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On 06/12/2010 10:49 AM, Bernie Innocenti wrote: Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. It is one thing to say that we need a new datastore, and another to say what the new datastore should look like. I believe we have consensus on the first part, and I'm fairly sure we don't have consensus on the second. For the record, I am pushing a proposal in which no deltas are computed. Files are stored as whole files. Instead, I want each datastore object version to consist of an entire directory. To save space, files that are identical inside multiple objects would only be stored once on disk. This allows us to store and launch Activity Bundles directly from the journal. It also allows slight modifications to objects (including activities) to be stored efficiently if the object consists of multiple files and not all of them are changed. This is the de-duplication approach that was favored over three years ago [1]. I think Martin has listed some important use cases, and we should consider them carefully. One way to do that might be to try to reach a consensus on design. I believe the last attempt at this was over two years ago [2] ... and produced many good ideas but ultimately not much code. --Ben [1] http://lists.sugarlabs.org/archive/sugar-devel/2007-April/002344.html [2] http://lists.laptop.org/pipermail/community-news/2008-January/95.html , section 10. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Besides, the assumption that VCS-style deltas will work well with the binary files stored by most Sugar activities is... wishful at best. A design working in real-world scenarios would probably require ad-hoc deltifiers for each file format, making it very complex, slow and fragile. Whether a generic versioned filesystem could ever become feasible, remains a fascinating research subject for the next decade. Perhaps we could slightly enhance the current datastore design to store full copies of each version without any attempt to deltify them. This is also how git started. Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Sat, 12-06-2010 a las 20:45 +0200, NoiseEHC escribió: Actually these are the exact same problems that could be solved much better with some kind of per activity DS (not the Android one, which would be a little bit overkill). I mean that even making or not making deltas is dependent on the object the activity stores and the deltifier is also activity object dependent. Also the single file or multi files thing is activity dependent and so on. So you can implement every possible feature in a global glorified DS but I personally do not think that you will reach a really usable general DS ever. This is the same conclusion me and Sascha reached on IRC some time ago. To me, saying that activity authors will have to deal directly with the concept of deltas is equivalent to admitting that it can't be done at all. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 5:54 AM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael, thanks for stepping up to be the 0.90 development manager :-P Peter PS I'm sure Walter will back me up here! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
Hi, Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Linux memory management shares identical pages between processes. - 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] Hypothetical sugar-0.90 material, draft 1.
On 10 June 2010 04:28, Jameson Quinn jameson.qu...@gmail.com wrote: 2010/6/9 Luke Faraone l...@faraone.cc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2010 08:11 PM, Bernie Innocenti wrote: As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. Actually, hulahop is used by pyjamas[1], as evidenced by these bug reports[2][3] spawned when sugar-hulahop was removed from Ubuntu Lucid. An aside, according to upstream this is not an integral part of their project, but it might be a good idea to involve them in the discussion. These days, I do my work in pyjamas - on the cloud. I have never used pyjamas on the desktop, but for people who do, hulahoop* was the least painful way to get there, and its removal sparked indignation. *OK, it's called hulahop, but this way all the code names mesh more surreally. Sir, you made my day. Seriously, though: the fact that pyjamas-desktop can exist without hulahop doesn't make it attractive to lose it. It may not be integral, but I don't see anybody in the pyjamas world who would be replacing it any time soon, so it is essential as a practical matter. Jameson For pyjamas's purposes, i'm not sure if webwrap (my abstraction layer over hulahop and pywebkitgtk) would be enough. But if I do this right, all Sugar apps will be able to use either hulahop or pywebkitgtk without any further effort. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
El Wed, 09-06-2010 a las 23:46 -0300, Gonzalo Odiard escribió: SocialCalc depends of hulahop. My activity Elements too. Ugh. BTW, SocialCalc hardcodes a 3-second delay for localization which opens a race condition. It works intermittently on the XO-1 with Sugar 0.84 and it probably fails to work altogether in other scenarios. Does anyone have any idea how it could be done in an event-driven way? I'm afraid I know nothing about XPCOM embedding. -- // 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] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) Hi Michael, thanks for taking on this effort. Overall, it's a fantastic thing that this is rolling forward. The two first items on your list make me think a bit. - 0install and Vala are controversial, risky and not focussed on pressing end-users' needs. Yes there are some benefits and potential to both (otherwise Aleksey would not be working on them! :-) ) but they also break lots of toys. - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. 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 Hopefully your list is not prioritised ;-) and it's just an accident that those two are top-of-the-list... Or maybe there's a goal to have 0.90 be a break lots of toys towards a 'developer release' and then make 1.0 the real deal. 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] Hypothetical sugar-0.90 material, draft 1.
On Thu, Jun 10, 2010 at 11:48:50AM -0400, Martin Langhoff wrote: On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) Hi Michael, thanks for taking on this effort. Overall, it's a fantastic thing that this is rolling forward. The two first items on your list make me think a bit. - 0install and Vala are controversial, risky and not focussed on pressing end-users' needs. Yes there are some benefits and potential to both (otherwise Aleksey would not be working on them! :-) ) but they also break lots of toys. I would say this is targeting to break not toys but players' minds :). The core idea behind these tools, they are just tools, to reach workflow of huge LEGO i.e. low floor - declaring base rules that let use/share/change things more smooth and decentralized in heterogeneous environment (not only for particular deployment like OLPC) when there is only doer-doer interaction scheme. This is not replacing/substitution of existed major sugar core workflow (targeting mainly on deployment e.g. GNU/Linux distributions or OLPC) but about adding another vector. And, I'm tending to think that this 0sugar/polyol/etc stuff is more for Activity Team rather than Development Team. - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. 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 Hopefully your list is not prioritised ;-) and it's just an accident that those two are top-of-the-list... Or maybe there's a goal to have 0.90 be a break lots of toys towards a 'developer release' and then make 1.0 the real deal. 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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On 06/10/2010 11:48 AM, Martin Langhoff wrote: - 0install and Vala are controversial, risky and not focussed on pressing end-users' needs. Yes there are some benefits and potential to both (otherwise Aleksey would not be working on them! :-) ) but they also break lots of toys. In my view, OLPC's ARM announcement creates a pressing problem of avoiding total confusion and fragmentation between different CPU architectures. 0install is, in my view, the most promising candidate solution. (I think the mention of Vala here is a red herring. The Vala sugar-toolkit effort is deliberately independent of Sugar version. It merely provides a new executable that activity developers may opt to include in their activity bundles.) - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for the past three years. Perhaps you should publish your thoughts on DS architecture, or even just a list of use cases that you believe have been overlooked. We need _a good, polished DS that covers many aspects sanely_... a new DS is unlikely to do so. Do you think our current datastore meets your criteria? The consensus among the developers seems to be that our datastore does not live up to our goals for data management. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for No. _It says exactly what it says_. People have been thinking lots about the fun part of the problem, thinking superficially about what they'll have fun implementing. Not about the complete problem space. Not about what hits users. Not about what we need for a saner implementation. even just a list of use cases that you believe have been overlooked. Ah... - ENOSPC? - Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have a bad patch for that...) - Integration with GNOME? (for those dual desktop OS builds) - Some reasonable degree of atomicity? - Sensible backup/restore? - Smarter handling of bundle filetypes... = so together with the Journal, it can expose the many images or videos in a 'Record' = so the Record file format gets untangled - Re-thinking of the Journal / Datastore interactions to access the normal filesystem so that Gnome's ~/Documents directory can be browsed - Working gracefully with large files Do you think our current datastore meets your criteria? No. It has heaps of problems. And I love some the cool ideas (git-like smarts for example). But _first_ DS has to shed its current stupidities. Talk of a rewrite that lists cool ideas but none of the big gaps gives me the CADT shakes. Just in case, I am taking http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html to be Sascha's plan. Hope that's the right one. Hate to sound so cranky, and I honestly like a VCS-styled Journal/DS. But there are many hard problems to solve in the Journal/DS, and many added hard problems that come with the VCS. Ignoring the hard problems and charging with the features won't help a bit. 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] Hypothetical sugar-0.90 material, draft 1.
It seems that I cannot stop myself killing some kittens: As I see the problem is that the DS wants to solve a lot of problems in a general way. I think that this is simply impossible. A lot of companies tried to create some general storage abstraction other that files, but all of them failed (even M$ tried that for decades...). My prophecy is that you will fail as well. Another way to solve those problems would be to have every activity have its own journal with its own user interface. The activity then could use plain files for storage or an SQLite database or just append a text file. The point is that the storage would be activity specific, with activity dependent optimizations if necessary. The activity would also show a list of existing documents/objects when started and have a New... button to start a fresh one. It would also eliminate the troubled activity start mechanic from the activity ring. Of course SUGAR should have some very good library support to enable creating the default DS user interface in several lines of code. Of course for activities which does not save objects this would be optional. Now because the DS storage would be scattered between activities, they should have to implement a backup/restore API, lets call it BackupAgent: http://developer.android.com/guide/topics/data/backup.html A simple activity could just mention in the MANIFEST that it has a data directory to be backed up and that would be all. Of course the user should be able to use full text search so there should be a either a central index or the activities should implement a search API, lets call it SearchRecentSuggestionsProvider: http://developer.android.com/guide/topics/search/adding-recent-query-suggestions.html Of course SUGAR should have library support to ease creating this search functionality. Now to allow activities to share data they should implement some API to be able to provide content to other activities, lets call it ContentProvider: http://developer.android.com/guide/topics/providers/content-providers.html Of course a flag in the MANIFEST could just allow SUGAR to index the data automatically. It would need some primitive OLE (Object Linking and Embedding) capability which is currently missing from SUGAR, lets call it AppWidgetProvider: http://developer.android.com/guide/topics/appwidgets/index.html The remaining piece would be a dead simple Journal which would just list the recently launched activities. Now why would it be cool? 1. Searching among contacts, mp3 albums and picture bundles can be totally different from the end user perspective. 2. It can be efficient, does not need copying large amounts of data. 3. Activities could be launched from GNOME. 4. It could be backwards compatible (if the APIs are set in stone). 5. The DS code (the library) could be developed when there is a need in an activity, there is no need to redesign the whole thing over and over again. 6. And I am sure that I could find some more... Why it is just a pipe dream? 1. Python does not have anything like the DALVIK virtual machine so every Python process consumes a lot of memory. Because of this, implementing the above infrastructure would consume all available RAM and so would not work. Of course the DS part could be C++ code as well but unfortunately children could not look at the source. 2. It is already implemented so why bother? Now, you should not take this message too seriously but you could seriously consider a per activity DS if you have some free time. Martin Langhoff wrote: On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: - Reworking the datastore... while I welcome efforts in a new datastore... _every Sugar release has a new DS implementation_ and they get little testing and I've seen extremely light thinking about what is _actually_ needed. That's a very polite way of saying that you disagree with the extensive thinking that's been done about datastore design and implementation for No. _It says exactly what it says_. People have been thinking lots about the fun part of the problem, thinking superficially about what they'll have fun implementing. Not about the complete problem space. Not about what hits users. Not about what we need for a saner implementation. even just a list of use cases that you believe have been overlooked. Ah... - ENOSPC? - Backwards compatibility? (Horrendously broken ATM on 0.84 -- I have a bad patch for that...) - Integration with GNOME? (for those dual desktop OS builds) - Some reasonable degree of atomicity? - Sensible backup/restore? - Smarter handling of bundle filetypes... = so together with the Journal, it can expose the many images or videos in a 'Record' = so the Record file format gets untangled - Re-thinking of the Journal / Datastore interactions to access the normal filesystem so that Gnome's ~/Documents directory can be browsed -
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
You are not explaining why this will happen, so this point is moot. The reason is that it seems that it is impossible to do. I just extrapolated historical data. So we're indexing the data automatically, but we still don't have a datastore? Please explain how that would work. The Search activity's data is the generated index. And we want users to have to start other applications to find there stuff *why*? From what I can tell, the trend in the mobile space has been to unify searching across formats, a la the iOS's Spotlight. Exactly. Launch Pictures to handle pictures and launch Write to handle documents. You can have unified search across formats just not unified object handling (display, delete, etc). You'll be breaking backwards compatibility with every previous Sugar version (from what I can tell by your description), and rather than requring us to rewrite the Journal every so often in Sugar, each activity maintainer will have to rewrite it themselves. Now here is the interesting part. You already break compatibility. If there is shared code between these activities (since most cases involve similar models of data storage) we'll have to patch each individually, rather than a shared library. That is the point, to not have shared DS code other than some library what would be included in every activity which would provide some data to search or other activities. Most activities will not have such data. The few activities which would have such DS could be updated individually without breaking compatibility. They could be developed individually *when* *the* *need* *arises*. Now all that said, the Android model is overkill. Something much-much simpler could work IMHO. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
2010/6/10 NoiseEHC noise...@freemail.hu: It seems that I cannot stop myself killing some kittens: Well. Do kill some metaphorical kittens but... maybe... try to avoid being a /perfect example of CADT/. Or maybe it's a good joke and I need to relax ;-) 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] Hypothetical sugar-0.90 material, draft 1.
On Thu, Jun 10, 2010 at 02:28:01PM -0400, Martin Langhoff wrote: On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: In my view, OLPC's ARM announcement creates a pressing problem of avoiding total confusion and fragmentation between different CPU architectures. 0install is, in my view, the most promising candidate solution. I agree that the problem of multiple arches exists. But you can refer to the lengthy thread about 0install about the nasty tradeoffs involved. No intention to rehash a controversial topic here :-) No intension to fallback to another useless discussion. Just want to synchronize what other people think with what I'm thinking they think. --- So, what the object... The code: 1.1) Sugar Platform dependencies i.e. bunch of required libraries/applications like glibc and xulrunner etc. 1.2) Sucrose 1.3) Sugar Objects (to not separate to activities and documents, since some time it is hard e.g. TA objects or Etoys projects). 1.4) Sugar Objects dependencies that are not part of Sugar Platform could be various libraries or activities (e.g. TA for TA objects) Who might distribute this code: 2.1) GNU/Linux distribution from native packages 2.2) sugar deployments like OLPC that use the same mechanisms like distros but provide additional packages/QA/support efforts 2.3) directly from creator Where this code could be used: 3.1) on XO deployed by particular distributor with sugar installed 3.2) on regular GNU/Linux desktop with some kind of sugar support About subject... I hope I won't be failed if say that ideal sugar user is doer. --- And most popular scheme should be 1.3(4) - 2.3 - 3.*. In most cases for Sugar Objects and in less cases for activities (but still important) and its dependencies (like if some one created convenience math library). Trying to push this flow via 2.1 (less in 2.2) makes the flow much smaller. And tool like 0install lets us follow 2.3. At the same time 0install is not intended to cover all possible variants i.e. not lets switch all sugar deployments to 0install. For example for all sugar deployments regular GNU/Linux distribution way is more preferable. One of core benefits of 0install is that is lets us reuse 2.1 and 2.2 e.g. if someone tying to launch Vnc activity, sugar will popup window with suggestions to install native vnc package. --- Back to original purpose of this post, are people who disagree with 0install (which is just an instrument), are disagree with particular instrument or with 1.3(4) - 2.3 - 3.* scheme itself (or think it is not so important to make not trivial things to rich it). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 08, 2010 at 12:54:01AM -0400, Michael Stone wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit My current workflow is not targeting to soon inclusion to the core but if people think it will be useful to start 0sugar and polyol integration from 0.90 and keeping in mind API/ABI starting from Jul 19 2010 I can guaranty: * support requires tag in activity.info to fetch 0install dependencies for activities, this feature will be especially useful after adding PackageKit to sugar core dependencies to try install dependencies from native packaging system at first. * initial polyol release with python binding that will be backward compatible with current sugar-toolkit (well, just an initial try). So, having these things, 0.90 will be less stable then 0.88 is. 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On 8 June 2010 05:54, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction After some debate on what exactly I should be doing, I've decided that it's both prudent and relatively easy to make that abstraction layer after all. Since I last used it, pywebkitgtk's API has grown much closer to hulahop's, so a snippet similar to this one http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works for both hulahop and pywebkitgtk. I will be going forward trying to remove all hulahop xpcom imports from Browse, effectively writing a complete hulahop backend for my abstraction layer. After that, I'll implement the pywebkitgtk backend. 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael ___ 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] Hypothetical sugar-0.90 material, draft 1.
Hi Lucian, On Wed, Jun 9, 2010 at 1:30 PM, Lucian Branescu lucian.brane...@gmail.com wrote: On 8 June 2010 05:54, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction After some debate on what exactly I should be doing, I've decided that it's both prudent and relatively easy to make that abstraction layer after all. Since I last used it, pywebkitgtk's API has grown much closer to hulahop's, so a snippet similar to this one http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works for both hulahop and pywebkitgtk. I will be going forward trying to remove all hulahop xpcom imports from Browse, effectively writing a complete hulahop backend for my abstraction layer. After that, I'll implement the pywebkitgtk backend. I found some more information about the changes Mozilla is planning for XPCom in gecko2. Each week they have a platform meeting [1] and the notes generally have good information about what's going on there. In this weeks meeting [2] they covered some upcoming changes to XPCom [3] so you might find more useful information there. Cheers, Peter [1] https://wiki.mozilla.org/Platform#Meetings [2] https://wiki.mozilla.org/Platform/2010-06-08#Electrolysis [3] https://bugzilla.mozilla.org/show_bug.cgi?id=568691 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Mon, Jun 7, 2010 at 9:54 PM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel sverma: A healthy dose of input from educators. 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] Hypothetical sugar-0.90 material, draft 1.
El Wed, 09-06-2010 a las 13:30 +0100, Lucian Branescu escribió: After some debate on what exactly I should be doing, I've decided that it's both prudent and relatively easy to make that abstraction layer after all. Since I last used it, pywebkitgtk's API has grown much closer to hulahop's, so a snippet similar to this one http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works for both hulahop and pywebkitgtk. To simplify our dependencies, couldn't you also fold hulahop into WebView, or vice-versa? As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. -- // 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] Hypothetical sugar-0.90 material, draft 1.
Folding hulahop into this abstraction layer could possibly make sense. Let me finish it first, though. Hulahop has a lot of weird code and a lot of XPCOM magic. Both pywebkitgtk and hulahop have very similar WebView classes. My wrapper now offers some extra methods for engine-specific bits and a few utility functions, but very little is added to the base WebView classes. On 10 June 2010 01:11, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 09-06-2010 a las 13:30 +0100, Lucian Branescu escribió: After some debate on what exactly I should be doing, I've decided that it's both prudent and relatively easy to make that abstraction layer after all. Since I last used it, pywebkitgtk's API has grown much closer to hulahop's, so a snippet similar to this one http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works for both hulahop and pywebkitgtk. To simplify our dependencies, couldn't you also fold hulahop into WebView, or vice-versa? As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. -- // 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] Hypothetical sugar-0.90 material, draft 1.
SocialCalc depends of hulahop. My activity Elements too. Gonzalo On Wed, Jun 9, 2010 at 9:11 PM, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 09-06-2010 a las 13:30 +0100, Lucian Branescu escribió: After some debate on what exactly I should be doing, I've decided that it's both prudent and relatively easy to make that abstraction layer after all. Since I last used it, pywebkitgtk's API has grown much closer to hulahop's, so a snippet similar to this one http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView already works for both hulahop and pywebkitgtk. To simplify our dependencies, couldn't you also fold hulahop into WebView, or vice-versa? As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. -- // 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 -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2010 08:11 PM, Bernie Innocenti wrote: As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. Actually, hulahop is used by pyjamas[1], as evidenced by these bug reports[2][3] spawned when sugar-hulahop was removed from Ubuntu Lucid. An aside, according to upstream this is not an integral part of their project, but it might be a good idea to involve them in the discussion. Going forward, Canonical is trying to get rid of most of the XULRunner embedders, which prompted the removal of hulahop in the first place. [1]: http://pyjs.org/ [2]: https://bugs.launchpad.net/ubuntu/+source/sugar-hulahop/+bug/573772 [3]: https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/567819 - -- Luke Faraone http://luke.faraone.cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwQVlAACgkQtrC51grHAgb7YgCfRlH21+1DE8AC+FtELPb/SBCj TmYAnje4sTwEszm5vTNXPbuKRq+L0atG =3/M3 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
2010/6/9 Luke Faraone l...@faraone.cc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/09/2010 08:11 PM, Bernie Innocenti wrote: As far as I know, Browse is still the only hulahop user on this planet, so it's not like we need to keep it around for API compatibility. Actually, hulahop is used by pyjamas[1], as evidenced by these bug reports[2][3] spawned when sugar-hulahop was removed from Ubuntu Lucid. An aside, according to upstream this is not an integral part of their project, but it might be a good idea to involve them in the discussion. These days, I do my work in pyjamas - on the cloud. I have never used pyjamas on the desktop, but for people who do, hulahoop* was the least painful way to get there, and its removal sparked indignation. *OK, it's called hulahop, but this way all the code names mesh more surreally. Seriously, though: the fact that pyjamas-desktop can exist without hulahop doesn't make it attractive to lose it. It may not be integral, but I don't see anybody in the pyjamas world who would be replacing it any time soon, so it is essential as a practical matter. Jameson ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) Bernie gather more rumors this weekend in an impromptu meeting in IRC. Not sure where the log is, but the list is similar. 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 12:54 AM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here I'll also write up a Feature page for Multiple Home Views (e.g., my math class home view, my home home view, etc.) -walter Comments? Additions? Substitutions? Deletions? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Tue, Jun 8, 2010 at 5:54 AM, Michael Stone mich...@laptop.org wrote: Hi folks, Under the temporary working hypothesis that we want to make a Sugar release in a couple of months, I'd like to know more about what we might find ourselves integrating. Here's my current list of, er... mostly unvetted rumors. :) 1. Aleksey: 0install integration, Vala-based sugar-toolkit 2. Sascha: versioned datastore 3. Tomeu: collaboration refactoring 4. Gary + Christian: alternative activity launch UI 5. Michael: git repo reorganization and build system rewrite 6. Gary + Scott: preliminary touch-related UI tweaks 7. Raul: rainbow 8. Esteban: virtual keyboard 9. Lucian: browser abstraction 10. Martin L.: polish 11. Walter: write to journal any time 12. Simon: dotted activity versions 13. Walter: enhanced color selector 14. Jorge + Martin A.: journal backup + restore 15. Andres: journal entry sorting 15. you: your patch series here Comments? Additions? Substitutions? Deletions? I would also like to add an item regarding making sure the 0.90 release works properly with all the upcoming changes (deprecations being the big one) for the gnome-3 release. In 0.88 for Sugar on a Stick we saw the start of these issues with the issues with Read, its possible this could only get worse over the next 6 months. It would also be worth looking at things like dconf for the things that are currently stored in GConf. It would be worthwhile updating the default jhbuild config to reflect the gnome minimum versions covering the usual gnome suspects and gstreamer / telepathy etc. as that should make it easier for developers to pick up issues over the coming months sooner rather than later. Cheers, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
