Re: [Sugar-devel] sounds in Speak
On Tue, Jul 28, 2009 at 05:48:39PM -0700, Sameer Verma wrote: Hello everybody, This afternoon, I had an interesting conversation with a Montessori teacher, about Speak. She asked me why Speak says a when a is pressed and not the *sound* of the letter a. Montessori teachers teach the shape and sound of letters first, and then the name of the alphabet. I did not have an answer for her, but I wondered if it would be possible to have an option in Speak to do so. not sure it could be done in existed Speak(it just passes string to speak engine). But it could separate activity or mode in Speak which teaches alphabet. I'd imagine that the sound of the letter would vary depending on language, right? cheers, Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ ___ 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] [FEATURE] [DESIGN] Frame Panels
On Mon, Dec 14, 2009 at 03:47:23PM -0200, Tomeu Vizoso wrote: On Sun, Dec 13, 2009 at 03:42, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). I'm having trouble guessing which needs addresses this change. Does this idea come from any need expressed by our users? oh sorry, I denied my feature.. and user who asked for such feature was me the idea was instead of having modular Journal(former name for this feature was, Journal Plugins) I thought that having ala GNOME panels let 3rd party developers integrate theirs activities to shell UI e.g. replacing Journal by replacing Journal icon/in-this-proposal,-panel-component by launcher that starts their activity. But now, I think it(e.g. such Journal customizing) could be done by forking Journal itself i.e. w/o adding complexity like plugins or ala GNOME panels and sharing this fork via 0install. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Frame Panels
On Mon, Dec 14, 2009 at 01:34:38PM -0500, Eben Eliason wrote: On Sun, Dec 13, 2009 at 12:42 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). Frame Panles feature has the same major idea, social context - giving non core developers more freedom in case of releasing/supporting theirs code, e.g. adding GSM modem support could be implemented not in core(thus stuck to sugar version, when previous sugar version users can't grab last changes of GSM modem component) but as a standalone activity(and deployed as a regular activity). Is this an extension of the device concept already present? The idea there was to allow anyone to create devices (in the bottom edge of the frame) that added extended features (such as text-to-speech, additional hardware support, dictionaries, etc.). Having a way to separate these from the core of Sugar, and even add or remove them at will, would be nice. it was more common proposal, ala GNOME panels == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. I'm a bit confused by this. The panels, clockwise from top, are for activities, people, devices, and objects (clipboard). Only the bottom edge is currently thought of as a place for extension. Are you proposing that all of these would be extensible? yup, e.g. could move any predefined components to panel he wants.. i.e. like GNOME panle components == Detailed Description == The major reason is to let activities like FileShare or Chat special UI representation in shell's interface. It could be also useful if user wants fast access to some activities like Journal replacements. I would raise some caution here. The Frame was specifically designed as a place for active elements to live, and is specifically not a launcher. As such, any running activities, current friends, available devices, etc. appear there. Your description of fast access makes it sound more like a launcher and less like a place of status. my intention was to have panel components ala GNOME panel launchers(or even menus) Any of four panels could be stuck i.e. let user see its components all time. This is an interesting idea. yup, I'm also strongly for such feature, despite of accepting panels feature We played with similar concepts early on, but decided at the time that the Frame as more comprehensible as a single unit that could be shown and hidden at will. If we break that paradigm, how do we handle the overlap that a persistent frame edge would cause? Does the activity window move/shrink in these instances? yup, activity windows should be shrunk e.g. like application in GNOME have less free space for maximization after adding new panel. === Predefined components === * rings switch * activities list These are views within the Home zoom level. What's your proposal for making these Frame components? * clipboard * users list Yup, these are the left and right edges, currently. * sources list * network component Are these equivalent to the devices (bottom) edge of the frame? Are you proposing we split them somehow? idea was just to make all existed frame components freely added/removed * notification area I'd much rather see a general notification system built up (we have the beginnings of one already). There are a number of design mockups showing how notifications are bound to the 4 corners of the screen, associated with the 4 edges for activities, people, devices, and objects. notifications would include activity invitations, group invitations, people joining/leaving activities, low battery, lost network, etc. I think these various notifications belong in the context of the respective edges of the frame, instead of in a single area. the major idea was provide common tool - panels and panel components and let 3rd party developers implement what they want e.g. notification area(for example in GNOME, notification area is just another panel component) and make this out of sucrose releases cycle like regular activities. Overall, there are 7 components you've identified here, so it's unclear to me how these map onto the 4 edges of the Frame. == Benefit to Sugar == * let users more freedom to organize sugar shell how they want * provide to activity developers a way to integrate theirs activities * to shell UI(useful for activities that work in background and * requires some kind all-time-present indicator in UI) * having stable API for panel components, activity developers have more * freedom and aren't stuck to core releases e.g. Network * activity/component(analog of NM widget in GNOME) could support * several sugar releases
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. well, thats all true but it doesn't exclude easy to change and easy to share possibility of doer's changes e.g. if I want to hack Journal by adding wallpaper support(and of course want to expose my changes) the worst way that could be is proposing my changes to core team(e.g. think about proposing your patches to kernel.org team - maybe exaggerating but the same level issue). Having ready to use sugarized 0install environment gives developers easy sharing method. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Mon, Dec 14, 2009 at 07:01:26PM -0500, Sebastian Silva wrote: I for one would love to learn a new way to hack on my sugar and easily share patches. If we can do better than jhbuild does (user experience wise), I would love it! yeah, some day we can provide 0install glucose e.g. for testing purposes so, users on any distro can install last development release of sugar by trivial gestures - copy past 0install url and click OK Icarito 2009/12/14 Tomeu Vizoso to...@sugarlabs.org On Mon, Dec 14, 2009 at 17:01, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Dec 14, 2009 at 04:19:51PM -0200, Tomeu Vizoso wrote: On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. well, thats all true but it doesn't exclude easy to change and easy to share possibility of doer's changes e.g. if I want to hack Journal by adding wallpaper support(and of course want to expose my changes) the worst way that could be is proposing my changes to core team(e.g. think about proposing your patches to kernel.org team - maybe exaggerating but the same level issue). Having ready to use sugarized 0install environment gives developers easy sharing method. As I said, I agree with your points of view and also agree something should be done in the path you show. But I also think that presently, what would bring more users and deployers on board, is by caring of their more immediate needs. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- Sebastian Silva Colectivo FuenteLibre http://blog.fuentelibre.org/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Future of Zero Sugar
On Tue, Dec 15, 2009 at 10:16:02AM +0545, Bryan Berry wrote: I strongly agree w/ tomeu on this. Making Sugar easier to contribute to isn't anywhere near the top of the list of requested features by our kids and teachers in Nepal. The far and away most requested feature by teachers in Nepal is a mechanism for kids to turn in homework. I am not talking about invasive testing here. The typical Nepali teacher just wants to know which students out of 50-70 kids are failing to understand basic concepts. I absolutely agree with such points, but: * as a 3rd party developer, I don't see such teachers requests listed somewhere on wiki, that let me see what can I do and peek most interesting/suitable-for-my-skils/etc task * I'm feeling huge discomfort as a developer when I need to package binary blobs to my .xo, w/o instrument which let me unify installing/upgrading process of such non-SP/specific-to-my-activity dependencies * I'm feeling less(but still big) discomfort as a developer when I don't have standard method to share my core related changes, for-testing-purposes/to-show-what-I-have-in-mind, well please, attach my cloned repos, install them still works but not so attractive for users * implementing Zero Sugar initiative, in my mind, is providing fishing-rod for developers/doers instead of feeding users thus has prime priority On Tue, Dec 15, 2009 at 12:04 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Dec 14, 2009 at 11:25, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I agree. I think this has been a central part of the Sugar design philosophy from the beginning. I think your message is very much on the right track. While I think this is in the spirit of my vision for Sugar, my experience with how Sugar is being used and deployed _today_ makes it quite uninteresting and too invasive to consider for the near future. The current barriers for people to contribute to Sugar development and share their work are mostly cultural. We can make the technology a thousand times easier to modify, but if people still think that they can be only users, we won't gain anything. If we really want more people to realize their power and modify sugar and share their work, we need to, in order: - show how the community can address some of their needs, as perceived by them, - show how they can better address the rest of their needs by working within the community. The rest is just icing on the top, IMHO. Regards, Tomeu [snip] * I hope to see many shell forks with implemented features like new sugar themes(wallpapers support, new icons etc.), Actions view implementations from non-core development/doers. The benefit they will have after 0install integration is more useful method to share these forks - just a regular entity on Activity Library that brings new shell to user environment I don't think this part will work as a regular entity on Activity Library, for security reasons. Any Activity that hooks so deeply into the shell is no longer safe to run. It is running with the full authority of the user and can violate the user's privacy or interfere with the user's actions. In orders to encourage users to become doers, Sugar is designed to make sure that Activities are always safe to run (thanks to Bitfrost/Rainbow protections). I would of course support an effort to wall off parts of the shell in a secure fashion, but so far almost no work has been done in that direction. --Ben ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ 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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Sat, Dec 12, 2009 at 11:31:43PM +0100, Martin Langhoff wrote: On Sat, Dec 12, 2009 at 2:00 AM, Aleksey Lim alsr...@member.fsf.org wrote: I've coded[1] initial implementation[2] for standalone 0install mode, w/o any support from shell. So, activity could bundle saccharin module to .xo and maybe 0install pure python library as well(otherwise system should have already installed zeroinstall-injector package, it could be any version - saccharin will update it from the web on the first start). Sounds like a fantastic development. I personally won't be able to review/test/use for a while but as Wade mentions, not needing explicit support from Sugar is a great, and avoids a ton of bootstrapping issues. BTW that's driving me to second evolution of Unified Objects - Journal Plugins - and now, just a Shell Integration API, thanks! I'm going to post corrective message to [FEATURE] Journal Plugins thread.. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Zero-calorie bundles?
On Sat, Dec 12, 2009 at 01:48:19PM -0500, Wade Brainerd wrote: On Fri, Dec 11, 2009 at 8:00 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, I've coded[1] initial implementation[2] for standalone 0install mode, w/o any support from shell. So, activity could bundle saccharin module to .xo and maybe 0install pure python library as well(otherwise system should have already installed zeroinstall-injector package, it could be any version - saccharin will update it from the web on the first start). So, any devs interested in such features are welcome to test it. I'm planing to complete PackageKit integration to 0install and start implementing feeds for ASLO activities that have bundled binary blobs. This is great - as a big user of binary blobs this will relieve a big headache for me. Nice to know it won't require a Sugar update too. Let me know what I need to do to get my activities ported over. I'd like to at least ship the 32bit py2.5 blobs with the activities if possible. In short terms, saccharin is just another UI for 0install infrustracture, so you need just cook proper 0install feed(it could be bundled to .xo or saccharin could use web link to your feed). See [3] for 0install packaging tutorials. There is only one difference - saccharin could use 0install feed not to launch final application(the final target of feed is describing how to install/launch such application) but using feed's dependencies as a activity dependencies[4] (saccharin will just fetch/build/install dependencies and w/o launching feed's application, will run regular activity). But saccharin could be used for launching regular 0install applications as well[5] (it depends on what arguments were passed to injection command). [3] http://0install.net/injector-packagers.html [4] http://wiki.sugarlabs.org/go/Features/Zero_Install_integration#Activity_mode [5] http://wiki.sugarlabs.org/go/Features/Zero_Install_integration#Launch_0install_packages -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] File Share Activity
On Sat, Dec 12, 2009 at 06:28:40PM +, Gary C Martin wrote: Hi Justin, On 12 Dec 2009, at 16:17, Justin Lewis wrote: I am not the author of Bundle. If people would like to test it, fine by me. This was written mainly to get some sort of file transfer system on the olpc. Another reason is on the 84, it seems you have to pick a file and send it to a specific user, where this system lets you pick files and then send them to anyone who has joined. +1! Being able to publish a number of items for download is a very useful feature (imagine a teacher sharing several resources for a specific class lesson). Thanks for stepping up to do this. There has been talk on Journal at some future point providing something similar, but to be honest a really clean/simple/robust activity would be better, why? 1). Journal could be kept clean and simple instead of trying to overload it with multiple types of sharing features (technically possible, but the design will just get more and more unusable until it looks like a Microsoft office product). Well, maybe I wasn't so clear in that question, but the final target of Journal Plugins was 1) technical, make core development process more flexible and 2) social, encourage non core developers to experiment with Journal. And I see what people think about this proposal - fat journal application. At the end I wasn't sure that plugins should work in shell process. One of consequence of 1) is having some kind of shell integration. That could be very useful if activities like that, will be more integrated to the shell UI e.g. this activity will behave like regular GUI downloader, so needs at least notification area integration from shell(or so). I'm going to rename Journal Plugins feature to Shell UI integration.. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] File Share Activity
..and making my thoughts more clear :) On Sat, Dec 12, 2009 at 06:28:40PM +, Gary C Martin wrote: 2). As a separate activity it can be developed out side of the Sucrose development/release cycle and team. that was another reason for Plugins proposal(now Shell Integration API) 3) As a separate activity it can be used by folks not running the latest and greatest version of Sugar (think a generation of hundreds of thousands of kids who use 0.82, and perhaps only ever will). as well -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] Problem Reports
Wade, could you prepare shell agnostic code, it could be utilized in saccharin to report problems while downloading/compiling, so having the same UI would be useful. On Sat, Dec 12, 2009 at 08:47:05PM -0500, Wade Brainerd wrote: Hi all, Here is my feature proposal for Sugar Problem Reports. It's a quick way for users to provide feedback about Sugar. Reports automatically bundle relevant log files, and the PHP log server some simple scraping for Python exceptions, logger.error() calls, etc. The patches are all posted to http://trac.sugarlabs.org/ticket/1439, the wiki page which this content came from is http://wiki.sugarlabs.org/index.php?title=Features/Problem_Reports. Best, -Wade == Summary == The Report a problem control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem. == Owner == * Name: Wade Brainerd * Email: wad...@gmail.com == Current status == * Targeted release: 0.88 * Last updated: October 16th, 2009 * Percentage of completion: 90% == Detailed Description == A new control panel will be added, titled Report a problem. This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server. The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties. When a problem is detected in an Activity, such as failure to launch, Sugar will offer a Report problem button which takes the user directly to the control panel. After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email. == Benefit to Sugar == Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options: * Create a Trac account and enter a bug. * Write an email to sugar-de...@lists.sugarlabs.org. The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem. The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers. The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket. == Scope == A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches. The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-repo...@lists.sugarlabs.org mailing list. ___ 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] [Feature] Problem Reports
On Sun, Dec 13, 2009 at 02:43:57AM +, Aleksey Lim wrote: Wade, could you prepare shell agnostic code, it could be utilized in saccharin to report problems while downloading/compiling, so having the same UI would be useful. btw that could be another point for Shell UI Integration proposal, provide Sugar Problem Reports as a service for activities(despite of target SP version). On Sat, Dec 12, 2009 at 08:47:05PM -0500, Wade Brainerd wrote: Hi all, Here is my feature proposal for Sugar Problem Reports. It's a quick way for users to provide feedback about Sugar. Reports automatically bundle relevant log files, and the PHP log server some simple scraping for Python exceptions, logger.error() calls, etc. The patches are all posted to http://trac.sugarlabs.org/ticket/1439, the wiki page which this content came from is http://wiki.sugarlabs.org/index.php?title=Features/Problem_Reports. Best, -Wade == Summary == The Report a problem control panel provides a way for the user to report issues with the Sugar shell and activities. The control panel uploads system information and logs, along with the user's description of the problem. == Owner == * Name: Wade Brainerd * Email: wad...@gmail.com == Current status == * Targeted release: 0.88 * Last updated: October 16th, 2009 * Percentage of completion: 90% == Detailed Description == A new control panel will be added, titled Report a problem. This panel contains a description box and an Upload report button. When the button is pressed, the description and system logs are uploaded to a central Sugar Labs server. The central server logs the problem reports in a database and stores a copy of the logs. It also analyzes the logs for specific errors (such as Python Tracebacks). When a problem report is added, the server sends an email out to a mailing list of developers and interested parties. When a problem is detected in an Activity, such as failure to launch, Sugar will offer a Report problem button which takes the user directly to the control panel. After uploading, the user is given a Report ID number (a small decimal number). They can use this if they wish to follow up with the Sugar developers by email. == Benefit to Sugar == Currently there is no mechanism for non-technical users to submit problem reports. In order to inform the Sugar or Activity developers of a problem, a user has two options: * Create a Trac account and enter a bug. * Write an email to sugar-de...@lists.sugarlabs.org. The first option is time consuming and requires the user to fill in confusing fields such as Component and Version manually. The second option requires the user to have an email account, and the report is not logged anywhere. Neither option is convenient or provides relevant details about the problem. The new control panel offers a way for casual users to report problems encountered in Sugar. It also supplies a high level of detail about the problem to the developers. The reason problem reports are not added directly to Trac is that we don't want to spam the database with spurious reports. Problem reports are intended to be triaged by subscribers to the mailing list, and then either bugged or noted on an existing ticket. == Scope == A prototype of the control panel and server have been finished and posted to [http://trac.sugarlabs.org/ticket/1439 #1439] as patches. The collection server is currently running at logcollect.sugarlabs.org. Logs are emailed out to the sugar-repo...@lists.sugarlabs.org mailing list. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] create new Sugar SIG group on google groups or lists.sugarlabs.org?
On Sun, Dec 13, 2009 at 08:31:53AM +0545, Bryan Berry wrote: It is time for me to create a mailing list for the Karma SIG. I would prefer to use a google group over using the mailman lists because is it easier to search the google group. What are the pros of using mailman ( lists.sugarlabs.org) over a google group? imho -1, having several places for sugar mls... -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] create new Sugar SIG group on google groups or lists.sugarlabs.org?
On Sun, Dec 13, 2009 at 02:52:05AM +, Aleksey Lim wrote: On Sun, Dec 13, 2009 at 08:31:53AM +0545, Bryan Berry wrote: It is time for me to create a mailing list for the Karma SIG. I would prefer to use a google group over using the mailman lists because is it easier to search the google group. What are the pros of using mailman ( lists.sugarlabs.org) over a google group? imho -1, having several places for sugar mls... and users can use services like http://gmane.org/ and http://www.mail-archive.com/ to search emails from web. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Frame Panels
Hi all, At the end Journal Plugins mutated to Frame Panles feature. All UI visible changes I wanted to implement in plugins could be done via Frame Panle components(the rest of code are shell agnostic). Frame Panles feature has the same major idea, social context - giving non core developers more freedom in case of releasing/supporting theirs code, e.g. adding GSM modem support could be implemented not in core(thus stuck to sugar version, when previous sugar version users can't grab last changes of GSM modem component) but as a standalone activity(and deployed as a regular activity). == Summary == Treat frame as a containers(upper, left, right and bottom) for predefined or custom components i.e. having GNOME panels analog in sugar. == Detailed Description == The major reason is to let activities like FileShare or Chat special UI representation in shell's interface. It could be also useful if user wants fast access to some activities like Journal replacements. Any of four panels could be stuck i.e. let user see its components all time. === Predefined components === * rings switch * activities list * clipboard * users list * sources list * network component * notification area == Benefit to Sugar == * let users more freedom to organize sugar shell how they want * provide to activity developers a way to integrate theirs activities * to shell UI(useful for activities that work in background and * requires some kind all-time-present indicator in UI) * having stable API for panel components, activity developers have more * freedom and aren't stuck to core releases e.g. Network * activity/component(analog of NM widget in GNOME) could support * several sugar releases and previous release sugar users will benefit * from last Network component. * previous sugar release users will benefit from last updates of * predefined components as well == UI Design == * all of four frame panels could be stuck * manage components, way to add-new/remove/move components * components could have shell level key shortcuts == User Experience == * sugar frame as a regular GNOME panels -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Installing ASLO
On Fri, Dec 11, 2009 at 12:02:45PM -0200, Javier Valenzani wrote: I'm trying to install an instance of ASLO following this guide at the Wiki (http://wiki.sugarlabs.org/go/Activity_Library/Devel/Installing#Install_server). I've installed all packages, configured Apache, MySql, clone the repository, etc. I didn't find the script db-create-stub.sh named in the guide. Now i cannot get the application to run. It seems to be a configuration problem, but it has so many configuration files that it's getting really messy. examples for configs are http://git.sugarlabs.org/projects/slo-activities/repos/mainline/blobs/master/aslo/config.php http://git.sugarlabs.org/projects/slo-activities/repos/mainline/blobs/master/aslo/config-local.php these config.php and config-local.php should be placed to site/app/config/ directory. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Feature] activity.info enhancements
On Fri, Dec 11, 2009 at 12:43:56PM -0500, Walter Bender wrote: Summary: It would facilitate the packaging of Sugar activities into RPMs and DEBs if there were additional information available in the activity.info file. Details: In walking the process of creating an RPM of one of my activities with Sebastian Dziallas, who is doing lots of packaging for Fedora and SoaS, we observed that many fields in packages' .spec files could readily be pulled from the activity.info file. A few additional fields would be necessary, such as the following: * a short summary * an URL to the source package * an URL to the activity home page * the required dependencies to run Having such info could be really messy, various distors have various naming schemes, some programs could be splited to several packages etc. If it will be formal info why do not just use regular README/INSTALL/etc files, it it will be formal info, why invent another packaging scheme instead of reusing existed(e.g. 0install as was proposed in [1]). [1] http://wiki.sugarlabs.org/go/Zero_Install_integration None of these additional fields are particularly onerous for an activity developer to provide and it would enable the creation of a script (as part of setup.py/bundlebuilder.py) to do most of the work in creating the .spec file. (I assume .deb has similar requirements to ..rpm). Things are more complex for activities that include binaries and the like, but for the most part, we should be able to greatly facilitate upstream maintenance of our code while asking little more of Sugar developers. None of these additional fields need be required, but their inclusion would make things easier. (This is not a new idea, but one that seems timely given all the upstream interest in Sugar these days.) See: http://wiki.sugarlabs.org/go/Features/Feature_ActivityInfo -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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Scrollbar width
On Thu, Dec 10, 2009 at 03:45:38PM -0500, Art Hunkins wrote: I'm not eager to tinker with Themes - especially a theme persists through other activities in the same session. Does it require reboot to reset changes made to a theme, or do changes only last for the given activity? previously mentioned CartoonBuilder's code, affects only to current process (FWIW, I'm really surprised that gtk.Scrollbar doesn't allow for varying scrollbar width.) Art Hunkins - Original Message - From: Aleksey Lim alsr...@member.fsf.org To: Art Hunkins abhun...@uncg.edu Cc: sugar-devel@lists.sugarlabs.org Sent: Thursday, December 10, 2009 5:00 AM Subject: Re: [Sugar-devel] Scrollbar width On Wed, Dec 09, 2009 at 10:43:49PM -0500, Art Hunkins wrote: I've now got whole-screen scrollbars working well in my music activities, but I'd like to make the bars wider. The automatic settings (as used in most activities) are too narrow for my taste. Can someone point me in the right direction? I guess it's a gtk theme field, so you can just tweak sugar theme for your activity e.g. by redefining it from your gtkrc http://git.sugarlabs.org/projects/cartoon-builder/repos/mainline/blobs/master/theme.py#line108 or so But not sure its worth doing, I mean having different metrics for standard widgets for various activities. -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Tue, Dec 08, 2009 at 10:05:30AM +0100, Simon Schampijer wrote: On 12/07/2009 01:09 PM, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I prefer to have a plugins over activities - here I agree. Do you have a layout of the plugins structure already? How much code/how invasive is it? iiuc, new feature should be included to new release cycle before starting development process, so I don't have detailed plan for plugins structure, but I guess it should mean at least refactoring of existed Journal code and I also think to include remote objects to model abstraction. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO Google result displays Mozilla description
On Wed, Dec 09, 2009 at 11:37:18AM +1100, James Cameron wrote: On Tue, Dec 08, 2009 at 10:55:47PM +0100, Sean DALY wrote: Activities for Sugar Customize Firefox, Thunderbird, and other Mozilla products with thousands of free extensions and themes. activities.sugarlabs.org/ - the above appeared in results of a Google search... does anyone know how the old Mozilla text can be changed? Sure. It is in the page HTML. If you view source, you'll see it: meta name=description content=Customize Firefox, Thunderbird, and other Mozilla products with thousands of free extensions and themes./ thanks for catch, I've fixed meta tags You might like to review the other meta tags too. -- James Cameron http://quozl.linux.org.au/ ___ 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] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote: On 12/07/2009 05:58 AM, Aleksey Lim wrote: On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Limalsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description Generally the idea of plugins is interesting - it always adds extensibility and make parts exchangeable. In the Journal case it is the support for different pluggable views. Looking just at the idea: great! Let's take a concrete example of a scenario with different views that is floating around: the action/object view. While there have been some pros for the change to have these two views, the implementation could be done using plugins or not. From a technical point of view: while having to change code it might be a good moment to add a plugin structure. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. I agree with Tomeu in the question: has this Feature of pluggable views been asked by the community?. well, this feature is not final users targeted, it's just about making development process more flexible. In the arguments we list: encourage developers to create new views. How many deployments will write their own view because they miss a Feature? As a deployer I would ask myself: When writing my own view I am off the mainline track. No support from
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote: On Mon, Dec 07, 2009 at 12:09:59PM +, Aleksey Lim wrote: Sorry I didn't enter into the other discussions about your features yet; I'm having quite a hard time understanding most of what you write. Would be nice if you could try to be more elaborate and explain your use cases and goals in more detail as that is likely to increase my understanding. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. What did you copy most of the time? UI code or backend? If the latter, why? I.e. in which way was the data store API insufficient for your activity? UI, since I had the same widgets(activity, stared icons, list widget etc), lazy model and shell code to launch objects, edit them etc So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. No, it will just raise exactly the same concerns again that were the reason for including such restrictions in Bitfrost/Rainbow, leading to exactly the same solutions (only certain combinations of rights granted by default; elevated privileges by using signed builds or explicit user configuration). According to [1], those restrictions where never actually implemented. So when they are, we can take the use case Data store explorer into account and see whether there's anything we could do differently to address it. No need to design a new API to work around it, especially given it's a deliberate design decision. as I said, we can improve shell API, it will let activities launch Journal objects, having default list widget, default propery dialog, model for lazy displaying, model could provide source abstraction as well(e.g. could be useful to browse remote Journal objects, not only local or having subset of local/remote objects) There will always be a way for the _user_ to gain full control (*) and thus grant any privilege to any activity, BTW: [2]: No lockdown Though in their default settings, the laptop's security systems may impose various prohibitions on the user's actions, there must exist a way for these security systems to be disabled. When that is the case, the machine will grant the user complete control. [1] http://wiki.laptop.org/go/Bitfrost#Current_Status [2] http://wiki.laptop.org/go/Bitfrost#Principles (*) At least from the upstream side. Any computer can be locked down to prevent the user from tampering with it (which again can be broken with enough sophistication from the user), there's nothing we can do about it. Whoever disables root access etc. is likely to disable Journal plugins and similar elevated rights as well. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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] [FEATURE] [DESIGN] for Journal Plugins feature
On Mon, Dec 07, 2009 at 01:24:14PM +, Aleksey Lim wrote: On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote: On Mon, Dec 07, 2009 at 12:09:59PM +, Aleksey Lim wrote: Sorry I didn't enter into the other discussions about your features yet; I'm having quite a hard time understanding most of what you write. Would be nice if you could try to be more elaborate and explain your use cases and goals in more detail as that is likely to increase my understanding. Well, I guess there are two obvious ways, coding pure activities or having several views(somehow) in core. I tried 1st way while developing Library activity in 0.84 release cycle and, at the end, I realized that I copy/pasted much code from the shell, so tried to reimplement shell. What did you copy most of the time? UI code or backend? If the latter, why? I.e. in which way was the data store API insufficient for your activity? UI, since I had the same widgets(activity, stared icons, list widget etc), lazy model and shell code to launch objects, edit them etc So, we can just extend shell public API but there could be another issue - security reasons. I heard about plans to restrict activities in case of searching/changing/removing objects that were not created by this activity. Having special API(and plugins) could soften situation then. No, it will just raise exactly the same concerns again that were the reason for including such restrictions in Bitfrost/Rainbow, leading to exactly the same solutions (only certain combinations of rights granted by default; elevated privileges by using signed builds or explicit user configuration). According to [1], those restrictions where never actually implemented. So when they are, we can take the use case Data store explorer into account and see whether there's anything we could do differently to address it. No need to design a new API to work around it, especially given it's a deliberate design decision. as I said, we can improve shell API, it will let activities launch Journal objects, having default list widget, default propery dialog, model for lazy displaying, model could provide source abstraction as well(e.g. could be useful to browse remote Journal objects, not only local or having subset of local/remote objects) another featrure whic could be useful is UI integration with shell, ObjectChooser integration, having fast method to access to such plugins/activities(not only from activity tray, could keys or so) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88
On Sun, Dec 06, 2009 at 02:37:07PM +0100, Simon Schampijer wrote: On 11/28/2009 05:00 AM, Aleksey Lim wrote: Hi all, Hi Aleksey, thanks for proposing this feature! http://wiki.sugarlabs.org/go/Features/TableView_Widget GTK widget to replace gtk.TreeView in Journal. Benefit to Sugar Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders(like gtk components), introduced component uses widgets instead(could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us). Can you elaborate on this? Instead of using the cell renderers to draw the data in the tree model we would pack widgets? we should just implement Cell class(regular wigdet) and it will be used for all(visible) cells, see example http://wiki.sugarlabs.org/go/Features/TableView_Widget#Simple_example_for_SmootTable_widget Benefits we have for such scheme: Can you describe the benefit for a user? Faster scrolling? I meant here only developers, for users it could have only disadvantages :) if we have many visible cells at the same time, but in our case it should be ok, I tested thumbs view on XO-1 and didn't see lags * coding cells is more useful by using widgets then renders, we can reuse our existed custom widgets instead of coding sugarized cell renders * in some cases its hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar Don't we use the gtk.ProgressBar already? not for TreeView, it uses progress render Or do you mean it would just look better? Our cells will look like other widgets(since cells are the same widgets) and we won't have to sugarize renders' theme(e.g. in exsited code, we have not fully sugarized pregress renders) There is an ongoing discussion in gnome community about replacing GtkTreeView, not sure if new widget is ready to use for 0.88 and since Journal's view widget is pretty simple we can use our own simple implementation(360 lines of code). Do you have pointers to the GNOME discussion? I found that snippet from someone having the same problem: http://www.mail-archive.com/gtk-app-devel-l...@gnome.org/msg12127.html Better to ask tomeu, I heard about GNOME discussion from him I guess better for us will be switching to GNOME implementation when it's ready(for now we can use as simple as possible lazy view implementation and imho proposed widgets meet that) Do you have written some code already? The model less widget is fully implemented, in case of model, current code has TableView class which uses gtk.TreeModel. Exact model scheme will depend on what we will use in Journal -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Sun, Dec 06, 2009 at 11:56:09PM +, Gary C Martin wrote: On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote: 2009/11/27 Aleksey Lim alsr...@member.fsf.org: On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) Can anyway relate these benefits from actual requests from deployments? I think this is something that would be good to do in Sugar at some point, but I'm not convinced we are yet in the best moment for that. I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters. The core idea of plugins is exactly to avoid situation when we have to release fat UI change set, plugins let us decentralize existed scheme when entirely sugar design(not only UI) depends on what core team thinks. We just provide usable toolset developers cold use to implement what they think. [1] proposes UI changes in [2] but plugins API could be implemented w/o any UI changes at all - user will see the same Journal(but it will be Journal plugin). The idea is let developers make plugin out of sucrose release cycle, yeah developers could do it in pure activities(but see [3]) and even out of sugar at all, but imho it will be useful(in all cases, not only technical) to initiate/support/organize such process from core. [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Actions request for inclusion to 0.88
Hi all, I've created a stub feature page[1] for actions metaphor. Could someone, who are original initiators(or have ideas) of this feature, tweak wiki page to cover all workflows that they have in mind for Actions in Journal. [1] http://wiki.sugarlabs.org/go/Features/Actions -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion when user deletes activity instead of activity objects but having [5], by default, all object sets could not contain activity object except special activity views that can make activity removing more explicit for users * shouldn't be invasive in case of codding [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles How its invasive: * codding shouldn't be invasive Summarising above text, I think we can start implementation of these features in 0.88 release cycle(but we shouldn't implement the final workflows and make only initial steps e.g. in case of Actions). So, what community thinks about how such features could be invasive to users workflows and codebase and how it could(invasive changes) be reduced. [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
(oops, wrong subject) Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion when user deletes activity instead of activity objects but having [5], by default, all object sets could not contain activity object except special activity views that can make activity removing more explicit for users * shouldn't be invasive in case of codding [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles How its invasive: * codding shouldn't be invasive Summarising above text, I think we can start implementation of these features in 0.88 release cycle(but we shouldn't implement the final workflows and make only initial steps e.g. in case of Actions). So, what community thinks about how such features could be invasive to users workflows and codebase and how it could(invasive changes) be reduced. [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
..to continue summarising.. In fact, all proposed features are not about increasing complexity but about decreasing for floor level - user all time works with sugar objects(activities, activity objects, foreign object etc) but from different views. And let developers/deployments/teachers increase/localize complexity for their needs - coding/forking/tweaking existed/new view plugins. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Thu, Dec 03, 2009 at 12:23:37AM -0500, Eben Eliason wrote: On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Gentlemen, alerts do not work with young users. We have to just DTRT, or provide actions that are very clearly different (and even then...). On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Good catch, what about more explicit following user works all time with the same objects but from different views and add Action view as a Journal plugin(and maybe make it default) to [1](technically we need addition data to form actions view but for users it could be the same (as in objects view) objects but organized to actions. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-datastore-0.87.1
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-datastore/sugar-datastore-0.87.1.tar.bz2 == News == * Make reading version file more robust (sayamindu) #1562 * Use gobject_timeout_add_seconds to make power usage more efficient (sayamindu) #1567 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] [REQUEST] Etoys-113
On Tue, Dec 01, 2009 at 09:08:10PM +0100, Bert Freudenberg wrote: On 01.12.2009, at 21:05, Aleksey Lim wrote: On Tue, Dec 01, 2009 at 08:54:26PM +0100, Bert Freudenberg wrote: On 01.12.2009, at 20:42, Aleksey Lim wrote: On Tue, Dec 01, 2009 at 12:34:35PM -0600, dfarn...@sugarlabs.org wrote: On Tue, Dec 1, 2009 at 12:27 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 01.12.2009, at 18:52, Sugar Labs Activities wrote: A Sugar Labs Activities Editor requested further information from you regarding version 113 of your activity Etoys. Aleksey Lim wrote: This activity works with 0.82 as well but previous version was only 0.84. I can't remember releasing the previous version for 0.84 only. And wouldn't marking the new bundle as only for 0.86 give the impression it does not work in earlier releases? OTOH since it is pre-installed anyway it doesn't really matter. If you think marking it for 0.86 only is better, feel free to do so. And since its only startup wrapper maybe it makes sense to keep this activity per sugar release(to not confuse users when they see etoys last version in Home view)? Well I'm confused. Doesn't the updater respect the bundle's update_url? What does the updater have to do with a.sl.o? As of .86 sugar ships with a aslo-updater. The updater pings a.sl.o to see if any new versions of installed activities exist. at the end it depends on what the right version of etoys+etoys-activity (keeping in mind that sugar user can see only etoys-activity version) e.g. 0.82 user can install(since v133 was marked 0.82-0.86) v133 and will see Etoys-133 in Home view but etoys will be the same(from sucrose-0.82). Except neither 0.82 nor 0.84 pay attention to a.sl.o. Only 0.86 does - that's when the new updater was introduced, right? but user can install activity manually from ASLO And ASLO hides versions based on the browser's user-agent? Is this documented anywhere? it was mentioned in [ASLO] announce email We should move this conversation to sugar-devel ... the full picture is, there are two methods to install activity from ASLO: * ASLO updater which was introduced in 0.86, it checks all locally installed activities for updates on ASLO by passing bundle_id and sugar version(so ASLO, using activities SP range, returns last versions for proper SP) * any user can manually install activity version * all fast Download buttons let user download proper(to his SP, assuming what activity developer filled to SP range for particular version) activity version(ASLO calculates SP version from useragent string) * user can download any version from activity history page (page has relevant warning) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sharing question
On Mon, Nov 30, 2009 at 08:35:42AM -0500, Walter Bender wrote: I have a new activity (http://activities.sugarlabs.org/en-US/sugar/addon/4246) to which I am about to add sharing. It will hat be pretty straight forward in terms of simply exchanging game state and mouse clicks, but I want to be able to let people join in two different ways: as a cooperator or as a competitor. (We have had a few games where people are automatically put into observer role, by joining late, but I cannot think of any instances where we offer this choice when joining.) Ideally people should be able to choice what group to cooperate with as they join. I guess we already have such groups - in Net View, users with shared activities. Seems to be mostly a UI issue, but is there any mechanism in your recent work that would support this? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 12:34:45PM +, Daniel Drake wrote: On Fri, 2009-11-27 at 22:16 +, Aleksey Lim wrote: Hi all, While preparing new 0.88 features, I encountered some in consistence in activities vs. activity bundles case, so I'm going to reveal Activity as regular objects(see [1] ml thread) feature but make it less invasive in case existed user experience. http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object I feel that this is quite a fundamental change to the Journal philosophy. Until now, the Journal is something that record what the user has done, and it only stores the work (or history) of the users session within the activities. In tune with this, the Journal is empty when you start for the same time. This would no longer be the case with this feature. Well, I'm sure we should start such rethinking sometime since we don't have any native sugar shell workflow for forking/changing activities (imho having such workflow could be very useful to encourage tweaking existed activities in the field). And we can start from small steps like proposed feature. I think this topic needs larger forward-thinking discussion. Personally, I prefer the concept of the Journal for what it is now. The major reason for this feature is eliminating confusion when: * theres are activities(in Home view) and activity bundles(in Journal) * user can remove bundle from Journal and activity will be preserved(and vise versa) * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal I guess it depends on the UI, but I worry this would actually add confusion. Users would be prone to accidentally deleting the activity installation from their Journal when they think they are just deleting some work they have done in that activity. I guess it relates to another forkflow which is proposed by [2], bookmarks from [2] is just a set of objects(I think it could be useful e.g. having fast method to access to some tricky query or for sharing objects from bookmarks, to not share all objects), so user can delete/change object from bookmark or from full Journal View and that shouldn't confuse him(I hope) if he will keep in mind that he is working with the same object(but from different views) all time. In that case, having Home view(which is not just another view) and Journal with bundles could be really confusing. [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 02:54:49PM +, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 12:34:45PM +, Daniel Drake wrote: On Fri, 2009-11-27 at 22:16 +, Aleksey Lim wrote: Hi all, While preparing new 0.88 features, I encountered some in consistence in activities vs. activity bundles case, so I'm going to reveal Activity as regular objects(see [1] ml thread) feature but make it less invasive in case existed user experience. http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object I feel that this is quite a fundamental change to the Journal philosophy. Until now, the Journal is something that record what the user has done, and it only stores the work (or history) of the users session within the activities. In tune with this, the Journal is empty when you start for the same time. This would no longer be the case with this feature. Well, I'm sure we should start such rethinking sometime since we don't have any native sugar shell workflow for forking/changing activities (imho having such workflow could be very useful to encourage tweaking existed activities in the field). And we can start from small steps like proposed feature. I think this topic needs larger forward-thinking discussion. Personally, I prefer the concept of the Journal for what it is now. The major reason for this feature is eliminating confusion when: * theres are activities(in Home view) and activity bundles(in Journal) * user can remove bundle from Journal and activity will be preserved(and vise versa) * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal I guess it depends on the UI, but I worry this would actually add confusion. Users would be prone to accidentally deleting the activity installation from their Journal when they think they are just deleting some work they have done in that activity. I guess it relates to another forkflow which is proposed by [2], bookmarks from [2] is just a set of objects(I think it could be useful e.g. having fast method to access to some tricky query or for sharing objects from bookmarks, to not share all objects), so user can delete/change object from bookmark or from full Journal View and that shouldn't confuse him(I hope) if he will keep in mind that he is working with the same object(but from different views) all time. In that case, having Home view(which is not just another view) and Journal with bundles could be really confusing. [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model In fact it(user all time work with the same object but from different views) is the same intention as [3](user all time work with the same type of files out of sugar environment). [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:50:59PM +, Aleksey Lim wrote: On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. I have not followed the discussions on 0install, but it surprises me that this should be mandatory - I always considered 0install as comparable to a distribution. afaik there is no plans to switch to 0install, in my mind its an edition[1] to existed scheme(but if we accept this feature we should have 0install injector library in SP), so using 0install dependencies we won't extend Sugar Platform too much [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary btw 0install could install native packages as well, the reason to use 0install(instead of another distro agnostic method to install distro packages) is that w/ 0install we can install packages that are not well packaged and activity specific binaries. [2] http://0install.net/tests/Gimp-native.xml I might loose interest in Sugar if 0install becomes integral part of core Sugar. But that's another discussion. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Mon, Nov 30, 2009 at 03:10:29PM +, Aleksey Lim wrote: On Sun, Nov 29, 2009 at 05:50:59PM +, Aleksey Lim wrote: On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. I have not followed the discussions on 0install, but it surprises me that this should be mandatory - I always considered 0install as comparable to a distribution. afaik there is no plans to switch to 0install, in my mind its an edition[1] to existed scheme(but if we accept this feature we should have 0install injector library in SP), so using 0install dependencies we won't extend Sugar Platform too much [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary btw 0install could install native packages as well, the reason to use 0install(instead of another distro agnostic method to install distro packages) is that w/ 0install we can install packages that are not well packaged and activity specific binaries. [2] http://0install.net/tests/Gimp-native.xml oops, looks like it only starts applications not install them but imho could be useful too I might loose interest in Sugar if 0install becomes integral part of core Sugar. But that's another discussion. -- Aleksey -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? My point was, that we do not have to be backwards compatible at all costs (this was a general assumption). Thanks, Simon ___ 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] [Systems] aslo - CDN
On Mon, Nov 30, 2009 at 02:17:20PM -0500, Bernie Innocenti wrote: [cc += sugar-de...@] On Thu, 2009-11-26 at 08:44 -0600, dfarn...@sugarlabs.org wrote: Many people have access to the upload directory. We could mitigate this by using separate groups. We already use a soas group for soas. Besides, do the activity authors still need to upload source tarballs here? Couldn't this be done with Remora? yup, I thought to add such functionality after getting rid of fructose but it could be implemented anyway If not, couldn't we set release tags on Gitorious and download the tarballs from cgit? I know release tarballs sometimes contain more files than just a git snapshot, but it would work for most activities. My thought is to start moving towards a staging directory layer. Individuals will have assess to specific staging directories. From there, a cron job can sync from staging/ to downloads/ . If the script just moves the files over without any additional checking, security would remain unchanged. One possibility is requiring all files to be gpg signed by the author, but this makes things quite complicated: most developers do not seem to be familiar with gpg, and we'd still have to come up with some fancy ACL system based on the gpg key. It would be much easier if Remora could be configured or extended to distribute all our source tarballs too. -- // 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 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 07:58:57PM +, Daniel Drake wrote: 2009/11/30 Wade Brainerd wad...@gmail.com: I disagree that showing activities in the Journal, in addition to activity instances and MIME objects, will cause confusion. Many activities are more like content. Activities can be downloaded, copied, modified, and deleted. In Sugar terminology, Activities are intended to be verbs while Journal objects are like proper nouns. But if an activity is a verb, the object which performs the activity can still be a noun. For example, the word hammer is both a noun and a verb. The noun in the Journal (Hammer.xo) is an object which enables the verb in the Home view (Hammer Activity). It's quite simple. I agree. I find it simple too. I'd have no problem with it. The problem is when you give it to 6 year olds -- do you also expect them to be able to understand this? Have you followed the number of problems caused to deployments by the activity removal feature that was added to sugar-0.82? The children do this because they think they are removing work created with the activity. I think it relates to Low floor no ceiling but we can try to solve such issues for example by having profiles for different age ranges. BTW declaring that The majority of our users are 12 years old or under it could be useful to have a voice from teachers(even rather then deployers) while discussing users experience invasive features(or add new features according to teachers feedback). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Mon, Nov 30, 2009 at 07:18:47PM -0500, Walter Bender wrote: On Mon, Nov 30, 2009 at 2:54 PM, Daniel Drake d...@laptop.org wrote: 2009/11/30 Walter Bender walter.ben...@gmail.com: This isn't quite accurate. We've been adding some pre-loaded content to the Journal for quite some time now, Are you sure? Or are you referring to a manual process that you do in certain deployments? I have yet to see a sugar installation that comes with a non-empty journal. And also I can't think of any non-horrible way that you'd be able to hook into the sugar profile creation stages to pre-provide the content, even if I did like the idea. Many deployments are doing this in some fashion or another. It is currently an ugly kludge. This proposal will presumable make it less ugly and less kludgy, but it is undoubtedly useful. and some activities (as you noted, Turtle Art) have been adding content to the Journal as well. This is the only one I'm aware of, and it was a big surprise, to the extent that I filed bugs upstream and downstream that were confirmed by other people who also didn't realise this. I also got the impression from you that you don't feel like it is the appropriate place to put it, you just did it because it is the only option. On the contrary. I don't like it because it is clumsy to implement and manage. Again, this proposal will address that. What I don't like is having to keep my examples in the file system and use a file browser to retrieve them. It turns out that because they are kept separately, people don't find them. well, there is another proposal which was already mentioned here http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model so, with this feature implemented, user can create bookmark My TurtleArt programs(with query by activity id) I could implement my only browser, a la Pippy, but as an activity developer, I would much prefer to use the Journal and I suspect our users would prefer that as well. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] OLPC updates from ASLO
Hi all, AFAIK OLPC will use 0.84 release and will lack of native sugar updater but it could be useful idea to keep activities repository in one place. So, the question is will html page which lists all ASLO activities in microformat enough for OLPC updater. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
On Sun, Nov 29, 2009 at 05:37:44PM +0100, Jonas Smedegaard wrote: On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote: Once 0install support gets merged, Sugar Platform should be enhanced to include build tools (autocrap, c(++) compiler, ...); in that case, activity authors can also rely on the corresponding -dev(el) packages (i.e. libraries, header files, etc.) to be installed as well. I have not followed the discussions on 0install, but it surprises me that this should be mandatory - I always considered 0install as comparable to a distribution. afaik there is no plans to switch to 0install, in my mind its an edition[1] to existed scheme(but if we accept this feature we should have 0install injector library in SP), so using 0install dependencies we won't extend Sugar Platform too much [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Summary I might loose interest in Sugar if 0install becomes integral part of core Sugar. But that's another discussion. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 17:15, Aleksey Lim wrote: On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 07:13, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I like the idea. Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey I'm not sure we are talking about the same thing, though maybe we do - so I'll be explicit: I'm suggesting that activities would contain those plugins for the types they support. got it, but not sure, we can get the same result with preview feature, in preview() every activity can convert its object to image, in my mind its more useful(at least for now) then complicated system with preview plugins. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 04:16:30PM +, Aleksey Lim wrote: On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 17:15, Aleksey Lim wrote: On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 07:13, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I like the idea. Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey I'm not sure we are talking about the same thing, though maybe we do - so I'll be explicit: I'm suggesting that activities would contain those plugins for the types they support. got it, but not sure, we can get the same result with preview feature, in preview() every activity can convert its object to image, in my mind its more useful(at least for now) then complicated system with preview plugins. [1] is more about adding special UI components, like for Books plugins, add extra columns to object list(author, date etc) or subwidget with preview etc. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 06:59:51PM +0100, Bert Freudenberg wrote: On 28.11.2009, at 17:16, Aleksey Lim wrote: On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 17:15, Aleksey Lim wrote: On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 07:13, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I like the idea. Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey I'm not sure we are talking about the same thing, though maybe we do - so I'll be explicit: I'm suggesting that activities would contain those plugins for the types they support. got it, but not sure, we can get the same result with preview feature, in preview() every activity can convert its object to image, in my mind its more useful(at least for now) then complicated system with preview plugins. That works only if the activity is running. The bundle-provided converter can be run any time, like when downloading a file or from a USB stick. but preview image could be embedded[3] to USB file (if we are talking about objects that activity supports, thus about regular activity objects that have preview field, and not about non-sugar objects) [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] for Journal Plugins feature
On Sat, Nov 28, 2009 at 06:08:53PM +, Aleksey Lim wrote: On Sat, Nov 28, 2009 at 06:59:51PM +0100, Bert Freudenberg wrote: On 28.11.2009, at 17:16, Aleksey Lim wrote: On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 17:15, Aleksey Lim wrote: On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 07:13, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I like the idea. Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey I'm not sure we are talking about the same thing, though maybe we do - so I'll be explicit: I'm suggesting that activities would contain those plugins for the types they support. got it, but not sure, we can get the same result with preview feature, in preview() every activity can convert its object to image, in my mind its more useful(at least for now) then complicated system with preview plugins. That works only if the activity is running. The bundle-provided converter can be run any time, like when downloading a file or from a USB stick. but preview image could be embedded[3] to USB file (if we are talking about objects that activity supports, thus about regular activity objects that have preview field, and not about non-sugar objects) but if we are talking about non-sugar objects(e.g. plain video which could be opened in Jukebox), there could be another issue in having preview plugins that come from activities - security reasons. [1] proposes API for plugins that could/should be well checked for malicious code. But if any activity can leave resident part(preview plugin) in shell which will be started in shell process... [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Examples in Journal (#1585)
On Fri, Nov 27, 2009 at 02:57:01PM +0100, Sascha Silbe wrote: From: Sugar Labs Bugs bugtracker-nore...@sugarlabs.org Subject: Re: #1585 UNSP: need some way to present examples to other activities Cc: b...@lists.sugarlabs.org Reply-To: sugar-devel@lists.sugarlabs.org Date: Fri, 27 Nov 2009 13:48:57 - #1585: need some way to present examples to other activities --+- Reporter: dsd| Owner: tomeu Type: enhancement| Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar |Version: Git as of bugdate Severity: Unspecified| Keywords: Distribution: Unspecified| Status_field: Needinfo --+- Changes (by sascha_silbe): * cc: sascha_silbe (added) * version: Unspecified = Git as of bugdate * status_field: Unconfirmed = Needinfo Comment: IMO examples belong into the Journal as much (or as few, depending on your POV) as activity bundles belong there. Maybe we should hide them in the default view and just show them in specialised ones. Splitting up the Journal into Object and Action views (as already in the designs for a long time) would IMO be a prerequisite for this. I'll boldly set NEEDINFO on this as we need further discussion on the mailing list and designs before we can start working on it. Not sure if its right way to go(some special rules for showing Journal entries), in my mind having common and explicit method is preferable[1]. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
On Fri, Nov 27, 2009 at 06:13:55AM +, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I tweaked Benefit to Sugar section a bit * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea. * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar * encourage developers create new view for different purposes(books, media etc.) * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them) * shared bookmarks is more powerful and useful method of network sharing(in comparing with Send to option) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Examples in Journal (#1585)
On Fri, Nov 27, 2009 at 04:23:02PM +0100, Sascha Silbe wrote: On Fri, Nov 27, 2009 at 02:57:57PM +, Aleksey Lim wrote: IMO examples belong into the Journal as much (or as few, depending on your POV) as activity bundles belong there. Maybe we should hide them in the default view and just show them in specialised ones. Splitting up the Journal into Object and Action views (as already in the designs for a long time) would IMO be a prerequisite for this. Not sure if its right way to go(some special rules for showing Journal entries), in my mind having common and explicit method is preferable[1]. Sorry, I don't understand what you're trying to say. Can you elaborate, please? in [1], hidden examples means just some kind of bookmark(which have query terms to hide other/show-only) and having default set to browse all objects [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ 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] [DESIGN] for Journal Plugins feature
On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote: On 27.11.2009, at 07:13, Aleksey Lim wrote: Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes I like the idea. Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. yup, I had the same in mind, API will let Journal plugin to use query (tags(which include MIME types tags) and search string) to restrict final set of objects That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail. there is another benefit for separate plugins - plugins could be out of sugar release cycle(;P to core maintainers) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Zero Install integresion request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/Zero_Install_integration The reason for this feature is to cover situations * an activity has dependencies that weren't included to the Sugar * Platform * install/build activity specific binaries * run non-sugar applications that are not well packaged to * GNU/Linux distributions Benefit to Sugar * let activity authors use non Sugar Platform dependencies * exclude binary blobs from activity bundles, 0install will let sugar install/build proper blobs for local architecture/OS-environment * having sugar UI to start 0install packages(non-sugar) and having common 0install dependencies, sugar and 0install communities could benefit each other * so, we can replace sugarized activities like TuxPaint and GCOmpris on ASLO by 0install packages(that could be useful for non-sugar users as well) New UI intoduced bu feature: * progress bar for launcher window to download dependencies * progress bar in Journal's column for manual 0install downloads * additional activity palette item if activity has not yet downloaded 0install files * new control panel component #Control panel component http://wiki.sugarlabs.org/go/Features/Zero_Install_integration#UI_changes -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Sugar Bundles request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/Sugar_Bundles One file format to transfer various types of content in/out to/from sugar environment with keeping metadata. In fact, this feature is an end users oriented(technically we not invent super format for various types of content, just unified sugar wrapper). Users all time know that there is only one type of sugar objects, they see it as a Journal item, one file with suffix .xo in non-sugar environments etc. So they need only upload this file to Journal and click to activate it. Benefit to Sugar Out of sugar environment, users know that there is only one type of sugar objects and only thing they should do to activate them is uploading .xo file to Journal and click it. So if one user uploaded Journal object(any type - activity, activity object, content library etc.) to the web, another user can download/transfer-through-many-non-sugar-environments it and open in his sugar environment with keeping all metadata(he will get the same Journal entry). We can also collect users object on public server like ASLO to have server like sharing feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: It seems time to think about the next _big_ technical issue for growing Sugar Labs. Clearly articulating the Sugar Stack. For the last year or so, we have been circling the issue with talk of stable APIs, Glucose, Fructose, and expected dependencies. Last year, we created the release cycle. At first, _everyone_ disagreed with the idea; Release cycles are perfect for _no_one_. Defining the Sugar Stack is going to be nearly as painful, because the 'stack definition' is not going to be perfect for anyone. yeah, but using 0install dependencies[1] should make stack definition issue not so hard(we can include to stack only very common dependencies) Some reasons for defining a stack: 1. Statement of quality. One of the most frequently cited reasons for the glucose, fructose, honey classification is quality. - Glucose is the core stuff. - Fructose is the supported stuff. - Honey is the rest. This is a very valid method of defining layers of the project; Fedora had core and extras, Ubuntu has main and universe, Eclipse has various levels of official-ness, (none of which I can remember) The kernel simply has 'in-tree' and 'out-of-tree'. 2. Statement of synchronisation. In some instances it is desirable for various parts of a project to be tested and release together. - Sugar core is developed according to a release cycle. - Fructose tends to align with the release cycle. - Honey happens 'when it happens.' This is also very valid; Distro all have synchronised releases. The desktop managers all ship a core at distinct release points. Ecplise has its release train. 3. Statement of what is provided. Down streams _need_ to know what applications they can depend on. - Core APIs - Optional things to meet dependencies. Most languages provide for core functionality which can be extended with modules. Apache also is organized as http server and installable modules. Many of the discussion about this have stalled because of confusion over what aspect the stack we are trying to define. As a starting point, I would suggest: 1. That we get rid of the glucose - fructose categorisation. It is overloaded and confusing yup, I like scheme when new activity developer well understands(from beginning) that there is core and his new activity(w/o core, since fructose comes from sucrose release) which uses core functionality. 2. That Quality and synchronisation of activities becomes an Activities Team issue. and ASLO could be useful on that way(featured activities, editors collections etc) and this process is pretty transparent(e.g. we have public aslo@ ml to discuss editros questions) and well visible(all editors changes are accessible right after changes) on ASLO. So, in comparing with fructose scheme(which e.g. involves all distro packagers, since they should package fructose) in case of ASLO we have more flexible method. This shifts the discussion back to the hard problem of how to think terms of 'Sugar-Space' and 'Activities-Space'. Long term projects success depends on external organisation knowing what they can depend on to be part of Sugar. Before starting a holy war The process of articulating the Sugar stack, much the the release cycle, is an evolutionary process. There is no way the anyone could sit down and declare, 'This is what Sugar consists of... and will consist of in the future.' Instead, the stack is a snapshot of agreed upon APIs, libraries, and applications on which downstream activities developers can depend. I suggest that: 1. The development team and activities team work together to start defining the boundary between core and activities. well, from tech POV, its pretty clear - there are core packages and activities that use core API/services/resources 2. All changes to the core and activities boundary should go through the new features (or similar) process. After a few iterations, this process will become as second nature as the release process. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel [1] http://wiki.sugarlabs.org/go/Zero_Install_integration#Download_dependencies_for_sugar_activity -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The sugar stack
On Fri, Nov 27, 2009 at 05:56:42PM +, Aleksey Lim wrote: On Fri, Nov 27, 2009 at 09:55:20AM -0600, David Farning wrote: Many of the discussion about this have stalled because of confusion over what aspect the stack we are trying to define. As a starting point, I would suggest: 1. That we get rid of the glucose - fructose categorisation. It is overloaded and confusing yup, I like scheme when new activity developer well understands(from beginning) that there is core and his new activity(w/o core, since fructose comes from sucrose release) which uses core functionality. 2. That Quality and synchronisation of activities becomes an Activities Team issue. and ASLO could be useful on that way(featured activities, editors collections etc) and this process is pretty transparent(e.g. we have public aslo@ ml to discuss editros questions) and well visible(all editors changes are accessible right after changes) on ASLO. So, in comparing with fructose scheme(which e.g. involves all distro packagers, since they should package fructose) in case of ASLO we have more flexible method. I guess one of major reasons to keep fructose is localization issue (its much easier for translators to have tough set of activities to localize them at first). In my mind its just remains from OLPC scheme(when where is only one developer/deployer). But now, another deployment could have another priority in choosing activities. So translate.sl.o could have several activity sets for various deployers/deployments such we have now only for OLPC. And in addition to such sets, using Featured activities which will be set of featured activities on ASLO(last activity versions). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Sugar Bundles request for inclusion to 0.88
On Fri, Nov 27, 2009 at 06:30:52PM +0100, Sascha Silbe wrote: On Fri, Nov 27, 2009 at 04:40:00PM +, Aleksey Lim wrote: Out of sugar environment, users know that there is only one type of sugar objects and only thing they should do to activate them is uploading .xo file to Journal and click it. What about interacting with non-Sugar environments? What are the workflows for a) Tunneling Journal objects through legacy systems (e.g. USB stick) and b) Exporting Journal objects so legacy systems can read them (i.e. as plain text, HTML, etc.)? thats just a zip with stuctured ascii metadata file(s) so, could be opened and chaged inplace http://wiki.sugarlabs.org/go/Features/Sugar_Bundles#Specification -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
Hi all, While preparing new 0.88 features, I encountered some in consistence in activities vs. activity bundles case, so I'm going to reveal Activity as regular objects(see [1] ml thread) feature but make it less invasive in case existed user experience. http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object The major reason for this feature is eliminating confusion when: * theres are activities(in Home view) and activity bundles(in Journal) * user can remove bundle from Journal and activity will be preserved(and vise versa) * activities could not have bundles in journal(were deleted or its a system wide activity), so user can't copy activity(e.g. to share it via USB stick) using regular shell workflow(Journal) and should be aware of stuff like Terminal Feature declares: * every activity which is accessible in sugar has Journal entry o for activity came from bundles, entry will have .xo's metadata(timestamp, title etc) o for system wide activities, based of /usr directory properties * there is strong linkage between activity in Home view and journal entry, removing activity in one place, removes it from another o in fact, Home view could be treated as a predefined set(with query terms to show only activities) of Journal entries which is viewed in Home plugin * reflect on system wide activities update, Journal entry's metadata will be changed with keeping only one object per activity * reflect on uploading to Journal new .xo version of existed activity, could be: o follow the same forkflow like with system activities, remove previous .xo from Journal or even do not store uploaded .xo at all, on upload, unzip it to ~/Activities and follow system activities way(entry which represent activity) o storing in Journal several versions of the same activity(including system) and on clicking on particular version in Journal, if it its not installed, ask user to upgrade/downgrade activity(to ~/Activities directory) and then start Benefit to Sugar * feature eliminates confusion, e.g. in case of removing activities, when there are activities(in Home view) and .xo bundles in the Journal(that could be absent - .xo deleted, system activity) * let users, that are not experienced in command line applications, copy existed activity(even system) just by draging Journal entry to USB source * since all activities have Journal representation, keep useful information in entry fields(time of installing activity, additional info in description etc.) Except opinions about feature itself, I'm especially interested in reflect on uploading to Journal new .xo version of existed activity part of it [1] http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] TableView Widget request for inclusion to 0.88
Hi all, http://wiki.sugarlabs.org/go/Features/TableView_Widget GTK widget to replace gtk.TreeView in Journal. Benefit to Sugar Standard gtk components are not designed to be lazy. Third party widgets, I managed to find, uses scheme with renders(like gtk components), introduced component uses widgets instead(could have performance penalties, I guess, in common case but we don't have many rows in Journal view, so should be ok for us). Benefits we have for such scheme: * coding cells is more useful by using widgets then renders, we can reuse our existed custom widgets instead of coding sugarized cell renders * in some cases its hard to sugarize cells theme(we still have ugly progress bar for Journal entries), with new widget, we use just gtk.ProgressBar There is an ongoing discussion in gnome community about replacing GtkTreeView, not sure if new widget is ready to use for 0.88 and since Journal's view widget is pretty simple we can use our own simple implementation(360 lines of code). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state
On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas sebast...@when.com wrote: Hi all, with the next SoaS release coming up really soon (final image is supposed to be composed this weekend, release date is Dec 8), there's a new snapshot ready for you. It includes a lot of fixes and smaller adjustments. It's currently only available as a general .iso build, others will presumably follow later. You can get it from here: http://download.sugarlabs.org/soas/snapshots/2/soas06.iso Let us know how it goes and help us debugging and fixing the remaining bugs here: https://bugs.launchpad.net/soas/+bugs A last note, if anybody knows what's wrong with Record, Cairo and F12, Who is the maintainer of Record? It would be a pity to ship BB without that working as its one off the Activities that kids seem to love. What's the issue with Cairo? last time /me patched Record.. and looks like it doesn't work in 0.86 for a long time, so its the right moment to fix 0.86 issues then Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65 and make lightweight Record: * w/o collaboration feature as it was designed in existed Record * it just share records, I'm planing to do the same on Journal level * it just doesn't work well(especially for big files) * w/o gtk.Windows that represent Record's controls, only widgets * using more robust gst scheme I decide to use camerabin[1] gst plugin which is a good option for Record but it doesn't work(stop w/ gst errors on recording) any help from people who are aware of such gst and video recording stuff is appreciated. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-camerabin.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Ooo4Kids in several languages - how to let it appear on aslo?
On Thu, Nov 26, 2009 at 10:37:31AM +, Carlo Falciola wrote: On Thu, Nov 26, 2009 at 09:48, Tomeu Vizoso tomeu at sugarlabs.org wrote: Hi Bastien, On Thu, Nov 26, 2009 at 09:27, Bastien bastienguerry at googlemail.com wrote: Dear all, I just uploaded Ooo4Kids 0.5.1 on aslo: http://activities.sugarlabs.org/fr/sugar/addon/4241 There is an spanish version here: http://download.ooo4kids.org/es/descargar-ooo4kids-xo-intel How to host this spanish version on aslo? Should I make another activity, or is it possible to upload several branches? Thanks for any hint! Has the OOo4Kids team considered using gettext or similar so can ship a single bundle containing several localizations? Eric has told me in #sugar that the reason for this is because each locale takes about 100MB when compressed. If it's not feasible to make the locales smaller, then I would recommend creating different activities, with different activity ids. Regards, Tomeu If I remember correctly, we'd discussed similar issue back in Paris with Bruno about Gcompris additional language packages, those packages where in the same order of magnitude in size. Look a common issue for bigger (in text content) projects not sure if GCompis has the same issue, for now, GCompis activites on ASLO have gettext strings for all langs (I just used activity specific strings from common .po files) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Record rewrite -- was Re: [SoaS] SoaS v2 approaching RC state
On Thu, Nov 26, 2009 at 02:49:31PM -0800, Peter Robinson wrote: On 11/26/09, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Nov 25, 2009 at 12:25:12AM +, Aleksey Lim wrote: On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas sebast...@when.com wrote: Hi all, with the next SoaS release coming up really soon (final image is supposed to be composed this weekend, release date is Dec 8), there's a new snapshot ready for you. It includes a lot of fixes and smaller adjustments. It's currently only available as a general .iso build, others will presumably follow later. You can get it from here: http://download.sugarlabs.org/soas/snapshots/2/soas06.iso Let us know how it goes and help us debugging and fixing the remaining bugs here: https://bugs.launchpad.net/soas/+bugs A last note, if anybody knows what's wrong with Record, Cairo and F12, Who is the maintainer of Record? It would be a pity to ship BB without that working as its one off the Activities that kids seem to love. What's the issue with Cairo? last time /me patched Record.. and looks like it doesn't work in 0.86 for a long time, so its the right moment to fix 0.86 issues then Sorry, I'm a bit stuck with it, my plans were to rewrite Record-65 and make lightweight Record: * w/o collaboration feature as it was designed in existed Record * it just share records, I'm planing to do the same on Journal level * it just doesn't work well(especially for big files) * w/o gtk.Windows that represent Record's controls, only widgets * using more robust gst scheme I decide to use camerabin[1] gst plugin which is a good option for Record but it doesn't work(stop w/ gst errors on recording) any help from people who are aware of such gst and video recording stuff is appreciated. You shouldn't rely on any of the plugins in gst-plugins-bad as most distros won't ship them by default due to either quality or legal issues. I didn't think to rely on -bad, just make fat bundle or use 0instal. Can you look at what apps like cheese use for that sort of thing? since cheese also moving to camerabin... except camerabin, Record is prety simple activity(about collab features, see text above). I posted upstream bug about record errors and going to return to Record developing when at least upstream example will work ok (camerabin bin example from git tree doesn't record as well in my case). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] for Journal Plugins feature
Hi all, Want to know what people think about Journal Plugins feature[1] and particularly that design team think about UI changes[2] involved in this feature. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins# [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] 0depend feature request
On Wed, Nov 25, 2009 at 10:27:57AM +, Thomas Leonard wrote: 2009/11/24 Aleksey Lim alsr...@member.fsf.org: [...] I've just tried simple example[1] with simple feed[2] in system w/o any 0install remains and it fails for the first time[3] but runs ok for 2nd. I missed something in example code or its a unpredictable behaviour (since [3] cailms for missed ROX-Lib dependensy but solve_and_download_impls() should make all downloads)? [1] http://pastebin.be/22131 [2] http://pastebin.be/22132 [3] http://pastebin.be/22133 An async task needs to be a Python generator, which means it needs to include a yield statement somewhere (even if it's never called). Normally key confirmation has to be async because it has to wait for the key information to arrive and it has to wait for the user to confirm. I'll update handler.py so that it doesn't need to be async, but meanwhile just putting yield at the end will fix the problem. thanks, I added yield to confirm_import_feed() and it works fine -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 12:20:15PM +0100, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Most of activities are compatible with several release cycles, so using SP in activity versions adds only confusing b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0. Fixes would go into 115.1, 115.2... c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be 115.0.0. Fixes would go into 115.1.0, 115.2.1... What do people like best? Thanks, Simon ___ 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] Activity Versioning - Dotted Scheme
On Tue, Nov 24, 2009 at 02:21:09PM +0100, Simon Schampijer wrote: On 11/24/2009 01:42 PM, Gary C Martin wrote: Hi Simon, On 24 Nov 2009, at 11:20, Simon Schampijer wrote: Hi, as a follow up on an older thread: http://lists.sugarlabs.org/archive/sugar-devel/2009-October/019939.html - we want to get the versioning sorted in 0.88 for real. So far we came up with these three options: a) The release cycle dependent one: Activities name their activity after the Sugar version they are developed against. If it was released during the 0.88 cycle and developed against 0.88, then it would be 0.88.x. Ok, I do not like that option neither. And the people that have replied, do not neither. Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible. If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support Yes, good point. We should revisit the current activities in Fructose and think if it makes sense to keep them in Fructose. As you said, one point is if an activity has dependencies on the platform itself like Browse (Hulahop). In mind thats wrong way, some activities have non-sugar SP dependencies and can work fine with several SP releases, I guess its better to not add additioanl complexity and use only one source for compatibility info - on ASLO(moreove we have fructose activities on ASLO). BTW for 0.88 can exclude fructose from core packages at all and let deployers decide what should be included to deployments. I propose to go through all Fructose activities and see which one makes sense to keep in Fructose. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fructose - What is it? What should it be?
On Tue, Nov 24, 2009 at 02:57:16PM +0100, Simon Schampijer wrote: Hi, this came up several times now. People where wondering what Fructose is. From the definition it is: The Sugar developers will need some example set of activities with which to demonstrate Sugar. This set is Fructose. The packages in Fructose should be selected to make the resulting environment as impressive as possible for a potential client or user. Packages should therefore be stable, polished, and exercise the widest possible range of features. Fructose may also serve as an example for people constructing their own Activity sets. [1] The current list of activities can be found at [2]. The fructose activities follow the Sucrose development cycle (0.84, 0.86...). This means they follow the freezes, provide source tarballs, need a present maintainer etc. The duties are described at [3]. The activity gets noted in release notes, possibly more attention by the localization teams as revenue. In the end their are downsides and upsides to be part of Fructose. There were some arguing, that only system dependent activities should be part of it (e.g. Browse with the dependency on hulahop). There were some discussions that we would loose the show case activities when an activity would not be part of Fructose anymore. This comes down to packaging, as for rpm packaging one needs to provide the source tarballs and need to follow certain rules. Some distributors may ship the .xo bunles at one point, otherwise probably won't, so it is a good habit to do the source releases. Anyhow, this is a bit of the background. Let's think how we can move forward on this topic. We should do it quickly, to be able to keep the work on 0.88 going. In my mind, the best thing we can do is making clear definition: 1) we have core with strong release cycle * glucose(and its dependencies) * sugar platform(additional dependencies) (core) 2) various sugar activities (the rest of development community) 3) sugar users (the rest of community) Relations between 1) and 2) totally depends on sugar release cycles. Activity developers decide what release cycles they can/should/will support. For activities like Browse it will several activities versions per SP release. Most activities will support several SP release. Relations between 2) and 3) is task for various deployment methods. Since fructose makes sense mostly for users, its content should totally depends on deployers not core. So I can't see the 4rd place for fructose, only as a part of 2). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Zero-install-devel] 0depend feature request
On Tue, Nov 24, 2009 at 10:20:27PM +, Thomas Leonard wrote:
2009/11/24 Michael Stone mich...@laptop.org:
Aleksey wrote:
To have some implementation mockups for next 0install debates,
I've coded how(I'm thinking) 0install integration could be implemented
in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned
repos[2] and follow simple test case[3].
[1] http://wiki.sugarlabs.org/go/Zero_Depend
[2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope
[3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test
Aleksey,
I tried out your patches in a Debian Sid chroot with
zeroinstall-injector-0.42.1-1
installed and got the following exception in shell.log when running your
test
case:
AssertionError: Solver is not ready!
{Interface http://rox.sourceforge.net/2005/interfaces/ROX-Lib: None,
Interface /home/sugar/Activities/Terminal.activity/activity/0depend.xml:
v1 (/home/sugar/Activities/Terminal.activity/activity)}
The problem seems to be that you haven't told the policy object to solve the
feeds. You can do that with
policy.solve_with_downloads()
and maybe in other ways too.
That's right:
- need_download() will do a solve and return True if you're missing
feeds or implementations
- solve_with_downloads() will solve and download any extra feeds it
needs repeatedly until it has all the information it needs
- solve_and_download_impls() will additionally download the selected
implementations afterwards
I've just tried simple example[1] with simple feed[2] in system w/o
any 0install remains and it fails for the first time[3] but runs ok for 2nd.
I missed something in example code or its a unpredictable behaviour
(since [3] cailms for missed ROX-Lib dependensy but
solve_and_download_impls() should make all downloads)?
[1] http://pastebin.be/22131
[2] http://pastebin.be/22132
[3] http://pastebin.be/22133
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] SoaS v2 approaching RC state
On Tue, Nov 24, 2009 at 11:51:55PM +, Peter Robinson wrote: On Tue, Nov 24, 2009 at 9:13 PM, Sebastian Dziallas sebast...@when.com wrote: Hi all, with the next SoaS release coming up really soon (final image is supposed to be composed this weekend, release date is Dec 8), there's a new snapshot ready for you. It includes a lot of fixes and smaller adjustments. It's currently only available as a general .iso build, others will presumably follow later. You can get it from here: http://download.sugarlabs.org/soas/snapshots/2/soas06.iso Let us know how it goes and help us debugging and fixing the remaining bugs here: https://bugs.launchpad.net/soas/+bugs A last note, if anybody knows what's wrong with Record, Cairo and F12, Who is the maintainer of Record? It would be a pity to ship BB without that working as its one off the Activities that kids seem to love. What's the issue with Cairo? last time /me patched Record.. and looks like it doesn't work in 0.86 for a long time, so its the right moment to fix 0.86 issues then -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Tue, Nov 24, 2009 at 03:01:07PM -0500, Michael Stone wrote:
Aleksey wrote:
To have some implementation mockups for next 0install debates,
I've coded how(I'm thinking) 0install integration could be implemented
in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned
repos[2] and follow simple test case[3].
[1] http://wiki.sugarlabs.org/go/Zero_Depend
[2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope
[3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test
Aleksey,
I tried out your patches in a Debian Sid chroot with
zeroinstall-injector-0.42.1-1
installed and got the following exception in shell.log when running your test
case:
Traceback (most recent call last):
File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py,
line 519, in __button_release_event_cb
self._activate()
File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py,
line 531, in _activate
self._resume(self._journal_entries[0])
File /usr/lib/python2.5/site-packages/jarabe/desktop/favoritesview.py,
line 524, in _resume
shell.resume(journal_entry, self._activity_info.get_bundle_id())
File /usr/lib/python2.5/site-packages/jarabe/util/shell.py, line 222,
in resume
launch(bundle, handle, get_icon_color(metadata))
File /usr/lib/python2.5/site-packages/jarabe/util/shell.py, line 238,
in launch
launcher.add_launcher(bundle, activity_handle, color)
File /usr/lib/python2.5/site-packages/jarabe/view/launcher.py, line
185, in add_launcher
zdepend.fetch(zfeed, progress, create_activity, cancel)
File /usr/lib/python2.5/site-packages/jarabe/util/zdepend.py, line 49,
in fetch
downloaded = policy.download_uncached_implementations()
File /usr/lib/python2.5/site-packages/zeroinstall/injector/policy.py,
line 393, in download_uncached_implementations
assert self.solver.ready, Solver is not ready!\n%s %
self.solver.selections
AssertionError: Solver is not ready!
{Interface http://rox.sourceforge.net/2005/interfaces/ROX-Lib: None,
Interface /home/sugar/Activities/Terminal.activity/activity/0depend.xml: v1
(/home/sugar/Activities/Terminal.activity/activity)}
The problem seems to be that you haven't told the policy object to solve the
feeds. You can do that with
policy.solve_with_downloads()
and maybe in other ways too.
yeah, in my testing environment I have remains from previous 0install
sessions
Anyway, after teaching zdepend.py to solve the policy, I ran into into further
trouble because my zeroinstall trust-db doesn't contain the ROX keys.
To deal with this, I think you need to construct the policy object with a
Handler object
http://0install.net/python-api/html/zeroinstall.injector.handler.Handler-class.html
and override its confirm_keys method.
I've pushed new commits with fixed these issues and added cancel button
@Thomas, Rene: is this about right?
Michael
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Non sugar activities on ASLO
Hi all, Non sugar activities we (could)have on ASLO: ++ programs with high sugar integration(journal etc.) + programs that start smooth in sugar environment(sugarised screen mode etc.) - programs that are just absent in GNU/Linux distributions -- programs that present in GNU/Linux distributions In case of '-*' programs we just not follow Occam's razor principle moreover we are splitting education community(people should know that there is native GCompris and sugarized GCompris). On the other side if ASLO intended to be software repository for sugar DE. So, what about not multiplying entities and reusing 0install for '-*' programs(but still not sure about '--'). For example in case of OO4kids activity we can create 0install infrastructure(and benefit other non sugar 0install users) or reuse existed 0install package. For sugar user, 0install activities will look on ASLO like other activities, so click on Download button just runs sugarized 0install GUI. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: Hi all, Non sugar activities we (could)have on ASLO: ++ programs with high sugar integration(journal etc.) + programs that start smooth in sugar environment(sugarised screen mode etc.) btw sugarizing programs only by fixing window issues and bundling blobs to .xo could be also wrong way to go, better to have universal method to run non-sugar programs w/o troubles with non-fullsreen/dialogs/etc windows. Does someone have any idea.. maybe special desktop mode to run non-sugar applications, fullscreen top window which is represented by one item in activity tray(or special icon in sugar frame). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 05:59:44PM +0100, Tomeu Vizoso wrote: On Mon, Nov 23, 2009 at 17:30, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: Hi all, Non sugar activities we (could)have on ASLO: ++ programs with high sugar integration(journal etc.) + programs that start smooth in sugar environment(sugarised screen mode etc.) btw sugarizing programs only by fixing window issues and bundling blobs to .xo could be also wrong way to go, better to have universal method to run non-sugar programs w/o troubles with non-fullsreen/dialogs/etc windows. Is there any serious problem other than the launcher not appearing in the home view? About the launcher issue, we could support .desktop files. I've just tried to start several non-sugar applications(gnome-terminal, gimp, ooffice) and it looks now not so bad as I thought before. If we fix launcher related issues and maybe set gnome theme to something non-sugar(sugar theme looks ugly for regular gnome applications) and we can stop sugarizing applications just by tweaking window sizes(tuxpaint, gcompris) and start .desktop applications and 0install packages as is. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 12:03:24PM -0600, David Farning wrote: On Mon, Nov 23, 2009 at 10:59 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Mon, Nov 23, 2009 at 17:30, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Nov 23, 2009 at 01:23:22PM +, Aleksey Lim wrote: Hi all, Non sugar activities we (could)have on ASLO: ++ programs with high sugar integration(journal etc.) + programs that start smooth in sugar environment(sugarised screen mode etc.) btw sugarizing programs only by fixing window issues and bundling blobs to .xo could be also wrong way to go, better to have universal method to run non-sugar programs w/o troubles with non-fullsreen/dialogs/etc windows. Is there any serious problem other than the launcher not appearing in the home view? About the launcher issue, we could support .desktop files. Regards, Tomeu I have been trying to keep current active Sugar Labs developers 'out of the way' on activities.sugarlabs.org policies. a.sl.o is one of the most user driven and user visible aspects of Sugar Labs.A very interesting recent thread has been about distributing scratch via a.sl.o. This has been interesting, and hopefully precedent setting, because it has been driven by users asking for something rather than Sugar Labs trying to provide something. One of the key premises behind community development is participants who see a problem which needs fixing and then take the time to fix it. In this case, Jeff has been tracking down what is necessary to distribute scratch as an .XO bundle. The short answer for why scratch is not in a.sl.o is that no one has had the time, interest, and ability to package and maintain scratch 1.4. Maybe that person will be Jeff or he can find someone who can work on scratch. in case of how to package something to .xo bundle(which is not sugar activity) I start think that we are trying to do redundant work, we can utilize 0install(for example), so sugar and 0install(for example) communities will benefit each other. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Thu, Nov 12, 2009 at 05:51:27AM +, Aleksey Lim wrote: Hi all, To have some implementation mockups for next 0install debates, I've coded how(I'm thinking) 0install integration could be implemented in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned repos[2] and follow simple test case[3]. [1] http://wiki.sugarlabs.org/go/Zero_Depend [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test I've changed this feature a bit, so now its a Zero Install integration[4] The reason for this feature is to cover situations: * an activity has dependencies that weren't included to the Sugar Platform * install/build activity specific binaries * run non-sugar applications that are not well packaged to GNU/Linux distributions [4] http://wiki.sugarlabs.org/go/Zero_Install_integration -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:39:14PM +0100, Martin Langhoff wrote: On Mon, Nov 23, 2009 at 7:31 PM, Aleksey Lim alsr...@member.fsf.org wrote: I've changed this feature a bit, so now its a Zero Install integration[4] Good to see progress on this. Much appreciated. Some questions... - Why is the depcheck happening at first start time? Install time seems be more appropriate: install time means there is a src of software, needed deps can be grabbed from the same src if present... in that case we entirely depend on 0install, so sugar provide just new GUI for 0launch(here just for downloading/building dependencies). - What happens if the deps are missing? If the user is offline? activity fails to start but in case of offline, 0install provides some options that could be useful for users(0share, 0mirror). - What happens when the build fails? activity just fails, and of course we can add some kind of bugreporting feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: Hi Aleksey, On 23 Nov 2009, at 18:45, Aleksey Lim wrote: On Mon, Nov 23, 2009 at 07:39:14PM +0100, Martin Langhoff wrote: On Mon, Nov 23, 2009 at 7:31 PM, Aleksey Lim alsr...@member.fsf.org wrote: I've changed this feature a bit, so now its a Zero Install integration[4] Good to see progress on this. Much appreciated. Some questions... - Why is the depcheck happening at first start time? Install time seems be more appropriate: install time means there is a src of software, needed deps can be grabbed from the same src if present... in that case we entirely depend on 0install, so sugar provide just new GUI for 0launch(here just for downloading/building dependencies). - What happens if the deps are missing? If the user is offline? activity fails to start but in case of offline, 0install provides some options that could be useful for users(0share, 0mirror). - What happens when the build fails? activity just fails, and of course we can add some kind of bugreporting feature. First up, to be honest, I don't plan to use or involve myself with 0install for any activities I'm involved with (may be if it works invisibly as a worst case fallback)... if you have ready to use 0depend.xml file(for example from another activity which uses the same deps) you as developer should only place it to activity/ directory and for users starting this activity means only having additional downloading progressbar(for the first time). But, if a deployment/teacher wanted to distribute one (or several) of these non-Sugar compliant installs on a USB stick for remote class installation, is it a trivial step for them to put 'the activity' on a stick so it can be installed without any network access or local server at install time? 0install integration is just an optional addon to activity bundles, you can all time package fat .xos as usual. Example: Teacher travels from a remote village to an education ministry or town with internet access once a month. Downloads a selection of new activities and content from ASLO to their USB stick. Journeys back to their village and uses the USB stick to install/upgrade each machine, kids also share the activity .xo bundle from Journal with friends who can't make it to the school. http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities as an addition, we can support offline mode for such activities (request for downloading all required deps for all such activities by one click). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 08:05:21PM +0100, Martin Langhoff wrote: On Mon, Nov 23, 2009 at 7:45 PM, Aleksey Lim alsr...@member.fsf.org wrote: - Why is the depcheck happening at first start time? Install time seems be more appropriate: install time means there is a src of software, needed deps can be grabbed from the same src if present... in that case we entirely depend on 0install, so sugar provide just new GUI for 0launch(here just for downloading/building dependencies). So it'll be triggered when users download run an .xo? When they double-click an .xo from a USB disk? 0install procedures will be triggered on avery activity launch, but we can trigger them on uploading such bundle to journal(installation), so there won't be any differences (in case of downloading from ASLO) between regular activities and activities w/ 0install dependencies Will there be a way (control panel?) to see the disk space taken by 0install stuff and prune/uninstall parts? dunno, I guess in most cases its a designers question I thought about simple download progress bar for launcher http://wiki.sugarlabs.org/go/File:0depend-launcher.png, control panel for setup 0install settings and we can have context menu item for activities that have 0install dependencies to show 0install status. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 07:22:23PM +, Aleksey Lim wrote: On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: Example: Teacher travels from a remote village to an education ministry or town with internet access once a month. Downloads a selection of new activities and content from ASLO to their USB stick. Journeys back to their village and uses the USB stick to install/upgrade each machine, kids also share the activity .xo bundle from Journal with friends who can't make it to the school. http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities as an addition, we can support offline mode for such activities (request for downloading all required deps for all such activities by one click). ..and share such dependencies by http://0install.net/0share.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Mon, Nov 23, 2009 at 08:00:49PM +, Aleksey Lim wrote: On Mon, Nov 23, 2009 at 07:22:23PM +, Aleksey Lim wrote: On Mon, Nov 23, 2009 at 07:06:19PM +, Gary C Martin wrote: Example: Teacher travels from a remote village to an education ministry or town with internet access once a month. Downloads a selection of new activities and content from ASLO to their USB stick. Journeys back to their village and uses the USB stick to install/upgrade each machine, kids also share the activity .xo bundle from Journal with friends who can't make it to the school. http://wiki.sugarlabs.org/go/Zero_Install_integration#Deploy_0install_packages_from_ASLO_like_a_regular_sugar_activities as an addition, we can support offline mode for such activities (request for downloading all required deps for all such activities by one click). ..and share such dependencies by http://0install.net/0share.html or doing something similar to http://roscidus.com/desktop/Zero2Bundle or http://0install.net/0export.html -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Non sugar activities on ASLO
On Mon, Nov 23, 2009 at 02:46:52PM -0600, Jim Simmons wrote: Aleksey, It would be helpful to have a way to distribute things like the gstreamer espeak plugin you wrote. Fedora doesn't currently include it. It would be even better if you could distribute versions that work on the XO running .82, as well as versions for current Fedora. Don't know if that was what you had in mind. yeah, thats another reason to have 0install dependencies - having over-distributions method to install deps that can't be installed from native packages(not yet packaged, packaged incompatible version). http://wiki.sugarlabs.org/go/Zero_Install_integration#Support_0install_integration_in_sugar_.3C0.88_activities -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] sugar-datastore sucrose-0.86 branch
Hi all, sugar-datastore was branced for 0.86 bug fixes, master branch is open for 0.88 commits. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release GCompris Additional Content-12
On Mon, Nov 16, 2009 at 06:06:05AM -0500, Sugar Labs Activities wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4090 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26359/gcompriscontent-12.xo Release notes: * GCompris 8.4.13 release * Run in sugar 0.86 environment This release is also for all GCompris activities. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Discrepancy regarding an Activity
On Sun, Nov 15, 2009 at 01:47:08PM +0100, Jonas Smedegaard wrote: By comparison, Debian have little technical protection against uploading evil code, but have a social mechanism of only allowing official members to upload (combined with requiring a large effort to become official member). I do not see the Debian design here as brilliant, but it seems to me that current Sugarlabs approach is even weaker :-/ In that case we just follow AMO practice, but our editors policy doesn't cover all cases[1] e.g. for various non-technical questions, I guess this topic[2] should be picked by SLOBS. [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy#Additional_technical_policy_for_editors [2] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy#Non-technical_policy -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] New aslo@ mailing list
On Thu, Nov 12, 2009 at 11:33:10PM +, Aleksey Lim wrote: Hi all, To ease Activity Library editors coordination, ASLO will send all kinds of review requests to new mailing list a...@lists.sugarlabs.org. So, any editor(and not only editrs) can subsribe to this list and be informed of all reviews threads. There is no need in subscription to this list for activity developers, every review email from ASLO will be CCed and REPLYTOed to proper activity authors. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0depend feature request
On Thu, Nov 12, 2009 at 08:10:11PM +0100, Tomeu Vizoso wrote: On Thu, Nov 12, 2009 at 06:51, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, To have some implementation mockups for next 0install debates, I've coded how(I'm thinking) 0install integration could be implemented in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned repos[2] and follow simple test case[3]. Hi, I would like to know more about how the experience changes for activity authors 0depend is just optional feature, for bundles that have activity/0depend.xml file, while launching activity sugar(via 0install) will download(or build, just 0install feature) all dependencies that are mentioned in 0depend.xml and pass proper info via environment variables (PATH, PYTHONPATH etc) to activity startup. and what happens when the .xo is not downloaded from the web but copied from an usb stick. only 0depend.xml makes sense(its just regular bundle file), if it exists, shell will enable 0install integration. Thanks, Tomeu [1] http://wiki.sugarlabs.org/go/Zero_Depend [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] New aslo@ mailing list
Hi all, To ease Activity Library editors coordination, ASLO will send all kinds of review requests to new mailing list a...@lists.sugarlabs.org. So, any editor(and not only editrs) can subsribe to this list and be informed of all reviews threads. Broadcast editor notifications were removed since it doesn't make much sense in case of having new mailing list. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] 0depend feature request
Hi all, To have some implementation mockups for next 0install debates, I've coded how(I'm thinking) 0install integration could be implemented in sugar[1]. To check existed code, pull sugar and sugar-toolkit cloned repos[2] and follow simple test case[3]. [1] http://wiki.sugarlabs.org/go/Zero_Depend [2] http://wiki.sugarlabs.org/go/Zero_Depend#Scope [3] http://wiki.sugarlabs.org/go/Zero_Depend#How_To_Test -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Mon, Nov 02, 2009 at 11:18:21PM -0500, Art Hunkins wrote: All is good now. Prior to this evening, Our Music MC was not showing up as an activity for me. (I appreciate David having uploaded both activities, and am sorry the MC version was late appearing.) Now it is here, and I have completed its presentation (having learned in the meantime how to take snapshots!) FYI: I'm using IE8 in Windows as a browser. dunno about ie and windos, while merging AMO I can't test it It might be helpful on the initial commit/upload page in the developers hub to state that the Activity file should be an .xo bundle, and that its top directory should be (blah, blah). And perhaps give the OLPC link telling how to make bundles. That would sure have been helpful to me. already done :) -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] is csound-python part of the Sugar Platform?
On Tue, Nov 03, 2009 at 11:35:12AM +, Daniel Drake wrote: Hi, http://wiki.sugarlabs.org/go/0.84/Platform_Components doesn't make it clear. Is csound-python part of the Sugar platform? In my mind its wasn't part of SP-0.84, we didn't have activities (at least on ASLO) that use python binding. But I guess we can add it to SP-0.86 - in most cases if distribution has csound, it has python binding. For old OLPC builds, olpcsound did include the csound python module, although this was unused by all of the standard OLPC-shipped activities. (TamTam uses csound directly, without the python wrapper) As of the latest fedora packages, the standard csound packages do not include the python wrapper, you need an extra package (csound-python) for that. FWIW, The OurMusic activity requires this. Thanks, Daniel ___ 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] Submitting New Activities
On Mon, Nov 02, 2009 at 09:31:45AM -0500, Art Hunkins wrote: Attached are the two .xo bundles. BTW, I created them manually - not with the help of setup.py. Yeah, that was the problem, valid .xo bundles should contain directory w/ activity name on top of files hierarchy, anyway the best option is creating .xo bundles with setup.py. That could be the problem, though I don't think so. Please let me know. btw ASLO says on uploading attached bundles: Oops! There seems to be a problem with this file... The activity bundle must contain a file named activity/activity.info Please correct this problem and upload your file again. I guess activity/activity.info could be confused, since it means activity-name/activity/activity.info, I'll tune error message -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Submitting New Activities
On Mon, Nov 02, 2009 at 08:36:51PM -0500, Art Hunkins wrote: Aleksey, I made the change you suggested, as in the attached .xo. I still was unable to upload, receiving the same message error on page. The error log is not at all helpful; I uploaded in Win XP, and the message you indicated did not at all come through. Are you using firefox under winxp? I don't have win*, so I can't test it I uploaded with the following archive names: OurMusicMC-1.xo, ourmusicmc-1.xo, OurMusicMC.xo and ourmusicmc.xo. Same result for each. but anyway if you are trying to upload new activity it should be failed since there are already both these activities(I guess David uploaded them), so use http://activities.sugarlabs.org/en-US/developers/versions/4226/ http://activities.sugarlabs.org/en-US/developers/versions/4227/ to manage versions for these activities(if you want to reupload existed version, you need to delete that version first) I tried to upload your attached bundle and it didn't fail. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Activity Library v4
== News == * rebase to last AMO code base * new sugar theme == News for users == * revert fast link to global statistics http://activities.sugarlabs.org/en-US/statistics (click on activities downloaded at the right top corner on main page) * bar with links to common sugar resources at the left top corner on main page (analog of http://www.sugarlabs.org/ links bar) * vote for particular collection * attach personal tags to activities (on left sidebar, click Add a tag button) == News for activity developers == * New developers UI http://activities.sugarlabs.org/developers * per activity developer profile (Developer Profile button in edit menu) * attach default tags to activities (Tags button in edit menu) * see recent activity for particular activity (Recent Activity button in edit menu) == News for editors == * promo box was disabled for this release (will be sugarized and enabled for next release) * editors can black list tags (http://activities.sugarlabs.org/sugar/admin/tags) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO testing
On Mon, Oct 26, 2009 at 01:42:50PM -0700, Josh Williams wrote: If you have a minute please test: http://activities-testing.sugarlabs.org/en-US/sugar/ Bugs fixed since last round of testing: 1. # of Activities downloaded number added 2. Fixed pagination for long search results 3. Fixed user profile section 4. cleaned up a few general typographical inconsistencies Thanks, Josh Another issue, inconsistence in translation input box.. -- Aleksey attachment: inputbox.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO testing
On Mon, Oct 26, 2009 at 01:42:50PM -0700, Josh Williams wrote: If you have a minute please test: http://activities-testing.sugarlabs.org/en-US/sugar/ Bugs fixed since last round of testing: 1. # of Activities downloaded number added 2. Fixed pagination for long search results 3. Fixed user profile section 4. cleaned up a few general typographical inconsistencies Thanks, Josh overlapping and selcolor in dev menu on http://activities-testing.sugarlabs.org/en-US/developers/addon/edit/4055/ -- Aleksey attachment: devmenu.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ASLO updates
On Fri, Oct 23, 2009 at 03:30:08PM -0700, Josh Williams wrote: Updates have been made to ASLO, I'm sure there are display bugs floating around because a lot of the code was changed. Please take a few minutes to test it out: http://activities-testing.sugarlabs.org/en-US/sugar/ If you're an activities developer, please check out the developers hub to check for errors (btw, I haven't made all of the branding changes yet, please just check for display errors): http://activities-testing.sugarlabs.org/en-US/developers just encontered, wrong paging in Browse and Firefox -- Aleksey attachment: paging.png___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memorize 33 is buggy - what should I do?
On Fri, Oct 16, 2009 at 09:12:24AM +, Aleksey Lim wrote: On Thu, Oct 15, 2009 at 10:38:03PM -0400, Caroline Meeks wrote: I doubt this is a SoaS only problem but I haven't tested it on an XO Tickets - 1055 I'm going to test Memorize in last soas2(12-Oct-2009) #1055 is about pulseaudio issue, maybe in last soas it will be better Caroline, could you test last soas(in my case it sounds more smooth) , 1503 1503 is a total blocker for using Memorize and 1055 is going to give me hell in the field trying to get kids not clear that inviting face. #1503 looks weird, telepathy signals don't work... trying to investigate and Memorize-34 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.86.3
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.86.3.tar.bz2 == News == * Sporadic freezes while scrolling journal #1506 * Suppress race condition with Journal appearing on sugar startup #1373 * Alt+Space not working to show/hide the tray #1476 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.86.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.86.2.tar.bz2 == News == * Do not stop processing motion-notify-event #1507 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Memorize 33 is buggy - what should I do?
On Thu, Oct 15, 2009 at 10:38:03PM -0400, Caroline Meeks wrote: I doubt this is a SoaS only problem but I haven't tested it on an XO Tickets - 1055 I'm going to test Memorize in last soas2(12-Oct-2009) #1055 is about pulseaudio issue, maybe in last soas it will be better , 1503 1503 is a total blocker for using Memorize and 1055 is going to give me hell in the field trying to get kids not clear that inviting face. #1503 looks weird, telepathy signals don't work... trying to investigate -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
