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