<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-08-15 12:20 GMT+02:00 Chris Green <span dir="ltr"><<a href="mailto:cl@isbd.net" target="_blank">cl@isbd.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Gilles Caulier <<a href="mailto:caulier.gilles@gmail.com">caulier.gilles@gmail.com</a>> wrote:<br>
> > The issue is more subtle than that.  :-)<br>
> ><br>
> > I agree wholly with your sentiments above and there are places where I<br>
> > do contribute, however Digikam is a bit out of my 'spectrum' being KDE<br>
> > based (among other things).<br>
> ><br>
> <br>
> Do you mean 'out of your spectrum' because digiKam is based on KDE ?<br>
> <br>
</span>Yes, sort of, it's also not the sort of software I'm particularly<br>
familiar with (I'm more into low level 'interact with the hardware'<br>
stuff).<br></blockquote><div><br></div><div>You must know that since 5.0.0, and now the future 6.0.0, the KDE dependencies are reduced to the minimum to increase the portability and simplify the maintenance in time.</div><div><br></div><div>It's simple : historically we use a lots of functions, classes, frameworks from KDE to develop quickly the application.</div><div><br></div><div>The side effects are to be too much dependend of a lots of code more and less maintained and not very well working outside Linux. Remember that digiKam must work under MacOS and Windows. This is a challenge with more than 1.4 M of line of C++ codes.</div><div><br></div><div>Qt5 support all these platforms, not KF5 (the KDE frameworks).</div><div><br></div><div>As more and more code can remplace KF5 in Qt5, step by step we remove KF5 dependencies when it's possible.</div><div><br></div><div>Another point is the port to new main frameworks version. The stage to create DK 5 from DK 4 with the switch from Qt4/KDE4 to Qt5/KF5 have take more than 2 years. It's not really acceptable and make developer completely crazy.</div><div><br></div><div>This is the reality, even if KDE developer don't care or don't want to know my words : Depending of KF5 indeed is not acceptable for a multiple desktop application with a lots of code. Can you imageine the quatity of code from KF5 more and less maintened and where each summer we let's students to add more features without regression tests in client applications. Because it's the reallity and this cannot work.</div><div><br></div><div>This is the big problem of KDE project and more and less in Open Source world. In the real life (in computer office where large code is developed - as in mine), we cannot work like this.</div><div><br></div><div>In fact, it miss QA in open source. This is complex to use, time consuming, and need human ressource, but it's necessary at least a little bit.</div><div><br></div><div>Another personal viewpoint : KDE project try to do more and more different stuff, as phone support for ex, that client application projects don't care in fact.</div><div><br></div><div>What's we need :</div><div><br></div><div>- all main platforms support (as Qt5)</div><div>- A wiki support to write documentations and translations on-line (this always require to pass through a complex workflow with developer account, git support, etc...)</div><div>- A financial mechanism to support main application developers. Open Source is not valid model in time. People come and left faster and don't get any interest to support a project (as me for ex) on the long term.</div><div><br></div><div>Gilles Caulier</div></div></div></div>