I agree with the plan.
My goal is to leverage work done on activities so that they are
available on both Sugar and Sugarizer. Having a Sugar Web library
that works on both is a better outcome than having two separate
libraries, because it will reduce maintenance.
What has tended to happen is that developers who want to work on
JavaScript are attracted to Sugarizer, and developers who want to work
on Python are attracted to Sugar. A division by language preference.
Once an activity is accepted into Sugarizer, developers have been
content with that dopamine hit and haven't worked to get the activity
working in Sugar. Firstly because of the evolution of the Sugar Web
library inside Sugarizer, secondly because of scope constraints for
GCI tasks or GSoC projects, and thirdly because no other developers
have been working on JavaScript activities in Sugar.
This is an opportunity for developers skilled in JavaScript to write
or port activities to Sugar.
On Tue, Apr 07, 2020 at 12:42:08AM +0800, Cheong Siu Hong wrote:
> Hello all,
>
> Currently, the sugar-web library is fairly outdated. I have been working on
> backporting changes from Sugarizer's sugar-web, and more details can be seen
> in
> the pull request at [1]https://github.com/sugarlabs/sugar-web/pull/133.
>
> I would like to open this up to more discussion, but so far from the
> discussion
> in the PR, the plan currently is as follows:
>
> 1. Update a set of files for sugar-web (i.e. for each component)
> 2. Test if some Sugar Web activities work with the updated library, else make
> porting fixes.
> 3. Repeat steps 1 and 2 until sugar-web is up to date with Sugarizer.
> 4. Select a version for next release (i.e. 0.118)
> 5. Push changes to selected Sugar Web activities to make them work with the
> updated library.
> 6. Write a guide for porting old Sugar Web activities.
>
> This merely brings the sugar-web repository back up to speed with that of
> Sugarizer's. Sugarizer activities may still not work natively on Sugar.
>
> I would also like to ask and discuss about the direction that this library is
> going to take. Is the aim to have a sugar-web library that will work on both
> native Sugar Desktop and Sugarizer? Currently, I have submitted a GSoC
> proposal
> for working on this, and it would be great to hear the community's thoughts on
> the matter.
>
> Best regards,
> Cheong Siu Hong
>
> References:
>
> [1] https://github.com/sugarlabs/sugar-web/pull/133
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
--
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
