Re: [Sugar-devel] Sugar-devel Digest, Vol 20, Issue 76
Thanks for your reply Mr. Simmons, I had gone through the manual before writing the code. The problem is that I use a separate window to display the program, hence the program pops out. I need guidance in running the program in the default window of Sugar. Date: Thu, 17 Jun 2010 11:01:05 -0500 From: James Simmons nices...@gmail.com Subject: Re: [Sugar-devel] Help Needed - Convert python code into Sugar To: sugar-devel@lists.sugarlabs.org Message-ID: aanlktiljsefbovcokdvr0ch3abhuxuuwa75id6zv5...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 John, We have a manual which should help you figure out what you're doing wrong: http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction James Simmons Date: Thu, 17 Jun 2010 03:28:52 -0700 (PDT) From: John Samuel johnsamuel...@yahoo.com Subject: [Sugar-devel] Help Needed - Convert python code into Sugar To: Sugar Devel sugar-devel@lists.sugarlabs.org Message-ID: 350718.92048...@web45305.mail.sp1.yahoo.com Content-Type: text/plain; charset=us-ascii Hi, this is John Samuel here.I am new to Sugar. I've made a small program in python for the viewing of images.It runs perfectly as a standalone program, but when I convert it into Sugar, it runs in a different window coz of which it cannot be stopped.I have to close Xephyr and run it again.I use Sugar .88 on Ubuntu 9.10 KarmicCould anyone please help me? I've attached my code along with this mail. John Samuel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RD vs Product Support
On Fri, Jun 18, 2010 at 00:56, Bernie Innocenti ber...@codewiz.org wrote: El Wed, 16-06-2010 a las 18:27 +0200, Simon Schampijer escribió: 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. I couldn't agree more. At the same time, I'm seeing a number of very skilled Sugar hackers who would be more inclined to work on complex innovative projects and would therefore prefer a less structured approach. I'm always puzzled when I hear this argument. In which ways is the stable release process impeding people to experiment? If you want to do weird stuff, do it. And when this becomes something that can get into a stable product, propose it for merging. Long term, both approaches are essential to the evolution of a project. Some large hi-tech companies I worked for in my previous life solved the conflict of approaches by splitting their engineering staff into two departments: RD lab and Design/Engineering office. Do you have an example of a FOSS community that has done such a split? RD creates prototypes and then hands them off to the other department which turns them into an industrialized product. Needless to say, many projects die during the transition. Not everything that is technically possible can become a finished, marketable product. It may seem that RD is doing all the hard work while engineering just adds the finishing touches,but Brooks claims that there's a x3 factor in effort between a working program and a finished product that could be commercialized to paying customers. I believe that Brooks' law holds also for a FLOSS project like ours. Despite being used in production for ~2 years, Sugar still has many traits of a half-finished prototype: it can backup but not yet restore... Stuff that RD people wouldn't normally do, but still takes many years of organized engineering work to get right. Moreover, some of these missing features are urgently needed. A simple pragmatic solution often serves our users better than a theoretically perfect one which would require redesigning a large subsystem. Every time I see a hypothetical design blocking the delivery of a quick effective solution available today, I think that we should rethink our project structure to minimize this tension. Ensuring that the proper design will eventually be implemented is as important as delivering a sufficiently polished product to our current user base. It seems that the two approaches should proceed in parallel. I'm also concerned about this, but frankly, if we haven't learned yet to discuss things in a productive way, no project reorganization will save us. I see people worried about their work not being upstreamed because it doesn't match the maintainer criteria. This is about the most common conflict in FOSS communities and we really need to get better at handling it. Downstreams and upstreams need first to, for every case, define together the problem space so we are all discussing the same thing. Often the maintainer would accept a change if she knew the whole story behind it, but that information is not passed upstream. Sometimes, the maintainer will be mistaken (surprise!), and though I don't think we should override her prerogative about what gets in and what not, the submitter could try to gather some consensus from the community so the maintainer can reconsider her decision with more information. But right now, there are some conflicts going on that haven't even been explained in the mailing list. And one more thing: not EVERYTHING needs to be upstreamed, we should use common sense to decide what really needs to and what doesn't need to. Regards, Tomeu -- // 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 16:33, 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. We're going to get a BoF in GUADEC for hacking on PyGI so I definitely see it getting ready during this cycle. Regards, Tomeu 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 17:10, Daniel Drake d...@laptop.org wrote: 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) It has been mentioned that by updating these dependencies, we'll have to build some more modules in jhbuild for distros such as Debian which won't have it for now in their current versions and that this will raise significantly the bar for contributing. Regards, Tomeu Daniel ___ 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] Alt-Tab, sugar-settings-manager (was: [IAEP] F11-0.88 os260py)
Excerpts from Bernie Innocenti's message of Fri Jun 18 03:26:56 + 2010: With this build, all the major regression relative to 0.84 are fixed. Congratulations! * Make ALT-TAB work. It was caused by a bug with XUngrabKey() in the old Xorg server of Fedora 11, but we worked it around in Metacity. We spent a lot of time to figure it out! (tch, bernie) So that Alt-Tab doesn't work on my systems (Debian squeeze, Xorg 7.5) is a different bug? * Fix fonts too big in all activities. This was a fallout of us temporarily disabling sugar-settings-manager, due to another bug (jasg). Shouldn't sugar-settings-manager only be required to change font size at run-time (see e.g. [1] at [09:59:32] ff. - the meeting where we originally discussed it doesn't seem to have been logged)? Sascha [1] http://me.etin.gs/sugar-meeting/sugar-meeting.log.20100208_0908.html -- 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
After much trouble getting hulahop xpcom to work in the abstraction layer webwrap, I've decided to drop it and focus on pywebkitgtk. To this end, yesterday I got Browse to start and load pages with pywebkitgtk, but with several features disabled. I'll be working on getting all of Browse's features to work with pywebkitgtk. I've also looked at webkitgtk+'s API and I'm confident that switching to PyGI will be quite easy, mostly just renaming things. On 16 June 2010 11:48, Lucian Branescu lucian.brane...@gmail.com wrote: 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] RD vs Product Support
Excerpts from Bernie Innocenti's message of Thu Jun 17 22:56:27 + 2010: [RD vs. Finished Product] Every time I see a hypothetical design blocking the delivery of a quick effective solution available today, I think that we should rethink our project structure to minimize this tension. Ensuring that the proper design will eventually be implemented is as important as delivering a sufficiently polished product to our current user base. It seems that the two approaches should proceed in parallel. +5 on everything you wrote. FWIW, this doesn't necessarily mean we have two disjunct teams. Like I am working on both the version support branch and current bug fix currently, there will (and should!) be some overlap between those doing RD and those polishing the result. 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] RD vs Product Support
On Fri, Jun 18, 2010 at 8:17 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Excerpts from Bernie Innocenti's message of Thu Jun 17 22:56:27 + 2010: [RD vs. Finished Product] Every time I see a hypothetical design blocking the delivery of a quick effective solution available today, I think that we should rethink our project structure to minimize this tension. Ensuring that the proper design will eventually be implemented is as important as delivering a sufficiently polished product to our current user base. It seems that the two approaches should proceed in parallel. +5 on everything you wrote. FWIW, this doesn't necessarily mean we have two disjunct teams. Like I am working on both the version support branch and current bug fix currently, there will (and should!) be some overlap between those doing RD and those polishing the result. For Activity Central I am going to take a slightly different approach. Following Mayo hospital (and google) I am going to ask Activity central employees to spend 60% of their time on directed (revenue generating) tasks. The remaining 40% of their time will be 'upstream time' to work on anything they want to in the Netbook, Linux, Sugar, Content stack. The notion is that: a) it attracts the type of people we want. b) it builds the ecosystem. and c) by working upstream on some things and downstream on others it helps people internalize the upstream downstream tensions. I still have to convince AC's various partners that this plan is a good use of their limited resources:( david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Help Needed - Convert python code into Sugar
On Fri, Jun 18, 2010 at 01:48:56PM +, Sascha Silbe wrote: Excerpts from John Samuel's message of Thu Jun 17 10:28:52 + 2010: Hi, this is John Samuel here.I am new to Sugar. I've made a small program in python for the viewing of images.It runs perfectly as a standalone program, but when I convert it into Sugar, it runs in a different window coz of which it cannot be stopped.I have to close Xephyr and run it again.I use Sugar .88 on Ubuntu 9.10 KarmicCould anyone please help me? I've attached my code along with this mail. I'd suggest starting by converting the code to use GTK instead of TK. Python-tk is not being installed on most systems running Sugar (see the Sugar Platform page [1] for a list of packages that should be available on all systems). Also with GTK it will be much easier to integrate into Sugar; you can use several GTK-based widgets made specifically for Sugar (the sugar.graphics submodules on [2]), in addition to the regular activity framework (sugar.activity) that I highly recommend to build on. It'll make Sugar integration much easier. It might be quite a bit of work to switch to GTK, but it'll pay off in the long run. AFAIK nobody has tried making a TK-based application yet and Sugar is still a bit peculiar about how it expects windows to appear. If you nevertheless decide to keep using TK, the low-level activity API page has some details [3] on what X11 properties need to be set to make Sugar recognize your window. Polyol[4] is designed exactly for this purpose, these are C libraries that should cover all sugar related low level routines, starting from getting sugar environment settings via full featured sugar GUI to high level stuff i.e. what sugar-toolkit does for python based activities. It is not yet finished (but already in some useful stage, I'm using it for C based GCompris and less for Tuxpaint) and contains only python binding for now. [1] http://wiki.sugarlabs.org/go/0.88/Platform_Components [2] https://api.sugarlabs.org/ [3] http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#X_Properties [4] http://wiki.sugarlabs.org/go/Activity_Team/Polyol -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
On 18 June 2010 05:04, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: It has been mentioned that by updating these dependencies, we'll have to build some more modules in jhbuild for distros such as Debian which won't have it for now in their current versions and that this will raise significantly the bar for contributing. If you wait for Debian you'll likely be waiting a long time. My view: don't let it hold back. Make the change, hack jhbuild, and put pressure on them to push the package updates. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Help Activity -- Spanish translation?
Hi David, Brian, list, Is there any translation of the Help activity to Spanish? Or anyone working on it? If it was to be done, should potential translators work on the FLOSS Manuals version? (The terms 'help' and 'translation' are so generic that Google doesn't help finding good leads...) cheers, 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 -- 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] depending on introspection
On Fri, Jun 18, 2010 at 9:29 AM, Daniel Drake d...@laptop.org wrote: On 18 June 2010 05:04, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: It has been mentioned that by updating these dependencies, we'll have to build some more modules in jhbuild for distros such as Debian which won't have it for now in their current versions and that this will raise significantly the bar for contributing. If you wait for Debian you'll likely be waiting a long time. My view: don't let it hold back. Make the change, hack jhbuild, and put pressure on them to push the package updates. Tomeu, Could you raise this issue on debian-olpc-devel debian-olpc-de...@lists.alioth.debian.org (CCed) for feed back from the .deb team? Possibly Jonas could help us to understand the debian roadmap. I don't understand the technical issues well enough to participate in the conversation. david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
Excerpts from Daniel Drake's message of Fri Jun 18 14:29:39 + 2010: If you wait for Debian you'll likely be waiting a long time. Please note that we're talking about Sugar development (i.e. sugar-jhbuild) on Debian unstable here, which is usually rather current. Native Debian packages to go into a stable release are a totally separate matter. My view: don't let it hold back. Make the change, hack jhbuild, and put pressure on them to push the package updates. If somebody else volunteers to maintain a sugar-jhbuild that replaces major libraries shipped by the distro: go ahead! It will get you into dependency hell and I have neither the time nor any inclination to re-enter it after working hard to get _rid_ of most non-Sugar packages in sugar-jhbuild. As mentioned on IRC, the reason it works well for Gnome is because they replace _all_ the libraries. Apart from raising the bar to using sugar-jhbuild (think disk space, time to build) it requires a lot of effort to keep all packages current. 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] depending on introspection
On 18 June 2010 10:59, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: My view: don't let it hold back. Make the change, hack jhbuild, and put pressure on them to push the package updates. If somebody else volunteers to maintain a sugar-jhbuild that replaces major libraries shipped by the distro: go ahead! It will get you into dependency hell and I have neither the time nor any inclination to re-enter it after working hard to get _rid_ of most non-Sugar packages in sugar-jhbuild. As mentioned on IRC, the reason it works well for Gnome is because they replace _all_ the libraries. Apart from raising the bar to using sugar-jhbuild (think disk space, time to build) it requires a lot of effort to keep all packages current. Fair points, but these are all Debian's problems, in my opinion. It falls into the We're innovating, can you keep up? camp. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] RD vs Product Support
On Thu, Jun 17, 2010 at 6:56 PM, Bernie Innocenti ber...@codewiz.org wrote: At the same time, I'm seeing a number of very skilled Sugar hackers who would be more inclined to work on complex innovative projects and would therefore prefer a less structured approach. Long term, both approaches are essential to the evolution of a project. ... I agree. But before we go into big debate-land... ... how about an experimental branch? Or a bunch of them? Clearly, some people want to take on approaches that others (for example myself) consider risky, and that are only worthwhile if someone can show that they have a clear, tangible return. I like how Junio manages git -- in simplified summary: - Many branches, one per experimental project. - They get merged to pu (proposed updates) -- pu is torn down and remade/remerged frequently (git-rerere remembers the conflict resolutions to ease the pain here). - Experimental projects that show clear benefits, don't break toys or APIs graduate to 'master', where they get merged and become part of the final project history. Both the experimental branches and pu are a drafting space. - 'master' is from where new releases are made. Doing this for every new thing is too costly and cumbersome. But is really good for experimental code. Despite being used in production for ~2 years, Sugar still has many traits of a half-finished prototype Completely agreed. I want to find a way out of that particular conundrum. And at the same time, not stop anyone from doing potentially revolutionary work. Truth is: most revolutionary changes don't pan out (or cost 100x than initially expected). We want to find that out, before they reach master. cheers, 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
[Sugar-devel] [PATCH] Add font dpi schema
From: Jorge Saldivar jsaldi...@paraguayeduca.org --- data/sugar.schemas.in | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/data/sugar.schemas.in b/data/sugar.schemas.in index b9606ba..78aea9d 100644 --- a/data/sugar.schemas.in +++ b/data/sugar.schemas.in @@ -249,6 +249,17 @@ longFont size that is used throughout the desktop./long /locale /schema +schema + key/schemas/desktop/sugar/font/dpi/key + applyto/desktop/sugar/font/dpi/applyto + ownersugar/owner + typeint/type + default200/default + locale name=C +shortDefault font dpi/short +longFont dpi that is used throughout the desktop./long + /locale +/schema schema key/schemas/desktop/sugar/i18n/langpackdir/key @@ -328,6 +339,5 @@ longGSM network personal unlock key configuration/long /locale /schema - /schemalist /gconfschemafile -- 1.7.0.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
Excerpts from Daniel Drake's message of Fri Jun 18 16:08:34 + 2010: Fair points, but these are all Debian's problems, in my opinion. It falls into the We're innovating, can you keep up? camp. No, they're my problem because I develop Sugar on Debian systems. Can you afford to leave me behind? Is it worth the advantage of being able to use introspection (or whatever other bleeding edge technology that requires modifying major system libraries instead of just installing additional ones) right now? 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] Hypothetical sugar-0.90 material, draft 1.
On Wed, Jun 16, 2010 at 9:47 PM, James Cameron qu...@laptop.org wrote: Could you briefly explain what bundling forces means? How about rowing in sync? From LWN's coverage: For a while now, Mark has been pushing the idea of a coordinated cadence across multiple projects. http://lwn.net/Articles/392016/ (will be free soon -- freebie link to be had to read Right Now if you ping me in private) 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] depending on introspection
On 18 June 2010 12:20, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org No, they're my problem because I develop Sugar on Debian systems. Can you afford to leave me behind? Is it worth the advantage of being able to use introspection (or whatever other bleeding edge technology that requires modifying major system libraries instead of just installing additional ones) right now? Regardless of who or which, I don't think its right that the problems of a single developer or distribution should hold back the rest of the Sugar project, which is realistically much much larger than that. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Last changes before release Paint
On Fri, Jun 18, 2010 at 5:36 AM, Manusheel Gupta m...@laptop.org wrote: Gonzalo, Neat work. Ok. Pushed. On Fri, Jun 18, 2010 at 10:40 AM, Gonzalo Odiard godi...@gmail.comwrote: I have two changes I would include in this release. The first is patch i sent to sugar-devel. The second its a change to the icons of fill and stroke selection color buttons. The problem what I am trying to resolve is, when the color selected is black, the icons are invisible. I am not a graphic artist :( . I send the icons to see if you have a better option. I think we are good to go for this release. We'll put the task of revising the icons if required in the to-do list for the August release. Did you get a chance to complete the documentation at your end? No. I will try to write briefly my plans and will send it to you. Regards, Manu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add font dpi schema
On Fri, Jun 18, 2010 at 10:49 PM, jorgesaldi...@gmail.com wrote: From: Jorge Saldivar jsaldi...@paraguayeduca.org --- data/sugar.schemas.in | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/data/sugar.schemas.in b/data/sugar.schemas.in index b9606ba..78aea9d 100644 --- a/data/sugar.schemas.in +++ b/data/sugar.schemas.in @@ -249,6 +249,17 @@ longFont size that is used throughout the desktop./long /locale /schema + schema + key/schemas/desktop/sugar/font/dpi/key + applyto/desktop/sugar/font/dpi/applyto + ownersugar/owner + typeint/type + default200/default + locale name=C + shortDefault font dpi/short + longFont dpi that is used throughout the desktop./long + /locale + /schema schema key/schemas/desktop/sugar/i18n/langpackdir/key @@ -328,6 +339,5 @@ longGSM network personal unlock key configuration/long /locale /schema - /schemalist /gconfschemafile -- Note that support for reading the value of this GConf key has been added to sugar-settings-managed. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] depending on introspection
The way I see it, activities can't really use PyGI until it's a sugar dependency. The sooner it is available as a dependency on all relevant platforms (debian being one of them), the sooner important things like Browse can start using it. So, how about making some packages for all relevant platforms? There can be some PPAs for ubuntu and some repos for debian and whatever other platforms we care about. This will be some work, but I'm sure other projects are interested in this as well. On 18 June 2010 18:59, Daniel Drake d...@laptop.org wrote: On 18 June 2010 12:20, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org No, they're my problem because I develop Sugar on Debian systems. Can you afford to leave me behind? Is it worth the advantage of being able to use introspection (or whatever other bleeding edge technology that requires modifying major system libraries instead of just installing additional ones) right now? Regardless of who or which, I don't think its right that the problems of a single developer or distribution should hold back the rest of the Sugar project, which is realistically much much larger than that. Daniel ___ 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] [PATCH] Add font dpi schema
Excerpts from Sayamindu Dasgupta's message of Fri Jun 18 18:12:31 + 2010: Note that support for reading the value of this GConf key has been added to sugar-settings-managed. Shouldn't it also be set during Sugar start-up so that it keeps working even without sugar-settings-manager? 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] [SoaS] Your thoughts on My proposed feature Revised_Browse_default-bookmarks
On Wed, Jun 16, 2010 at 12:14 PM, Thomas C Gilliard satel...@bendbroadband.com wrote: 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 Its not going to point to the SCK, the SoaS possibly but I'm not sure of the conversation you had with Mel. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add font dpi schema
Excerpts from jorgesaldivar's message of Fri Jun 18 17:19:44 + 2010: First of all, thanks for working on this! From: Jorge Saldivar jsaldi...@paraguayeduca.org --- Some more explanation about this new feature would be nice. What exactly gets changed (X server DPI setting? some font library setting? a GTK setting)? What does it affect (any non-font stuff? do applications need to do anything special?) If it's not the X server DPI setting that gets changed, how do they relate (i.e. what happens if they're different)? Given this patch only adds the schema, who sets and gets the value? Why does Sugar provide the schema, but some other package actually uses it? +shortDefault font dpi/short +longFont dpi that is used throughout the desktop./long How about Pixel density to assume when typesetting text? 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
On Fri, Jun 18, 2010 at 14:01, Lucian Branescu lucian.brane...@gmail.com wrote: After much trouble getting hulahop xpcom to work in the abstraction layer webwrap, I've decided to drop it and focus on pywebkitgtk. To this end, yesterday I got Browse to start and load pages with pywebkitgtk, but with several features disabled. I'll be working on getting all of Browse's features to work with pywebkitgtk. I've also looked at webkitgtk+'s API and I'm confident that switching to PyGI will be quite easy, mostly just renaming things. I also expect it to be the case unless pywebkitgtk contained a lot of non-generated code or webkitgtk+ substantially changed their API. And none of them are very likely to happen. Regards, Tomeu On 16 June 2010 11:48, Lucian Branescu lucian.brane...@gmail.com wrote: 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] depending on introspection
On Fri, Jun 18, 2010 at 3:29 PM, Daniel Drake d...@laptop.org wrote: On 18 June 2010 05:04, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: It has been mentioned that by updating these dependencies, we'll have to build some more modules in jhbuild for distros such as Debian which won't have it for now in their current versions and that this will raise significantly the bar for contributing. If you wait for Debian you'll likely be waiting a long time. My view: don't let it hold back. Make the change, hack jhbuild, and put pressure on them to push the package updates. I agree with this, but I might have some Debian contributors that are interested in helping out with maintaining sugar and associated dependencies (yea, I know shocking that a Fedora person is talking to a Debian person :-D ) so with luck that might slowly start to improve. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Fwd: [PATCH] Add dpi font support]
Oops, this was supposed to go also to the list.
- Mensaje reenviado
From: Jorge (jasg) Saldivar jsaldi...@paraguayeduca.org
To: sayami...@laptop.org
Cc: ber...@codewiz.org, Jorge Saldivar jsaldi...@paraguayeduca.org
Subject: [PATCH] Add dpi font support
Date: Fri, 18 Jun 2010 12:51:06 -0400
From: Jorge Saldivar jsaldi...@paraguayeduca.org
---
src/sugar-settings-manager.c | 35 +++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/src/sugar-settings-manager.c b/src/sugar-settings-manager.c
index 1180334..52b8b89 100644
--- a/src/sugar-settings-manager.c
+++ b/src/sugar-settings-manager.c
@@ -21,6 +21,7 @@
*
* Authors: Owen Taylor, Red Hat, Inc.
* Sayamindu Dasgupta sayami...@laptop.org
+ * Jorge Saldivar jorgesaldi...@gmail.com
*/
#include stdlib.h
@@ -36,9 +37,11 @@
#define SUGAR_FONT_DIR /desktop/sugar/font
#define SUGAR_FONT_FACE_KEY /desktop/sugar/font/default_face
#define SUGAR_FONT_SIZE_KEY /desktop/sugar/font/default_size
+#define SUGAR_FONT_DPI_KEY /desktop/sugar/font/dpi
/* See http://freedesktop.org/wiki/Specifications/XSettingsRegistry */
#define XSETTINGS_REGISTRY_GTK_FONT_NAME Gtk/FontName
+#define XSETTINGS_REGISTRY_XFT_DPI Xft/DPI
XSettingsManager *manager;
GConfClient *client;
@@ -77,6 +80,19 @@ void update_font()
xsettings_manager_notify(manager);
}
+void update_font_dpi()
+{
+gint font_dpi;
+
+font_dpi = gconf_client_get_int(client, SUGAR_FONT_DPI_KEY, NULL);
+if (!font_dpi)
+ return;
+
+xsettings_manager_set_int(manager, XSETTINGS_REGISTRY_XFT_DPI,
+font_dpi);
+xsettings_manager_notify(manager);
+}
+
void
font_face_changed_callback(GConfClient * client,
guint cnxn_id,
@@ -109,6 +125,21 @@ font_size_changed_callback(GConfClient * client,
}
}
+void
+font_dpi_changed_callback(GConfClient * client,
+ guint cnxn_id,
+ GConfEntry * entry, gpointer user_data)
+{
+if (entry-value == NULL) {
+ return;
+} else {
+ if (entry-value-type == GCONF_VALUE_INT) {
+ update_font_dpi();
+ } else {
+ return;
+ }
+}
+}
void setup_font()
{
@@ -123,8 +154,12 @@ void setup_font()
gconf_client_notify_add(client, SUGAR_FONT_SIZE_KEY,
(GConfClientNotifyFunc)
font_size_changed_callback, NULL, NULL, NULL);
+gconf_client_notify_add(client, SUGAR_FONT_DPI_KEY,
+ (GConfClientNotifyFunc)
+ font_dpi_changed_callback, NULL, NULL, NULL);
update_font();
+update_font_dpi();
}
int main(int argc, char **argv)
--
1.7.0.4
--
// 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] [PATCH] [trivial] Free From Malaria
Hi,
Wtgn testers have notived that the Free From Malaria Activity [1]
currently has gtk test as its activity name in activity.py. Here's a
fix :)
-Tim
=== modified file 'activity.py'
--- activity.py 2010-06-19 00:07:52 +
+++ activity.py 2010-06-19 00:09:04 +
@@ -45,7 +45,7 @@
print Journal resume.
# Set title for our Activity
-self.set_title('gtk test')
+self.set_title('Free From Malaria')
# Attach sugar toolbox (Share, ...)
# Use old = 0.84 toolbar design
___
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 Fri, Jun 18, 2010 at 01:01:05PM +0100, Lucian Branescu wrote: After much trouble getting hulahop xpcom to work in the abstraction layer webwrap, I've decided to drop it and focus on pywebkitgtk. To this end, yesterday I got Browse to start and load pages with pywebkitgtk, but with several features disabled. I'll be working on getting all of Browse's features to work with pywebkitgtk. I've reviewed your patches in the webkit branch of the Browse git repo, and I can see the sense of what you're doing. Let us know when you're ready for wider testing. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
