libmm-qt/libnm-qt as KF5

[Lamarque Souza]

Hi,

 I understood that, I just do not know all the other things we need to do
to make NMQt/MMQt part of KF5. And yes, I agree in making NMQt/MMQt part of
KF5. The other doubt I still have is  where _kde_add_platform_definitions
is defined. By what I could figure out it is not in ECM, so something else
is needed to parse the CMakeLists.txt file in current NMQt's framework
branch.

As for my questioning about merging NMQt/MMQt into plasma-nm repo is
because every time I argue that we should make them usable for non-KDE
users arguments like this appears: "I would be really interested how many
distributions would have it [NMQt] without Plasma NM.". Now I am wondering
if I am the only one that still thinks NMQt/MMQt are useful for other
software besides Plasma NM.

Lamarque V. Souza

KDE's Network Management maintainer

http://planetkde.org/pt-br


On Mon, Apr 7, 2014 at 10:11 AM, Mario Fux <kde-ml at unormal.org> wrote:

> Am Montag, 07. April 2014, 14.38:14 schrieb Lamarque Souza:
> > Hi all,
>
> Morning Lamarque
>
> > I have cloned ECM git repo and looked at it. I agree that it is small and
> > it has useful features for NMQt/MMQt. I like the fact that it provides a
> > FindNetworkManager.cmake. Ok, we can make ECM a hard dependency for
> > NMQt/MMQt.
> >
> > My only concern now is the kde-modules that Jan used in NMQt/MMQt's
> > framework branches. Is it necessary to have KF5 installed to use those
>
> Here still seems to be a misunderstanding about KDE Frameworks (KF5). The
> goal
> and idea was and is it to modularize kdelibs so that people can pick the
> frameworks (e.g. KConfig and Sonnet) they need for an app and don't need to
> use and install all of them. So for the case of our (KDE) apps a lot (or
> most)
> of them will depend on many or all of the Frameworks in KF5. But all other
> Qt
> apps and libs that want to use the KDE Frameworks can just pick the once
> they
> need.
>
> Hope that clarifies KF5 a bit
> Mario
>
> > modules? I am asking it because I did not find where in ECM repo the
> > macro _kde_add_platform_definitions is defined.
> >
> > Lamarque V. Souza
> >
> > KDE's Network Management maintainer
> >
> > http://planetkde.org/pt-br
> >
> > On Mon, Apr 7, 2014 at 5:31 AM, Martin Gräßlin <mgraesslin at kde.org>
> wrote:
> > > On Monday 07 April 2014 10:14:12 David Faure wrote:
> > > > On Monday 07 April 2014 09:47:43 Jan Grulich wrote:
> > > > > 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.
> > > >
> > > > I agree. ECM is a very tiny dependency to have, and in return it
> solves
> > > > a large number of issues for you (deployment, cmake config files,
> > > > qmake
> > >
> > > .pri
> > >
> > > > file, dependency handling for users of your libs, forwarding headers,
> > > > versioning, releasing, etc. etc.).
> > >
> > > This is IMHO the important point. Just look at what ECM provides and
> you
> > > will
> > > realize that it's extremely useful and that even if those libraries
> will
> > > not
> > > end up in KF5, they will use ECM. How can I do such a bold statement?
> > > Because
> > > ECM solves real world problems you want to have solved in your library,
> > > too.
> > > The developers using your library will expect a proper Config.cmake
> file
> > > and a
> > > proper Version.cmake file and ECM solves that for you. I'm using ECM in
> > > libraries not intended to ever be part of KF5 exactly for that and
> before
> > > I added that dependency it was just not possible to reliable use the
> > > library.
> > >
> > > Of course you can also write that CMake Foo all by yourself but I have
> > > the feeling that the knowledge to write proper CMake Foo is not wide
> > > spread among
> > > our developers. I personally prefer to use the CMake Foo written by
> > > people who
> > > know their stuff instead of doing my own.
> > >
> > > Cheers
> > > Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140408/e7f6b7de/attachment.html>