[Sugar-devel] Taking over Browse maintainership
[Resend because mail with non-subscribed sender address was silented dropped] Since Browse has been unmaintained for several months [1] now, Lucian and I finally decided to step up as maintainers. This does NOT mean the current Browse will see a lot of improvements or even just bug fixes, as we are both already rather busy. We will, however, handle patches to the best of our abilities and maybe do some minor changes (e.g. include the CAcert root certs) or trivial fixes. For those who don't know yet: Lucian is working [2] on an abstraction layer that will allow Browse to use WebKit (or xulrunner, should anyone want to ;) ) as part of this years GSoC. He already worked on adding SSB support [3] to Browse during last years GSoC. I'll let these facts speak for themselves. :) If someone else would like to maintain (or co-maintain) Browse, please speak up now. Sascha [1] http://wiki.sugarlabs.org/index.php?title=Development_Team/Release/Modulesdiff=44090oldid=37446 [2] http://wiki.sugarlabs.org/go/Summer_of_Code/2010/Abstract_Browser [3] http://wiki.sugarlabs.org/go/Webified -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] depending on introspection
Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.88 Activities Font Size Problems
Hola Jorge, On Tue, Jun 15, 2010 at 22:04, Jorge Saldivar jorgesaldi...@gmail.com wrote: Hi all, sorry for bothering. We are having problems with the fonts size in activities toolbars, tooltips, buttons labels, and all the things related with the activities main window. It is a really strange problem because it only happend inside the activities not in sugar desktop where the fonts size are ok. I made some modifications via gconf with gconftool but the changes only affects the fonts size in sugar desktops. Look up the images attached where you can see the differences font sizes between desktop and activities. Someone have any ideas about it?, may be something related with the sugar setting manager? Could you please paste here the output of the 'printenv' command when executed inside the Terminal activity? Thanks, Tomeu -- Jorge A. Saldivar G. (jasg) ___ 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] Fwd: [laptop.org #63512] OX on the Internet [Dan Healy]
On Tue, Jun 15, 2010 at 18:34, Dan Healy dfhe...@gmail.com wrote: This forwarded message explains what I am looking for. It was sent to h...@laptop.org and they suggested I send it to this mail list. Any ideas, thoughts, or help would be appreciated. Dan H. -- Forwarded message -- From: h...@laptop.org Date: Sun, Jun 13, 2010 at 7:45 PM Subject: [laptop.org #63512] OX on the Internet [Dan Healy] To: dfhe...@gmail.com Hi Dan, Please contact the following mailing lists with your questions about the Sugar Learning Platform used on OLPC's XO Laptops: http://lists.sugarlabs.org/listinfo/sugar-devel http://lists.sugarlabs.org/listinfo/iaep Thanks! --Adam Holt On Sat Jun 12 14:36:51 2010, dfhe...@gmail.com wrote: I have developed a browser based learning system application. It has both author and student functions. I can connect to the student function and it works -- almost. When a student makes an error a pop-up window gives an explanation. When that occurs on the OX the pop-up takes up the entire window and there is no way to close it. Some of the buttons don't work on the OX that do work on IE and Firefox. I would like this application to work on the OX out of the box with no customization. If you really cannot change the web app, then an alternative would be to clone the Browse activity and modify it so popups open in the way you want. Then you would distribute the resulting activity pointing by default to some server. But I would recommend just stop using popups. Regards, Tomeu On the keyboard there are special characters for languages other than English. How do I get them to work? Is there an online source for the workings of the OX? I would be glad to go there and check that out. Thanks, Dan H. -- OLPC Support, Volunteer-Driven (http://support.laptop.org) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fwd: Analysis help needed re: sugargame (pygame) on the 1.0XO (build 802)
Hi George, On Wed, Jun 16, 2010 at 03:40, George Hunt georgejh...@gmail.com wrote: As I understand it, Sugargame puts a gtk.socket into an eventbox, and the event box is loaded into the XO's VBox by the sugar.graphics.window.set_canvas function -- which is a super of sugar.activity.activity. In sugargame/canvas.py line 41 self._socket.get_window().set_cursor(None) AttributeError: 'gtk.Socket' object has no attribute 'get_window' If I understand the problem, you are trying to use that method in a version that still hasn't have it: http://www.pygtk.org/docs/pygtk/class-gtkwidget.html#method-gtkwidget--get-window PyGtk 2.14 was released in January 2009 so cannot be in F9-based 8.2.x as per: http://koji.fedoraproject.org/koji/packageinfo?packageID=53 Regards, Tomeu This is after an environment variable SDL_WINDOWID has been passed to the pygame.init() routine, (I guess pygame uses this ID to create the gtk.Plug(). What works on the 1.5 (test.activity, and demoiselle.activity, and my application) gtk.ver = 2.16.1 pygame.ver = 1.8.1 What doesn't work on 1.0XO build 802: (all three of these fail with the above AttributeError) gtk.ver = 2.14.2 pygame.ver = 1.8.0 I looked into putting the pygame 1.9.1 on Build 802, but there were dependencies more than just SDL-devel, and I've still got the nagging feeling that I'm missing something simple (the test.activity was probably tested on build 802) Any insight, advice would be appreciated, George ___ 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] Displaying the current status of system resources (such as memory, cpu)
On Wed, Jun 16, 2010 at 07:55, James Cameron qu...@laptop.org wrote:
On Wed, Jun 16, 2010 at 03:18:31AM +0530, Anish Mangal wrote:
Sugar presently lacks a means to display the current status of system
resources such as free memory, CPU load, etc. I'd like form an opinion
as to what should be the ideal way to make these numbers available to
the user.
Frame slider showing percentage available memory.
CPU load is unimportant. Most problems occur as a result of depletion
of memory.
Here's some simple and quick code to measure the available memory and
return a percentage:
def percentage_memory_available():
for line in file('/proc/meminfo').readlines():
name, value, unit = line.split()[:3]
if 'MemTotal:' == name: total = value
elif 'MemFree:' == name: free = value
elif 'Buffers:' == name: buffers = value
elif 'Cached:' == name: cached = value
elif 'Active:' == name: break
return 100 * (int(free)+int(buffers)+int(cached)) / int(total)
Free, buffers, and cached are added because these are what an activity
is easily able to consume if it makes a demand for memory.
I'd also like to have a mode where a warning message is displayed.
I've also tested some systems with a sound emitted where the frequency
is chosen based on the memory available. This gives very nice feedback
about what is happening on a system without interfering with the
display.
I would agree with James in that the amount of free memory is probably
the most useful metric we can provide. Wonder if we could tie it
graphically with activity launching.
I also agree with Tony in that though we have space in the frame right
now for more device icons, it's a resource that will be quickly scarce
if we don't think of alternatives.
Also wonder if according to the guiding principle of low-floor
high-ceiling we could find a place for this feature so it doesn't
raise the floor but it's there as a smoother next step than having to
use the terminal.
Regards,
Tomeu
--
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 mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine
On Sun, Jun 6, 2010 at 15:33, Lucian Branescu lucian.brane...@gmail.com wrote: I've received even less feedback from upstreams about their respective engines. There are still 2 issues: 1) Mozilla have given up on having xulrunner work as a distro-provided VM and now they just bundle it.. They plan some major changes to embedding and they have no plan forward that would allow hulahop to exist. It's no longer just about maintaining hulahop, but the entire stack up from gecko. 2) pywebkitgtk does not have a clear future. The changelog shows activity, but stable maintenance is not assured 3) webkitgtk+ and PyGI might be the best solution, but it doesn't yet work everywhere. From a technical p.o.v. the bits missing from PyGI should not (significantly) hinder Browse, since web engines tend to have comparatively little interaction with their GUIs. Right now, the only option that would actually works everywhere we care about is pywebkitgtk. While it may not be future-proof, PyGI would be targeting the same webkit API, so switching should be very easy. Just wanted to make sure you know that the pywebkitgtk+ maintainer recommends using PyGI instead: http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/ That was written in January and since then PyGI has progressed greatly. I personally think that you should have less concerns than other people that are moving to PyGI right now. As a general remark, I don't think it's a good idea to cling to software modules whose authors are so willing to drop down and will be less painful in the medium term if people start moving now. That said, it hasn't been decided yet that Sugar will depend on PyGI from 0.90 on (see a new thread from today). Regards, Tomeu Since it's already late into the project, unless someone has a better idea, I'll stick to fully porting Browse to pywebkitgtk, using any Surf code that is relevant. This should result in a fully-working Browse with SSB features in time for GSoC that also has a clear enough future. On 31 May 2010 13:41, Lucian Branescu lucian.brane...@gmail.com wrote: Since I got little feedback about the time, there will be a meeting in #sugar-meeting at 3PM GMT On 31 May 2010 10:09, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, May 30, 2010 at 01:58, Lucian Branescu lucian.brane...@gmail.com wrote: In case you don't already know, I'm doing a GSoC project on improving the browser engine situation in Sugar http://wiki.sugarlabs.org/go/Summer_of_Code/2010/AbstractBrowser My exams haven't finished yet (last one on Wednesday), so before I start working, I want the opinion of people that use web engines in sugar applications or that are otherwise interested in web engines for sugar on how to proceed. I'd like answers to questions like Should I drop hulahop and focus on webkit? or Is an API like hulahop's nice?, etc. What we need to find out in order to find the right answers to that is what's the future of xulrunner. If Mozilla plans to drop some part of their platform essential for hulahop, or if distros are not willing to keep packaging it in a way that hulahop can work, then we should just forget about it and move to webkit. I'd like to set up a meeting on #sugar-meeting on Monday between 9 AM and 9 PM GMT, depending on the availability of attendees. Great idea! Regards, Tomeu Individual chats/ml are also welcome, but an IRC meeting would be ideal. ___ 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] depending on introspection
Excerpts from Tomeu Vizoso's message of Wed Jun 16 09:27:17 + 2010: anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? What are the required packages (including minimum version numbers)? How stable are the APIs? The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. How backwards-compatible is the introspection stuff? I.e. how much effort would it be to support both? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Sugar-Devel] Sugar Web Engine
Unfortunately, that doesn't solve any of my problems. I would gladly drop hulahop entirely (it's a mess and very low-level), but several people have expressed concern that gecko might be a better choice long-term. However, I have not been able to confirm any of their performance concerns. In my tests, gecko always used more memory and was much slower than webkit. Also, xulrunner is made first for firefox and second for embedding, and it shows painfully. On the other hand, I can't decide by myself to use PyGI since it's too experimental for a platform's main browser and the rest of Sugar doesn't use it. However, the API of pywebkitgtk would be similar to webkitgtk+PyGI, so switching later on shouldn't be very hard. Especially since pywebkitgtk's author himself already did it. Because of various hulahop xpcom quirks, webwrap (the abstraction layer) is proving increasingly hard to write. I will give it a few more days, but if I can't figure out a clean way to wrab both hulahop and pywebkitgtk I'll drop hulahop entirely and let any future switching back to hulahop rely on git. On 16 Jun 2010 11:07, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Jun 6, 2010 at 15:33, Lucian Branescu lucian.brane...@gmail.com wrote: I've received eve... Just wanted to make sure you know that the pywebkitgtk+ maintainer recommends using PyGI instead: http://janalonzo.wordpress.com/2010/01/18/using-introspected-webkitgtk-in-gwibber/ That was written in January and since then PyGI has progressed greatly. I personally think that you should have less concerns than other people that are moving to PyGI right now. As a general remark, I don't think it's a good idea to cling to software modules whose authors are so willing to drop down and will be less painful in the medium term if people start moving now. That said, it hasn't been decided yet that Sugar will depend on PyGI from 0.90 on (see a new thread from today). Regards, Tomeu Since it's already late into the project, unless someone has a better idea, I'll stick to fully... ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Taking over Browse maintainership
On Wed, Jun 16, 2010 at 3:08 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: [Resend because mail with non-subscribed sender address was silented dropped] Since Browse has been unmaintained for several months [1] now, Lucian and I finally decided to step up as maintainers. This does NOT mean the current Browse will see a lot of improvements or even just bug fixes, as we are both already rather busy. We will, however, handle patches to the best of our abilities and maybe do some minor changes (e.g. include the CAcert root certs) or trivial fixes. For those who don't know yet: Lucian is working [2] on an abstraction layer that will allow Browse to use WebKit (or xulrunner, should anyone want to ;) ) as part of this years GSoC. He already worked on adding SSB support [3] to Browse during last years GSoC. I'll let these facts speak for themselves. :) Thanks for accepting responsibility for this critical activity. The combination of your general Sugar Labs expertise and Lucian's browser expertise will make an excellent team. david If someone else would like to maintain (or co-maintain) Browse, please speak up now. Sascha [1] http://wiki.sugarlabs.org/index.php?title=Development_Team/Release/Modulesdiff=44090oldid=37446 [2] http://wiki.sugarlabs.org/go/Summer_of_Code/2010/Abstract_Browser [3] http://wiki.sugarlabs.org/go/Webified -- 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Taking over Browse maintainership
On Wed, Jun 16, 2010 at 12:50, David Farning dfarn...@gmail.com wrote: On Wed, Jun 16, 2010 at 3:08 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: [Resend because mail with non-subscribed sender address was silented dropped] Since Browse has been unmaintained for several months [1] now, Lucian and I finally decided to step up as maintainers. This does NOT mean the current Browse will see a lot of improvements or even just bug fixes, as we are both already rather busy. We will, however, handle patches to the best of our abilities and maybe do some minor changes (e.g. include the CAcert root certs) or trivial fixes. For those who don't know yet: Lucian is working [2] on an abstraction layer that will allow Browse to use WebKit (or xulrunner, should anyone want to ;) ) as part of this years GSoC. He already worked on adding SSB support [3] to Browse during last years GSoC. I'll let these facts speak for themselves. :) Thanks for accepting responsibility for this critical activity. The combination of your general Sugar Labs expertise and Lucian's browser expertise will make an excellent team. Excellent, unless someone speaks up against it, please update this page: http://wiki.sugarlabs.org/go/Development_Team/Release/Modules Thanks, Tomeu david If someone else would like to maintain (or co-maintain) Browse, please speak up now. Sascha [1] http://wiki.sugarlabs.org/index.php?title=Development_Team/Release/Modulesdiff=44090oldid=37446 [2] http://wiki.sugarlabs.org/go/Summer_of_Code/2010/Abstract_Browser [3] http://wiki.sugarlabs.org/go/Webified -- 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 ___ 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] [SoaS] Your thoughts on My proposed feature Revised_Browse_default-bookmarks
Sascha: Thanks for the feedback. I met with mchua this morning on #sugar-meeting and It looks like the proposal is to just add 1 item to existing Browse start new screen for the Soas Spin only. A Crude mock up is available at http://people.sugarlabs.org/Tgillard/index6.html The idea is to add this Menu link to the existing screen and point it to http://wiki.sugarlabs.org/go/Sugar_Creation_Kit#Introduction Cordially; Tom Gilliard satellit Sascha Silbe wrote: Excerpts from Thomas C Gilliard's message of Wed Jun 16 09:52:51 + 2010: I would appreciate input on my proposal to modify the index.html in the Browse.activity for the fedora spins Soas .iso I'm not part of the SoaS team and can't speak for them. As for upstream Browse: if the Design Team decides on a new start page, I'll be happy to include it. Sorry to just refer you to other people - I appreciate the work you did, but the Browse start page is the first thing users see when starting Browse (and maybe even one of the first few things people see when starting to use Sugar), so we should craft it carefully. AFAIK quite a bit of thought has gone into the current design. I suggest gradually improving it rather than starting over with a cluttered page (as your screenshot suggests). A good next step would be to call for a design meeting. There are already enough topics (touchscreen support for example) queued up to fill more than one meeting and we haven't had one for quite a while. Sascha ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GNOME and protecting Sugar --
On Tue, Jun 15, 2010 at 8:17 PM, Bernie Innocenti ber...@codewiz.org wrote: During the last development cycle we lacked the time to lock-down GNOME a little more and we're still paying the consequences :-( Ouch. - Were there any other problems? Solutions? Indeed, some kids manage to do damage Sugar, with or without intention. More frequently, they mess up the panel icons in ways that make it difficult to restore functionality. Mess up the panel icons in Sugar or in Gnome? In one case, a kid managed to click Disable Networking in nm-applet and then switch back to Sugar. Not Disable Wireless, that would have been easy! It took me one hour of debugging to figure that out. That would be in Gnome. Everyone, including teachers and teacher trainers, manages to fill up the filesystem with large multimedia files downloaded from the Internet, solowing down the system due to frequent jffs2 garbage collections. That has nothing to do with Gnome. In some cases, it's not the user's fault: various programs, including Firefox and Browse, can hide up to 50MB of junk in dot-files. Clever users managed to discover some of these locations and passed the word. Good to know. Still, not much to do with Gnome. ... To mitigate the problem: - lock down the panel: http://library.gnome.org/admin/deployment-guide/ - add a panic button to olpc-configure which would bring up a text menu with various recovery functions, such as resetting GNOME configuration to its default and clearing temporary caches. - remove the desktop switcher icon from the Sugar control panel give the field technicians a secret shell command to restore it. This should prevent children who are too young to figure it out. - Hide the Activities. We can't really make them read-only or immutable because the updater runs as user olpc. - Also hide .sugar Ok -- that's a good initial guide - thanks! m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Taking over Browse maintainership
Excerpts from Tomeu Vizoso's message of Wed Jun 16 11:00:27 + 2010: Excellent, unless someone speaks up against it, please update this page: http://wiki.sugarlabs.org/go/Development_Team/Release/Modules Done. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New ASLO features to implement
El Tue, 15-06-2010 a las 22:31 +, Aleksey Lim escribió: Here it is my preliminary TODO (not prioritized list): * Support(revert) of per architecture uploads, there are bunch of activities that are binaries and having requirement to have all supported blobs could be overkill for uploaders. +1 * Support per languages uploads. In some cases (GCompris, OOo4Kids) all languages in one bundle weights too much and per locale bundles makes sense. While downloading, ASLO will suggest only current locale bundle. +1 (does upstream remora already provide this?) * By default, ASLO just an repository of activities (not regarding their stability status) and anonymous downloading is required (for now, experimental downloads requires be logged in). +1 on allowing anonymous download of any bundle, regarding its stable/experimental status. -1 on showing experimental activity bundles as the default download for activities. Probably, even maintainers should go through a peer review process. * Current QA[1] scheme is too weak for deployment(various) needs and having previous option, more reliable scheme is required. Current plan is implementing QA profiles. Every activity could be stamped (from -n to +n) in several QA profiles. QA stamp is not part of activity itself and could be set by QA editors in any time. User can nominate activity to be stamped in several QA profiles to notify QA editors about new activity. QA editors will be notified about new version of already stamped activities via a...@. Perhaps a simpler scheme to implement, which would be sufficient to fulfill our needs would be adding the ability to specify exact versions of bundles in collections. Then, we could simply point the updater to a page like this: http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88 The deployment people would keep the versions updated after doing their QA on activities. * Support microformat for OLPC updater. Also support collections as microformat groups. Take into account QA profiles. +1 It could be not full list of required features. If you are interested in some ASLO improvements, post an comment. Thanks Aleksey, recapitulating this list of requirements was indeed very helpful. I'll try to find a php developer to help out implementing these features ASAP. Can we make them work in the activities-devel sandbox on sunjammer? [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] VncLauncher doesn't run on F11
El Tue, 27-04-2010 a las 15:27 +0100, Peter Robinson escribió: On Tue, Apr 27, 2010 at 3:06 PM, Daniel Drake d...@laptop.org wrote: Hi, Using VncLauncher-4 on F11: it fails to start the VNC server because the binary links against the wrong version of libssl. This activity is used very often in deployments for presentations, training sessions, etc, so it would be nice to have a new version. Some time around F-11 Fedora moved from the standard vnc to tigervnc for various different reasons (don't remember the exact time or reasons). Do any of the tigervnc* packages provide the same functionality? Carlos created a new bundle with an updated libssl. It should already be available from ASLO. Carlos? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
On Wed, Jun 16, 2010 at 11:27 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. I think its inevitable that we go that route. The only suggestion I would ask about is the requirements to be able to support it on RHEL/CentOS 6. Fedora 12/13 already had some introspection support so is it much different in requirements to those in the initial implementaiton as I think for long running suppor I believe there is a desire to be able to use that platform. If they are new packages we can easily add them into EPEL so that´s not too much of an issue, the issue comes is if the upstream package is in RHEL mainline that we can´t duplicate it. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)
El Wed, 16-06-2010 a las 09:17 +1000, fors...@ozonline.com.au escribió: Time and date would be good. Good catch :-) I am not sure how important memory and cpu are to the average user but there's plenty of room in the frame at the moment. Any extra displayed data adds to the cognitive load of the beginner but the frame probably contains stuff that the beginner can just ignore and explore at their leisure. Maybe default as not displayed but have the frame items which are displayed configurable through control panel? In order to show the correct time, we first need to add another missing feature to Sugar: time-zone configuration. Who would like to take this task? Hopefully, manual configuration of time and date isn't that critical for connected laptops. Does the xs run an ntp service? Making 1000 laptops from the same school go query a public ntp server is a silly waste of bandwidth. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)
On Wed, 16 Jun 2010 11:55:25 +0200, Tomeu Vizoso to...@sugarlabs.org
wrote:
On Wed, Jun 16, 2010 at 07:55, James Cameron qu...@laptop.org wrote:
On Wed, Jun 16, 2010 at 03:18:31AM +0530, Anish Mangal wrote:
Sugar presently lacks a means to display the current status of system
resources such as free memory, CPU load, etc. I'd like form an opinion
as to what should be the ideal way to make these numbers available to
the user.
Frame slider showing percentage available memory.
CPU load is unimportant. Most problems occur as a result of depletion
of memory.
Here's some simple and quick code to measure the available memory and
return a percentage:
def percentage_memory_available():
for line in file('/proc/meminfo').readlines():
name, value, unit = line.split()[:3]
if 'MemTotal:' == name: total = value
elif 'MemFree:' == name: free = value
elif 'Buffers:' == name: buffers = value
elif 'Cached:' == name: cached = value
elif 'Active:' == name: break
return 100 * (int(free)+int(buffers)+int(cached)) / int(total)
Free, buffers, and cached are added because these are what an activity
is easily able to consume if it makes a demand for memory.
I'd also like to have a mode where a warning message is displayed.
I've also tested some systems with a sound emitted where the frequency
is chosen based on the memory available. This gives very nice feedback
about what is happening on a system without interfering with the
display.
I would agree with James in that the amount of free memory is probably
the most useful metric we can provide. Wonder if we could tie it
graphically with activity launching.
Assuming theres are no heavy weight processing Activities in sugar, the
memory alone is useful enough. My concern is, how to display this concept?
I'm not sure if everyone will agree on this, but the users here (in
Paraguay), are kids that (mostly) have never seen a computer, so, using
conventional units or percentage is not going to help much, at least not
for younger kids. A graphical gauge is probably the best way.
Game interfaces often translate complex concepts using graphical metaphors
such as The face of your hero become more tired or title smokes coming
from a damage car, etc. If we could somehow personify the computer, it
would let us report its status very intuitively.
Keep in mind this is just an idea. And at this time anything would better
than have absolutely nothing.
I also agree with Tony in that though we have space in the frame right
now for more device icons, it's a resource that will be quickly scarce
if we don't think of alternatives.
Also wonder if according to the guiding principle of low-floor
high-ceiling we could find a place for this feature so it doesn't
raise the floor but it's there as a smoother next step than having to
use the terminal.
Regards,
Tomeu
--
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 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] depending on introspection
On Wed, Jun 16, 2010 at 4:00 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: On Wed, Jun 16, 2010 at 15:17, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 11:27 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. I think its inevitable that we go that route. The only suggestion I would ask about is the requirements to be able to support it on RHEL/CentOS 6. Fedora 12/13 already had some introspection support so is it much different in requirements to those in the initial implementaiton as I think for long running suppor I believe there is a desire to be able to use that platform. If they are new packages we can easily add them into EPEL so that´s not too much of an issue, the issue comes is if the upstream package is in RHEL mainline that we can´t duplicate it. Hmm, I think we would need newer glib and pygobject. Would that be possible? If so, then by staying with gtk+ 2.0 versions of all the libraries we could run on RHEL, but from what I have read in desktop-devel, not all maintainers are keen on doing that. How bad would be the consequences of Sugar 0.90 requiring components only in GNOME 3.x? I´m not sure to be honest. I think we´ll only be able to tell that properly once RHEL-6 is out, it is anyone´s guess as to what their plan is with the desktop side of it. Being desktop its possible that if its not supported initially that support will be added later as it doesn´t impact the server side so much. Its something worth considering but I don´t believe it should be the only consideration. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
On Wed, Jun 16, 2010 at 15:17, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 11:27 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. I think its inevitable that we go that route. The only suggestion I would ask about is the requirements to be able to support it on RHEL/CentOS 6. Fedora 12/13 already had some introspection support so is it much different in requirements to those in the initial implementaiton as I think for long running suppor I believe there is a desire to be able to use that platform. If they are new packages we can easily add them into EPEL so that´s not too much of an issue, the issue comes is if the upstream package is in RHEL mainline that we can´t duplicate it. Hmm, I think we would need newer glib and pygobject. Would that be possible? If so, then by staying with gtk+ 2.0 versions of all the libraries we could run on RHEL, but from what I have read in desktop-devel, not all maintainers are keen on doing that. How bad would be the consequences of Sugar 0.90 requiring components only in GNOME 3.x? Regards, Tomeu Peter ___ 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] New ASLO features to implement
Alexsey; Maybe simple preliminary workaround for incompatible activity downloads: Could a Group of working activities be created for each sugar version ie 0.84/0.86/0.88 to be selected by user on opening ASLO? Tom Gilliard satellit Bernie Innocenti wrote: El Tue, 15-06-2010 a las 22:31 +, Aleksey Lim escribió: Here it is my preliminary TODO (not prioritized list): * Support(revert) of per architecture uploads, there are bunch of activities that are binaries and having requirement to have all supported blobs could be overkill for uploaders. +1 * Support per languages uploads. In some cases (GCompris, OOo4Kids) all languages in one bundle weights too much and per locale bundles makes sense. While downloading, ASLO will suggest only current locale bundle. +1 (does upstream remora already provide this?) * By default, ASLO just an repository of activities (not regarding their stability status) and anonymous downloading is required (for now, experimental downloads requires be logged in). +1 on allowing anonymous download of any bundle, regarding its stable/experimental status. -1 on showing experimental activity bundles as the default download for activities. Probably, even maintainers should go through a peer review process. * Current QA[1] scheme is too weak for deployment(various) needs and having previous option, more reliable scheme is required. Current plan is implementing QA profiles. Every activity could be stamped (from -n to +n) in several QA profiles. QA stamp is not part of activity itself and could be set by QA editors in any time. User can nominate activity to be stamped in several QA profiles to notify QA editors about new activity. QA editors will be notified about new version of already stamped activities via a...@. Perhaps a simpler scheme to implement, which would be sufficient to fulfill our needs would be adding the ability to specify exact versions of bundles in collections. Then, we could simply point the updater to a page like this: http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88 The deployment people would keep the versions updated after doing their QA on activities. * Support microformat for OLPC updater. Also support collections as microformat groups. Take into account QA profiles. +1 It could be not full list of required features. If you are interested in some ASLO improvements, post an comment. Thanks Aleksey, recapitulating this list of requirements was indeed very helpful. I'll try to find a php developer to help out implementing these features ASAP. Can we make them work in the activities-devel sandbox on sunjammer? [1] http://wiki.sugarlabs.org/go/Activity_Library/Editors/Policy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
On Wed, Jun 16, 2010 at 16:28, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 4:00 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: On Wed, Jun 16, 2010 at 15:17, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 11:27 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. I think its inevitable that we go that route. The only suggestion I would ask about is the requirements to be able to support it on RHEL/CentOS 6. Fedora 12/13 already had some introspection support so is it much different in requirements to those in the initial implementaiton as I think for long running suppor I believe there is a desire to be able to use that platform. If they are new packages we can easily add them into EPEL so that´s not too much of an issue, the issue comes is if the upstream package is in RHEL mainline that we can´t duplicate it. Hmm, I think we would need newer glib and pygobject. Would that be possible? If so, then by staying with gtk+ 2.0 versions of all the libraries we could run on RHEL, but from what I have read in desktop-devel, not all maintainers are keen on doing that. How bad would be the consequences of Sugar 0.90 requiring components only in GNOME 3.x? I´m not sure to be honest. I think we´ll only be able to tell that properly once RHEL-6 is out, it is anyone´s guess as to what their plan is with the desktop side of it. Being desktop its possible that if its not supported initially that support will be added later as it doesn´t impact the server side so much. Its something worth considering but I don´t believe it should be the only consideration. Just asked in #fedora-desktop: tomeu I guess we cannot expect a complete introspection stack in RHEL? walters tomeu: nope, unfortunately walters but for fedora 14 ideally it's essentially finished Colin cares mostly about gjs, but my impression of PyGI is that it will be feature complete in F14 as well. Regards, Tomeu Peter ___ 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] depending on introspection
On Wed, Jun 16, 2010 at 4:33 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: On Wed, Jun 16, 2010 at 16:28, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 4:00 PM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: On Wed, Jun 16, 2010 at 15:17, Peter Robinson pbrobin...@gmail.com wrote: On Wed, Jun 16, 2010 at 11:27 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. I think its inevitable that we go that route. The only suggestion I would ask about is the requirements to be able to support it on RHEL/CentOS 6. Fedora 12/13 already had some introspection support so is it much different in requirements to those in the initial implementaiton as I think for long running suppor I believe there is a desire to be able to use that platform. If they are new packages we can easily add them into EPEL so that´s not too much of an issue, the issue comes is if the upstream package is in RHEL mainline that we can´t duplicate it. Hmm, I think we would need newer glib and pygobject. Would that be possible? If so, then by staying with gtk+ 2.0 versions of all the libraries we could run on RHEL, but from what I have read in desktop-devel, not all maintainers are keen on doing that. How bad would be the consequences of Sugar 0.90 requiring components only in GNOME 3.x? I´m not sure to be honest. I think we´ll only be able to tell that properly once RHEL-6 is out, it is anyone´s guess as to what their plan is with the desktop side of it. Being desktop its possible that if its not supported initially that support will be added later as it doesn´t impact the server side so much. Its something worth considering but I don´t believe it should be the only consideration. Just asked in #fedora-desktop: tomeu I guess we cannot expect a complete introspection stack in RHEL? walters tomeu: nope, unfortunately walters but for fedora 14 ideally it's essentially finished Colin cares mostly about gjs, but my impression of PyGI is that it will be feature complete in F14 as well. If its feature complete in time for gnome 3 it will be feature complete in F'14. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GNOME and protecting Sugar --
El Wed, 16-06-2010 a las 08:19 -0400, Martin Langhoff escribió: Indeed, some kids manage to do damage Sugar, with or without intention. More frequently, they mess up the panel icons in ways that make it difficult to restore functionality. Mess up the panel icons in Sugar or in Gnome? In GNOME. If you try hard enough, apparently you can make some icons become invisible and unreachable even though they're somewhere in the panel. Everyone, including teachers and teacher trainers, manages to fill up the filesystem with large multimedia files downloaded from the Internet, solowing down the system due to frequent jffs2 garbage collections. That has nothing to do with Gnome. The problem is applications bypassing the journal: it becomes hard to hunt down these files to reclaim the space. In some cases, it's not the user's fault: various programs, including Firefox and Browse, can hide up to 50MB of junk in dot-files. Clever users managed to discover some of these locations and passed the word. Good to know. Still, not much to do with Gnome. Yes, it's the individual applications, but it's hard for users to figure out why the disk became full after using Firefox, and how to solve the problem. If users learn that deleting random dot files in their homes could fix problems, there's a risk that they will try to delete them at random. Ok -- that's a good initial guide - thanks! Let me know if you do some work in this direction, I'd be very interested in joining efforts. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
+1 PyGI as a working dependency would make Browse work somewhat easier and would assure Browse's future. On 16 June 2010 10:27, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: Hi, anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. Thanks, Tomeu ___ 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] 0.88 Activities Font Size Problems
On 06/16/2010 05:34 AM, Tomeu Vizoso wrote: Hola Jorge, On Tue, Jun 15, 2010 at 22:04, Jorge Saldivarjorgesaldi...@gmail.com wrote: Hi all, sorry for bothering. We are having problems with the fonts size in activities toolbars, tooltips, buttons labels, and all the things related with the activities main window. It is a really strange problem because it only happend inside the activities not in sugar desktop where the fonts size are ok. I made some modifications via gconf with gconftool but the changes only affects the fonts size in sugar desktops. Look up the images attached where you can see the differences font sizes between desktop and activities. Someone have any ideas about it?, may be something related with the sugar setting manager? Could you please paste here the output of the 'printenv' command when executed inside the Terminal activity? Thanks for answer Tomeu! Here the output of printenv HOSTNAME=xo-35-83-92.localdomain TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=192.168.0.176 51554 22 SSH_TTY=/dev/pts/0 USER=olpc LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;3 5:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: MAIL=/var/spool/mail/olpc PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/olpc/bin PWD=/home/olpc PYTHONOPTIMIZE=2 LANG=en_US.utf8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/home/olpc LOGNAME=olpc SSH_CONNECTION=192.168.0.176 51554 192.168.0.200 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/usr/bin/printenv Thanks, Tomeu -- Jorge A. Saldivar G. (jasg) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Jorge A. Saldivar G (jasg).- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GNOME and protecting Sugar --
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2010 10:39 AM, Bernie Innocenti wrote: Yes, it's the individual applications, but it's hard for users to figure out why the disk became full after using Firefox, and how to solve the problem. Try http://en.wikipedia.org/wiki/Baobab_(software) if you want something GUI-oriented that will show you what's using your disk. - -- Luke Faraone http://luke.faraone.cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwY5QsACgkQtrC51grHAgbwOwCgmZcreXq5f8oGnML9S3OU5TD2 WOQAn1jcraKZ9+t7SoXlkJlwEeLgOVBW =yRHT -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
I don't know about RH, but @ litl we're using all-introspected bindings w/ a distro based on Ubuntu Hardy. So backporting shouldn't be too painful, really. (Of course, we're not using the python introspection, so you might have other troubles there.) +1 on introspection in general. Hopefully the python introspection support is sufficiently lazy -- we certainly haven't had any startup issues w/ gjs. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.88 Activities Font Size Problems
On Wed, Jun 16, 2010 at 16:41, Jorge Saldivar jorgesaldi...@gmail.com wrote: On 06/16/2010 05:34 AM, Tomeu Vizoso wrote: Hola Jorge, On Tue, Jun 15, 2010 at 22:04, Jorge Saldivarjorgesaldi...@gmail.com wrote: Hi all, sorry for bothering. We are having problems with the fonts size in activities toolbars, tooltips, buttons labels, and all the things related with the activities main window. It is a really strange problem because it only happend inside the activities not in sugar desktop where the fonts size are ok. I made some modifications via gconf with gconftool but the changes only affects the fonts size in sugar desktops. Look up the images attached where you can see the differences font sizes between desktop and activities. Someone have any ideas about it?, may be something related with the sugar setting manager? Could you please paste here the output of the 'printenv' command when executed inside the Terminal activity? Thanks for answer Tomeu! Here the output of printenv Are you sure this is from the Terminal activity? I'm specially interested in the env vars SUGAR_SCALING and GTK2_RC_FILES. Regards, Tomeu HOSTNAME=xo-35-83-92.localdomain TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=192.168.0.176 51554 22 SSH_TTY=/dev/pts/0 USER=olpc LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: MAIL=/var/spool/mail/olpc PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/olpc/bin PWD=/home/olpc PYTHONOPTIMIZE=2 LANG=en_US.utf8 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass SHLVL=1 HOME=/home/olpc LOGNAME=olpc SSH_CONNECTION=192.168.0.176 51554 192.168.0.200 22 LESSOPEN=|/usr/bin/lesspipe.sh %s G_BROKEN_FILENAMES=1 _=/usr/bin/printenv Thanks, Tomeu -- Jorge A. Saldivar G. (jasg) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Jorge A. Saldivar G (jasg).- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
On Wed, Jun 16, 2010 at 16:59, C. Scott Ananian csc...@laptop.org wrote: I don't know about RH, but @ litl we're using all-introspected bindings w/ a distro based on Ubuntu Hardy. So backporting shouldn't be too painful, really. glib sounds to me like the most problematic dependency to backport. I think RHEL's case is a bit different because litl OS is used only by litl but RHEL is supposed to be used in wildly different use cases. But well, that decision belongs to RH. (Of course, we're not using the python introspection, so you might have other troubles there.) +1 on introspection in general. Hopefully the python introspection support is sufficiently lazy -- we certainly haven't had any startup issues w/ gjs. Right now we lazily import anything in the module scope, and eagerly anything inside classes, etc. But this should be reconsidered again when we start profiling real-life apps. There's certainly a big reduction in the work performed at process startup, but the biggest advantage IMO is memory usage. Regards, Tomeu --scott -- ( http://cscott.net/ ) ___ 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] depending on introspection
On 16 June 2010 04:27, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: anybody has thoughts about the convenience (or not) of making Sugar depend on the introspection stack in GNOME 3.0? The biggest practical downside will be that Sugar 0.90 will only run on next-cycle distros (Fedora 14, Ubuntu Maverick, etc) unless people backport a lot of other packages (not recommended nor likely). The upsides include: gradually dropping static bindings which are generally unmaintained, less memory use, less cpu usage during startup, access to new APIs such as GSettings and Telepathy-GLib. These improvements sound really worthwhile, and if the technology is in F14 then it sounds mature enough as well. If someone is prepared to do the work I don't think they should feel held back by the concerns about backporting difficulties (thats not your problem) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] HippoCanvas 0.3.1
On 06/15/2010 03:01 PM, Tomeu Vizoso wrote: Hi, a new version of HippoCanvas has been released, get it at: http://ftp.gnome.org/pub/GNOME/sources/hippo-canvas/0.3/ Changes are basically bug fixes and improvements to introspection support. Packagers should be aware that the required PyGObject version has been updated to 2.21.2. Regards, Tomeu Congrats to that work! Happy that there is so much good work being done on the introspection front. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Taking over Browse maintainership
On 06/16/2010 10:08 AM, Sascha Silbe wrote: [Resend because mail with non-subscribed sender address was silented dropped] Since Browse has been unmaintained for several months [1] now, Lucian and I finally decided to step up as maintainers. This does NOT mean the current Browse will see a lot of improvements or even just bug fixes, as we are both already rather busy. We will, however, handle patches to the best of our abilities and maybe do some minor changes (e.g. include the CAcert root certs) or trivial fixes. For those who don't know yet: Lucian is working [2] on an abstraction layer that will allow Browse to use WebKit (or xulrunner, should anyone want to ;) ) as part of this years GSoC. He already worked on adding SSB support [3] to Browse during last years GSoC. I'll let these facts speak for themselves. :) If someone else would like to maintain (or co-maintain) Browse, please speak up now. Sascha These are great news, indeed! I very much appreciate as well how you present your proposal and second your plan on how to maintain the activity. At the moment, it is important to do the minimum to keep it alive. As well sharing the load by having a peer is a really good idea. If we have others following your example we will be in a much better position soon. Thanks to you Sascha and Lucian! Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 0.88 Activities Font Size Problems
On 06/16/2010 11:19 AM, Tomeu Vizoso wrote: On Wed, Jun 16, 2010 at 17:08, Jorge Saldivarjorgesaldi...@gmail.com wrote: On 06/16/2010 11:00 AM, Tomeu Vizoso wrote: On Wed, Jun 16, 2010 at 16:41, Jorge Saldivarjorgesaldi...@gmail.com wrote: On 06/16/2010 05:34 AM, Tomeu Vizoso wrote: Hola Jorge, On Tue, Jun 15, 2010 at 22:04, Jorge Saldivarjorgesaldi...@gmail.com wrote: Hi all, sorry for bothering. We are having problems with the fonts size in activities toolbars, tooltips, buttons labels, and all the things related with the activities main window. It is a really strange problem because it only happend inside the activities not in sugar desktop where the fonts size are ok. I made some modifications via gconf with gconftool but the changes only affects the fonts size in sugar desktops. Look up the images attached where you can see the differences font sizes between desktop and activities. Someone have any ideas about it?, may be something related with the sugar setting manager? Could you please paste here the output of the 'printenv' command when executed inside the Terminal activity? Thanks for answer Tomeu! Here the output of printenv Are you sure this is from the Terminal activity? I'm specially interested in the env vars SUGAR_SCALING and GTK2_RC_FILES. Sorry, I ran from bash. Here from Terminal activity Ah, this changed in 0.88: http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/96bbf75d78c64ec51350db752997d48dd0e47ca9 http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/commits/634b2fce So you can change the font size in GConf. I made some changes with gconftools-2, for example: 'gconftool-2 -s -t float /desktop/sugar/font/default_size 8.0' but it only affects the fonts size in sugar desktops and journals not activities. May be we don't have the last activity.py version. Thanks! Regards, Tomeu ORBIT_SOCKETDIR=/tmp/orbit-olpc SUGAR_BUNDLE_PATH=/home/olpc/Activities/Terminal.activity IMSETTINGS_INTEGRATE_DESKTOP=yes SUGAR_SCALING=100 SUGAR_BUNDLE_NAME=Terminal TERM=xterm SHELL=/bin/bash XDG_SESSION_COOKIE=f66e720b1d031a2d1ab007bc4c155e28-1276555406.495782-1221639328 GTK2_RC_FILES=/usr/share/sugar/data/sugar-100.gtkrc IMSETTINGS_MODULE=none USER=olpc LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=0 1;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: SUGAR_BUNDLE_ID=org.laptop.Terminal SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1833,unix/unix:/tmp/.ICE-unix/1833 USERNAME=olpc PATH=/usr/local/sbin:/usr/sbin:/sbin:/home/olpc/Activities/Terminal.activity/bin:/usr/bin:/bin:/sbin:/usr/sbin QT_IM_MODULE=xim XSERVERAUTH=/var/tmp/olpc-auth/.Xserverauth PWD=/home/olpc SUGAR_ACTIVITY_ROOT=/home/olpc/.sugar/default/org.laptop.Terminal xmodifie...@im=none PYTHONOPTIMIZE=2 LANG=es_UY.UTF-8 TZ=UTC SUGAR_BUNDLE_VERSION=31 SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass ICEAUTHORITY=/var/tmp/olpc-auth/.ICEauthority HOME=/home/olpc SHLVL=1 LANGUAGE=es_UY.UTF-8 LOGNAME=olpc DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-haWEkWawLS,guid=9b7fdfcad9b3f1f6cd8d69a64c16b090 LESSOPEN=|/usr/bin/lesspipe.sh %s DISPLAY=:0 GTK_IM_MODULE=gtk-im-context-simple SUGAR_LOCALEDIR=/home/olpc/Activities/Terminal.activity/locale G_BROKEN_FILENAMES=1 XAUTHORITY=/var/tmp/olpc-auth/.Xauthority _=/usr/bin/printenv Thanks!, regards! Regards, Tomeu HOSTNAME=xo-35-83-92.localdomain TERM=xterm SHELL=/bin/bash HISTSIZE=1000 SSH_CLIENT=192.168.0.176 51554 22 SSH_TTY=/dev/pts/0 USER=olpc
Re: [Sugar-devel] [ASLO] Release Abacus-13
On 06/10/2010 05:30 PM, Sugar Labs Activities wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4293 Sugar Platform: 0.82 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26944/abacus-13.xo Release notes: * added save/restore of custom abacus parameters Congrats to this great new activity! We already showed it proudly at Linuxtag. Actually, the day before we discovered it, an educator was asking for an activity like Abacus. This activity is a great example of a technically simple' but powerful activity from a pedagogical point of view. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] activity updater
On 06/14/2010 11:02 AM, Tomeu Vizoso wrote: On Sun, Jun 13, 2010 at 23:51, Bernie Innocentiber...@codewiz.org wrote: El Sun, 13-06-2010 a las 20:55 +0100, Gary C Martin escribió: OK, not strictly a patch but attached is an updated version of the currently malformed svg module-updater icon that's not drawing correctly in F13. Not sure who this needs to get to (could only find it in Bernie's old depreciated software update git rep). It should live in the filesystem at: /usr/share/sugar/data/icons/module-updater.svg There are two updaters: the old one written by C.Scott, which is the one in my obsolete repo and Fedora packages, and a new one written from scratch by DFarning for ASLO, which lives in the sugar repository. For the F11-0.88, we have a dilemma: the new updater is missing some crucial features that deployments were relying upon. Daniel Drake and I discussed possible solutions when he visited Paraguay. There are two equally acceptable possibilities: 1) is adding the missing features to the new codebase, which shouldn't be too hard but needs someone to do it by mid-July maximum. Anyone available? 2) The other possibility is adding the OLPC microformat support to ASLO and reverting to the old updater, which would mean less developer time but reintroduces the dependency on bitfrost which we'd rather keep away from the Sugar codebase. Or even a combination of the two. The new query protocol is very slow, so we might want to teach ASLO about the microformat anyway. When I checked the php code with Daniel, it seemed very easy to do. Alsroot and I discussed the possibility to add .xol support to ASLO. While we agree that ASLO isn't a very good fit for static content, we're going to support .xol for the utilitarian purpose of making the updater work in F11-0.88. Wish I had time to help with that, but I wanted to mention that I greatly admire the work you have been doing since you arrived in Paraguay. I specially value your understanding of what is required in the field to make Sugar fulfill its mission and wish people like you had more voice in SLs as opposed to visionaries. Regards, Tomeu I want to second that! Thanks Bernie for your great work in Paraguay. And I am convinced that this is the sustainable way to move forward. To me, my experiences in the field helped a lot to understand what is needed. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New ASLO features to implement
El Wed, 16-06-2010 a las 07:32 -0700, Thomas C Gilliard escribió: Alexsey; Maybe simple preliminary workaround for incompatible activity downloads: Could a Group of working activities be created for each sugar version ie 0.84/0.86/0.88 to be selected by user on opening ASLO? This can already be done by editing the compatibility flags. Unfortunately, some teachers bypass this mechanism by downloading bundles to their pendrives and then installing them directly on Sugar. Adding compatibility checks on bundle installation would be rather high priority, imho. In fact, I made it item #2 in my personal list of critical mid-term goals for Sugar. There's already some code written: http://bugs.sugarlabs.org/ticket/1442 Does anyone have the bandwidth to test it, finish whatever is missing and send me a well tested that I could merge before F11-0.88 Beta1? The deadline is Jun 25, but please don't send it to me the very last day. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On 06/14/2010 08:03 PM, Tomeu Vizoso wrote: On Sat, Jun 12, 2010 at 16:15, Bernie Innocentiber...@codewiz.org wrote: El Sat, 12-06-2010 a las 10:26 +0200, Simon Schampijer escribió: PS I'm sure Walter will back me up here! Can someone explain me what a development manager is? Didn't we talk about about Release Management? I hope people don't want to throw away what we have been establishing over the last releaeses. Our release and Feature process have been in place for several releases and to change that there should be good reasons to do so. I don't see any yet. +1. I would also very much like our next RM to preserve our 6-months release cycle and keep it synchronized with the major Linux distros, like GNOME and other high-profile projects do. FWIW, I think that keeping Sugar aligned with GNOME and other downstreams of the GNOME platform will be key for putting a limit to the growing maintenance costs. This does not imply that we cannot ever do very large restructuring of our codebase, if needed. This kind of work just needs to happen in a development trees and be merged when it's sufficiently stable. Right, other projects keep the 6 month cycle and do radical revampings from time to time. We can also do it if it's really worth it. Regards, Tomeu Ideally there should be short term and long term planning. That is why I drafted the 0.90 schedule already at the beginning of the 0.88 cycle. Other projects, for example Ubuntu, are doing the same. This allows to do long term planning and gives bigger features or changes a way to developed accordingly and landed. I saw the talk from Mark Shuttleworth at Linuxtag and he said a few words on Releases, and why is makes sense to bundle forces. Basically, bundling forces is a powerful idea behind open source. We are a small project, if we keep being aligned with all the bigger projects especially gnome we will profit from this joined efforts a lot. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New ASLO features to implement
On Wed, Jun 16, 2010 at 12:28:20AM -0500, Rafael Enrique Ortiz Guerrero wrote: On Tue, Jun 15, 2010 at 11:38 PM, Aleksey Lim alsr...@member.fsf.org wrote: * just regular uploads w/o need to be logged in to download them; later, there could be experimental status set by developer e.g. development version but it should be managed by activity developer not by someone else Complementing: this experimental state should allow only other developers or admins of ASLO to download the activity but it should be hidden from public to avoid conflicts. I think we can fast implement it just by making stable versions public automatically and if uploader set development flag, make version experimental (w/o making it public later). Later, only stable(public) versions will be suggested for downloading and development versions will be accessible via activity history page. * user can apply one of QA profiles (one could be set by default) to see list of activiteis that were tested by someone else e.g. SoaS, XO-1.5, XO-Paraguay etc. -- Aleksey ___ 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] New ASLO features to implement
On Wed, Jun 16, 2010 at 08:34:10AM -0400, Bernie Innocenti wrote: El Tue, 15-06-2010 a las 22:31 +, Aleksey Lim escribió: * Support per languages uploads. In some cases (GCompris, OOo4Kids) all languages in one bundle weights too much and per locale bundles makes sense. While downloading, ASLO will suggest only current locale bundle. +1 (does upstream remora already provide this?) At least for now, there could be only per arch/OS uploads. Don't know about plans but I was planing to not rebase ASLO to recent AMO (to minimize work). * By default, ASLO just an repository of activities (not regarding their stability status) and anonymous downloading is required (for now, experimental downloads requires be logged in). +1 on allowing anonymous download of any bundle, regarding its stable/experimental status. -1 on showing experimental activity bundles as the default download for activities. Probably, even maintainers should go through a peer review process. Keeping in mind what Rafael posted about development versions, the whole picture could be: * stable versions will be public automatically * development versions (flag should be set while uploading) will be treated as current experimental uploads but w/o making them public(since only next version could be stable) * versions stamped(somehow) by QA * Current QA[1] scheme is too weak for deployment(various) needs and having previous option, more reliable scheme is required. Current plan is implementing QA profiles. Every activity could be stamped (from -n to +n) in several QA profiles. QA stamp is not part of activity itself and could be set by QA editors in any time. User can nominate activity to be stamped in several QA profiles to notify QA editors about new activity. QA editors will be notified about new version of already stamped activities via a...@. Perhaps a simpler scheme to implement, which would be sufficient to fulfill our needs would be adding the ability to specify exact versions of bundles in collections. Then, we could simply point the updater to a page like this: http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88 The deployment people would keep the versions updated after doing their QA on activities. To be honest, I also want to keep ASLO patch as minimal as possible. My concern about using only collections is that it is not so useful in regular ASLO usecase i.e. there is no way to see activities by category within collection. But at the end it is all about how deployments will use QAed activities from ASLO, if for the first time using only microformat groups/collections will be enough, QA stuff could be only OLPC updater support. * Support microformat for OLPC updater. Also support collections as microformat groups. Take into account QA profiles. +1 It could be not full list of required features. If you are interested in some ASLO improvements, post an comment. Thanks Aleksey, recapitulating this list of requirements was indeed very helpful. I'll try to find a php developer to help out implementing these features ASAP. Can we make them work in the activities-devel sandbox on sunjammer? Only shell account on sunjammer is required. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Displaying the current status of system resources (such as memory, cpu)
On Wed, Jun 16, 2010 at 11:55:25AM +0200, Tomeu Vizoso wrote: I would agree with James in that the amount of free memory is probably the most useful metric we can provide. Wonder if we could tie it graphically with activity launching. I propose a simple square icon with colour fill from bottom up representing unused memory. Empty fill means no memory remaining. Similar to the wireless device icon in behaviour. In both the frame and on the activity launch screen. Palette can be like My Battery; a status assessment, and a percentage bar; after boot it will be at greatest value. Why these particular directions? So that they are consistent with the desirability of the other values displayed. Users are already encouraged to: - maximise the fill of the wireless device icon, since this represents signal strength, - maximise the percentage bar of the battery palette, since this represents remaining running time on battery. (As a optimisation for normalisation, Sugar might offset the full value based on the percentage of memory available at the time that startup has completed, retuning the value when all activities are stopped.) I also agree with Tony in that though we have space in the frame right now for more device icons, it's a resource that will be quickly scarce if we don't think of alternatives. It isn't scarce yet, and an accessible indicator is needed. Also wonder if according to the guiding principle of low-floor high-ceiling we could find a place for this feature so it doesn't raise the floor but it's there as a smoother next step than having to use the terminal. Lost me there, sorry. If you mean what about a different way of doing it, you might use a palette entry in the XO icon. The journal icon already shows free Mb. The XO icon might show memory available. On Wed, Jun 16, 2010 at 09:45:49AM -0400, Bernie Innocenti wrote: In order to show the correct time, we first need to add another missing feature to Sugar: time-zone configuration. Who would like to take this task? My Settings - Date Time works for me on Sugar 0.84. Are you writing about a different feature? -- 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] [Read PATCH] don't break if HAL is not available
HAL is only used for displaying the current battery status, so it's
entirely optional.
Signed-off-by: Sascha Silbe sascha-...@silbe.org
---
readtopbar.py | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/readtopbar.py b/readtopbar.py
index 3f338f5..b891afe 100644
--- a/readtopbar.py
+++ b/readtopbar.py
@@ -134,17 +134,21 @@ class _TopBar(gtk.HBox):
self._completion_level = 0
self._progressbar = None
-bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
-proxy = bus.get_object('org.freedesktop.Hal',
-'/org/freedesktop/Hal/Manager')
-hal_manager = dbus.Interface(proxy, 'org.freedesktop.Hal.Manager')
-udis = hal_manager.FindDeviceByCapability('battery')
-if len(udis) 0:
-self._battery = BattMan(udis[0]) # TODO: Support more than one
battery
-self._battery.connect('notify::level', \
-self._battery_level_changed_cb)
-else:
-self._battery = None
+
+self._battery = None
+try:
+bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
+proxy = bus.get_object('org.freedesktop.Hal',
+'/org/freedesktop/Hal/Manager')
+hal_manager = dbus.Interface(proxy, 'org.freedesktop.Hal.Manager')
+udis = hal_manager.FindDeviceByCapability('battery')
+if len(udis) 0:
+self._battery = BattMan(udis[0]) # TODO: Support more than one
battery
+self._battery.connect('notify::level', \
+self._battery_level_changed_cb)
+
+except dbus.DBusException:
+pass
self._icon = None
--
1.6.5
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New ASLO features to implement
On Wed, Jun 16, 2010 at 2:49 PM, Aleksey Lim alsr...@member.fsf.org wrote: On Wed, Jun 16, 2010 at 08:34:10AM -0400, Bernie Innocenti wrote: El Tue, 15-06-2010 a las 22:31 +, Aleksey Lim escribió: * Support per languages uploads. In some cases (GCompris, OOo4Kids) all languages in one bundle weights too much and per locale bundles makes sense. While downloading, ASLO will suggest only current locale bundle. +1 (does upstream remora already provide this?) At least for now, there could be only per arch/OS uploads. Don't know about plans but I was planing to not rebase ASLO to recent AMO (to minimize work). * By default, ASLO just an repository of activities (not regarding their stability status) and anonymous downloading is required (for now, experimental downloads requires be logged in). +1 on allowing anonymous download of any bundle, regarding its stable/experimental status. -1 on showing experimental activity bundles as the default download for activities. Probably, even maintainers should go through a peer review process. Keeping in mind what Rafael posted about development versions, the whole picture could be: * stable versions will be public automatically * development versions (flag should be set while uploading) will be treated as current experimental uploads but w/o making them public(since only next version could be stable) * versions stamped(somehow) by QA Agreed :). * Current QA[1] scheme is too weak for deployment(various) needs and having previous option, more reliable scheme is required. Current plan is implementing QA profiles. Every activity could be stamped (from -n to +n) in several QA profiles. QA stamp is not part of activity itself and could be set by QA editors in any time. User can nominate activity to be stamped in several QA profiles to notify QA editors about new activity. QA editors will be notified about new version of already stamped activities via a...@. Perhaps a simpler scheme to implement, which would be sufficient to fulfill our needs would be adding the ability to specify exact versions of bundles in collections. Then, we could simply point the updater to a page like this: http://activities.sugarlabs.org/en-US/sugar/collection/f11-xo1-0.88 The deployment people would keep the versions updated after doing their QA on activities. To be honest, I also want to keep ASLO patch as minimal as possible. My concern about using only collections is that it is not so useful in regular ASLO usecase i.e. there is no way to see activities by category within collection. But at the end it is all about how deployments will use QAed activities from ASLO, if for the first time using only microformat groups/collections will be enough, QA stuff could be only OLPC updater support. * Support microformat for OLPC updater. Also support collections as microformat groups. Take into account QA profiles. +1 It could be not full list of required features. If you are interested in some ASLO improvements, post an comment. Thanks Aleksey, recapitulating this list of requirements was indeed very helpful. I'll try to find a php developer to help out implementing these features ASAP. Can we make them work in the activities-devel sandbox on sunjammer? Only shell account on sunjammer is required. -- Aleksey ___ 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] [Read PATCH] don't break if HAL is not available
On 06/16/2010 06:22 PM, Sascha Silbe wrote: +except dbus.DBusException: +pass It might be worth logging an explanation like NOTICE: Battery tray icon not displayed because HAL is not available. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hypothetical sugar-0.90 material, draft 1.
On Wed, Jun 16, 2010 at 06:27:55PM +0200, Simon Schampijer wrote: I saw the talk from Mark Shuttleworth at Linuxtag and he said a few words on Releases, and why is makes sense to bundle forces. Basically, bundling forces is a powerful idea behind open source. We are a small project, if we keep being aligned with all the bigger projects especially gnome we will profit from this joined efforts a lot. Could you briefly explain what bundling forces means? Or refer us to a recording of Mark's talk? -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] VncLauncher doesn't run on F11
El Wed, 16-06-2010 a las 13:34 -0400, Carlos Daniel Garay Ayala escribió: Is available on ASLO as activity VNCLauncher. I can't find it in the public list nor in the review queue. Can you try again? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] New share button style
Hi all, While sugarizing GCompris, I've implemented new ShareButton style in polyol[1] (while changing share status it pulsing by setting alpha channel). I think it would be not bad to use the same style for all combobox like tool buttons. [1] http://people.sugarlabs.org/~alsroot/tmp/share-menu.ogv -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
Hi Aleksey, On 17 Jun 2010, at 04:41, Aleksey Lim wrote: Hi all, While sugarizing GCompris, I've implemented new ShareButton style in polyol[1] (while changing share status it pulsing by setting alpha channel). I think it would be not bad to use the same style for all combobox like tool buttons. [1] http://people.sugarlabs.org/~alsroot/tmp/share-menu.ogv Yea, fab that works for me :-) Nice to have some UI feedback for a network process that can take some seconds to complete (or sometimes never complete when something in the stack silently fails). Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.orgwrote: Hi all, While sugarizing GCompris, I've implemented new ShareButton style in polyol[1] (while changing share status it pulsing by setting alpha channel). I think it would be not bad to use the same style for all combobox like tool buttons. [1] http://people.sugarlabs.org/~alsroot/tmp/share-menu.ogv This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Thanks,--Fred http://bugs.sugarlabs.org/ticket/405 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On Thu, Jun 17, 2010 at 12:09:24AM -0400, Frederick Grose wrote: On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.orgwrote: Hi all, While sugarizing GCompris, I've implemented new ShareButton style in polyol[1] (while changing share status it pulsing by setting alpha channel). I think it would be not bad to use the same style for all combobox like tool buttons. [1] http://people.sugarlabs.org/~alsroot/tmp/share-menu.ogv This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Not trying to argue but for me busy cursor means that the whole application is in suspended (more or less) state, but in case of share button, activity could be used as usual. There is also another reason against setting cursor. ShareButton is only low level widget which is not aware of high level use cases where global setting like changing cursor is unaccessible (or sounds overkill). What about just making ShareButton inactive while changing status? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On Thu, Jun 17, 2010 at 04:47:30AM +, Aleksey Lim wrote: On Thu, Jun 17, 2010 at 12:09:24AM -0400, Frederick Grose wrote: On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.orgwrote: Hi all, While sugarizing GCompris, I've implemented new ShareButton style in polyol[1] (while changing share status it pulsing by setting alpha channel). I think it would be not bad to use the same style for all combobox like tool buttons. [1] http://people.sugarlabs.org/~alsroot/tmp/share-menu.ogv This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Not trying to argue but for me busy cursor means that the whole application is in suspended (more or less) state, but in case of share button, activity could be used as usual. There is also another reason against setting cursor. ShareButton is only low level widget which is not aware of high level use cases where global setting like changing cursor is unaccessible (or sounds overkill). What about just making ShareButton inactive while changing status? http://people.sugarlabs.org/~alsroot/tmp/share-menu-sensitive.ogv -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On Thu, Jun 17, 2010 at 1:07 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Jun 17, 2010 at 04:47:30AM +, Aleksey Lim wrote: On Thu, Jun 17, 2010 at 12:09:24AM -0400, Frederick Grose wrote: On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.org wrote: ... This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Not trying to argue but for me busy cursor means that the whole application is in suspended (more or less) state, but in case of share button, activity could be used as usual. There is also another reason against setting cursor. ShareButton is only low level widget which is not aware of high level use cases where global setting like changing cursor is unaccessible (or sounds overkill). Yes, those are good reasons not to modify the cursor in the Activity sharing case. For the general case that you suggested, the throbbing icon is a nice feature, but to serve those with low vision or in a difficult viewing environment, a small, high-contrast element or badge (perhaps a small stop sign, or just a small x as a badge on the icon) should be added. What about just making ShareButton inactive while changing status? http://people.sugarlabs.org/~alsroot/tmp/share-meornu-sensitive.ogvhttp://people.sugarlabs.org/~alsroot/tmp/share-menu-sensitive.ogv That would work in the successful or quick failure cases, but if there was a failure, and the process was stuck retrying, the static signal would not provide the information about process state. See http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Controls/Indicators for some other ideas on how to badge the icon with process state information. Thanks again!--Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On Thu, Jun 17, 2010 at 01:42:58AM -0400, Frederick Grose wrote: On Thu, Jun 17, 2010 at 1:07 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Jun 17, 2010 at 04:47:30AM +, Aleksey Lim wrote: On Thu, Jun 17, 2010 at 12:09:24AM -0400, Frederick Grose wrote: On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.org wrote: ... This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Not trying to argue but for me busy cursor means that the whole application is in suspended (more or less) state, but in case of share button, activity could be used as usual. There is also another reason against setting cursor. ShareButton is only low level widget which is not aware of high level use cases where global setting like changing cursor is unaccessible (or sounds overkill). Yes, those are good reasons not to modify the cursor in the Activity sharing case. For the general case that you suggested, the throbbing icon is a nice feature, but to serve those with low vision or in a difficult viewing environment, a small, high-contrast element or badge (perhaps a small stop sign, or just a small x as a badge on the icon) should be added. What about just making ShareButton inactive while changing status? http://people.sugarlabs.org/~alsroot/tmp/share-meornu-sensitive.ogvhttp://people.sugarlabs.org/~alsroot/tmp/share-menu-sensitive.ogv That would work in the successful or quick failure cases, but if there was a failure, and the process was stuck retrying, the static signal would not provide the information about process state. See http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Controls/Indicators for some other ideas on how to badge the icon with process state information. To be honest I was planing to use alerts to notify about sharing errors with message like Cannot make it Public, fallback to Offline, imho this kind of fails is critical enough to use alserts. Thanks again!--Fred ___ 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
