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

[Tony Anderson]

Alejandro García

Generally, I believe you first need to know how to do something several 
times before deciding to automate. In that case, the question is whether 
the automation will be used enough to justify the implementation time 
and effort and whether the automation will make the process enough 
faster and easier to be worthwhile. Being inherently lazy, I love the 
idea of software which makes my life easier. However, most often I have 
spent more time implementing the solution than it would have cost to do 
the job directly.


Would you be willing to spend some time working on some of these 
critical problems directly? You are pointing to serious issues which at 
the moment are not being handled by Sugar_Devel. The following is a list 
off the top of my head of open issues. Some of these can be handled 
directly and simply. Others such as the activity.info issue may take 
some development effort.


Collaboration is considered an important capability for an activity. How 
many activities now support collaboration. How many use Collabwrapper? 
How many of these are suitable for porting to Colllabwrapper?


How many activities in ASLO are based on pygames. As I understand it, 
upgrade to gtk3 depends on using pygames with olpcgames. This is 
currently done with only one activity (Simulate Activity). How many 
activities depend on pygames? What is required to use olpcgames with 
pygames? Is a special gtk3 compatible version of pygames required?


How many activities in ASLO are not yet ported to GTK3? In general any 
activity in ASLO which does not have a github repository. However, there 
are activities in github which have not been converted (and some 
attempted conversions).


The sound in Block Party is not working because of an incorrect use of 
C-Sound. Are there any other activities affected? What is required to 
fix the problem?


The Bridge activity fails because of its use of Box2D. How many 
activities depend on Box2D? What is the required version of Box2D and 
what is required to interface to it?


There are some activities which depend on Java runtime. The Java-1 
activity is intended as a 'shim' but is not capable. How should Java be 
installed as a possibly optional sugar tool so that it can be used by 
any activity that needs it?


There are activities that still use deprecated parameter names in 
activity.info. The solution is to put a warning in the log outpu of that 
activity. How hare would it be to prepare a script that fixed the 
property names in all activities in ASLO? This one involves small 
changes to many activities so some means acceptable to James Cameron 
will be needed to make these changes to the activities in ASLO (and in 
gitHub). Putting the changes in the form of a Pull Request by script may 
be prohibitive.


There are activities that still use hulahop although that has been gone 
since 0.98. Which activiteis have this problem and is there a common way 
to upgrade to WebKit? (Note: this means these activities have not been 
available to our users for years!).


There are activities which fail because of a dependency on vte. How many 
and what is the issue that causes them to fail?


As always, the first step in solving a problem is to identify it. 
Solution space should be avoided until this is done. I don't have enough 
information to believe that development of a general software tool is 
the most effective way forward.


One exception may be to develop an automated means to test the suite of 
activities in a specific execution environment. From what I have seen, 
what might be practical is a Bash or Python script which downloads via 
Browse each activity in turn, executes it, and determines whether the 
activity started or failed to start, and then erases it. In many cases, 
regression with new releases results from changes in the dependencies. 
Often they cause the activity to fail to start.
Detecting this outcome may be facilitated by a change to Sugar which 
causes a specific signal when an activity fails to start that the script 
can use. A more complicated step may be to mine the logs to report the 
problem encountered. This is of lower priority since the number of 
failed activities should be small and consulting the logs is not difficult.


There is a lot of work to be done and much of it of immediate, direct 
and significant value to our user community.


Tony


On 2/16/19 2:27 AM, Alejandro García wrote:
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  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 

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

[Alejandro García]

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  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

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

[James Cameron]

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

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

[Alejandro García]

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.

Why aren't CollabWrapper and SugarGame very common between activities?
Especially CollabWrapper.

If CollabWrapper is simple, why not expanding it?


On Sun, Feb 10, 2019, 10:42 PM James Cameron  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
>
> 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
> http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[James Cameron]

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

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
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Alejandro García]

Yes, something like that.

