<div dir="ltr">How are they are going to change? The "etc" here is important too. Remember that NMQt follows NetworkManager's release numbers, the same is true for MMQt and ModemManager. That is for simplify things for those who are used to NetworkManager's release number, I prefer to keep that. Is there any document explaining what is needed for a library to be part of KF5? I prefer to know all the implications beforehand.<div>
<br></div><div>Keeping the dependencies for NMQt/MMQt to the minimum is important to make them more available to other users. I know Plasma NM is the main user of NMQt/MMQt. However we moved them to separated libraries to make them usefull for non-KDE users as well. Adding ECM's kde-modules as dependencies seems to break that goal. If it was not to make NMQt/MMQt usefull for non-KDE users it would be simpler to merge them into Plasma NM again (like they are in Plasma NM 0.9.0.x). That would remove the burden of keeping binary compatibility from us.</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">
<p style="margin:0px">Lamarque V. Souza</p>
<p style="margin:0px">KDE's Network Management maintainer</p>
<p style="margin:0px"><a href="http://planetkde.org/pt-br" target="_blank">http://planetkde.org/pt-br</a></p></div></div>
<br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 9:46 AM, Jan Grulich <span dir="ltr"><<a href="mailto:jgrulich@redhat.com" target="_blank">jgrulich@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you agree also with making libmm-qt/libnm-qt as KDE Frameworks? That means<br>
probably change versions, releasing etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Monday 07 of April 2014 09:38 Lamarque Souza wrote:<br>
> Hi all,<br>
><br>
> I have cloned ECM git repo and looked at it. I agree that it is small and<br>
> it has useful features for NMQt/MMQt. I like the fact that it provides a<br>
> FindNetworkManager.cmake. Ok, we can make ECM a hard dependency for<br>
> NMQt/MMQt.<br>
><br>
> My only concern now is the kde-modules that Jan used in NMQt/MMQt's<br>
> framework branches. Is it necessary to have KF5 installed to use those<br>
> modules? I am asking it because I did not find where in ECM repo the<br>
> macro _kde_add_platform_definitions is defined.<br>
><br>
> Lamarque V. Souza<br>
><br>
> KDE's Network Management maintainer<br>
><br>
> <a href="http://planetkde.org/pt-br" target="_blank">http://planetkde.org/pt-br</a><br>
><br>
> On Mon, Apr 7, 2014 at 5:31 AM, Martin Gräßlin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>> wrote:<br>
> > On Monday 07 April 2014 10:14:12 David Faure wrote:<br>
> > > On Monday 07 April 2014 09:47:43 Jan Grulich wrote:<br>
> > > > You are still talking about users, but I'm sure that 99% of them will<br>
> > > > install it from distro repositories and because e-c-m is build<br>
> ><br>
> > dependency,<br>
> ><br>
> > > > they won't notice that. For remaining 1% of users you are talking<br>
> > > > about<br>
> > > > will be e-c-m available from distro repositories as well, so what's<br>
> > > > the<br>
> > > > problem? Now those libraries are compiled mostly because of Plasma NM,<br>
> > > > which requires unreleased versions (i.e. for frameworks version) and<br>
> > > > in<br>
> > > > this case they have already e-c- m installed.<br>
> > > ><br>
> > > > I don't want to have libnm-qt/libmm-qt as separated libraries, I think<br>
> > > > that<br>
> > > > a lot of distributions have them in their repositories, because they<br>
> ><br>
> > are<br>
> ><br>
> > > > as<br>
> > > > dependency for Plasma NM. I would be really interested how many<br>
> > > > distributions would have it without Plasma NM. It makes sense to me be<br>
> > > > part<br>
> > > > of KF5, don't be separated and be more visible and available for other<br>
> > > > developers and users and probably less confusing for packagers.<br>
> > ><br>
> > > I agree. ECM is a very tiny dependency to have, and in return it solves<br>
> > > a<br>
> > > large number of issues for you (deployment, cmake config files, qmake<br>
> ><br>
> > .pri<br>
> ><br>
> > > file, dependency handling for users of your libs, forwarding headers,<br>
> > > versioning, releasing, etc. etc.).<br>
> ><br>
> > This is IMHO the important point. Just look at what ECM provides and you<br>
> > will<br>
> > realize that it's extremely useful and that even if those libraries will<br>
> > not<br>
> > end up in KF5, they will use ECM. How can I do such a bold statement?<br>
> > Because<br>
> > ECM solves real world problems you want to have solved in your library,<br>
> > too.<br>
> > The developers using your library will expect a proper Config.cmake file<br>
> > and a<br>
> > proper Version.cmake file and ECM solves that for you. I'm using ECM in<br>
> > libraries not intended to ever be part of KF5 exactly for that and before<br>
> > I<br>
> > added that dependency it was just not possible to reliable use the<br>
> > library.<br>
> ><br>
> > Of course you can also write that CMake Foo all by yourself but I have the<br>
> > feeling that the knowledge to write proper CMake Foo is not wide spread<br>
> > among<br>
> > our developers. I personally prefer to use the CMake Foo written by people<br>
> > who<br>
> > know their stuff instead of doing my own.<br>
> ><br>
> > Cheers<br>
> > Martin<br>
</div></div></blockquote></div><br></div>