libmm-qt/libnm-qt as KF5

Mon Apr 7 07:47:43 UTC 2014

You are still talking about users, but I'm sure that 99% of them will install 
it from distro repositories and because e-c-m is build dependency, they won't 
notice that. For remaining 1% of users you are talking about will be e-c-m 
available from distro repositories as well, so what's the problem? Now those 
libraries are compiled mostly because of Plasma NM, which requires unreleased 
versions (i.e. for frameworks version) and in this case they have already e-c-
m installed. 

I don't want to have libnm-qt/libmm-qt as separated libraries, I think that a 
lot of distributions have them in their repositories, because they are as 
dependency for Plasma NM. I would be really interested how many distributions 
would have it without Plasma NM. It makes sense to me be part of KF5, don't be 
separated and be more visible and available for other developers and users and 
probably less confusing for packagers. 

Cheers,
Jan

On Saturday 05 of April 2014 12:39 Lamarque Souza wrote:
>  In CMakeLists.txt:
> 
> find_package(ECM 0.0.12 REQUIRED NO_MODULE)
> include(KDEInstallDirs)
> include(KDEFrameworkCompilerSettings)
> include(KDECMakeSettings)
> 
> The way it is now you need to install KF'5's cmake modules to parse NMQt's
> CMakeLists.txt, nothing more from KF5 is used. In master branch we use
> modules from cmake package only since the beginning to avoid depending on
> kdelibs. I think KF5's cmake modules should be optional dependency and not
> hard dependency.
> 
> PS: I assuming the three includes above came from KF5. If they are included
> in cmake package so there will be no problem.
> 
> Lamarque V. Souza
> 
> KDE's Network Management maintainer
> 
> http://planetkde.org/pt-br
> 
> On Sat, Apr 5, 2014 at 12:08 PM, Albert Astals Cid <aacid at kde.org> wrote:
> > El Divendres, 4 d'abril de 2014, a les 07:57:26, Lamarque Souza va
> > 
> > escriure:
> > > NMQt and MMQt used to be backends for Solid. We moved them from Solid so
> > > they can be used by more people, even people that do not use KDE
> > 
> > software.
> > 
> > > Forcing everybody to install KF5 just to compile them does not sound a
> > 
> > good
> > 
> > > thing to me. Imagine this talk with someone that want to use those
> > > libraries and do not use KDE software:
> > > 
> > > User: I want to use it, what should I install to compile it?
> > > Us: a c++ compiler, Qt (and its dependencies), NetworkManager (and its
> > > dependencies), cmake and KF5.
> > > User: What is KF5 and why is it needed.
> > > Us: It's the next version of libraries used by KDE software.
> > > User: Does NMQt use it?
> > > Us: No.
> > > User: Why do I need to install it?
> > > Us: Because we want it.
> > 
> > That seems a bit strange. Can you point at where in the framework branch
> > of
> > libnm-qt KF5 is required but not used?
> > 
> > Cheers,
> > 
> >   Albert
> >   
> > > There is absolutely no technical reason for NMQt/MMQt to depend on KF5.
> > 
> > You
> > 
> > > can make that dependency optional but do not force it over everybody
> > > like
> > > you did in NMQt/MMQt's frameworks branches.
> > > 
> > > Besides depending on KF5's cmake modules what else does "being part of
> > 
> > KDE
> > 
> > > frameworks" require?
> > > 
> > > Lamarque V. Souza
> > > 
> > > KDE's Network Management maintainer
> > > 
> > > http://planetkde.org/pt-br
> > > 
> > > On Fri, Apr 4, 2014 at 5:53 AM, Jan Grulich <jgrulich at redhat.com> wrote:
> > > > And what is the problem depending on e-c-m? It's the base package,
> > 
> > which
> > 
> > > > will
> > > > be available everywhere and being a part of KDE frameworks will make
> > 
> > our
> > 
> > > > libraries more visible and connected to KDE. We should be definitely
> > 
> > part
> > 
> > > > of
> > > > frameworks, like Solid. Well, libnm-qt/libmm-qt are  basically Solid
> > > > libraries.
> > > > 
> > > > Those libraries are reusable, they are basically Qt API for
> > > > NetworkManager/ModemManager, so you can manage connections and
> > > > devices.
> > > > 
> > > > Jan
> > > > 
> > > > On Friday 04 of April 2014 05:29 Lamarque Souza wrote:
> > > > > Both libraries are meant to be reusable. What I meant with "merge"
> > > > > is
> > > > > the
> > > > > fact that the branches "frameworks" in NMQt and MMQt depends on
> > > > > KF5's
> > > > 
> > > > cmake
> > > > 
> > > > > modules. I still want NMQt/MMQt usable for those that use Qt but not
> > > > 
> > > > KDE's
> > > > 
> > > > > libraries (kdelibs and KF5).
> > > > > 
> > > > > Lamarque V. Souza
> > > > > 
> > > > > Em 04/04/2014 02:55, "Kevin Ottens" <ervin at kde.org> escreveu:
> > > > > > Hello,
> > > > > > 
> > > > > > On Thursday 03 April 2014 20:19:45 Lamarque Souza wrote:
> > > > > > > Well, NetworkManagerQt and ModemManagerQt are Qt only libraries
> > > > > > > since
> > > > > > > the
> > > > > > > beginning. They are not meant to depend on any KDE libraries as
> > > > > > > I
> > > > 
> > > > said,
> > > > 
> > > > > > so
> > > > > > 
> > > > > > > they are not meant to be merged to KF5.
> > > > > > 
> > > > > > Note this is a blatant logic mistake. All the tier 1 frameworks
> > 
> > depend
> > 
> > > > > > only on
> > > > > > Qt too, but still they are very much part of KF5.
> > > > > > 
> > > > > > There might be reasons to not have those two in KF5, but the one
> > 
> > you
> > 
> > > > > > advance
> > > > > > is clearly the wrong one.
> > > > > > 
> > > > > > Regards.
> > > > > > --
> > > > > > Kévin Ottens, http://ervin.ipsquad.net
> > > > > > 
> > > > > > KDAB - proud supporter of KDE, http://www.kdab.com
> > > > 
> > > > --
> > > > Jan Grulich
> > > > Red Hat Czech, s.r.o
> > > > jgrulich at redhat.com

-- 
Jan Grulich 
Red Hat Czech, s.r.o
jgrulich at redhat.com