<div dir="ltr">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.<div><br></div><div>regards.</div><div><br></div><div>-walter</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 10, 2019 at 7:19 PM Alejandro García <<a href="mailto:tonadevv@gmail.com">tonadevv@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div dir="ltr"><div>***************</div><div>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.<br></div><div>***************<br></div><div>Hi, <br></div><div>I was a participant at GCI 2018, I worked mostly porting to GTK3, WebKit2, and TelepathyGLib.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Advantage:</div><div>- 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). </div><div>- Developing new activities could be easier too, learning GTK (or any other library) won't be necessary at all. <br></div><div><br></div><div>Probably there are more advantages that I'm ignoring. <br></div><div><br></div><div>Disadvantages:</div><div>-
 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.</div><div><br></div><div>Again there might be more disadvantages that I'm ignoring.</div><div><br></div><div>I think that's all. If you have something to say, don't doubt to do it. I want to know what you think. <br></div><div><br></div><div>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.<div class="gmail-m_7562463510855732303gmail-adL"><br></div></div></div>

</div>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div>