Re: [Sugar-devel] Gtk 3.10 icon size regression
On 20 January 2014 07:14, James Cameron qu...@laptop.org wrote: On Sat, Jan 18, 2014 at 12:07:34PM +0100, Daniel Narvaez wrote: On 18 January 2014 11:32, James Cameron qu...@laptop.org 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. For the record what I was saying is that the XO is a dead end because OLPC is not marketing it anymore, in favor of the Android tablet. As a result I'd expect organizations to not be ordering it anymore. Factual corrections appreciated, pointless sarcasm not so much. Thanks. ___ 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
Very interesting! Couple of initial questions, trying to understand better: * Why did you go with a separate web activity instead on integrating directly in the shell? * Would it be possible to implement this without adding to apisocket and thus making it sugar specific? On 20 January 2014 00:09, Emil Dudev emildu...@gmail.com wrote: 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 emildu...@gmail.com 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 dwnarv...@gmail.comwrote: Interesting! Are you planning to use a js actitvity or a python one as client? On 18 January 2014 01:21, Emil Dudev emildu...@gmail.com 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
Re: [Sugar-devel] Collaboration support for sugar web activities
On Mon, Jan 20, 2014 at 12:48 PM, Daniel Narvaez dwnarv...@gmail.comwrote: * Why did you go with a separate web activity instead on integrating directly in the shell? Integrating it directly with the current neighborhood? One problem would be of duplicates if a user is both on the telepathy neighborhood and this 'new' one. As mentioned in the earlier messages, I was thinking of writing a python class that would act as the client between the sugar's mesh and the web socket server. I wasn't sure how exactly to handle regular activities and web activities in such a 'merged' neighborhood. * Would it be possible to implement this without adding to apisocket and thus making it sugar specific? Making web collaboration sugar specific, or not (being able to collaborate from a normal browser)? Since apisocket.py is the only way to communicate between the javascript code and sugar, I'd say it won't be easy. As noted above, it won't be very easy to have collaboration outside of sugar, because the browser does not know where the activity page lies (if it needs to join/open an activity). It is possible to join a web activity, without changes to apisocket.py. The problem would be that the current webkit page (sugar-net activity) would be overwritten by the new activity (the one that is joined). There's no problem from the web activity's point of view. The problem is that sugar would still think that this is the sugar-net activity, and I'm not sure what that would lead to. An other problem is that the sugar-net activity is lost (it's page was reloaded into the joined activity). A possible way to solve this is to open the new activity's page into a separate tab. But then there are other problems: sugar would think the sugar-net activity and it's new tab (the new activity) are one. Also, I'm not sure how tab handling would look in webkit, without the top navigation bars. The questions don't seem to have simple answers... When I'm writing the code, I'm not sure which way to go. I don't believe that I can decide what is best for sugar. It would be nice to know what the community is thinking and what is their vision of how web collaboration should be handled. Emil Dudev ___ 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
On 20 January 2014 13:53, Emil Dudev emildu...@gmail.com wrote: On Mon, Jan 20, 2014 at 12:48 PM, Daniel Narvaez dwnarv...@gmail.comwrote: * Why did you go with a separate web activity instead on integrating directly in the shell? Integrating it directly with the current neighborhood? Not necessarily, I was also wondering why you didn't write the same thing in python inside the shell. But now I probably see, an activity was the only sensible place to put it if you wasn't merging with the telepathy view. One problem would be of duplicates if a user is both on the telepathy neighborhood and this 'new' one. As mentioned in the earlier messages, I was thinking of writing a python class that would act as the client between the sugar's mesh and the web socket server. I wasn't sure how exactly to handle regular activities and web activities in such a 'merged' neighborhood. I'm not sure to understand where we would get duplicates. It seems like the mesh view is a list of activities. The new framework will provide you another list. Isn't it just matter of merging the two? Even in the current view if the user is in two activities, I believe we show it two times. (Might very well be missing something!). The reason I want to figure out if it's possible to merge the views is that we are not going to be able to drop telepathy based collaboration any time soon. We will have first to prove that the new framework works better and get activity authors to buy into it, then deprecate, finally wait a few years for activities to be migrated. So we need a plan on how the two can coexist. I'm afraid having two separate views it's not something we can afford user experience wise... but it would be good to hear the design team opinions on this. * Would it be possible to implement this without adding to apisocket and thus making it sugar specific? Making web collaboration sugar specific, or not (being able to collaborate from a normal browser)? Since apisocket.py is the only way to communicate between the javascript code and sugar, I'd say it won't be easy. As noted above, it won't be very easy to have collaboration outside of sugar, because the browser does not know where the activity page lies (if it needs to join/open an activity). It is possible to join a web activity, without changes to apisocket.py. The problem would be that the current webkit page (sugar-net activity) would be overwritten by the new activity (the one that is joined). There's no problem from the web activity's point of view. The problem is that sugar would still think that this is the sugar-net activity, and I'm not sure what that would lead to. An other problem is that the sugar-net activity is lost (it's page was reloaded into the joined activity). A possible way to solve this is to open the new activity's page into a separate tab. But then there are other problems: sugar would think the sugar-net activity and it's new tab (the new activity) are one. Also, I'm not sure how tab handling would look in webkit, without the top navigation bars. Yeah, some sugar specific bits will be necessary to launch the activity. It seems like it would be good to keep those bits as minimal as possible. The questions don't seem to have simple answers... When I'm writing the code, I'm not sure which way to go. I don't believe that I can decide what is best for sugar. It would be nice to know what the community is thinking and what is their vision of how web collaboration should be handled. Yes. I think we are all a bit unsure about the way we should go. The research you are doing is extremely valuable because it's bringing us closer to figure that out... Lionel and Suraj has been experimenting with collaboration too, so it would be very interesting to hear their feedback. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gtk 3.10 icon size regression
On Mon, Jan 20, 2014 at 11:16:09AM +0100, Daniel Narvaez wrote: For the record what I was saying is that the XO is a dead end because OLPC is not marketing it anymore, in favor of the Android tablet. As a result I'd expect organizations to not be ordering it anymore. I don't know how to measure marketing except by observation. The marketing that I see offers both products. There has been no announcement of retirement of the laptop, and it is still in production. In the last two weeks I worked on second sourcing of SPI FLASH ROM and the eMMC chips in the XO-1.75 and XO-4. How are you measuring marketing? For the purposes of planning Sugar development, should you instead be measuring deployment? -- 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] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 ___ 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
On Mon, Jan 20, 2014 at 10:33 PM, Daniel Narvaez dwnarv...@gmail.comwrote: On 20 January 2014 13:53, Emil Dudev emildu...@gmail.com wrote: On Mon, Jan 20, 2014 at 12:48 PM, Daniel Narvaez dwnarv...@gmail.comwrote: * Why did you go with a separate web activity instead on integrating directly in the shell? Integrating it directly with the current neighborhood? Not necessarily, I was also wondering why you didn't write the same thing in python inside the shell. But now I probably see, an activity was the only sensible place to put it if you wasn't merging with the telepathy view. I've got some plans rotating in my head to rebuild sugar entirely as a desktop web app. It's subjective. I'll try to not think 'big'. When I have some free time I'll work on integrating it with the current neighborhood. One problem would be of duplicates if a user is both on the telepathy neighborhood and this 'new' one. As mentioned in the earlier messages, I was thinking of writing a python class that would act as the client between the sugar's mesh and the web socket server. I wasn't sure how exactly to handle regular activities and web activities in such a 'merged' neighborhood. I'm not sure to understand where we would get duplicates. It seems like the mesh view is a list of activities. The new framework will provide you another list. Isn't it just matter of merging the two? Even in the current view if the user is in two activities, I believe we show it two times. (Might very well be missing something!). As mentioned in the earlier messages, I was never able to get collaboration between normal activities to work, so probably I'm missing something. From what I was able to get working with telepathy is that on the network view (without the user doing/sharing anything), I can see all the users in 'the neighborhood' (on the same jabber server). I see their XO icons. These icons could be duplicated, as there would be an icon from the jabber server and an icon from the web socket server for the same user. Besides the XO icons on the network view, I've heard rumors (and/or seen pictures) of having shared activities next to a user's icon, having adhoc/ wifi networks on the view, having other things on the view. What I've done with the sugar-net activity is to place all the users on a random position and when the mouse hovers the user's icon a list with that user's shared activities will show. Clicking on an item from the list will join the activity. I've went for a similar, but slightly different approach. Who can I ask for the proper behavior of the network view? When I'll be merging the two, it would be good to know what to aim for. I'll probably not be able to test all the features (e.g. wifi/adhoc networks). The reason I want to figure out if it's possible to merge the views is that we are not going to be able to drop telepathy based collaboration any time soon. We will have first to prove that the new framework works better and get activity authors to buy into it, then deprecate, finally wait a few years for activities to be migrated. So we need a plan on how the two can coexist. I'm afraid having two separate views it's not something we can afford user experience wise... but it would be good to hear the design team opinions on this. Right. Life would be a lot easier if you didn't have to worry about backward compatibility and deprecation policies. I haven't given much thought to telepathy and normal activities. It won't happen again, I'll think of them first, before I do something collaboration related. * Would it be possible to implement this without adding to apisocket and thus making it sugar specific? Making web collaboration sugar specific, or not (being able to collaborate from a normal browser)? Since apisocket.py is the only way to communicate between the javascript code and sugar, I'd say it won't be easy. As noted above, it won't be very easy to have collaboration outside of sugar, because the browser does not know where the activity page lies (if it needs to join/open an activity). It is possible to join a web activity, without changes to apisocket.py. The problem would be that the current webkit page (sugar-net activity) would be overwritten by the new activity (the one that is joined). There's no problem from the web activity's point of view. The problem is that sugar would still think that this is the sugar-net activity, and I'm not sure what that would lead to. An other problem is that the sugar-net activity is lost (it's page was reloaded into the joined activity). A possible way to solve this is to open the new activity's page into a separate tab. But then there are other problems: sugar would think the sugar-net activity and it's new tab (the new activity) are one. Also, I'm not sure how tab handling would look in webkit, without the top navigation bars. Yeah, some sugar specific bits will be necessary to launch the activity. It seems like
Re: [Sugar-devel] Gtk 3.10 icon size regression
On 20 January 2014 21:34, James Cameron qu...@laptop.org wrote: On Mon, Jan 20, 2014 at 11:16:09AM +0100, Daniel Narvaez wrote: For the record what I was saying is that the XO is a dead end because OLPC is not marketing it anymore, in favor of the Android tablet. As a result I'd expect organizations to not be ordering it anymore. I don't know how to measure marketing except by observation. The marketing that I see offers both products. There has been no announcement of retirement of the laptop, and it is still in production. In the last two weeks I worked on second sourcing of SPI FLASH ROM and the eMMC chips in the XO-1.75 and XO-4. How are you measuring marketing? I'm not measuring myself but relying on the opinions of people which are more into OLPC things then me, which is why I pointed out my feeling might be misguided. For example John Watlington on this thread http://lists.sugarlabs.org/archive/sugar-devel/2013-October/045461.html For the purposes of planning Sugar development, should you instead be measuring deployment? Well, today Sugar development will take years to reach most deployments, thus I suspect it's not going to be useful to a large part of XOs which are currently deployed. It would be interesting to know if and how fast we are deploying new XOs today and that was my initial question. But if OLPC has abandoned the XO-4, as many are suspecting, I think that's very relevant to today development planning. Not that I expect anyone to say that clearly, even if it is the case. Anyway, from the very subjective perspective of a volunteer, if the XO was the main target for Sugar, I would not be contributing to the project. OLPC is showing no commitment to the XO and even less to Sugar and it's community, of whose work it has benefited for years. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Less confusing activities list
Hi, I was looking at bug #806 (http://bugs.sugarlabs.org/ticket/806), Activities list view is very similar to Journal view and users delete activities instead of journal entries. I was thinking we could fix this issue by adopting an icon view for the activities list. It sort of looks a little tablety, which is good considering some of the sugar deployments are almost tablets (XO-4). Here is a prototype: [image: https://lh3.googleusercontent.com/-W5cngQcZCeg/UtzmsQYgbzI/A_w/KS_NuNRdeko/w821-h621-no/design-icons.png] Maybe this would be good? I just wanted to get some feedback before I continued :) Sam :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
Reviewed-by: James Cameron qu...@laptop.org Like it. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Less confusing activities list
On Tue, Jan 21, 2014 at 08:32:15AM +1100, Sam Parkinson wrote: I was thinking we could fix this issue by adopting an icon view for the activities list. It sort of looks a little tablety, which is good considering some of the sugar deployments are almost tablets (XO-4). Here is a prototype: https://lh3.googleusercontent.com/-W5cngQcZCeg/UtzmsQYgbzI/A_w/ KS_NuNRdeko/w821-h621-no/design-icons.png Maybe this would be good? I just wanted to get some feedback before I continued :) I like it. Perhaps there is also room for showing time since last used, or maybe replace time since activity was installed. That would fix the annoying six year old activities problem. Don't forget a cascaded change of the icon at the top right corner; it should be a series of rectangles rather than a series of lines. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Less confusing activities list
Hi, I like it!Maybe we can remove the age of the activity.Would be good add the summary field from activity.info somewere..maybe, add summary as a tooltip. Regards! Alan From: sam.parkins...@gmail.com Date: Tue, 21 Jan 2014 08:32:15 +1100 To: sugar-devel@lists.sugarlabs.org; wal...@sugarlabs.org Subject: [Sugar-devel] [DESIGN] Less confusing activities list Hi, I was looking at bug #806 (http://bugs.sugarlabs.org/ticket/806), Activities list view is very similar to Journal view and users delete activities instead of journal entries. I was thinking we could fix this issue by adopting an icon view for the activities list. It sort of looks a little tablety, which is good considering some of the sugar deployments are almost tablets (XO-4). Here is a prototype: Maybe this would be good? I just wanted to get some feedback before I continued :) Sam :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Rework the wireless control panel section to respect non-wireless connections
On Mon, Jan 20, 2014 at 4:17 PM, Frederick Grose fgr...@gmail.com wrote: Fixes #4410 https://bugs.sugarlabs.org/ticket/4410 The 'Discard network history' button is peculiar to Sugar, and is destructive to all non-wireless connections, despite being in the 'Wireless' section of the control panel. In the proposed patch[0], the code variables and functions are renamed and coded to be specific to wireless connections. The 'Radio' checkbox instruction and 'Discard ...' button are reworded to avoid confusion over their state and actions.[1] If wireless hardware is not present on the system, the 'Wireless' section of the control panel is excluded.[2] [0,1,2] - https://github.com/sugarlabs/sugar/pull/228 Daniel Narvaez wrote via notificati...@github.com It seems like the code is handling adhoc networks specially, but I didn't find an explanation of that change. Can you please elaborate on it? The current code at, https://github.com/sugarlabs/sugar/blob/master/src/jarabe/model/network.py#L835 tests for sugar-internal connections by reading the connection_id string. The new code is specific to wireless connections. The first condition, the presence of a wifi_settings list, avoids 7 of the 7 sugar-internal connections on XO-1. The sugar ad hoc connections are avoided by a second condition, the same test as in the currrent code, connection_id.startswith(ADHOC_CONNECTION_ID_PREFIX). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
