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