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 <qu...@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]qu...@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@lists.sugarlabs.org > > [5]http://lists.sugarlabs.org/listinfo/sugar-devel > > > > References: > > > > [1] mailto:qu...@laptop.org > > [2] https://github.com/sugarlabs/sugar/tree/master/src/jarabe/view > > [3] http://quozl.netrek.org/ > > [4] mailto:Sugar-devel@lists.sugarlabs.org > > [5] http://lists.sugarlabs.org/listinfo/sugar-devel > > > _______________________________________________ > > 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