Re: [sugar] Reducing activity sharing boilderplate code
Subclassing makes sense to me (though I'm just a designer, so don't give me too much weight.) It seems that we could create a CollaborativeActivity subclass, and perhaps even subclass that if there are several common types of collaboration with different setups. The easier it is for someone to get started with a collaborative code base, the better, in my opinion. - Eben On Fri, Nov 7, 2008 at 7:41 AM, Morgan Collett [EMAIL PROTECTED] wrote: I want to push some of the code required for sharing into sugar-toolkit, for example: def _list_tubes_reply_cb(self, tubes): for tube_info in tubes: self._new_tube_cb(*tube_info) If I put this directly into sugar.activity.activity.Activity, then all activities will gain the code which might impose some overhead. Alternatively I can subclass Activity to SharableActivity or something like that, and add the telepathy/tubes helper code in there. Thoughts? Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Reducing activity sharing boilderplate code
On Fri, Nov 7, 2008 at 5:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: Subclassing makes sense to me (though I'm just a designer, so don't give me too much weight.) It seems that we could create a CollaborativeActivity subclass, and perhaps even subclass that if there are several common types of collaboration with different setups. The easier it is for someone to get started with a collaborative code base, the better, in my opinion. One of the 0.84 goals for Activity is to reduce the amount of code we import and run when the activity doesn't use all the class functionalities. Also we want modules to be imported more lazily. I'm sorry that I don't have a clear direction to point you to yet, I need to think about it more carefully, I just started measuring this week. But I thought it was worth to point this out... Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Reducing activity sharing boilderplate code
On Fri, Nov 7, 2008 at 1:41 PM, Morgan Collett [EMAIL PROTECTED] wrote: I want to push some of the code required for sharing into sugar-toolkit, for example: def _list_tubes_reply_cb(self, tubes): for tube_info in tubes: self._new_tube_cb(*tube_info) If I put this directly into sugar.activity.activity.Activity, then all activities will gain the code which might impose some overhead. Alternatively I can subclass Activity to SharableActivity or something like that, and add the telepathy/tubes helper code in there. If we make activities subclass SharableActivity, then they won't be able to subclass WebActivity, RedActivity, QTActivity, etc IMO, the alternative that is looking best right now is to have in sugar.activity.activity the bare minimum an activity needs to load (a window). Then add services like SharingService, JournalService, etc that can be used by the activities that actually need them, and loaded when they are actually needed. This is the approach followed in XULRunner and in Maemo, AFAIK. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Sugar on Ubuntu - Summary
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 07, 2008 at 06:50:52PM +1800, David Farning wrote: Yesterday we had a long thread about Sugar on Ubuntu which was helpful yet filled with misunderstandings. If you insist on focusing solely on Ubuntu, then please do not bother cc'ing me. - Jonas Debian deveopler, not Ubuntu developer. - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkUdA8ACgkQn7DbMsAkQLgypgCfeZ2IwPDR95wQb4OCVzdqBPXM 5VoAoKWKT6YLtG35lteduE2JQyNp1ZdV =v1QP -END PGP SIGNATURE- ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Sugar on Ubuntu - Summary
Hi, additionaly to what Bert said: to summarize _my understanding_ again: there is source, there is just no ascii representation of the source / you cannot compile the source to binaries. Because the source comes as blobs (being the VM in it's state), which can be edited inside the virtual machine it represents. In theory squeak can be bootstrapped, in practice not. (Hence, there is a chicken and egg problem. (For non squeak developers. Squeak developers are used to this and happy about it.)) regards, Holger pgpSd78xxEqvf.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wrapping Sugar activities for other desktops
On Fri, Nov 7, 2008 at 7:32 AM, Martin Langhoff [EMAIL PROTECTED] wrote: Thinking about how to extend the appeal (and long term viability!) of sugar activities, one thing that appears as a clear opportunity is to create a wrapper that allows to run sugar activities in a conventional gnome/kde/xfce/awesome desktop. Sounds good, it's on the list of the things I'd really like to do but I'm too swamped to put focus on :( It could open a regular window (instead of the root window), and mimick the minimal set of Sugar facilities that activities depend on. An activity is a regular window already. It's just the wm which displays it fullscreen. So we should be fine there. Perhaps a thinner, lighter set of classes providing the sugar api (add the path to these shim libraries early in the python path to mask the full blown sugar libs). Right now, if I install on ubuntu sugar-activities, I get turteart, but I can only use it inside sugar-emulator. If we had such a shim so that $ sugar-wrapper turtleart would start turtleart in a regular window, then that command can be given an icon in my gnome menu, kde's kickstart menu, etc. Yeah, you would need a little script to bridge to our non-standard activity launching stuff. Another approach might be to make it more standard or to brige it directly with desktop files. Of course there are some hard things - clipboard support probably needs glue You should be fine here, we use standard X stuff. - journal behaviour - though it might be relatively simple Not sure about this one... Do we want to make a journal activity available or to provide compatibility with posix? - naming documents that the user hasn't named explicitly Depends on what we want to do for the previous point. - the initial steps of sharing a collaborative activity (announcement, invites, etc) Maybe make the mesh view available as a standalone application? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Sugar on Ubuntu - Summary
Hi, On Friday 07 November 2008 14:39, David Van Assche wrote: the only option seems to seperate squeak from sugar, if sugar is to get into main or universe. thats not an option, but it's the (fine) status quo. there are these things called packages... regards, Holger, who also appreciates not to be cc:ed :) pgpy5DLRRRYaw.pgp Description: PGP signature ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Wrapping Sugar activities for other desktops
On Fri, Nov 7, 2008 at 5:00 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Sounds good, it's on the list of the things I'd really like to do but I'm too swamped to put focus on :( Ah, great to hear I'm not so lost in the woods! - journal behaviour - though it might be relatively simple Not sure about this one... Do we want to make a journal activity available or to provide compatibility with posix? Well, our journal use model says that the document is picked before the app is called, so if we support $ sugar-wrapper Write.xo mydocument.rtf then we're done. (Again, I might be extraordinarily naive about this :-) ). - naming documents that the user hasn't named explicitly Depends on what we want to do for the previous point. We can keep this part super-simple - save to a predefined directory - add something unique (timestamp? random string?) to the generic name if the user hasn't put a name in WRT random strings, one thing I've done in the past is to have a dictionary of safe words in the local language. Names of fruits, colours, simple nouns and adjectives, etc. And grab from there instead of using a fullblown random string. It is still random, but enormously more user-friendly :-) - the initial steps of sharing a collaborative activity (announcement, invites, etc) Maybe make the mesh view available as a standalone application? Yeah - perhaps something that looks and smells a lot like an IM window + desktop panel widget that knows how to blink and jump when you get an invite... - cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] new journal
Hi Scott, do you have any news for us about the work on your journal+datastore replacement? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] MPP with two XOs and a pppd via GPRS
I have two XOs (XO#1 and XO#2) with build 767. XO#1 is connected using wvdial (pppd) over GPRS. I am using Vodafone's service in India. By itself, XO#1 gets online. I do have to add the nameserver to /etc/resolv.conf but other than that, it works. When I try to set XO#1 as a MPP using the mpp.py script from http://wiki.laptop.org/go/Modem#How_to_share_internet_among_other_XOs I get an error related to iptables the first time. On a second attempt, I get no errors and the mpp.py script seems to do its magic. olpc-netstatus reveals that XO#1 is in MPP mode. XO#2 cycles through the 3 channels and finally settles at mesh 1 (same as the MPP XO#1) but does not say XO Mesh. XO#2 says Simple mesh and fails to get online via XO#1. Adding the nameserver t0 XO#2 does not help. Any pointers? 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 mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Fwd: CLKIDS
Enviando un trabajo de tesis de una compañera de la universidad -- Mensaje reenviado -- De: Claudia Colque [EMAIL PROTECTED] Fecha: 8 de noviembre de 2008 0:29 Asunto: CLKIDS Para: Alexis Luyo [EMAIL PROTECTED], Carlos Cardenas [EMAIL PROTECTED], Rafael [EMAIL PROTECTED], Samuel [EMAIL PROTECTED], Scott Ananian [EMAIL PROTECTED], Sebastian [EMAIL PROTECTED], Walter Bender [EMAIL PROTECTED] Buenas noches a todos Les paso el link donde he colgado el prototipo del proyecto, ojala les guste http://wiki.laptop.org/go/Projects/CLKIDS Saludos Atte Claudia Colque PDTA: estoy en proceso de conseguir un git -- http://unimauro.blogspot.com/ Creemos en el amor de los Seres Humanos Carlos Mauro Cárdenas Fernández 4582877 980525716 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
