date:20140409

Re: KDE(Libs)4Support rename

2014-04-09 Thread Kevin Ottens

Hello,

On Wednesday 09 April 2014 18:33:38 Alex Merry wrote:
> I have a local commit renaming kde4support to kdelibs4support.  It's
> long and tedious and repetitive, so I don't see much point in putting it
> on RB, but the gist is:
> 
> kde4support -> kdelibs4support
> KDE4SUPPORT -> KDELIBS4SUPPORT
> KDE4Support -> KDELibs4Support
> KDE4 Support -> KDELibs 4 Support (eg: top of README.md)
> Kde4support -> KdeLibs4Support (function names in autotests)
> 
> This goes for file names as well as contents.  The result is that both
> find -iname \*kde4support\*
> and
> git grep -i kde4support
> come up empty.
> 
> Are there any objections to me pushing this (along with relevant changes
> - mostly to CMake code and comments - in other repos, of course)?

Good to go from my side. The earlier the better for that one.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117454: Implement KUser::faceIconPath for Windows XP

2014-04-09 Thread Alexander Richardson


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117454/#review55319
---

Ship it!


Looks good, but hopefully we can drop XP support soon

- Alexander Richardson


On April 9, 2014, 7:06 p.m., Nicolás Alvarez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117454/
> ---
> 
> (Updated April 9, 2014, 7:06 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> ---
> 
> The undocuented API we're using has a different ordinal and parameters on 
> Windows XP vs Vista/7.
> 
> I refactored the code to use a template and structs encapsulating the 
> differences, as otherwise the code became too redundant.
> 
> Feedback welcome on identifier names, that's a known hard problem :)
> 
> 
> Diffs
> -
> 
>   src/lib/util/kuser_win.cpp aa48c04 
> 
> Diff: https://git.reviewboard.kde.org/r/117454/diff/
> 
> 
> Testing
> ---
> 
> Ran faceicontest on Windows 7 and on XP.
> 
> 
> Thanks,
> 
> Nicolás Alvarez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117440: Make sure that common licenses are accessed throught help:/ protocol

2014-04-09 Thread Commit Hook


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117440/#review55316
---


This review has been submitted with commit 
60b2ed0e85ed42b728473be4aed24d19cdf74a13 by Luigi Toscano to branch master.

- Commit Hook


On April 8, 2014, 10:02 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117440/
> ---
> 
> (Updated April 8, 2014, 10:02 p.m.)
> 
> 
> Review request for Documentation and KDE Frameworks.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> ---
> 
> This change removes one of the reason for keeping the "common"/ symlinks into 
> documentation directories; translated common licenses are accessed now using 
> the help:/ kioslave, which finds them in /common.
> Please note that help:/ prefix can be overridden by changing the 
> kde.common parameter (for example, generation of documentation on the 
> website).
> 
> 
> Diffs
> -
> 
>   src/customization/af/entities/underArtisticLicense.docbook f19b961 
>   src/customization/af/entities/underBSDLicense.docbook 1222e95 
>   src/customization/af/entities/underFDL.docbook 6afff8b 
>   src/customization/af/entities/underGPL.docbook 6d8ef8b 
>   src/customization/af/entities/underX11License.docbook a216e53 
>   src/customization/bg/entities/underArtisticLicense.docbook fa02270 
>   src/customization/bg/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/bg/entities/underFDL.docbook 633ce72 
>   src/customization/bg/entities/underGPL.docbook a2074f3 
>   src/customization/bg/entities/underX11License.docbook 7eb81f0 
>   src/customization/ca/entities/underArtisticLicense.docbook 300167f 
>   src/customization/ca/entities/underBSDLicense.docbook 4bde1df 
>   src/customization/ca/entities/underFDL.docbook 7ab5762 
>   src/customization/ca/entities/underGPL.docbook 1bfeec7 
>   src/customization/ca/entities/underLGPL.docbook 1bf0a38 
>   src/customization/ca/entities/underX11License.docbook 4e1093e 
>   src/customization/cs/entities/underArtisticLicense.docbook fa02270 
>   src/customization/cs/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/cs/entities/underFDL.docbook 65d5936 
>   src/customization/cs/entities/underGPL.docbook 27d9047 
>   src/customization/cs/entities/underX11License.docbook 7eb81f0 
>   src/customization/da/entities/underArtisticLicense.docbook 612fb2e 
>   src/customization/da/entities/underBSDLicense.docbook 3d2630b 
>   src/customization/da/entities/underFDL.docbook 78acfee 
>   src/customization/da/entities/underGPL.docbook 97e0af6 
>   src/customization/da/entities/underLGPL.docbook 591c332 
>   src/customization/da/entities/underX11License.docbook 69bad4c 
>   src/customization/de/entities/underArtisticLicense.docbook 78d63bc 
>   src/customization/de/entities/underBSDLicense.docbook ffbdf67 
>   src/customization/de/entities/underFDL.docbook dbb7c69 
>   src/customization/de/entities/underGPL.docbook 3bc2ca2 
>   src/customization/de/entities/underLGPL.docbook 91c4ee8 
>   src/customization/de/entities/underX11License.docbook 9027b44 
>   src/customization/el/entities/underArtisticLicense.docbook fa02270 
>   src/customization/el/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/el/entities/underFDL.docbook 65d5936 
>   src/customization/el/entities/underGPL.docbook 27d9047 
>   src/customization/el/entities/underX11License.docbook 7eb81f0 
>   src/customization/en-GB/entities/underArtisticLicense.docbook fa02270 
>   src/customization/en-GB/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/en-GB/entities/underFDL.docbook 633ce72 
>   src/customization/en-GB/entities/underGPL.docbook a2074f3 
>   src/customization/en-GB/entities/underX11License.docbook 7eb81f0 
>   src/customization/en/entities/underArtisticLicense.docbook fa02270 
>   src/customization/en/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/en/entities/underFDL.docbook 633ce72 
>   src/customization/en/entities/underGPL.docbook a2074f3 
>   src/customization/en/entities/underLGPL.docbook 35f89bd 
>   src/customization/en/entities/underX11License.docbook 7eb81f0 
>   src/customization/eo/entities/underArtisticLicense.docbook b214453 
>   src/customization/eo/entities/underBSDLicense.docbook 2eea358 
>   src/customization/eo/entities/underFDL.docbook edcab1b 
>   src/customization/eo/entities/underGPL.docbook 69ccd1d 
>   src/customization/eo/entities/underX11License.docbook f1295ff 
>   src/customization/es/entities/underArtisticLicense.docbook fdb0555 
>   src/customization/es/entities/underBSDLicense.docbook 78c5742 
>   src/customization/es/entities/underFDL.docbook 18b96e2 
>   src/customization/es/entities/underGPL.docbook 2bee3b0 
>   src

Re: Review Request 117440: Make sure that common licenses are accessed throught help:/ protocol

2014-04-09 Thread Luigi Toscano


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117440/
---

(Updated April 9, 2014, 11:14 p.m.)


Status
--

This change has been marked as submitted.


Review request for Documentation and KDE Frameworks.


Repository: kdoctools


Description
---

This change removes one of the reason for keeping the "common"/ symlinks into 
documentation directories; translated common licenses are accessed now using 
the help:/ kioslave, which finds them in /common.
Please note that help:/ prefix can be overridden by changing the 
kde.common parameter (for example, generation of documentation on the website).


Diffs
-

  src/customization/af/entities/underArtisticLicense.docbook f19b961 
  src/customization/af/entities/underBSDLicense.docbook 1222e95 
  src/customization/af/entities/underFDL.docbook 6afff8b 
  src/customization/af/entities/underGPL.docbook 6d8ef8b 
  src/customization/af/entities/underX11License.docbook a216e53 
  src/customization/bg/entities/underArtisticLicense.docbook fa02270 
  src/customization/bg/entities/underBSDLicense.docbook 0dc93f1 
  src/customization/bg/entities/underFDL.docbook 633ce72 
  src/customization/bg/entities/underGPL.docbook a2074f3 
  src/customization/bg/entities/underX11License.docbook 7eb81f0 
  src/customization/ca/entities/underArtisticLicense.docbook 300167f 
  src/customization/ca/entities/underBSDLicense.docbook 4bde1df 
  src/customization/ca/entities/underFDL.docbook 7ab5762 
  src/customization/ca/entities/underGPL.docbook 1bfeec7 
  src/customization/ca/entities/underLGPL.docbook 1bf0a38 
  src/customization/ca/entities/underX11License.docbook 4e1093e 
  src/customization/cs/entities/underArtisticLicense.docbook fa02270 
  src/customization/cs/entities/underBSDLicense.docbook 0dc93f1 
  src/customization/cs/entities/underFDL.docbook 65d5936 
  src/customization/cs/entities/underGPL.docbook 27d9047 
  src/customization/cs/entities/underX11License.docbook 7eb81f0 
  src/customization/da/entities/underArtisticLicense.docbook 612fb2e 
  src/customization/da/entities/underBSDLicense.docbook 3d2630b 
  src/customization/da/entities/underFDL.docbook 78acfee 
  src/customization/da/entities/underGPL.docbook 97e0af6 
  src/customization/da/entities/underLGPL.docbook 591c332 
  src/customization/da/entities/underX11License.docbook 69bad4c 
  src/customization/de/entities/underArtisticLicense.docbook 78d63bc 
  src/customization/de/entities/underBSDLicense.docbook ffbdf67 
  src/customization/de/entities/underFDL.docbook dbb7c69 
  src/customization/de/entities/underGPL.docbook 3bc2ca2 
  src/customization/de/entities/underLGPL.docbook 91c4ee8 
  src/customization/de/entities/underX11License.docbook 9027b44 
  src/customization/el/entities/underArtisticLicense.docbook fa02270 
  src/customization/el/entities/underBSDLicense.docbook 0dc93f1 
  src/customization/el/entities/underFDL.docbook 65d5936 
  src/customization/el/entities/underGPL.docbook 27d9047 
  src/customization/el/entities/underX11License.docbook 7eb81f0 
  src/customization/en-GB/entities/underArtisticLicense.docbook fa02270 
  src/customization/en-GB/entities/underBSDLicense.docbook 0dc93f1 
  src/customization/en-GB/entities/underFDL.docbook 633ce72 
  src/customization/en-GB/entities/underGPL.docbook a2074f3 
  src/customization/en-GB/entities/underX11License.docbook 7eb81f0 
  src/customization/en/entities/underArtisticLicense.docbook fa02270 
  src/customization/en/entities/underBSDLicense.docbook 0dc93f1 
  src/customization/en/entities/underFDL.docbook 633ce72 
  src/customization/en/entities/underGPL.docbook a2074f3 
  src/customization/en/entities/underLGPL.docbook 35f89bd 
  src/customization/en/entities/underX11License.docbook 7eb81f0 
  src/customization/eo/entities/underArtisticLicense.docbook b214453 
  src/customization/eo/entities/underBSDLicense.docbook 2eea358 
  src/customization/eo/entities/underFDL.docbook edcab1b 
  src/customization/eo/entities/underGPL.docbook 69ccd1d 
  src/customization/eo/entities/underX11License.docbook f1295ff 
  src/customization/es/entities/underArtisticLicense.docbook fdb0555 
  src/customization/es/entities/underBSDLicense.docbook 78c5742 
  src/customization/es/entities/underFDL.docbook 18b96e2 
  src/customization/es/entities/underGPL.docbook 2bee3b0 
  src/customization/es/entities/underLGPL.docbook 6340667 
  src/customization/es/entities/underX11License.docbook 5f40cc0 
  src/customization/et/entities/underArtisticLicense.docbook a17c99d 
  src/customization/et/entities/underBSDLicense.docbook a231ded 
  src/customization/et/entities/underFDL.docbook 4835cfbc 
  src/customization/et/entities/underGPL.docbook 20306e9 
  src/customization/et/entities/underLGPL.docbook f854aeb 
  src/customization/et/entities/underX11License.docbook 1975fd7 
  src/customization/fi/entities/underArtisticLic

Re: Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Hrvoje Senjan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/
---

(Updated April 9, 2014, 10:53 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: kio-extras


Description
---

KWin and libksysguard are not required. same with KDeclarative, Plasma, 
KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
linked in subdirectories, so explicitly search for them.


Diffs
-

  CMakeLists.txt e67becb 
  thumbnail/CMakeLists.txt 97fdbb0 

Diff: https://git.reviewboard.kde.org/r/117457/diff/


Testing
---

Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.


Thanks,

Hrvoje Senjan

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Commit Hook


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/#review55315
---


This review has been submitted with commit 
e6793e03a3c5ac6237673378aa327bb5a4d47ff4 by Hrvoje Senjan to branch master.

- Commit Hook


On April 9, 2014, 10:41 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117457/
> ---
> 
> (Updated April 9, 2014, 10:41 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> KWin and libksysguard are not required. same with KDeclarative, Plasma, 
> KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
> linked in subdirectories, so explicitly search for them.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e67becb 
>   thumbnail/CMakeLists.txt 97fdbb0 
> 
> Diff: https://git.reviewboard.kde.org/r/117457/diff/
> 
> 
> Testing
> ---
> 
> Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Aleix Pol Gonzalez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/#review55314
---

Ship it!


Ship It!

- Aleix Pol Gonzalez


On April 9, 2014, 10:41 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117457/
> ---
> 
> (Updated April 9, 2014, 10:41 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> KWin and libksysguard are not required. same with KDeclarative, Plasma, 
> KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
> linked in subdirectories, so explicitly search for them.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e67becb 
>   thumbnail/CMakeLists.txt 97fdbb0 
> 
> Diff: https://git.reviewboard.kde.org/r/117457/diff/
> 
> 
> Testing
> ---
> 
> Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Hrvoje Senjan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/
---

(Updated April 9, 2014, 10:41 p.m.)


Review request for KDE Frameworks and Aleix Pol Gonzalez.


Changes
---

resolved mentioned issues


Repository: kio-extras


Description
---

KWin and libksysguard are not required. same with KDeclarative, Plasma, 
KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
linked in subdirectories, so explicitly search for them.


Diffs (updated)
-

  CMakeLists.txt e67becb 
  thumbnail/CMakeLists.txt 97fdbb0 

Diff: https://git.reviewboard.kde.org/r/117457/diff/


Testing
---

Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.


Thanks,

Hrvoje Senjan

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Aleix Pol Gonzalez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/#review55313
---



CMakeLists.txt


You shouldn't need Core and Gui, they're both pulled by Widgets.



CMakeLists.txt


I would prefer using find_package(KF5) for all of them



thumbnail/CMakeLists.txt


Good catch!
Now that you're here, remove the commented target_link_libraries, it's 
never going to be useful


- Aleix Pol Gonzalez


On April 9, 2014, 6:35 p.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117457/
> ---
> 
> (Updated April 9, 2014, 6:35 p.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> KWin and libksysguard are not required. same with KDeclarative, Plasma, 
> KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
> linked in subdirectories, so explicitly search for them.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e67becb 
>   thumbnail/CMakeLists.txt 97fdbb0 
> 
> Diff: https://git.reviewboard.kde.org/r/117457/diff/
> 
> 
> Testing
> ---
> 
> Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: libmm-qt/libnm-qt as KF5

2014-04-09 Thread Lamarque Souza

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 for embedded programs that use NetworkManager to
connect. Sharing MMQt between Plasma NM and KDE Telepathy is also a good
example. Using dbus-send for creating NetworkManager connections used to be
very troublesome because of the settings parsing code required to
send/retrieve the connection settings to/from NetworkManager. Creating a
small program using NMQt is simpler since we already implement that parsing
code. There is even an example in libnm-qt/examples/createconnection about
that.

Ok, so let's move on. NMQt/MMQt are going to be part of KF5, I will try to
compile the framework branch next weekend and see what is still needed to
be done to make that happen.

Thanks to all for answering my questions.

Lamarque V. Souza

KDE's Network Management maintainer

http://planetkde.org/pt-br

On Wed, Apr 9, 2014 at 2:20 AM, 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
> > 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.
>
> _kde_add_platform_definitions is available in ECM. So from your
> perspective it
> means ECM is the only extra dependency as stated several times.
>
> > 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.
>
> Honestly, if you really think NMQt/MMQt are to be useful outside of
> plasma-nm,
> then KDE Frameworks is likely a good place for them, if not you'd better
> merge
> them in plasma-nm.
>
> Personally I doubt they're useful outside of plasma-nm though. But that's
> your
> job as maintainer to pick a choice.
>
> Regards.
> --
> Kévin Ottens, http://ervin.ipsquad.net
>
> KDAB - proud supporter of KDE, http://www.kdab.com
>
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: libmm-qt/libnm-qt as KF5

2014-04-09 Thread Lamarque Souza

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: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 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.
> >
> > _kde_add_platform_definitions is available in ECM. So from your
> perspective
> > it means ECM is the only extra dependency as stated several times.
> >
> > > 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.".
>
> I meant that nobody would not know about them, but I didn't mean that they
> are
> not useful.
>
> > > Now I am wondering
> > > if I am the only one that still thinks NMQt/MMQt are useful for other
> > > software besides Plasma NM.
> >
> > Honestly, if you really think NMQt/MMQt are to be useful outside of
> > plasma-nm, then KDE Frameworks is likely a good place for them, if not
> > you'd better merge them in plasma-nm.
> >
> > Personally I doubt they're useful outside of plasma-nm though. But that's
> > your job as maintainer to pick a choice.
> >
>
> I'm convinced that they could be useful for others, i.e ModemManagerQt
> could
> be used by KTp for sending sms (this was even implemented with the old
> version
> of MMQT).
>
> Cheers,
> Jan
>
> --
> Jan Grulich
> Red Hat Czech, s.r.o
> jgrul...@redhat.com
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE(Libs)4Support rename

2014-04-09 Thread Alex Merry

On 09/04/14 20:07, Martin Graesslin wrote:
> On Wednesday 09 April 2014 19:33:20 Alex Merry wrote:
>> On 09/04/14 18:38, Aleix Pol wrote:
>>> What happens with the cmake side? are we going to have to rename all
>>> KF5::KDE4Support for KF5::KDELibs4Support?
>>
>> Yes, that's what the changes I've got queued up require.
> 
> wouldn't it be possible to support both variants? So that the existing code 
> doesn't need to be updated?

Possibly, but it's not trivial.  Unfortunately, you can't make aliases
of targets that are themselves alias or imported targets.  But I'll look
into it.

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE(Libs)4Support rename

2014-04-09 Thread Martin Graesslin

On Wednesday 09 April 2014 19:33:20 Alex Merry wrote:
> On 09/04/14 18:38, Aleix Pol wrote:
> > What happens with the cmake side? are we going to have to rename all
> > KF5::KDE4Support for KF5::KDELibs4Support?
> 
> Yes, that's what the changes I've got queued up require.

wouldn't it be possible to support both variants? So that the existing code 
doesn't need to be updated?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kdeinit5 binary and man page in different repos

2014-04-09 Thread Alex Merry

On 09/04/14 19:34, Alex Merry wrote:
> On 09/04/14 19:08, Michael Palimaka wrote:
>> Hi,
>>
>> I noticed that kdeinit5 is in kinit, and its man page appears to be in
>> kservice. I guess the man page should be moved, but I'm not sure of the
>> best procedure with regards to preserving history etc.
> 
> Huh, so it is.  *Adds it to his TODO list*

Alternatively, if you want to learn how to do it, check out
http://community.kde.org/User:Randomguy3

Push it to a personal clone of the kinit repo
(http://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_clones_of_project_repositories)
and post the address on here, and I'll have a look to make sure it's
sensible.

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 117457: kio-extras: minor dependencies cleanup

2014-04-09 Thread Hrvoje Senjan


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117457/
---

Review request for KDE Frameworks and Aleix Pol Gonzalez.


Repository: kio-extras


Description
---

KWin and libksysguard are not required. same with KDeclarative, Plasma, 
KWindowSystem, Qt5Quick, Qt5Script. Added frameworks in top CMakeLists where 
linked in subdirectories, so explicitly search for them.


Diffs
-

  CMakeLists.txt e67becb 
  thumbnail/CMakeLists.txt 97fdbb0 

Diff: https://git.reviewboard.kde.org/r/117457/diff/


Testing
---

Built successfully with CMake 3.0.0-rc3 & Frameworks HEAD.


Thanks,

Hrvoje Senjan

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kdeinit5 binary and man page in different repos

2014-04-09 Thread Alex Merry

On 09/04/14 19:08, Michael Palimaka wrote:
> Hi,
> 
> I noticed that kdeinit5 is in kinit, and its man page appears to be in
> kservice. I guess the man page should be moved, but I'm not sure of the
> best procedure with regards to preserving history etc.

Huh, so it is.  *Adds it to his TODO list*

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE(Libs)4Support rename

2014-04-09 Thread Alex Merry

On 09/04/14 18:38, Aleix Pol wrote:
> What happens with the cmake side? are we going to have to rename all
> KF5::KDE4Support for KF5::KDELibs4Support?

Yes, that's what the changes I've got queued up require.

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

kdeinit5 binary and man page in different repos

2014-04-09 Thread Michael Palimaka

Hi,

I noticed that kdeinit5 is in kinit, and its man page appears to be in
kservice. I guess the man page should be moved, but I'm not sure of the
best procedure with regards to preserving history etc.

Best regards,
Michael

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KDE(Libs)4Support rename

2014-04-09 Thread Aleix Pol

On Wed, Apr 9, 2014 at 7:33 PM, Alex Merry  wrote:

> I have a local commit renaming kde4support to kdelibs4support.  It's
> long and tedious and repetitive, so I don't see much point in putting it
> on RB, but the gist is:
>
> kde4support -> kdelibs4support
> KDE4SUPPORT -> KDELIBS4SUPPORT
> KDE4Support -> KDELibs4Support
> KDE4 Support -> KDELibs 4 Support (eg: top of README.md)
> Kde4support -> KdeLibs4Support (function names in autotests)
>
> This goes for file names as well as contents.  The result is that both
> find -iname \*kde4support\*
> and
> git grep -i kde4support
> come up empty.
>
> Are there any objections to me pushing this (along with relevant changes
> - mostly to CMake code and comments - in other repos, of course)?
>
> Alex
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

What happens with the cmake side? are we going to have to rename all
KF5::KDE4Support for KF5::KDELibs4Support?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDE(Libs)4Support rename

2014-04-09 Thread Alex Merry

I have a local commit renaming kde4support to kdelibs4support.  It's
long and tedious and repetitive, so I don't see much point in putting it
on RB, but the gist is:

kde4support -> kdelibs4support
KDE4SUPPORT -> KDELIBS4SUPPORT
KDE4Support -> KDELibs4Support
KDE4 Support -> KDELibs 4 Support (eg: top of README.md)
Kde4support -> KdeLibs4Support (function names in autotests)

This goes for file names as well as contents.  The result is that both
find -iname \*kde4support\*
and
git grep -i kde4support
come up empty.

Are there any objections to me pushing this (along with relevant changes
- mostly to CMake code and comments - in other repos, of course)?

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Auto-restarting of DBus Services

2014-04-09 Thread Martin Gräßlin

Hi all,

kglobalacceld has the following piece of code:

// Restart on a crash
KCrash::setFlags(KCrash::AutoRestart);

Now I'm wondering whether this is needed at all. After all it's a DBus service 
and should get auto-restarted (or at least started when next accessed), 
shouldn't it?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 117454: Implement KUser::faceIconPath for Windows XP

2014-04-09 Thread Nicolás Alvarez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117454/
---

Review request for KDE Frameworks.


Repository: kcoreaddons


Description
---

The undocuented API we're using has a different ordinal and parameters on 
Windows XP vs Vista/7.

I refactored the code to use a template and structs encapsulating the 
differences, as otherwise the code became too redundant.

Feedback welcome on identifier names, that's a known hard problem :)


Diffs
-

  src/lib/util/kuser_win.cpp aa48c04 

Diff: https://git.reviewboard.kde.org/r/117454/diff/


Testing
---

Ran faceicontest on Windows 7 and on XP.


Thanks,

Nicolás Alvarez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: kcoreaddons: is src/mimetypes/kde.xml still in use?

2014-04-09 Thread Burkhard Lück

Am Mittwoch, 9. April 2014, 06:59:08 schrieb Aurélien Gâteau:
> Hi,
> 
> I am trying to figure out which code is responsible for loading
> xml_mimetypes.po. This file is produced by scripty when running on
> kcoreaddons, but I can't find any code actually loading the catalog. Is
> my git grep fu too weak?

No, this is just a intermediate file, not loaded directly, of an only half 
finished solution to translate MIME type entries, see 
http://osdir.com/ml/kde-i18n-doc/2013-12/msg00055.html

-- 
Burkhard Lück

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Writing a Frameworks book at Randa

2014-04-09 Thread Mario Fux

Am Mittwoch, 09. April 2014, 15.05:06 schrieb Kevin Funk:

Morning Valorie, Kevin and Co

Thanks for bringing this topic up again.

> On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> > Hello folks, I know that August is months away, but if you want your
> > Frameworks book, now is the time to step forward.
> > 
> > Here are some things to think about:
> > 
> > Most of this book is already written somewhere. When the words have
> > already been written down, all we need do is gather and arrange them.
> > When you think of such an email, dot story, blog post or have eloquent
> > thoughts in your head, please make a note.
> > 
> > If you are on this list, you are an expert. You know what the
> > Frameworks will do for KDE, and you know what they *can* do for
> > others. Our book will present that case. A good book will help grow
> > the Frameworks team; I'm sure of it. And a good book will make your
> > work more widely used. Oh, and you'll be a published author!
> > 
> > While in Randa, none of us will be writing full-time. In fact, I hope
> > that *all* of the Frameworks people will stop by the writing room, or
> > log into Booki and review, add, re-arrange, correct, or make the text
> > more graceful.
> > 
> > To make this work a few people must volunteer to take on the writing
> > of the book as their most important task at Randa. It will be mine,
> > and our goal is to have a book by the end of the week. We've done it
> > before, and I know we can do it again. This is a valuable work.
> > 
> > We need to know the core members of this team, soon. Please step
> > forward, and also add yourself to the Spints page for planning and
> > funding.

+1 from my side here ;-).

About the book. I think the first one was quite a success and often used to 
direct new people, contributors to. And IIRC you (Valorie) and Co took care 
not to integrate information in the book that was in heavy flux and often 
changed.

So it mostly a beginners guide for KDE Platform and soon KF5 users, a bigger 
brochure that helps to get a broad overview.

For the frameworks people that already registered on 
sprints.kde.org/sprint/212 please put some time aside to get to Valorie and Co 
in Randa and have a look or two and a helping hand.

> > Valorie
> 
> Hey,
> 
> I'm wondering if we should rather try spending the time in making our KF5
> apidocs shine. You could spend plenty of time on writing introductory parts
> for the individual modules, writing tutorials and examples, and make sure
> they're easy to reach and grasp for newcomers on apidocs.kde.org. This is
> an integral part for the docs on qt-project.org, too. Just have a look at
> the first hit for "qt docs": [1]
> 
> There's a "Getting Started" section, with overviews [2] with examples and
> tutorials [3]. That's *exactly* what we need for KF5, too. That's the best
> place to point newcomers to whenever they want to get wet with KF5. But it
> also takes time and people to get to this state.
> 
> Personally, from a developer POV, I don't really see the need for a
> separate "book". There will always be a discrepancy between the book and
> the actual code (be it completeness, accuracy, its up-to-date-ness), and
> for developers it's always an extra burden to make sure to amend the
> contents of the book whenever they change something in source code. It's
> much more straight-forward to make sure that at least the apidocs are
> up-to-date. The apidocs being inline in the source code being is an
> integral part in making sure they're amended alongside of source code
> changes.
> 
> Opinions? What do the frameworks devs think about it?

There is one above. And about the apidocs and examples and online resources I 
agree. They are important, very important and probably sometimes even more 
important than a book. But I think both are valuable and both have target 
groups.

The questions is probably more. Would a dedicated KF5 apidocs meeting or 
sprint be of value?

Another idea from my side is to include the kde-doc people in this effort and 
discussion?

> Greets
> 
> [1] http://qt-project.org/doc/qt-5/index.html
> [2] http://qt-project.org/doc/qt-5/overviews-main.html
> [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html

Thanks and best regards
Mario
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117132: Use QLocale for figuring out what languages we're translated into

2014-04-09 Thread Aleix Pol Gonzalez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117132/
---

(Updated April 9, 2014, 4 p.m.)


Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich.


Changes
---

Use KLocalizedString::availableApplicationTranslations() to figure out if the 
application is in more than 1 language.

Another option would be that we can always show this menu entry. It's not that 
much of a big deal to show the menu entry when the application is not 
translated either.


Repository: kxmlgui


Description
---

Instead of asking the file-system what languages the application is translated 
into, ask QLocale what languages we have available instead.


Diffs (updated)
-

  src/khelpmenu.cpp 4f6ce7b 

Diff: https://git.reviewboard.kde.org/r/117132/diff/


Testing
---


Thanks,

Aleix Pol Gonzalez

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Writing a Frameworks book at Randa

2014-04-09 Thread Kevin Funk

On Wednesday 09 April 2014 15:42:47 Aleix Pol wrote:
> On Wed, Apr 9, 2014 at 3:05 PM, Kevin Funk  wrote:
> > On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> > > Hello folks, I know that August is months away, but if you want your
> > > Frameworks book, now is the time to step forward.
> > > 
> > > Here are some things to think about:
> > > 
> > > Most of this book is already written somewhere. When the words have
> > > already been written down, all we need do is gather and arrange them.
> > > When you think of such an email, dot story, blog post or have eloquent
> > > thoughts in your head, please make a note.
> > > 
> > > If you are on this list, you are an expert. You know what the
> > > Frameworks will do for KDE, and you know what they *can* do for
> > > others. Our book will present that case. A good book will help grow
> > > the Frameworks team; I'm sure of it. And a good book will make your
> > > work more widely used. Oh, and you'll be a published author!
> > > 
> > > While in Randa, none of us will be writing full-time. In fact, I hope
> > > that *all* of the Frameworks people will stop by the writing room, or
> > > log into Booki and review, add, re-arrange, correct, or make the text
> > > more graceful.
> > > 
> > > To make this work a few people must volunteer to take on the writing
> > > of the book as their most important task at Randa. It will be mine,
> > > and our goal is to have a book by the end of the week. We've done it
> > > before, and I know we can do it again. This is a valuable work.
> > > 
> > > We need to know the core members of this team, soon. Please step
> > > forward, and also add yourself to the Spints page for planning and
> > > funding.
> > > 
> > > Valorie
> > 
> > Hey,
> > 
> > I'm wondering if we should rather try spending the time in making our KF5
> > apidocs shine. You could spend plenty of time on writing introductory
> > parts
> > for the individual modules, writing tutorials and examples, and make sure
> > they're easy to reach and grasp for newcomers on apidocs.kde.org. This is
> > an
> > integral part for the docs on qt-project.org, too. Just have a look at the
> > first hit for "qt docs": [1]
> > 
> > There's a "Getting Started" section, with overviews [2] with examples and
> > tutorials [3]. That's *exactly* what we need for KF5, too. That's the best
> > place to point newcomers to whenever they want to get wet with KF5. But it
> > also takes time and people to get to this state.
> > 
> > Personally, from a developer POV, I don't really see the need for a
> > separate
> > "book". There will always be a discrepancy between the book and the actual
> > code (be it completeness, accuracy, its up-to-date-ness), and for
> > developers
> > it's always an extra burden to make sure to amend the contents of the book
> > whenever they change something in source code. It's much more
> > straight-forward
> > to make sure that at least the apidocs are up-to-date. The apidocs being
> > inline in the source code being is an integral part in making sure they're
> > amended alongside of source code changes.
> > 
> > Opinions? What do the frameworks devs think about it?
> > 
> > Greets
> > 
> > [1] http://qt-project.org/doc/qt-5/index.html
> > [2] http://qt-project.org/doc/qt-5/overviews-main.html
> > [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html
> > 
> > --
> > Kevin Funk
> > ___
> > Kde-frameworks-devel mailing list
> > Kde-frameworks-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> Hi,
> I'm unsure what to say. On one hand, people always seem inclined to have
> some literature available, especially in the shape of a book. It helps you
> go through the technologies when you don't know much what you're doing but
> you still want to learn. It offers a linear overview of interesting things
> on a related subject, meaning that if things are not interesting, you can
> opt to not include them in the book.
> 
> On the other hand, documentation is much more future-proof in terms of
> having it actively-ish maintained and it will be more useful for the
> developers who decide to stay using KF5, since they will know what to look
> for.
> A proof of this is that even though we have wonderful Qt documentation, we
> see new books appearing all the time, and I guess this means they pay off,
> at least.
> 
> Maybe we should consider the book more as a replacement to the TechBase
> [1], if it's even possible to offer it in a proper web shape as well, at
> least.
> 
> Personally, given that there will be compromises either way, I would say
> that who codes (or writes) decides. I'll be happy to give a hand in either
> direction.

Fair point. Regardless of what we do, it will be an improvement.

>From my point of view, proper API documentation/tutorials should be given 
primary focus, though, given the lack of manpower in this area. Don't get me 
wrong, I don't want to demotivate anyo

kcoreaddons: is src/mimetypes/kde.xml still in use?

2014-04-09 Thread Aurélien Gâteau

Hi,

I am trying to figure out which code is responsible for loading
xml_mimetypes.po. This file is produced by scripty when running on
kcoreaddons, but I can't find any code actually loading the catalog. Is
my git grep fu too weak?

Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Writing a Frameworks book at Randa

2014-04-09 Thread Aleix Pol

On Wed, Apr 9, 2014 at 3:05 PM, Kevin Funk  wrote:

> On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> > Hello folks, I know that August is months away, but if you want your
> > Frameworks book, now is the time to step forward.
> >
> > Here are some things to think about:
> >
> > Most of this book is already written somewhere. When the words have
> > already been written down, all we need do is gather and arrange them.
> > When you think of such an email, dot story, blog post or have eloquent
> > thoughts in your head, please make a note.
> >
> > If you are on this list, you are an expert. You know what the
> > Frameworks will do for KDE, and you know what they *can* do for
> > others. Our book will present that case. A good book will help grow
> > the Frameworks team; I'm sure of it. And a good book will make your
> > work more widely used. Oh, and you'll be a published author!
> >
> > While in Randa, none of us will be writing full-time. In fact, I hope
> > that *all* of the Frameworks people will stop by the writing room, or
> > log into Booki and review, add, re-arrange, correct, or make the text
> > more graceful.
> >
> > To make this work a few people must volunteer to take on the writing
> > of the book as their most important task at Randa. It will be mine,
> > and our goal is to have a book by the end of the week. We've done it
> > before, and I know we can do it again. This is a valuable work.
> >
> > We need to know the core members of this team, soon. Please step
> > forward, and also add yourself to the Spints page for planning and
> > funding.
> >
> > Valorie
>
> Hey,
>
> I'm wondering if we should rather try spending the time in making our KF5
> apidocs shine. You could spend plenty of time on writing introductory parts
> for the individual modules, writing tutorials and examples, and make sure
> they're easy to reach and grasp for newcomers on apidocs.kde.org. This is
> an
> integral part for the docs on qt-project.org, too. Just have a look at the
> first hit for "qt docs": [1]
>
> There's a "Getting Started" section, with overviews [2] with examples and
> tutorials [3]. That's *exactly* what we need for KF5, too. That's the best
> place to point newcomers to whenever they want to get wet with KF5. But it
> also takes time and people to get to this state.
>
> Personally, from a developer POV, I don't really see the need for a
> separate
> "book". There will always be a discrepancy between the book and the actual
> code (be it completeness, accuracy, its up-to-date-ness), and for
> developers
> it's always an extra burden to make sure to amend the contents of the book
> whenever they change something in source code. It's much more
> straight-forward
> to make sure that at least the apidocs are up-to-date. The apidocs being
> inline in the source code being is an integral part in making sure they're
> amended alongside of source code changes.
>
> Opinions? What do the frameworks devs think about it?
>
> Greets
>
> [1] http://qt-project.org/doc/qt-5/index.html
> [2] http://qt-project.org/doc/qt-5/overviews-main.html
> [3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html
>
> --
> Kevin Funk
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

Hi,
I'm unsure what to say. On one hand, people always seem inclined to have
some literature available, especially in the shape of a book. It helps you
go through the technologies when you don't know much what you're doing but
you still want to learn. It offers a linear overview of interesting things
on a related subject, meaning that if things are not interesting, you can
opt to not include them in the book.

On the other hand, documentation is much more future-proof in terms of
having it actively-ish maintained and it will be more useful for the
developers who decide to stay using KF5, since they will know what to look
for.
A proof of this is that even though we have wonderful Qt documentation, we
see new books appearing all the time, and I guess this means they pay off,
at least.

Maybe we should consider the book more as a replacement to the TechBase
[1], if it's even possible to offer it in a proper web shape as well, at
least.

Personally, given that there will be compromises either way, I would say
that who codes (or writes) decides. I'll be happy to give a hand in either
direction.

Aleix

[1] http://techbase.kde.org/Welcome_to_KDE_TechBase
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Writing a Frameworks book at Randa

2014-04-09 Thread Kevin Funk

On Wednesday 09 April 2014 02:25:18 Valorie Zimmerman wrote:
> Hello folks, I know that August is months away, but if you want your
> Frameworks book, now is the time to step forward.
> 
> Here are some things to think about:
> 
> Most of this book is already written somewhere. When the words have
> already been written down, all we need do is gather and arrange them.
> When you think of such an email, dot story, blog post or have eloquent
> thoughts in your head, please make a note.
> 
> If you are on this list, you are an expert. You know what the
> Frameworks will do for KDE, and you know what they *can* do for
> others. Our book will present that case. A good book will help grow
> the Frameworks team; I'm sure of it. And a good book will make your
> work more widely used. Oh, and you'll be a published author!
> 
> While in Randa, none of us will be writing full-time. In fact, I hope
> that *all* of the Frameworks people will stop by the writing room, or
> log into Booki and review, add, re-arrange, correct, or make the text
> more graceful.
> 
> To make this work a few people must volunteer to take on the writing
> of the book as their most important task at Randa. It will be mine,
> and our goal is to have a book by the end of the week. We've done it
> before, and I know we can do it again. This is a valuable work.
> 
> We need to know the core members of this team, soon. Please step
> forward, and also add yourself to the Spints page for planning and
> funding.
> 
> Valorie

Hey,

I'm wondering if we should rather try spending the time in making our KF5 
apidocs shine. You could spend plenty of time on writing introductory parts 
for the individual modules, writing tutorials and examples, and make sure 
they're easy to reach and grasp for newcomers on apidocs.kde.org. This is an 
integral part for the docs on qt-project.org, too. Just have a look at the 
first hit for "qt docs": [1]

There's a "Getting Started" section, with overviews [2] with examples and 
tutorials [3]. That's *exactly* what we need for KF5, too. That's the best 
place to point newcomers to whenever they want to get wet with KF5. But it 
also takes time and people to get to this state.

Personally, from a developer POV, I don't really see the need for a separate 
"book". There will always be a discrepancy between the book and the actual 
code (be it completeness, accuracy, its up-to-date-ness), and for developers 
it's always an extra burden to make sure to amend the contents of the book 
whenever they change something in source code. It's much more straight-forward 
to make sure that at least the apidocs are up-to-date. The apidocs being 
inline in the source code being is an integral part in making sure they're 
amended alongside of source code changes.

Opinions? What do the frameworks devs think about it?

Greets

[1] http://qt-project.org/doc/qt-5/index.html
[2] http://qt-project.org/doc/qt-5/overviews-main.html
[3] http://qt-project.org/doc/qt-5/qtexamplesandtutorials.html

-- 
Kevin Funk
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: libmm-qt/libnm-qt as KF5

2014-04-09 Thread Alex Merry

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 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.

While _kde_add_platform_definitions is defined in KDECompilerSettings,
I'm puzzled as to why that matters.  That macro is for internal use in
that file, and not API in any way (as indicated by the starting
underscore).  Nothing outside KDECompilerSettings.cmake should use it.

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Kioslave repos

2014-04-09 Thread Kevin Ottens

On Wednesday 09 April 2014 11:57:37 Marco Martin wrote:
> On Wednesday 09 April 2014, Àlex Fiestas wrote:
> > I'm against having anything in plasma-* without maintainer and even less
> > if
> > it is something that is known to have bugs (many) in KDE4.
> > 
> > So we wither split it and hope somebody will give love to it or remove it.
> 
> Not talking about that repo in particular, but...
> on the other hand, putting stuff in own micro repositories is as swiping
> under the carpet as leaving them in one of the main ones, if anything it
> ensures even more that it will go abandoned and unnoticed.
> If it's stuff that really nobody is even using and is safe to drop, that's
> ok (would be even ok to just delete it tough)

Exactly.

> but if is something that the user needs anyways and potentially causes
> regressions in the experience, it has to stay, and in the place that goes
> the least unnoticed.
> Developers being confortable with it, or even (gasp!) being actively
> maintained goes completely secondary behind the causing as less regressions
> as possible for the users.

I suddenly feel understood. :-)

That's my worry with some of the recent splits in workspace land, they seem to 
be done without the user in mind or regressions in sight.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Re: Where to put kglobalacceld?

2014-04-09 Thread Aleix Pol

On Wed, Apr 9, 2014 at 9:34 AM, Martin Gräßlin  wrote:

> On Friday 04 April 2014 16:06:32 Aleix Pol wrote:
> > On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin 
> wrote:
> > > Hi,
> > >
> > > similar as to what we already have with DrKonqi moving kglobalacceld
> from
> > > kde-
> > > runtime into the globalaccel framework would significantly raise the
> tier
> > > and
> > > dependencies. At the moment KGlobalAccel is a tier1 framework.
> > >
> > > The runtime component though depends on:
> > > * KF5::GlobalAccel
> > > * KF5::KCMUtils
> > > * KF5::I18n
> > > * KF5::XmlGui
> > > * KF5::WindowSystem
> > > * KF5::DBusAddons
> > > * KF5::Notifications
> > > * KF5::KIOWidgets
> > > * KF5::Crash
> > >
> > > Even if we consider that some are probably not needed it would at least
> > > become
> > > tier2.
> > >
> > > Given that kglobalaccel is only intended for the kde-workspaces anyway
> my
> > > suggestion is to move it into plasma-workspace repository instead of
> > > merging
> > > with the framework. Please note that with Wayland it will be extremely
> > > difficult to provide a generic globalaccel anyway (no global keylogger
> > > like in
> > > X11 possible) and my plan is to implement the interface in KWin.
> > >
> > > Opinions?
> > >
> > > Cheers
> > > Martin
> > > ___
> > > Kde-frameworks-devel mailing list
> > > Kde-frameworks-devel@kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> >
> > In that case, I'd suggest moving it to plasma-workspace, but then we'll
> > have to make sure to make it explicit that KGlobalAccel is not a portable
> > framework, rendering components depending on it not portable (with
> emphasis
> > on KXmlGui) to platforms not supported by Plasma (or KWin).
> >
> > Not having a functional KGlobalAccel on Gnome sounds quite a regression
> to
> > me though...
>
> I just got the feedback from LXQt that they might consider using
> KGlobalAccel.
> That would clearly speak against putting the runtime component into plasma-
> workspace. But I also think that our current dependencies in the runtime
> component are too heavy.
>
> Cheers
> Martin
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
It's in Plasma Workspace for the moment.

Maybe they can help us work on the dependencies...?

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Kioslave repos

2014-04-09 Thread Marco Martin

On Wednesday 09 April 2014, Àlex Fiestas wrote:
> I'm against having anything in plasma-* without maintainer and even less if
> it is something that is known to have bugs (many) in KDE4.
> 
> So we wither split it and hope somebody will give love to it or remove it.

Not talking about that repo in particular, but...
on the other hand, putting stuff in own micro repositories is as swiping under 
the carpet as leaving them in one of the main ones, if anything it ensures 
even more that it will go abandoned and unnoticed.
If it's stuff that really nobody is even using and is safe to drop, that's ok 
(would be even ok to just delete it tough)

but if is something that the user needs anyways and potentially causes 
regressions in the experience, it has to stay, and in the place that goes the 
least unnoticed.
Developers being confortable with it, or even (gasp!) being actively 
maintained goes completely secondary behind the causing as less regressions as 
possible for the users.

-- 
Marco Martin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117440: Make sure that common licenses are accessed throught help:/ protocol

2014-04-09 Thread Burkhard Lück


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117440/#review55266
---

Ship it!


Works for me, thanks

- Burkhard Lück


On April 8, 2014, 10:02 p.m., Luigi Toscano wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117440/
> ---
> 
> (Updated April 8, 2014, 10:02 p.m.)
> 
> 
> Review request for Documentation and KDE Frameworks.
> 
> 
> Repository: kdoctools
> 
> 
> Description
> ---
> 
> This change removes one of the reason for keeping the "common"/ symlinks into 
> documentation directories; translated common licenses are accessed now using 
> the help:/ kioslave, which finds them in /common.
> Please note that help:/ prefix can be overridden by changing the 
> kde.common parameter (for example, generation of documentation on the 
> website).
> 
> 
> Diffs
> -
> 
>   src/customization/af/entities/underArtisticLicense.docbook f19b961 
>   src/customization/af/entities/underBSDLicense.docbook 1222e95 
>   src/customization/af/entities/underFDL.docbook 6afff8b 
>   src/customization/af/entities/underGPL.docbook 6d8ef8b 
>   src/customization/af/entities/underX11License.docbook a216e53 
>   src/customization/bg/entities/underArtisticLicense.docbook fa02270 
>   src/customization/bg/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/bg/entities/underFDL.docbook 633ce72 
>   src/customization/bg/entities/underGPL.docbook a2074f3 
>   src/customization/bg/entities/underX11License.docbook 7eb81f0 
>   src/customization/ca/entities/underArtisticLicense.docbook 300167f 
>   src/customization/ca/entities/underBSDLicense.docbook 4bde1df 
>   src/customization/ca/entities/underFDL.docbook 7ab5762 
>   src/customization/ca/entities/underGPL.docbook 1bfeec7 
>   src/customization/ca/entities/underLGPL.docbook 1bf0a38 
>   src/customization/ca/entities/underX11License.docbook 4e1093e 
>   src/customization/cs/entities/underArtisticLicense.docbook fa02270 
>   src/customization/cs/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/cs/entities/underFDL.docbook 65d5936 
>   src/customization/cs/entities/underGPL.docbook 27d9047 
>   src/customization/cs/entities/underX11License.docbook 7eb81f0 
>   src/customization/da/entities/underArtisticLicense.docbook 612fb2e 
>   src/customization/da/entities/underBSDLicense.docbook 3d2630b 
>   src/customization/da/entities/underFDL.docbook 78acfee 
>   src/customization/da/entities/underGPL.docbook 97e0af6 
>   src/customization/da/entities/underLGPL.docbook 591c332 
>   src/customization/da/entities/underX11License.docbook 69bad4c 
>   src/customization/de/entities/underArtisticLicense.docbook 78d63bc 
>   src/customization/de/entities/underBSDLicense.docbook ffbdf67 
>   src/customization/de/entities/underFDL.docbook dbb7c69 
>   src/customization/de/entities/underGPL.docbook 3bc2ca2 
>   src/customization/de/entities/underLGPL.docbook 91c4ee8 
>   src/customization/de/entities/underX11License.docbook 9027b44 
>   src/customization/el/entities/underArtisticLicense.docbook fa02270 
>   src/customization/el/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/el/entities/underFDL.docbook 65d5936 
>   src/customization/el/entities/underGPL.docbook 27d9047 
>   src/customization/el/entities/underX11License.docbook 7eb81f0 
>   src/customization/en-GB/entities/underArtisticLicense.docbook fa02270 
>   src/customization/en-GB/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/en-GB/entities/underFDL.docbook 633ce72 
>   src/customization/en-GB/entities/underGPL.docbook a2074f3 
>   src/customization/en-GB/entities/underX11License.docbook 7eb81f0 
>   src/customization/en/entities/underArtisticLicense.docbook fa02270 
>   src/customization/en/entities/underBSDLicense.docbook 0dc93f1 
>   src/customization/en/entities/underFDL.docbook 633ce72 
>   src/customization/en/entities/underGPL.docbook a2074f3 
>   src/customization/en/entities/underLGPL.docbook 35f89bd 
>   src/customization/en/entities/underX11License.docbook 7eb81f0 
>   src/customization/eo/entities/underArtisticLicense.docbook b214453 
>   src/customization/eo/entities/underBSDLicense.docbook 2eea358 
>   src/customization/eo/entities/underFDL.docbook edcab1b 
>   src/customization/eo/entities/underGPL.docbook 69ccd1d 
>   src/customization/eo/entities/underX11License.docbook f1295ff 
>   src/customization/es/entities/underArtisticLicense.docbook fdb0555 
>   src/customization/es/entities/underBSDLicense.docbook 78c5742 
>   src/customization/es/entities/underFDL.docbook 18b96e2 
>   src/customization/es/entities/underGPL.docbook 2bee3b0 
>   src/customization/es/entities/underLGPL.docbook 6340667 
>   src/customization/es/entities

Re: Kioslave repos

2014-04-09 Thread Àlex Fiestas

On Tuesday 08 April 2014 17:37:00 Kevin Ottens wrote:
> Good move.
> 
> Pushed me toward looking a bit closer to this page, as obviously we didn't
> look close enough before (sorry about that), I might have a concern still:
> solid-deviceautomounter getting its own repository. It looks again like a
> completely leave behind or put in plasma-workspace (maybe not the kcm which
> is perhaps more plasma-desktop).
> With the uncertainty around it, I'd say its put in plasma-* until we got a
> replacement solution.
I'm against having anything in plasma-* without maintainer and even less if it 
is something that is known to have bugs (many) in KDE4.

So we wither split it and hope somebody will give love to it or remove it.


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Writing a Frameworks book at Randa

2014-04-09 Thread Valorie Zimmerman

Hello folks, I know that August is months away, but if you want your
Frameworks book, now is the time to step forward.

Here are some things to think about:

Most of this book is already written somewhere. When the words have
already been written down, all we need do is gather and arrange them.
When you think of such an email, dot story, blog post or have eloquent
thoughts in your head, please make a note.

If you are on this list, you are an expert. You know what the
Frameworks will do for KDE, and you know what they *can* do for
others. Our book will present that case. A good book will help grow
the Frameworks team; I'm sure of it. And a good book will make your
work more widely used. Oh, and you'll be a published author!

While in Randa, none of us will be writing full-time. In fact, I hope
that *all* of the Frameworks people will stop by the writing room, or
log into Booki and review, add, re-arrange, correct, or make the text
more graceful.

To make this work a few people must volunteer to take on the writing
of the book as their most important task at Randa. It will be mine,
and our goal is to have a book by the end of the week. We've done it
before, and I know we can do it again. This is a valuable work.

We need to know the core members of this team, soon. Please step
forward, and also add yourself to the Spints page for planning and
funding.

Valorie
-- 
http://about.me/valoriez
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH

2014-04-09 Thread Dan Vrátil


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/
---

(Updated April 9, 2014, 10:47 a.m.)


Review request for KDE Frameworks.


Changes
---

Use KCRASH_DRKONQI_EXECUTABLE env variable to override the lookup path, as 
suggested by Alex.


Repository: kcrash


Description
---

Since KCrash is a framework that relies on DrKonqi binary being provided by a 
3rd party software (kde-runtime), it should not make assumptions regarding 
location of the utility.

This patch makes KCrash to look for drkonqi binary first in $PATH, then falling 
back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible 
for distributions to ship KDE Frameworks in normal prefix (/usr), but have 
current snapshots of kde-runtime in /opt/kde5 for instance.


Diffs (updated)
-

  src/kcrash.cpp 87163cc 

Diff: https://git.reviewboard.kde.org/r/117016/diff/


Testing
---

- Installed KCrash into /usr prefix
- Installed drkonqi from kde-runtime master to /opt/kde5 prefix
- started broken application
- no "could not find drkonqi" warning anymore
- crashed application, got drkonqi window


Thanks,

Dan Vrátil

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Re: Where to put kglobalacceld?

2014-04-09 Thread Martin Gräßlin

On Friday 04 April 2014 16:06:32 Aleix Pol wrote:
> On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin  wrote:
> > Hi,
> > 
> > similar as to what we already have with DrKonqi moving kglobalacceld from
> > kde-
> > runtime into the globalaccel framework would significantly raise the tier
> > and
> > dependencies. At the moment KGlobalAccel is a tier1 framework.
> > 
> > The runtime component though depends on:
> > * KF5::GlobalAccel
> > * KF5::KCMUtils
> > * KF5::I18n
> > * KF5::XmlGui
> > * KF5::WindowSystem
> > * KF5::DBusAddons
> > * KF5::Notifications
> > * KF5::KIOWidgets
> > * KF5::Crash
> > 
> > Even if we consider that some are probably not needed it would at least
> > become
> > tier2.
> > 
> > Given that kglobalaccel is only intended for the kde-workspaces anyway my
> > suggestion is to move it into plasma-workspace repository instead of
> > merging
> > with the framework. Please note that with Wayland it will be extremely
> > difficult to provide a generic globalaccel anyway (no global keylogger
> > like in
> > X11 possible) and my plan is to implement the interface in KWin.
> > 
> > Opinions?
> > 
> > Cheers
> > Martin
> > ___
> > Kde-frameworks-devel mailing list
> > Kde-frameworks-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
> 
> In that case, I'd suggest moving it to plasma-workspace, but then we'll
> have to make sure to make it explicit that KGlobalAccel is not a portable
> framework, rendering components depending on it not portable (with emphasis
> on KXmlGui) to platforms not supported by Plasma (or KWin).
> 
> Not having a functional KGlobalAccel on Gnome sounds quite a regression to
> me though...

I just got the feedback from LXQt that they might consider using KGlobalAccel. 
That would clearly speak against putting the runtime component into plasma-
workspace. But I also think that our current dependencies in the runtime 
component are too heavy.

Cheers
Martin


signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 117132: Use QLocale for figuring out what languages we're translated into

2014-04-09 Thread Chusslove Illich



> On March 28, 2014, 4:43 p.m., David Faure wrote:
> > Looks wrong, QLocale looks at .ts/.qm files while we mostly use .po/.gmo 
> > files - different translation system.
> > 
> > Also doubly wrong because uiLanguages() returns the user preferences (e.g. 
> > for me "en, fr"), which has nothing to do with "how many languages are 
> > actually installed" (e.g. there could be about 54).
> 
> Aleix Pol Gonzalez wrote:
> Then should we get a method to ask KLocalizedString what languages we 
> have available for the application.
> 
> In any case entry.desktop files are installed at bulk by kde-runtime, so 
> it's actually already broken in KDE4. Actually, I get to ask to switch 
> language and then I get to only choose the one.
> 
> John Layt wrote:
> Yes, QLocale::uiLanguages() returns the list of user preferences, i.e. 
> the LANGUAGE or LC_ALL or LC_MESSAGES or LANG envar on Linux (in order of 
> preference).  The list of available KDE translations is different.  
> KLocalizedString has a new method for 5.0 availableApplicationTranslations(), 
> but the docs state:
> 
>  * Get the languages for which there exists the translation catalog 
> file
>  * for the set application translation domain.
>  *
>  * The application domain is set by \c setApplicationDomain.
>  * If the application domain was not set, empty set is returned.
>  * If the application domain was set, the language set will always
>  * contain at least the source code language (en_US).
> 
> I suspect as we want the languages the user can switch the application 
> into then it should be the right method provided the application domain is 
> set by the application.

I missed that this patch is about translations available for a given 
application only. I switched to "globaly available languages" story, since it 
was again about entry.desktop files. And relying on them in this context was 
not very purposeful (i.e. Aleix's comment above).

Switching to KLocalizedString::availableApplicationTranslations here makes 
sense to me as well.


- Chusslove


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117132/#review54463
---


On March 28, 2014, 12:21 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117132/
> ---
> 
> (Updated March 28, 2014, 12:21 p.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid and Chusslove Illich.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> Instead of asking the file-system what languages the application is 
> translated into, ask QLocale what languages we have available instead.
> 
> 
> Diffs
> -
> 
>   src/khelpmenu.cpp 4f6ce7b 
> 
> Diff: https://git.reviewboard.kde.org/r/117132/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

39 matches

Mail list logo