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

James Cameron quozl at laptop.org
Sun Feb 10 23:42:09 EST 2019

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


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

More information about the Sugar-devel mailing list