On Sun, Feb 10, 2019, 8:24 PM Walter Bender 
>
> On Sun, Feb 10, 2019 at 9:19 PM 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?
>>
>> 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.
>>
>
> Maybe you are thinking more of something like this:
>
> https://github.com/sugarlabs/cardsort/blob/master/toolbar_utils.py
>
> -walter
>
>>
>>
>>
>> On Sun, Feb 10, 2019, 7:54 PM Alejandro García >
>>> Ok. Thanks for the clarification.
>>>
>>> On Sun, Feb 10, 2019, 7:44 PM James Cameron >>
 Examples of adapters used by Sugar activities are;

 - Sugar Toolkit for GTK 3, for Python activities,
   https://github.com/sugarlabs/sugar-toolkit-gtk3
   (assumed to be preinstalled on a system that runs Sugar)

 - Sugargame, an integration of GTK 3 and Pygame,
   https://github.com/sugarlabs/sugargame
   (kept as copies of files in activity source code)

 - CollabWrapper, a simplification of Telepathy,
   https://github.com/sugarlabs/collabwrapper
   (kept as copies of files in activity source code)

 - Sugar Web for JavaScript activities,
   https://github.com/sugarlabs/sugar-web
   (kept as copies of files in activity source code)

 We also call them Python modules or Sugar components.

 Please learn each of these adapters fully.

 We already have all the adapters needed, but if you have an idea for a
 new one, please specify it and show how it would simplify maintenance.

 Also, there are some common code patterns in activities that could be
 added to the above adapters.

 A disadvantage of adapters is where they are packaged for Linux
 distributions, such as the Toolkit, because then API version
 dependencies have to be considered.  (e.g. if we have to add a feature
 to the Toolkit to support a new release of the Chat activity, then
 those new releases of the Chat activity won't be able to be used on
 old releases of the Toolkit.)

 --
 James Cameron
 http://quozl.netrek.org/
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

>>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> 
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Walter Bender]

On Sun, Feb 10, 2019 at 9:19 PM 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?
>
> 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.
>

Maybe you are thinking more of something like this:

https://github.com/sugarlabs/cardsort/blob/master/toolbar_utils.py

-walter

>
>
>
> On Sun, Feb 10, 2019, 7:54 PM Alejandro García 
>> Ok. Thanks for the clarification.
>>
>> On Sun, Feb 10, 2019, 7:44 PM James Cameron >
>>> Examples of adapters used by Sugar activities are;
>>>
>>> - Sugar Toolkit for GTK 3, for Python activities,
>>>   https://github.com/sugarlabs/sugar-toolkit-gtk3
>>>   (assumed to be preinstalled on a system that runs Sugar)
>>>
>>> - Sugargame, an integration of GTK 3 and Pygame,
>>>   https://github.com/sugarlabs/sugargame
>>>   (kept as copies of files in activity source code)
>>>
>>> - CollabWrapper, a simplification of Telepathy,
>>>   https://github.com/sugarlabs/collabwrapper
>>>   (kept as copies of files in activity source code)
>>>
>>> - Sugar Web for JavaScript activities,
>>>   https://github.com/sugarlabs/sugar-web
>>>   (kept as copies of files in activity source code)
>>>
>>> We also call them Python modules or Sugar components.
>>>
>>> Please learn each of these adapters fully.
>>>
>>> We already have all the adapters needed, but if you have an idea for a
>>> new one, please specify it and show how it would simplify maintenance.
>>>
>>> Also, there are some common code patterns in activities that could be
>>> added to the above adapters.
>>>
>>> A disadvantage of adapters is where they are packaged for Linux
>>> distributions, such as the Toolkit, because then API version
>>> dependencies have to be considered.  (e.g. if we have to add a feature
>>> to the Toolkit to support a new release of the Chat activity, then
>>> those new releases of the Chat activity won't be able to be used on
>>> old releases of the Toolkit.)
>>>
>>> --
>>> James Cameron
>>> http://quozl.netrek.org/
>>> ___
>>> Sugar-devel mailing list
>>> Sugar-devel@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Alejandro García]

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?

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.



On Sun, Feb 10, 2019, 7:54 PM Alejandro García  Ok. Thanks for the clarification.
>
> On Sun, Feb 10, 2019, 7:44 PM James Cameron 
>> Examples of adapters used by Sugar activities are;
>>
>> - Sugar Toolkit for GTK 3, for Python activities,
>>   https://github.com/sugarlabs/sugar-toolkit-gtk3
>>   (assumed to be preinstalled on a system that runs Sugar)
>>
>> - Sugargame, an integration of GTK 3 and Pygame,
>>   https://github.com/sugarlabs/sugargame
>>   (kept as copies of files in activity source code)
>>
>> - CollabWrapper, a simplification of Telepathy,
>>   https://github.com/sugarlabs/collabwrapper
>>   (kept as copies of files in activity source code)
>>
>> - Sugar Web for JavaScript activities,
>>   https://github.com/sugarlabs/sugar-web
>>   (kept as copies of files in activity source code)
>>
>> We also call them Python modules or Sugar components.
>>
>> Please learn each of these adapters fully.
>>
>> We already have all the adapters needed, but if you have an idea for a
>> new one, please specify it and show how it would simplify maintenance.
>>
>> Also, there are some common code patterns in activities that could be
>> added to the above adapters.
>>
>> A disadvantage of adapters is where they are packaged for Linux
>> distributions, such as the Toolkit, because then API version
>> dependencies have to be considered.  (e.g. if we have to add a feature
>> to the Toolkit to support a new release of the Chat activity, then
>> those new releases of the Chat activity won't be able to be used on
>> old releases of the Toolkit.)
>>
>> --
>> James Cameron
>> http://quozl.netrek.org/
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Alejandro García]

