[Sugar-devel] Moving to GTK3 and GObject Introspection

[Daniel Drake]

On Mon, Aug 8, 2011 at 9:15 PM, Sascha Silbe <silbe at 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