Hi,
Sure I think they are, I am asking all those questions about dependencies
and implications of adding the libraries to KF5 because of that too. I just
want to make sure the other developers still think the same. I did not make
that decision alone back in 2011 in Madrid.
I think they are useful
Ok, so let's go make a better NMQt/MMQt :-)
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
On Wed, Apr 9, 2014 at 3:44 AM, Jan Grulich wrote:
> Hi,
>
> On Wednesday 09 of April 2014 07:20 Kevin Ottens wrote:
> > Hello,
> >
> > On Tuesday 08 April 2014 19:51:
On 08/04/14 23:51, Lamarque Souza wrote:
> 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 wh
Hi,
On Wednesday 09 of April 2014 07:20 Kevin Ottens wrote:
> Hello,
>
> On Tuesday 08 April 2014 19:51:05 Lamarque Souza wrote:
> > 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
>
Hello,
On Tuesday 08 April 2014 19:51:05 Lamarque Souza wrote:
> 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
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
On Mon, Apr 7, 2014, at 6:05, Lamarque Souza wrote:
> 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 NetworkMana
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 depe
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
docu
Do you agree also with making libmm-qt/libnm-qt as KDE Frameworks? That means
probably change versions, releasing etc.
Jan
On Monday 07 of April 2014 09:38 Lamarque Souza wrote:
> Hi all,
>
> I have cloned ECM git repo and looked at it. I agree that it is small and
> it has useful features for
On Mon, Apr 7, 2014, at 5:38, Lamarque Souza wrote:
> Hi all,
>
> 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.
Hi all,
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/MM
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 remainin
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 availabl
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
Is using ECM required to be part of KF5?
Lamarque V. Souza
KDE's Network Management maintainer
http://planetkde.org/pt-br
On Sat, Apr 5, 2014 at 12:56 PM, Albert Astals Cid wrote:
> El Dissabte, 5 d'abril de 2014, a les 12:39:27, Lamarque Souza va escriure:
> > In CMakeLists.txt:
> >
> > fi
El Dissabte, 5 d'abril de 2014, a les 12:39:27, Lamarque Souza va escriure:
> 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 mo
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
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
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
librarie
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, "Kevi
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
Hello,
On Thursday 03 April 2014 16:47:38 Jan Grulich wrote:
> 1) How to name them? Until now we named them ModemManagerQt and
> NetworkManagerQt, but if we add KF5 prefix, it would be maybe better to name
> it only ModemManager/NetworkManager (with KF5 prefix), but there is a
> problem, if you wi
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.
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. I looked the branches frameworks
and you basically did just that (make them depend on KF5). I think we
should
Hi all,
1) I do not see a real need to rename (again) ModemManagerQt and
NetworkManagerQt. They are named that way to indicate they depend only on
Qt and not on any library created by KDE, so they are tier1 since the
beginning. I am not familiar with KF5's library naming conventions but I
would li
On Thursday 03 of April 2014 12:52 Lamarque Souza wrote:
> Hi all,
>
> 1) I do not see a real need to rename (again) ModemManagerQt and
> NetworkManagerQt. They are named that way to indicate they depend only on
> Qt and not on any library created by KDE, so they are tier1 since the
> beginning. I
27 matches
Mail list logo
