GTK4???

[walterbender]

I wonder if there is something concrete (e.g., coding) that could be done this summer re GTK4? At the Gnome advisory board meeting today, they mentioned a 3-year GTK3 end of life. (That is mitigated on the GTK5 release, which is unlikely to be finished in just 3 year, but nonetheless, we should start thinking about this.)

[walterbender]

Maybe try migrating some small part of the toolkit to GTK4 as a proof of concept?

[quozl]

Yes, this could be a project. May I suggest iteration deliverables;

• migrate minimal toolkit components to support Hello World activity, in particular the activity and graphics classes,
• migrate Hello World,
• document migration strategy based on extending any existing upstream GTK 3 to GTK 4 porting documentation,
• migrate remaining toolkit components,
• extend Hello World to use remaining toolkit components, and rename as a Toolkit Test activity,
• migrate Sugar,
• migrate the Fructose activity set, as time permits.

There could be huge issues to deal with because of our C code and dependence on X11. We would have to select a student with demonstrated capacity in both C and Python. The first deliverable could be one that we use in selection.

[JuiP]

2018-Ideas mentions a project idea: GTK-4 exploration was there a student interested in 2018? Was there any progress on this project idea by anyone?

@quozl what you suggest seems good.

[quozl]

I don't know, I wasn't involved much in 2018. I can't imagine anyone would have got far, given that GTK 4 wasn't released then.

[srevinsaju]

Agreed, I am not sure of the benefits GTK4 would bring to Sugar, provided GTK2 is still used widely,

Porting Sugar to GTK4 without a use case doesn't seem useful. The GNOME 40 release has featured a lot of extensive animations and transitions. If a student is willing to implement both animations and transitions, new layouting, etc., I would agree with the port to GTK4.

This would include a complete overhaul of the Sugar GTK Shell, and would require a redesign.

I would suggest

• A design prototype of the new Sugar UI.
• Allocate GSoC21: idea for Human Interface Guidelines Redesign #114 to only-design and zero, or very less coding. The number of activities should be increased. The badges feature should then be handled by the student selected for the GTK4 port as they would have a better implementation.

If possible, it would be better to have 2-3 students working on the redesign of the Sugar GTK4 shell, as porting and shell redesign is a huge task.

[chimosky]

@quozl said;

There could be huge issues to deal with because of our C code and dependence on X11. We would have to select a student with demonstrated capacity in both C and Python. The first deliverable could be one that we use in selection.

I agree.

@srevinsaju said;

Agreed, I am not sure of the benefits GTK4 would bring to Sugar, provided GTK2 is still used widely,

I don't know when GTK2 will get to it's EOL but that might or might not be anytime soon and considering that GTK4 was just released, it might not be beneficial at the moment but it'll be in the long run and starting now might be good.

With the new GSoC changes we might have to break down this particular task to some other tasks so various students can work on it and we can have each communicate as this isn't something that can be done standalone at the moment and by just one person, there's been lots of changes to GTK4 and I haven't looked extensively yet but I plan to and this will be a reason to.

Allocate #114 to only-design and zero, or very less coding. The number of activities should be increased. The badges feature should then be handled by the student selected for the GTK4 port as they would have a better implementation.

My understanding of this task was more design than anything else and a little coding.
It could also include exploring GTK4 and how it's new features help Sugar wrt redesigning the Human Interface Guidelines.

[walterbender]

It took (is taking) a long time to migrate to GTK3, so I think it prudent to get started on GTK4 as soon as possible. GTK2 is deprecated as far as GNOME is concerned, so we really cannot rely on it, even if there are still many people using it. And at some point, the support burden will become more than we can manage as a community. (I would argue we have already reached that point.)

I think James' suggestions for very targeted programming tasks are spot on -- this should be a coding task, not just a design task. We need to get some experience with GTK4 within our context. It will take a talented student, but let's aim high.

[chimosky]

@walterbender said;

I think James' suggestions for very targeted programming tasks are spot on -- this should be a coding task, not just a design task. We need to get some experience with GTK4 within our context. It will take a talented student, but let's aim high.

I agree and my reference to the design task was #114.

[srevinsaju]

@srevinsaju said;

Agreed, I am not sure of the benefits GTK4 would bring to Sugar, provided GTK2 is still used widely,

I don't know when GTK2 will get to it's EOF but that might or might not be anytime soon and considering that GTK4 was just released, it might not be beneficial at the moment but it'll be in the long run and starting now might be good.

With the new GSoC changes we might have to break down this particular task to some other tasks so various students can work on it and we can have each communicate as this isn't something that can be done standalone at the moment and by just one person, there's been lots of changes to GTK4 and I haven't looked extensively yet but I plan to and this will be a reason to.

Agreed.

Allocate #114 to only-design and zero, or very less coding. The number of activities should be increased. The badges feature should then be handled by the student selected for the GTK4 port as they would have a better implementation.

My understanding of this task was more design than anything else and a little coding.
It could also include exploring GTK4 and how it's new features help Sugar wrt redesigning the Human Interface Guidelines.