Ok. Thanks for the clarification.

On Sun, Feb 10, 2019, 7:44 PM James Cameron  Examples of adapters used by Sugar activities are;
>
> - Sugar Toolkit for GTK 3, for Python activities,
>   https://github.com/sugarlabs/sugar-toolkit-gtk3
>   (assumed to be preinstalled on a system that runs Sugar)
>
> - Sugargame, an integration of GTK 3 and Pygame,
>   https://github.com/sugarlabs/sugargame
>   (kept as copies of files in activity source code)
>
> - CollabWrapper, a simplification of Telepathy,
>   https://github.com/sugarlabs/collabwrapper
>   (kept as copies of files in activity source code)
>
> - Sugar Web for JavaScript activities,
>   https://github.com/sugarlabs/sugar-web
>   (kept as copies of files in activity source code)
>
> We also call them Python modules or Sugar components.
>
> Please learn each of these adapters fully.
>
> We already have all the adapters needed, but if you have an idea for a
> new one, please specify it and show how it would simplify maintenance.
>
> Also, there are some common code patterns in activities that could be
> added to the above adapters.
>
> A disadvantage of adapters is where they are packaged for Linux
> distributions, such as the Toolkit, because then API version
> dependencies have to be considered.  (e.g. if we have to add a feature
> to the Toolkit to support a new release of the Chat activity, then
> those new releases of the Chat activity won't be able to be used on
> old releases of the Toolkit.)
>
> --
> James Cameron
> http://quozl.netrek.org/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[James Cameron]

Examples of adapters used by Sugar activities are;

- Sugar Toolkit for GTK 3, for Python activities,
  https://github.com/sugarlabs/sugar-toolkit-gtk3
  (assumed to be preinstalled on a system that runs Sugar)

- Sugargame, an integration of GTK 3 and Pygame,
  https://github.com/sugarlabs/sugargame
  (kept as copies of files in activity source code)

- CollabWrapper, a simplification of Telepathy,
  https://github.com/sugarlabs/collabwrapper
  (kept as copies of files in activity source code)

- Sugar Web for JavaScript activities,
  https://github.com/sugarlabs/sugar-web
  (kept as copies of files in activity source code)

We also call them Python modules or Sugar components.

Please learn each of these adapters fully.

We already have all the adapters needed, but if you have an idea for a
new one, please specify it and show how it would simplify maintenance.

Also, there are some common code patterns in activities that could be
added to the above adapters.

A disadvantage of adapters is where they are packaged for Linux
distributions, such as the Toolkit, because then API version
dependencies have to be considered.  (e.g. if we have to add a feature
to the Toolkit to support a new release of the Chat activity, then
those new releases of the Chat activity won't be able to be used on
old releases of the Toolkit.)

-- 
James Cameron
http://quozl.netrek.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Alejandro García]

Can you give me a link to an example where it's applied?

I don't know if I was clear. I was talking about something more "global".
Like a new package at the sugar repository, that way any activity can use
it. All the calls to Gtk (for example) are changed with the adapter in all
the activities and then only the adapter will change in case of an update.


On Sun, Feb 10, 2019, 6:55 PM Walter Bender  We do that to some extent -- for example, there is an "adapter" for
> collaboration and at one point we discussed doing the same with other
> "adapters" I use in the bulk of the activities I wrote -- abstractions of
> the various GTK classes. But it never go that much traction from the rest
> of the dev community.
>
> regards.
>
> -walter
>
> On Sun, Feb 10, 2019 at 7:19 PM Alejandro García 
> wrote:
>
>> ***
>> TLDR; Why not creating an adapter that calls the libraries/third parties
>> that we use creating activities (like GTK, WebKit, etc) and in the
>> activities we only call the adapter? For more information read below.
>> ***
>> Hi,
>> I was a participant at GCI 2018, I worked mostly porting to GTK3,
>> WebKit2, and TelepathyGLib.
>>
>> Time ago I read the book "Clean Code - Robert C. Martin", there he (Uncle
>> Bob) talked a little about using Adapters (what I mean for adapters are
>> files with methods and classes that call the libraries for us. And we
>> instead call the adapter instead of the library/third party) when using
>> third parties. That way you can use the third party in all the app, but if
>> there is an update in the third party you only need to change one place
>> (the adapter).
>>
>> After reading that, I thought how easy could it be if there were an
>> adapter for Gtk, WebKit, and TelepathyGLib instead of changing all the
>> instances of them in each Activity.
>>
>> Basically that's the proposal. Why not creating an Adapter for the
>> libraries that are used in mostly all the activities like GTK and start
>> using it from all the sugar activities.
>>
>> Advantage:
>> - The maintainability of the projects could be easier, as you only need
>> to change one place in case that the library gets an update (probably
>> useful in case of porting to GTK4 in a future, I think its release is going
>> to be at the end of this year).
>> - Developing new activities could be easier too, learning GTK (or any
>> other library) won't be necessary at all.
>>
>> Probably there are more advantages that I'm ignoring.
>>
>> Disadvantages:
>> - Creating this adapter will require time and people, and this can sound
>> like reinventing the wheel. But the dependency to the libraries/third
>> party, will be reduced.
>>
>> Again there might be more disadvantages that I'm ignoring.
>>
>> I think that's all. If you have something to say, don't doubt to do it. I
>> want to know what you think.
>>
>> This is the first proposal that I do to an organization. If there is a
>> template that I didn't follow or the Feature tag is incorrect, please tell
>> me and I can rewrite this mail.
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> 
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Walter Bender]

