Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
The big change moving to GTK3 is gobject-introspection. I'm not aware of any plans to change how scripting language bindings are done in the future, so that part of the sugar port should be future-proof. Other things like removing hippo-canvas are also future-proof -- there's no chance that any of that cruft is going to reappear in future versions of GTK. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Hi Daniel, On Wed, Aug 3, 2011 at 6:07 PM, Daniel Drake d...@laptop.org wrote: Hi, Unfortunately, the time has arrived at which we start encountering problems due to the fact that Sugar has not yet moved to GTK3 and GObject Introspection. Namely, if you run a modern distro such as Fedora 15, Read doesn't work (evince no longer has gtk2 bindings). Also, Browse is broken with no future (because of Mozilla no longer supporting embedding) and needs to switch to WebKit, but this first requires us to move to GTK3/PyGI. So, I'd like to initiate some movement on this front. We need to migrate sugar. As a first step, I aim to produce a fairly detailed, well-argued, and agreed-upon plan on how this could and should happen, so that if we were to get a number of experienced developers to focus on such a project for a few days, the project could be executed in part. I've spent some time thinking and researching this, and I've already spoken to a few community members, and here is what I have so far: http://wiki.sugarlabs.org/go/Features/GTK3 The key things I've tried to account for are: 1. Our developer resources are limited, so I'm proposing a path that stretches us to the least possible extent while taking on this big project. 2. We can't break all activities on a GTK3 changeover day, but neither can we let unported activities run forever. 3. Dividing up the work into stages, where Sugar continues to function as a whole at the end of each stage, is important to make the task more manageable/realistic. So, discuss! :) http://wiki.sugarlabs.org/go/Features/GTK3 Comments, agreement, and hate mail much appreciated - I'll refine the above page based on the discussion that follows. Something else that came to mind was I know the gtk team is planning on getting gtk4 [1] out before long (not sure the exact time scale) so it likely would be worth at least reviewing their plans [3] for that so we don't choose a particular approach that might disappear again before long. It doesn't need to be the main part of it but likely something worthwhile to keep in the back of our minds and it might be a worthwhile means of getting anything else we need or to ensure they don't suddenly go HW accell everywhere etc. In the very least they're aiming for large improvements in touch etc [2] Peter [1] https://live.gnome.org/GTK+/Roadmap [2] https://desktopsummit.org/program/sessions/gtk-4-future-your-favorite-toolkit [3] https://live.gnome.org/Hackfests/GTK2010/RoadmapDiscussion ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Sorry, I haven't read *all* of the linked documents, but... Congrats on getting a minimal GTK3 port running so quickly! That's very impressive. I'd originally thought that refactoring the Sugar API into more independent modules would be a necessary part of the effort, just to be able to do a more incremental port. I'd like to see that refactoring happen, but I guess it's good that it's not on the critical path? It seems like you ought to be able to port sugar-the-window-manager and sugar-the-library-used-by-activities separately, and run gtk2 activities under gtk3 window manager and vice-versa. But maybe maintaining that compatibility is just more trouble than it's worth. --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Tue, Aug 9, 2011 at 8:11 AM, C. Scott Ananian csc...@laptop.org wrote: I'd originally thought that refactoring the Sugar API into more independent modules would be a necessary part of the effort, just to be able to do a more incremental port. I'd like to see that refactoring happen, but I guess it's good that it's not on the critical path? As mixing pygtk/gtk2 and pygi/gtk3 is not possible, splitting into more modules would be unlikely to help much. For example, if an activity pulled one one GTK2-ported module and one GTK3-ported module, it would have to stick with GTK2. And yes, even though we can't do this on a fine incremental scale, the great work being done at the desktop summit suggests that indeed it is not necessary. That work has identified a handful of unanswered questions, must-be-done-first prerequisites (such as porting the theme), but after that point it seems like it will not be too difficult to port entire codebases at a time. It seems like you ought to be able to port sugar-the-window-manager and sugar-the-library-used-by-activities separately, and run gtk2 activities under gtk3 window manager and vice-versa. But maybe maintaining that compatibility is just more trouble than it's worth. Thats exactly the plan documented here: http://wiki.sugarlabs.org/go/Features/GTK3 It's also exactly what they've been doing at the desktop summit, and the experiments so far show that maintaining gtk2 compatibility for activities for a transition period won't be a drain on resources. Thanks for your input! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Tue, Aug 9, 2011 at 5:18 AM, Daniel Drake d...@laptop.org wrote: On Tue, Aug 9, 2011 at 8:11 AM, C. Scott Ananian csc...@laptop.org wrote: I'd originally thought that refactoring the Sugar API into more independent modules would be a necessary part of the effort, just to be able to do a more incremental port. I'd like to see that refactoring happen, but I guess it's good that it's not on the critical path? As mixing pygtk/gtk2 and pygi/gtk3 is not possible, splitting into more modules would be unlikely to help much. For example, if an activity pulled one one GTK2-ported module and one GTK3-ported module, it would have to stick with GTK2. By independent modules I meant modules communicating via DBus or g-o-i (C interface), not python all-in-one-interpreter modules. I should probably have said independent libraries; maybe that would have been clearer. (Memory management has to be thought through, but you could embed a python interpreter and a pile of python code into a library which exports a C API. Such a library can be running any version of python you like; it doesn't leak out and infect other libraries/modules.) --scott -- ( http://cscott.net ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Excerpts from Daniel Drake's message of Fri Aug 05 15:04:49 +0200 2011: No comments yet. The plan looks good in general, thanks for taking the time to draft and elaborate! It might be worth pointing out that the list in Proposed plan of action contains quite a few actions that can happen in parallel, not just in the particular order given. As mentioned in #sugar, I'd love to see a GTK 2 based version of Sugar without hippo-canvas (this seems to match your plan). Without hippo-canvas, we can finally do automated UI tests. I already have a few other missing pieces in my drawer, but they weren't too useful with the Home View still based on hippo-canvas. The value of the automated tests is that they can reduce the risk of the Gnome 3 port introducing regressions. I'd expect them to be quite limited at first (no simulation of external storage devices, no multiple instances collaborating, etc.) but still good as a band-aid. 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? I don't think that would be useful. AFAICT there need to be major textual changes anyway. 2. Are people happy with labelling components with version number 1.0 once they have a stable GTK3 port? The 1.0 tag was generally agreed upon when this was last discussed a while back, but it would be good to verify current opinion. If we make it clear that it's 1.0 of the technology preview / proof of concept and not of what Sugar wants to be (a learning platform with Collaboration and reflection etc.), that's fine with me. 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? I'd like us to work on other issue first. Topics that come to my mind include design changes for touch screen support and extending the Journal (e.g. finally adding the Action View). Of course that doesn't mean a Gnome 3 porting hack session wouldn't be welcome, just that it is less of a priority for me (because there's already one happening right now in Berlin). 4. Is a one year transition period OK? This would start when a GTK3 port of sugar-toolkit is declared stable and working, would freeze the GTK2 version of sugar-toolkit, and then after 1 year the GTK2 version would be deleted. Only time can tell. It will depend a lot on the details. However given the usual schedules (with a unit of school years) at deployments, I would expect that we need to keep the GTK 2 version of sugar-toolkit around for more than one year. But since you plan for it to be unmaintained, I wonder what would actually happen after that time. I don't think we should be removing git repositories or old release tarballs. 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] Moving to GTK3 and GObject Introspection
Excerpts from Samuel Greenfeld's message of Sun Aug 07 02:41:36 +0200 2011: The change I would like to see in the API (if we do not have it already) is to ensure that we have full ATK accessibility support for all Sugar controls. Not only would this allow screen readers, etc. to parse Sugar applications and the main window system, but it would make automated testing of Sugar easier as well. The only change we need to do for accessibility support that might touch APIs is removing hippo-canvas (there are a few places in sugar-toolkit that use it). We're building more or less directly on GTK, so I'd expect accessibility to just work in most cases or at least be fixable without API changes. I've been told in the past that automating Sugar was not possible apart from a point click approach because hippocanvas and similar did not expose any accessibility information. Since this may require developers to setup additional information inside of activities (alternate names/descriptions, focus tab order, etc.) it is better to get this in as early as possible so activities do not have to be retrofitted to support ATK after the fact. Activities can already be augmented with the necessary information today. Those parts that use hippo-canvas can't be augmented, but will need to be replaced soon anyway. We had a GSoC project for an automated activity testing framework [1] a while back. Unfortunately the student got confused by FUD about OLPC and lost interest [2]. Nobody else stepped up to work on this project. It uses a different technique than the accessibility based testing tools, so not sure whether it would continue to work in GTK 3 land. Sascha [1] http://gsoc-sugarbot.blogspot.com/ [2] http://lists.sugarlabs.org/archive/sugar-devel/2009-March/012687.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] Moving to GTK3 and GObject Introspection
On Mon, Aug 8, 2011 at 9:15 PM, Sascha Silbe si...@activitycentral.com wrote: The plan looks good in general, thanks for taking the time to draft and elaborate! Thanks for reviewing. It might be worth pointing out that the list in Proposed plan of action contains quite a few actions that can happen in parallel, not just in the particular order given. It already says that, but I'll make it a bit clearer. As mentioned in #sugar, I'd love to see a GTK 2 based version of Sugar without hippo-canvas (this seems to match your plan). Without hippo-canvas, we can finally do automated UI tests. I already have a few other missing pieces in my drawer, but they weren't too useful with the Home View still based on hippo-canvas. It doesn't quite match my plan, as I'm proposing full speed ahead on porting sugar-toolkit which does not require Sugar itself to be GTK3-ported or de-hippoized. The hippo stuff accross the board could feasibly come earlier, and much of the work has already been done, but we need people to step up and polish it and post it for review. I wouldn't want to hold back the migration of sugar-toolkit based on this. Another consideration: I learned from Raul and Walter is that removing hippo from sugar-toolkit is not as simple as just changing some internals. Some public classes in the sugar API are subclasses of hippo, and these are used by activities (which pass in other subclasses of hippo stuff). So, removing hippo will break activities such as Chat. Just something to keep in mind as another API break, and potentially quite an invasive one. 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? I don't think that would be useful. AFAICT there need to be major textual changes anyway. Yes, there do. If we make it clear that it's 1.0 of the technology preview / proof of concept and not of what Sugar wants to be (a learning platform with Collaboration and reflection etc.), that's fine with me. Some people don't like the sound of this, and indeed, it would be less controversial just to stick with the existing numbering scheme. If we don't call this 1.0, do you have any other suggestions for the naming of sugar1, or does it change your opinion on the sugar vs sugar1 choice? 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? I'd like us to work on other issue first. Topics that come to my mind include design changes for touch screen support and extending the Journal (e.g. finally adding the Action View). Of course that doesn't mean a Gnome 3 porting hack session wouldn't be welcome, just that it is less of a priority for me (because there's already one happening right now in Berlin). Agreed. I'm mindful of this, and I've asked Bastien for his opinion, particularly about running GTK3 after the programmed schedule. However, we have some people who are key to these efforts (e.g. Raul and Benjamin Berg) who could only attend for the weekend, so I hope some balance can be found. If we go ahead with these ideas, I'll do what I can to keep the weekend GTK3 sessions small and not drawing anything from the other sessions. Only time can tell. It will depend a lot on the details. However given the usual schedules (with a unit of school years) at deployments, I would expect that we need to keep the GTK 2 version of sugar-toolkit around for more than one year. But since you plan for it to be unmaintained, I wonder what would actually happen after that time. I don't think we should be removing git repositories or old release tarballs. I'll clarify that to say what I really meant - the removal of the frozen GTK2 sugar-toolkit from the development tree (i.e. sugar-toolkit master) after 1 year. Of course, old versions will still be available (and not deleted!) and will probably stay in widespread field use for some time to come, just like Sugar-0.82 is today. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 7, 2011 at 1:18 AM, Raul Gutierrez Segales raul.gutierrez.sega...@collabora.co.uk wrote: Today at the Desktop Summit Daniel Drake (working remotely), Benjamin Berg, Paul Proteus and me got the HelloWorld activity ported to gtk3 and running on a version of Sugar that doesn't use Hippo (based on the work we started with Walter and others to remove Hippo a couple of weeks ago). Great work!!! You should also be bragging about how you did this in less than *3 hours* - starting from nothing, not having ported code to PyGI before, etc. This is pretty convincing to me that this migration isn't going to generate too many headaches. Also, I can't see these lots of hacks that you talk of - I only see a few :) so that is great as well. And some of those things (e.g. set_geometry_hints) could probably be addressed quite quickly by a quick read of http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html and/or a quick exchange with Tomeu. It seems like the biggest remaining areas of uncertainty are sugarext and the theme. Looking forward to what you can solidify during the rest of the summit! cheers, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 07, 2011 at 08:04:47AM +0500, Sebastian Silva wrote: In general I'd propose avoiding 1.0 as long as we haven't implemented the full HIG. I think 1.0 tells users we are comfortable with a finished, generally not buggy product and should not be used for signifying a technology change, which in its first iteration is bound to not be perfect. +1, if during the process of moving to GTK3 sugar will be matured in all directions that it will be ready for 1.0, then switch to 1.0 is obvious. But not sure if it is a good idea to mix switching to gtk3 and trying to be 1.0 (as a well matured platform) at the same time. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 7, 2011 at 9:53 AM, Aleksey Lim alsr...@activitycentral.org wrote: +1, if during the process of moving to GTK3 sugar will be matured in all directions that it will be ready for 1.0, then switch to 1.0 is obvious. But not sure if it is a good idea to mix switching to gtk3 and trying to be 1.0 (as a well matured platform) at the same time. 1.0 doesn't have to indicate mature product - it could just indicate new underlying technologies - but you're right in that some people could/would interpret it with the mature product meaning. It will be interesting to see what happens with Linux 3.0. This major version change means far less than ours would (they didn't change *anything* from normal release cycles), and so far it has not caused any misunderstanding/turmoil, as far as I can see. But this view does raise a few questions: Do you think Sugar would ever be mature? To me, its one of those things that will always have major areas for improvement around the corner. In the case of the HIG, have we seen much movement on compliance in the last 2 years? Would the design team even regard it as something that should be aspired to for a mature release? (I suspect it's quite out of date, as Sugar is a moving target) In the end it is only a number, and there isn't anything wrong with sticking with the current scheme, even if the discussion did go in the 1.0 direction last time - see http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/25094/focus=25156 - but how would the existing scheme work? What release comes after 0.98? 0.100? Then 0.102? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 07, 2011 at 10:14:57AM +0100, Daniel Drake wrote: On Sun, Aug 7, 2011 at 9:53 AM, Aleksey Lim alsr...@activitycentral.org wrote: +1, if during the process of moving to GTK3 sugar will be matured in all directions that it will be ready for 1.0, then switch to 1.0 is obvious. But not sure if it is a good idea to mix switching to gtk3 and trying to be 1.0 (as a well matured platform) at the same time. 1.0 doesn't have to indicate mature product - it could just indicate new underlying technologies - but you're right in that some people could/would interpret it with the mature product meaning. It will be interesting to see what happens with Linux 3.0. This major version change means far less than ours would (they didn't change *anything* from normal release cycles), and so far it has not caused any misunderstanding/turmoil, as far as I can see. well, it might make sense but see the following paragraph.. But this view does raise a few questions: Do you think Sugar would ever be mature? To me, its one of those things that will always have major areas for improvement around the corner. In the case of the HIG, have we seen much movement on compliance in the last 2 years? Would the design team even regard it as something that should be aspired to for a mature release? (I suspect it's quite out of date, as Sugar is a moving target) It obviously depends on how someone is seeing sugar. * If sugar is just a python based window manager with some library toolkit to code python applications for this shell, then sugar is pretty ready to do Linux-3.0 shift (and having bunch of very cool ideas to make horizons wider, e.g., web based approach, integration with other DEs, etc.) * For me sugar is more a social phenomenon when things like python based window manager are just tools to support this phenomenon. The sugar phenomenon for me is an ecosystem for doing (e.g., not only using). One of aspects of such doing (which is closer to me) is creating/changing software (ie, not only creating python based applications for particular python based window manager). And I don't see several (major for me) features implemented: - decent sharing/distribution method of software peaces Once more, it is not about well skilled devs who do it for years and have theirs software well packaged for all major distros. It is about sharing/distributing not-well-matured/one-day-hack/etc software that was done by not skilled devs (ie, sugar doers) as a part of theirs learning while doing process. It is also about that current .xo model is *too* ineffective in several ways: - lack of dependencies when activity devs need to bundle (with all related minuses) or rely on particular sugar distributor that it will include some software (initiatives like Sugar Platform are fixes only in short time period) - it supports only python (or script based in general) software taking into account the lack of dependencies, ie, if activity is ruby based, there is no any guarantee that it will run on sugar box as-is - no official sdk/toolkit to support non-python software/activities but there is what Etoys did, ie, using low level dbus access but no way to create sugar looking UI library, but there is Polyol library that is vala based and can be used (and used in GCompris and Tuxpaint) for wrapping all dbus internals to high level API + gtk UI toolkit instead of python based sugar-toolkit - another way to avoid only-python doing, is reusing web technologies like what was done in Gnome3 and KDE4 eg, WebSDK (or any other SDKs) are the things that need to be introduced in Sugar-1.0 I just mentioned the major points for me, maybe other people have different ones. So, sugar is not ready for 1.0 for me. Of course switching to gtk3 will make it closer but thats not enough. In the end it is only a number, and there isn't anything wrong with sticking with the current scheme, even if the discussion did go in the 1.0 direction last time - see http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/25094/focus=25156 - but how would the existing scheme work? What release comes after 0.98? 0.100? Then 0.102? Well, it is a matter of taste... For me 1.0 should have at least initial implementations for what , at least, I mentioned in previous paragraph. For me having 0.102 sounds better then 1.0 w/o features I talked about. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Sun, Aug 7, 2011 at 5:14 AM, Daniel Drake d...@laptop.org wrote:
On Sun, Aug 7, 2011 at 9:53 AM, Aleksey Lim alsr...@activitycentral.org
wrote:
{...}
{...}
In the end it is only a number, and there isn't anything wrong with
sticking with the current scheme, even if the discussion did go in the
1.0 direction last time - see
http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/25094/focus=25156
- but how would the existing scheme work? What release comes after
0.98? 0.100? Then 0.102?
Daniel
0.982, 0.984 would provide 10 more even steps on the decimal number line
(and signal the imminence of 1.0),
0.9802, 0.9804, would provide 100 steps, if we really still weren't
satisfied.
--Fred
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Fri, 2011-08-05 at 15:12 +0100, Daniel Drake wrote: On Fri, Aug 5, 2011 at 2:26 PM, Gonzalo Odiard gonz...@laptop.org wrote: 2) Sugar theme: with the change to GTK3 we will need rewrite the Sugar theme, right? I think GTK3 use only cairo to draw the widgets, I don't know how is our theme working, and I don't know who can do this work. Good point - this is something that we'll need to investigate. I'll look into it on next opportunity. The current sugar theme does use cairo for all of its drawing (for everyone who does not know, I am the author of the theme). However, the theme is quite complicated, and GTK+ 3.0 introduced a completely new theming system based on CSS and a new engine API (that I am not familiar with). I do hope though that it will be less hackish to implement the required things with GTK+ 3.0. Benjamin ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Hey, On Fri, 2011-08-05 at 17:29 +0100, Daniel Drake wrote: On Fri, Aug 5, 2011 at 5:16 PM, Gonzalo Odiard gonz...@laptop.org wrote: Ok, that is the reason because I have started a new different page. We can start to research this API improvements anyway, probably will not be the same people involved. That's true. The example you have there is actually an API addition, so could fall into any release cycle (I think) - so as you say, it doesn't have to be linked with this project. Today at the Desktop Summit Daniel Drake (working remotely), Benjamin Berg, Paul Proteus and me got the HelloWorld activity ported to gtk3 and running on a version of Sugar that doesn't use Hippo (based on the work we started with Walter and others to remove Hippo a couple of weeks ago). Code is here (gtk3 branches): http://cgit.collabora.com/git/user/rgs/sugar/ http://cgit.collabora.com/git/user/rgs/sugar-toolkit/ The procedure, as suggested by Daniel, (I'll document this on the Wiki before the Summit ends) was: - remove Hippo (done previously) - make a copies of sugar and jarabe and name them sugar-gtk3 and jarabe-gtk3 - make sure that you import sugar-gtk3 and jarabe-gtk3 all over the code - port both of them to PyGObject/gtk3 using the pygi-convert.sh script - port the HelloWorld activity to gtk3 - use a hacked version of sugar-activity that invokes sugar-gtk3 - update a couple of method calls to their new PyGObject API and that was about it. Please note that this was a brute-force approach (i.e.: lots of hacks and comments here and there) to proof if this is conceptually possible (having gtk2 and gtk3 activities co-exist). And it seems it'll work (and it'll be fun!). I am planning on chasing Benjamin during the Summit to see if we can get Sugar's theme ported :) I'll keep the list updated with whatever progress we make and try to document all of this on the Wiki so others can join in. Cheers, Raul ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
The change I would like to see in the API (if we do not have it already) is to ensure that we have full ATK accessibility support for all Sugar controls. Not only would this allow screen readers, etc. to parse Sugar applications and the main window system, but it would make automated testing of Sugar easier as well. I've been told in the past that automating Sugar was not possible apart from a point click approach because hippocanvas and similar did not expose any accessibility information. Since this may require developers to setup additional information inside of activities (alternate names/descriptions, focus tab order, etc.) it is better to get this in as early as possible so activities do not have to be retrofitted to support ATK after the fact. On Fri, Aug 5, 2011 at 12:13 PM, Daniel Drake d...@laptop.org wrote: On Fri, Aug 5, 2011 at 5:08 PM, Gonzalo Odiard gonz...@laptop.org wrote: I have started a API Wishlist page to application developers. http://wiki.sugarlabs.org/go/Features/GTK3/APIWishList We can start to collect best practices, and try to avoid a little the code duplication there are today in the activities. I have no objections to API improvements and changes, but would like to reiterate my view: The importance here should still be placed on the technology shift, rather than on the opportunity to produce a perfect API (which we could spend all eternity designing and discussing). I really like the ideas you have put on that page, I just want to try and steer us clear of using this opportunity to hold up the migration and design a perfect and sparkly-clean API (which would take a long and possibly unbounded time). Thanks! 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] Moving to GTK3 and GObject Introspection
In general I'd propose avoiding 1.0 as long as we haven't implemented the full HIG. I think 1.0 tells users we are comfortable with a finished, generally not buggy product and should not be used for signifying a technology change, which in its first iteration is bound to not be perfect. Kudos for starting this effort! El 05/08/11 18:04, Daniel Drake escribió: 2. Are people happy with labelling components with version number 1.0 once they have a stable GTK3 port? The 1.0 tag was generally agreed upon when this was last discussed a while back, but it would be good to verify current opinion. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Wed, Aug 3, 2011 at 6:07 PM, Daniel Drake d...@laptop.org wrote: So, discuss! :) http://wiki.sugarlabs.org/go/Features/GTK3 Comments, agreement, and hate mail much appreciated - I'll refine the above page based on the discussion that follows. No comments yet. Here are the main questions that (IMO) need discussion: 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? 2. Are people happy with labelling components with version number 1.0 once they have a stable GTK3 port? The 1.0 tag was generally agreed upon when this was last discussed a while back, but it would be good to verify current opinion. 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? 4. Is a one year transition period OK? This would start when a GTK3 port of sugar-toolkit is declared stable and working, would freeze the GTK2 version of sugar-toolkit, and then after 1 year the GTK2 version would be deleted. 4. Are there unanswered questions or considerations that I've missed? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
I have 3 questions: 1) Is the move to python 3 in your plans too? (I don't know if is included in F15) but if we need to break compatibility will be good break it one time. 2) Sugar theme: with the change to GTK3 we will need rewrite the Sugar theme, right? I think GTK3 use only cairo to draw the widgets, I don't know how is our theme working, and I don't know who can do this work. 3) I am not sure about the timing to do this work. I would be more comfortable if we start a planning period now, and start coding after 11.3.0 release. Gonzalo On Fri, Aug 5, 2011 at 10:04 AM, Daniel Drake d...@laptop.org wrote: On Wed, Aug 3, 2011 at 6:07 PM, Daniel Drake d...@laptop.org wrote: So, discuss! :) http://wiki.sugarlabs.org/go/Features/GTK3 Comments, agreement, and hate mail much appreciated - I'll refine the above page based on the discussion that follows. No comments yet. Here are the main questions that (IMO) need discussion: 1. Do we use the python module table magic so that both GTK2 and GTK3 versions of sugar toolkit can have the name sugar, or do we give the GTK3 version a new name (e.g. sugar1)? 2. Are people happy with labelling components with version number 1.0 once they have a stable GTK3 port? The 1.0 tag was generally agreed upon when this was last discussed a while back, but it would be good to verify current opinion. 3. I'm toying with the idea of coordinating a hackfest for this at, or immediately after, Sugarcamp Paris next month. The result would be that sugar-toolkit-1.0 gets released at the end of the hackfest, including GTK2 and GTK3 support. What do people think about that? 4. Is a one year transition period OK? This would start when a GTK3 port of sugar-toolkit is declared stable and working, would freeze the GTK2 version of sugar-toolkit, and then after 1 year the GTK2 version would be deleted. 4. Are there unanswered questions or considerations that I've missed? 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] Moving to GTK3 and GObject Introspection
On Fri, Aug 5, 2011 at 2:26 PM, Gonzalo Odiard gonz...@laptop.org wrote: I have 3 questions: 1) Is the move to python 3 in your plans too? (I don't know if is included in F15) but if we need to break compatibility will be good break it one time. I did look into this, and concluded no. The Py3 move would be much less compatibility-breaking, and would make this task even more painful with no gain. Added my notes here: http://wiki.sugarlabs.org/go/Features/GTK3#Python_3 2) Sugar theme: with the change to GTK3 we will need rewrite the Sugar theme, right? I think GTK3 use only cairo to draw the widgets, I don't know how is our theme working, and I don't know who can do this work. Good point - this is something that we'll need to investigate. I'll look into it on next opportunity. 3) I am not sure about the timing to do this work. I would be more comfortable if we start a planning period now, and start coding after 11.3.0 release. Sugar Labs should not be held back by OLPC's schedule. The longer you leave this transition, the more painful it gets. Sugar is broken now, and we should do our bit to fix this, even though it would not directly contribute to OLPC's next release it would definitely have a very positive effect for OLPC's future releases. Note that this change is not very disruptive, it just needs planning. No activities would need to be ported immediately, and Sugar components can be ported one by one. The porting process is expected to be easy. Disruption could perhaps be further minimized by requiring that sugar-toolkit is ported to GTK3 and running stable before any other work commences. But do remember that sugar-toolkit is proposed to include the GTK2 version as well. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Wed, Aug 3, 2011 at 6:07 PM, Daniel Drake d...@laptop.org wrote: So, discuss! :) http://wiki.sugarlabs.org/go/Features/GTK3 Raul, Simon (and others?) will be attending the Desktop Summit in Berlin next week. I started a page here where we can give them ideas of things that could be done at this event that might be beneficial for this project ;) Please add your own! http://wiki.sugarlabs.org/go/Features/GTK3/DesktopSummitActivities Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
I have started a API Wishlist page to application developers. http://wiki.sugarlabs.org/go/Features/GTK3/APIWishList We can start to collect best practices, and try to avoid a little the code duplication there are today in the activities. Gonzalo On Fri, Aug 5, 2011 at 11:43 AM, Daniel Drake d...@laptop.org wrote: On Wed, Aug 3, 2011 at 6:07 PM, Daniel Drake d...@laptop.org wrote: So, discuss! :) http://wiki.sugarlabs.org/go/Features/GTK3 Raul, Simon (and others?) will be attending the Desktop Summit in Berlin next week. I started a page here where we can give them ideas of things that could be done at this event that might be beneficial for this project ;) Please add your own! http://wiki.sugarlabs.org/go/Features/GTK3/DesktopSummitActivities 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] Moving to GTK3 and GObject Introspection
On Fri, Aug 5, 2011 at 5:08 PM, Gonzalo Odiard gonz...@laptop.org wrote: I have started a API Wishlist page to application developers. http://wiki.sugarlabs.org/go/Features/GTK3/APIWishList We can start to collect best practices, and try to avoid a little the code duplication there are today in the activities. I have no objections to API improvements and changes, but would like to reiterate my view: The importance here should still be placed on the technology shift, rather than on the opportunity to produce a perfect API (which we could spend all eternity designing and discussing). I really like the ideas you have put on that page, I just want to try and steer us clear of using this opportunity to hold up the migration and design a perfect and sparkly-clean API (which would take a long and possibly unbounded time). Thanks! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
Ok, that is the reason because I have started a new different page. We can start to research this API improvements anyway, probably will not be the same people involved. Gonzalo On Fri, Aug 5, 2011 at 1:13 PM, Daniel Drake d...@laptop.org wrote: On Fri, Aug 5, 2011 at 5:08 PM, Gonzalo Odiard gonz...@laptop.org wrote: I have started a API Wishlist page to application developers. http://wiki.sugarlabs.org/go/Features/GTK3/APIWishList We can start to collect best practices, and try to avoid a little the code duplication there are today in the activities. I have no objections to API improvements and changes, but would like to reiterate my view: The importance here should still be placed on the technology shift, rather than on the opportunity to produce a perfect API (which we could spend all eternity designing and discussing). I really like the ideas you have put on that page, I just want to try and steer us clear of using this opportunity to hold up the migration and design a perfect and sparkly-clean API (which would take a long and possibly unbounded time). Thanks! Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Moving to GTK3 and GObject Introspection
On Fri, Aug 5, 2011 at 5:16 PM, Gonzalo Odiard gonz...@laptop.org wrote: Ok, that is the reason because I have started a new different page. We can start to research this API improvements anyway, probably will not be the same people involved. That's true. The example you have there is actually an API addition, so could fall into any release cycle (I think) - so as you say, it doesn't have to be linked with this project. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