Yes, that would be the best.

[quozl]

Thanks for the technical assessments and links to changes. I'd also like to see us use Qt, as it has proven more stable over the last ten years. When we started with GTK, it was the Gimp Toolkit. Now it seems to have been acquired mostly by the GNOME project, and that project has taken over maintenance to the point that they have no concern for the migration and porting effort that they induce in other projects. We always have the choice to do vendoring, where we maintain older GTK as software inside Sugar. I'm already doing that for GTK 2 on OLPC OS, so that GTK 2 activities can continue to be used. We have to appreciate the value that the upstream GTK project brings; and where that value has declined, we might have to switch somehow.

[srevinsaju]

Thanks for the technical assessments and links to changes. I'd also like to see us use Qt, as it has proven more stable over the last ten years.

Agreed. I remember asking this question exactly a year ago, when I came across Mnemosyne. I prefer Qt over GTK*. I hope this would also help us get remove metacity and use a better window manager like kwin.

Some benefits of using Qt:

• The availability of Qt Designer which is a drag-n-drop UI creation tool, extensively for C++/Python Qt projects
• QtQuick which is a powerful API to "create a rich application with a fluid and dynamic user interface". This help us to make use of web applications, Sugarizer Activities and Musicblocks natively.

[quozl]

@srevinsaju, as you've had recent experience in both, would you like to describe a Qt toolkit project? If you like, you could even get it started, and leave the boring bits to a GSoC student. ;-)

[walterbender]

FWIW, a bit of history: We had a project sponsored by Nokia circa 2009 to port Sugar to QT. It stalled out due to some contract issues with our then parent org. Water over the dam, but it might have been quite interesting had it seen the light of day.

[quozl]

Interesting, I've not heard anything about that. Then again why would anyone tell me? 😁

@srevinsaju, my hope is that porting to Qt will help us compensate long term for failure to maintain the port to JavaScript, which has been so bad as to prevent practical re-use of later JavaScript activities like in Sugarizer or Music Blocks. Plenty of Qt programmers out there, and it is often used in industry.

[chimosky]

Haven't used Qt before but I've read a bit about it and it does seem interesting.

[srevinsaju]

@srevinsaju, as you've had recent experience in both, would you like to describe a Qt toolkit project? If you like, you could even get it started, and leave the boring bits to a GSoC student. ;-)

Yea, agreed. A Sugar Qt Toolkit would be amazing, along with a Qt based Sugar Shell. I will try to give it a shot. Perhaps, I will draft out a GSoC proposal for the same. 😄

I would say, porting Sugar to Qt, and creating a Sugar Qt toolkit will still not hinder running Sugar GTK Activities, but I am not sure if the reverse would be possible.

@srevinsaju, my hope is that porting to Qt will help us compensate long term for failure to maintain the port to JavaScript, which has been so bad as to prevent practical re-use of later JavaScript activities like in Sugarizer or Music Blocks. Plenty of Qt programmers out there, and it is often used in industry.

Agreed. this would be indeed memory efficient and powerful.

[srevinsaju]

• we would also support wayland. 🚀

[quozl]

Yes. I think porting Sugar to Qt is less important than making a Sugar Toolkit for Qt, but still a good long term strategy.

[JuiP]

Haven't used Qt before but I've read a bit about it and it does seem interesting.

+1

[JuiP]

The deadline for applying as a mentoring organization in GSoC is Friday, Feb 19th at 1900 UTC. Is there something concrete we can add as a project idea?

[quozl]

We can add ideas after the application is made. It is however better to have good ideas at the time Google are reviewing the application. Sorry, I don't have time to write the idea.

[llaske]

Waow 😱 migrating Sugar to Qt basically means rewriting Sugar and activities from scratch.
It's what I've done with Sugarizer - which is more or less a rewriting of Sugar in JavaScript - and it was a 5 years project to have a basic set of features/activities!
Are you sure the Sugar community could support a such long effort?

[quozl]

Heh, we haven't even managed to port Sugar to JavaScript. Nothing works. We keep getting Python contributions. So no, I don't think our community could support even this effort.

[llaske]

Heh, we haven't even managed to port Sugar to JavaScript.

Sugarizer is build on Sugar-Web, the first brick of Sugar in JavaScript (credits here), so in a sense it's a success...

[quozl]

I know. But Sugar-Web hasn't been maintained in Sugar, and hasn't worked for some years, so there are no working JavaScript activities in Sugar.

[pikurasa]

Should this issue remain open?

[chimosky]

I think we can leave it open as we never really did anything about it and we'll need to at some point.

[quozl]

I think the discussion reached a useful consensus. Either GTK4, Qt or JavaScript are good next steps to ensure Sugar environment on PC platforms remains current. Staying with GTK3 is not a safe plan, in the same way that staying so long with GTK2 was not a good outcome.

Our technical debt still includes GTK2 activities that have not or will not be ported. No, I'm not going to enumerate them again, that doesn't seem to help. 😁