We do that to some extent -- for example, there is an "adapter" for
collaboration and at one point we discussed doing the same with other
"adapters" I use in the bulk of the activities I wrote -- abstractions of
the various GTK classes. But it never go that much traction from the rest
of the dev community.

regards.

-walter

On Sun, Feb 10, 2019 at 7:19 PM Alejandro García  wrote:

> ***
> TLDR; Why not creating an adapter that calls the libraries/third parties
> that we use creating activities (like GTK, WebKit, etc) and in the
> activities we only call the adapter? For more information read below.
> ***
> Hi,
> I was a participant at GCI 2018, I worked mostly porting to GTK3, WebKit2,
> and TelepathyGLib.
>
> Time ago I read the book "Clean Code - Robert C. Martin", there he (Uncle
> Bob) talked a little about using Adapters (what I mean for adapters are
> files with methods and classes that call the libraries for us. And we
> instead call the adapter instead of the library/third party) when using
> third parties. That way you can use the third party in all the app, but if
> there is an update in the third party you only need to change one place
> (the adapter).
>
> After reading that, I thought how easy could it be if there were an
> adapter for Gtk, WebKit, and TelepathyGLib instead of changing all the
> instances of them in each Activity.
>
> Basically that's the proposal. Why not creating an Adapter for the
> libraries that are used in mostly all the activities like GTK and start
> using it from all the sugar activities.
>
> Advantage:
> - The maintainability of the projects could be easier, as you only need to
> change one place in case that the library gets an update (probably useful
> in case of porting to GTK4 in a future, I think its release is going to be
> at the end of this year).
> - Developing new activities could be easier too, learning GTK (or any
> other library) won't be necessary at all.
>
> Probably there are more advantages that I'm ignoring.
>
> Disadvantages:
> - Creating this adapter will require time and people, and this can sound
> like reinventing the wheel. But the dependency to the libraries/third
> party, will be reduced.
>
> Again there might be more disadvantages that I'm ignoring.
>
> I think that's all. If you have something to say, don't doubt to do it. I
> want to know what you think.
>
> This is the first proposal that I do to an organization. If there is a
> template that I didn't follow or the Feature tag is incorrect, please tell
> me and I can rewrite this mail.
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>


-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

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

[Alejandro García]

 ***
TLDR; Why not creating an adapter that calls the libraries/third parties
that we use creating activities (like GTK, WebKit, etc) and in the
activities we only call the adapter? For more information read below.
***
Hi,
I was a participant at GCI 2018, I worked mostly porting to GTK3, WebKit2,
and TelepathyGLib.

Time ago I read the book "Clean Code - Robert C. Martin", there he (Uncle
Bob) talked a little about using Adapters (what I mean for adapters are
files with methods and classes that call the libraries for us. And we
instead call the adapter instead of the library/third party) when using
third parties. That way you can use the third party in all the app, but if
there is an update in the third party you only need to change one place
(the adapter).

After reading that, I thought how easy could it be if there were an adapter
for Gtk, WebKit, and TelepathyGLib instead of changing all the instances of
them in each Activity.

Basically that's the proposal. Why not creating an Adapter for the
libraries that are used in mostly all the activities like GTK and start
using it from all the sugar activities.

Advantage:
- The maintainability of the projects could be easier, as you only need to
change one place in case that the library gets an update (probably useful
in case of porting to GTK4 in a future, I think its release is going to be
at the end of this year).
- Developing new activities could be easier too, learning GTK (or any other
library) won't be necessary at all.

Probably there are more advantages that I'm ignoring.

Disadvantages:
- Creating this adapter will require time and people, and this can sound
like reinventing the wheel. But the dependency to the libraries/third
party, will be reduced.

Again there might be more disadvantages that I'm ignoring.

I think that's all. If you have something to say, don't doubt to do it. I
want to know what you think.

This is the first proposal that I do to an organization. If there is a
template that I didn't follow or the Feature tag is incorrect, please tell
me and I can rewrite this mail.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel