Re: [Sugar-devel] Gtk 3.10 icon size regression
On Sat, Jan 18, 2014 at 12:07:34PM +0100, Daniel Narvaez wrote: > On 18 January 2014 11:32, James Cameron wrote: > > On Sat, Jan 18, 2014 at 10:41:57AM +0100, Daniel Narvaez wrote: > > > By the way, XO is our main platform from the number of users > > > point of view but it seems like a dead end at this point. So IMO > > > it should not be our main target when designing future > > > solutions. > > > > Yes, but not for the reason you give. The OLPC XO is still in > > production, and is still in deployment. The best reason for not > > selecting the OLPC XO as your main target is so that Sugar can be > > suitable for as many platforms as possible. > > Are new XO being sold? My possibly misguided feeling is that OLPC is > not even trying anymore. I'm not in that part of OLPC, I'm in engineering and manufacturing support. As far as I know, you can still order new XO laptops if you have a large enough quantity in mind. Any organisations wishing to get a quote can write to countr...@laptop.org. I may be misguided, but I didn't think Sugar Labs wants to buy any XO laptops. ;-) I think developers have enough XO laptops to work on, or can share them around. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Physics-15
Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: 0.96 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28882/physics-15.xo Release notes: 15 ENHANCEMENT: * Add collaboration support for most tools BUG FIX: * Fixed problems with selector palettes Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mime type error in sugar
On Sun, Jan 19, 2014 at 1:47 PM, Daniel Narvaez wrote: > On 19 January 2014 17:04, Gonzalo Odiard wrote: > >> I don't know if this was needed by historical reasons, >> maybe the Gio functionality was not available. >> >> mime.get_for_file do some magic to recognize text files. >> > > Gio seems to handle that just fine (tested with Gio.content_guess_type). > > >> Probably mime.get_for_file could call Gio instead of the SugarExt >> equivalent. >> > > IMO we should deprecate mime.get_for_file and replace it with Gio. > I agree. This week I will be almost disconnected. Next week will be back working. Gonzalo -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
Please don't look at the poor javascript code :( I created a web activity that can act as sugar's mesh for web activities (with a few lines of code it should work for normal activities, too). This time I went the other way around. Instead of sending invites, when an activity is shared, everyone on the mesh can join it (it was easier to implement). Normal invites could also be implemented, I just have to work on integrating it with sugar's frame (for the invite notification). Since this 'new mesh' is a web activity, it can be opened with a normal desktop browser. Yet it will have little to no functionality. The simplest explanation: the mesh can not know the path of an activity to open. With a little work, this problem can be solved. For the past 2 days I went deep into TogetherJS and I no longer believe that it will suit sugar's needs. The first reason is a WebKit bug. I noticed that when a CSS transform property is used, the screen will go blank (gray). I manually edited TogetherJS' jQuery modifications to not include CSS transforms, yet this bug still happens. I have not yet found the problem. Although this is a WebKit bug (it does not happen outside of sugar), it is one of the reasons to drop TogetherJS. The second one is the communication protocol. Although it is quite easy (the server just replies the messages to all clients and lets them handle everything), the protocol isn't much secure and may cause more traffic than needed. I don't expect a kid to look at the code and 'hack' the protocol, yet I still don't like the idea of leaving everything to the clients. An other reason, although not much of a problem and more a feature, is the fact that TogetherJS syncs every single mouse move, mouse click, form change, input field update... These are lots of unneeded stuff. As it was discussed earlier, a low-level API can work fine for sugar and it won't be hard to create such an API. The thing that will be lost (and hard to implement) are the many neat high-level features of TogetherJS. About what I made and how to test it: The sugar-net web activity is the 'mesh'. And a nice activity to test with is the modified gtd-activity. Once the sugar-net activity is started, it will communicate with a WebMesh class in apisocket.py. When a web activity (like gtd-activity) is shared, it will appear as a shared activity when you hover the mouse over the XO icon in the sugar-net activity. When you click on it from an other mesh activity (an other instance of sugar), it will automatically start the web activity (gtd-activity) and the shared session will begin between the two. Both sugar-net and gtd-activity still use Mozilla's hub server for the communication. sugar-toolkit-gtk3: https://github.com/edudev/sugar-toolkit-gtk3/tree/webcollaboration sugar: https://github.com/edudev/sugar/tree/webcollaboration gtd-activity: https://github.com/edudev/gtd-activity/tree/collaboration sugar-net: https://github.com/edudev/sugar-net Emil Dudev On Sat, Jan 18, 2014 at 4:20 PM, Emil Dudev wrote: > I'm not quite sure. > > One way to do it is to use 1 class as the client and integrate the class > into the current mesh box (neighbourhood.py). This would probably mean that > normal sugar activities could use this 'new protocol'. > An other way would be to use a web activity as the client. I'm not sure > how exactly will I have to handle the activity -> sugar communication and > pass the invites. > > If going with the second approach I'd have to rewrite the whole > neighbourhood view in HTML/javascript. And with this an other question > arises: How much of sugar's core can be rewritten in HTML/javascript. > One of TogetherJS's features is to follow your friends around pages. I > think it's limited to a single domain, but I believe I can use it. > > I believe that the first approach would be easier, but with all this talk > about new frameworks for web activities and going multi platform, I'll > choose the second approach. > > Emil Dudev > > > > On Sat, Jan 18, 2014 at 1:19 PM, Daniel Narvaez wrote: > >> Interesting! Are you planning to use a js actitvity or a python one as >> client? >> >> >> On 18 January 2014 01:21, Emil Dudev wrote: >> >>> Busy month... >>> >>> Anyway, I checked out telepathy and tried to fix the many protocol >>> problems. Sadly, I gave up pretty easily. I suppose it would be easier to >>> rewrite the whole process from scratch. >>> >>> Today I was able to recreate the basic functionality of TogetherJS' >>> server. From a nodejs server, I rewrote it in python (using gwebsockets). >>> This will give me the ability to customize it freely. >>> >>> Tomorrow I plan on building the basic invitation process using web >>> sockets. I suppose it will be more reliable than telepathy. And it would >>> possibly be better for an Android app or other systems with limited >>> functionality. >>> >>> About WebRTC: I really think that peer-to-peer connections are needed. >>> But at this point, I'll go with client-server co
Re: [Sugar-devel] [DESIGN] Better journal icons
Adding [DESIGN]. On 19 January 2014 21:45, Sam Parkinson wrote: > Hi > > Here is my PR that makes the journal icons better. It now only shows the > white outline. You can check it out here: > https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/88 . > > Sam > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Better journal icons
Hi Here is my PR that makes the journal icons better. It now only shows the white outline. You can check it out here: https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/88 . Sam ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mime type error in sugar
On 19 January 2014 17:04, Gonzalo Odiard wrote: > I don't know if this was needed by historical reasons, > maybe the Gio functionality was not available. > > mime.get_for_file do some magic to recognize text files. > Gio seems to handle that just fine (tested with Gio.content_guess_type). > Probably mime.get_for_file could call Gio instead of the SugarExt > equivalent. > IMO we should deprecate mime.get_for_file and replace it with Gio. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] mime type error in sugar
I don't know if this was needed by historical reasons, maybe the Gio functionality was not available. mime.get_for_file do some magic to recognize text files. Probably mime.get_for_file could call Gio instead of the SugarExt equivalent. Gonzalo On Sat, Jan 18, 2014 at 6:49 AM, Daniel Narvaez wrote: > Why we need that method at all? Without knowing the history of this code, > it seems like we should Gio, both if the file exists and if it doesn't (if > I remember correctly guess if for when the file doesn't exist). > > > On 16 January 2014 20:42, Gonzalo Odiard wrote: > >> I have filled #4715 [1] with information about a problem with the mime >> database in sugar. >> A workaround is available, but I would like to know what other think >> about using Gio to identify the mime types instead of our own >> SugarExt.mime_get_mime_type_for_file >> Regards, >> -- >> Gonzalo Odiard >> >> SugarLabs - Learning Software for children >> >> [1] http://bugs.sugarlabs.org/ticket/4715 >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> > > > -- > Daniel Narvaez > -- Gonzalo Odiard SugarLabs - Learning Software for children ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
