[Sugar-devel] [FEATURE] Create an adapter that calls the third parties/libraries for better maintainability.

Alejandro García tonadevv at gmail.com
Fri Feb 15 13:27:09 EST 2019


I want to reduce the impact of an update of a third party in all the
activities, avoiding the need of change each activity when it happens.

Examples of what I want to avoid are the activities that were updated from
gtk2 to gtk3 and those that still need to be updated.


On Mon, Feb 11, 2019, 11:28 PM James Cameron <quozl at laptop.org wrote:

> On Mon, Feb 11, 2019 at 10:04:02PM -0600, Alejandro García wrote:
> > Let's discard the adapter/shim (main goal is to reduce the dependency).
> >
> > Isn't there anything that we can do to reduce the dependency. Especially
> with
> > Gtk.
>
> What problem are you trying to solve by reducing the dependencies?
>
> > Why aren't CollabWrapper and SugarGame very common between activities?
> > Especially CollabWrapper.
>
> Too few maintainers, and no requirement.
>
> CollabWrapper is not required where an activity does not support
> collaboration.
>
> SugarGame is not required where an activity does not use Pygame.
>
> > If CollabWrapper is simple, why not expanding it?
>
> I don't understand your question, sorry.
>
> > On Sun, Feb 10, 2019, 10:42 PM James Cameron <[1]quozl at laptop.org wrote:
> >
> >     On Sun, Feb 10, 2019 at 08:19:03PM -0600, Alejandro García wrote:
> >     > I was thinking something like calling a GtkAdapter.Label(...)
> instead of
> >     > Gtk.Label (...), or a WebKitAdapter.emit_signal (...) instead of
> >     > WebKit2.emit_signal (...).
> >     >
> >     > Are these examples more clear of what I'm trying to say?
> >
> >     Another word for this is a shim.  An abstraction that only exists to
> >     hide version dependencies.
> >
> >     We have an example of a WebKit API verson independence shim in
> Sugar, see
> >
> >     [2]https://github.com/sugarlabs/sugar/tree/master/src/jarabe/view
> >
> >     viewhelp_webkit1.py is the shim for WebKit.
> >
> >     viewhelp_webkit2.py is the shim for WebKit2.
> >
> >     viewhelp.py choses which of the shims to use.
> >
> >     A disadvantage of shims is huge increase in the number of lines of
> >     code to be maintained.
> >
> >     We cannot use a shim for GTK 2 and GTK 3 independence, because at the
> >     same time the binding moved from static to introspection; PyGObject.
> >
> >     > The CollabWrapper and SugarGame projects are closer to what I'm
> >     > trying to say.  But not the SugarToolkit, as it creates some
> >     > widgets, but if the developer needs more, he will use the Gtk
> >     > library directly.
> >
> >     Okay.  But to proceed with this idea, you must identify a clear
> >     benefit to cover the maintenance cost of adding the shim.
> >
> >     Long term, CollabWrapper could be added to the Toolkit, as it has no
> >     additional dependencies.
> >
> >     Sugargame cannot be added without creating a dependency for Pygame,
> >     which is something that has been resisted for some time; Pygame
> >     activities often do not adapt well to screen rotation and different
> >     display sizes.
> >
> >     --
> >     James Cameron
> >     [3]http://quozl.netrek.org/
> >     _______________________________________________
> >     Sugar-devel mailing list
> >     [4]Sugar-devel at lists.sugarlabs.org
> >     [5]http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> > References:
> >
> > [1] mailto:quozl at laptop.org
> > [2] https://github.com/sugarlabs/sugar/tree/master/src/jarabe/view
> > [3] http://quozl.netrek.org/
> > [4] mailto:Sugar-devel at lists.sugarlabs.org
> > [5] http://lists.sugarlabs.org/listinfo/sugar-devel
>
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
> --
> James Cameron
> http://quozl.netrek.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20190215/9ace23c4/attachment.html>


More information about the Sugar-devel mailing list