Re: Review Request 119798: Generating PkgConig files from ECM

2014-08-15 Thread Alex Merry 

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


I'm in favour of this - I was planning to do it myself before 1.0, but decided 
it wasn't important enough to rush.

Needs a unit test, please!


modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45132

Spelling (Pkf-Pkg)



modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45131

More for autotools, surely? We have .pri files for qmake.



modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45133

Please document the arguments.



modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45136

Why not have both be KF5Archive as the standard? And have LIB_NAME default 
to BASE_NAME (or vice versa)?

After all, KF5Archive is what you would search for in CMake.



modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45135

Not you?



modules/ECMGeneratePkgConfigFile.cmake
https://git.reviewboard.kde.org/r/119798/#comment45134

This belongs in KDEInstallDirs.cmake, not here (as 
CMAKE_INSTALL_PKGCONFIGDIR, ideally). Projects that don't use KDEInstallDirs 
can create their own variable.

Also, pkconfig - pkgconfig.


- Alex Merry


On Aug. 14, 2014, 11:10 p.m., Aleix Pol Gonzalez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119798/
 ---
 
 (Updated Aug. 14, 2014, 11:10 p.m.)
 
 
 Review request for Build System, KDE Frameworks and Harald Sitter.
 
 
 Repository: extra-cmake-modules
 
 
 Description
 ---
 
 So we decided we wanted those .pc files, so I created a small script that 
 generates one, I haven't used pc in the past, so feedback is welcome.
 
 
 Diffs
 -
 
   modules/ECMGeneratePkgConfigFile.cmake PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/119798/diff/
 
 
 Testing
 ---
 
 I added it in KCoreAddons, this is the patch:
 diff --git src/lib/CMakeLists.txt src/lib/CMakeLists.txt
 index 26eb5a1..3a07d1c 100644
 --- src/lib/CMakeLists.txt
 +++ src/lib/CMakeLists.txt
 @@ -188,4 +188,6 @@ install(FILES
  
  include(ECMGeneratePriFile)
  ecm_generate_pri_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons DEPS 
 core FILENAME_VAR PRI_FILENAME INCLUDE_INSTALL_DIR 
 ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons)
 +ecm_generate_pkgconfig_file(BASE_NAME KCoreAddons LIB_NAME KF5CoreAddons 
 DEPS Qt5Core FILENAME_VAR PC_FILENAME INCLUDE_INSTALL_DIR 
 ${KF5_INCLUDE_INSTALL_DIR}/KCoreAddons)
 +install(FILES ${PC_FILENAME} DESTINATION ${ECM_PKGCONFIG_INSTALL_DIR})
  install(FILES ${PRI_FILENAME} DESTINATION ${ECM_MKSPECS_INSTALL_DIR})
 
 This is the result, on my system:
 
 Name: KF5CoreAddons
 Version: 5.1.0
 Libs: -L/home/kde-devel/kde5/lib64 -l/home/kde-devel/kde5/lib64
 Cflags: -I/home/kde-devel/kde5/include/KF5/KCoreAddons 
 Requires: Qt5Core
 
 
 Thanks,
 
 Aleix Pol Gonzalez
 


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

Re: How to promote less mature Frameworks?

2014-08-15 Thread Mark Gaiser 
On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas afies...@kde.org wrote:
 Hi there

 At the Randa sprint we have discussed a little bit what to do with those
 frameworks that are still not mature (for example they can't commit on ABI/API
 stability) but they are ready for feedback from third party developers.

 Even though there was not consensus in the discussion this is an idea that
 came out during the discussion:

 -We introduce a Maturity level that we can use to manage expectations about
 the Framework (for example whether API/ABI will be kept)
 -We release Frameworks that are not ready together with the rest, but we have
 to make damn sure we manage expectations.

 With this we can get early feedback for new frameworks, and since we have a
 rapid release cycle we can improve them fast.

 What do you think?

It depends on how you define maturity.

For instance, if a maturity is simply a value set in each project'
metainfo.yaml and set by those that maintain it then the maturity
level quite frankly doesn't tell you anything.

But if you decide maturity dynamically based on git activity, api/abi
stability, number of people contributing and where the project itself
is used in other projects (just some conditions that i can think of
now, there is probably more). With this a project maturity actually
has a meaning. When going for this approach it would also be nice to
show a list of projects using Framework X. Also, i do not consider a
project being healthy when it has only one developer [1] even if the
project is used by dozens of other projects and has much activity. For
us - kde devs - we probably don't care much if a framework is being
developed/maintained by one person, but for external potential
framework users that will be a concern. Specially companies.

[1] http://en.wikipedia.org/wiki/Bus_factor
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: How to promote less mature Frameworks?

2014-08-15 Thread Alex Merry 
On Friday 15 August 2014 10:21:57 Mark Gaiser wrote:
 On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas afies...@kde.org wrote:
  Hi there
  
  At the Randa sprint we have discussed a little bit what to do with those
  frameworks that are still not mature (for example they can't commit on
  ABI/API stability) but they are ready for feedback from third party
  developers.
  
  Even though there was not consensus in the discussion this is an idea that
  came out during the discussion:
  
  -We introduce a Maturity level that we can use to manage expectations
  about
  the Framework (for example whether API/ABI will be kept)
  -We release Frameworks that are not ready together with the rest, but we
  have to make damn sure we manage expectations.
  
  With this we can get early feedback for new frameworks, and since we have
  a
  rapid release cycle we can improve them fast.
  
  What do you think?
 
 It depends on how you define maturity.
 
 For instance, if a maturity is simply a value set in each project'
 metainfo.yaml and set by those that maintain it then the maturity
 level quite frankly doesn't tell you anything.
 
 But if you decide maturity dynamically based on git activity, api/abi
 stability, number of people contributing and where the project itself
 is used in other projects (just some conditions that i can think of
 now, there is probably more). With this a project maturity actually
 has a meaning. When going for this approach it would also be nice to
 show a list of projects using Framework X. Also, i do not consider a
 project being healthy when it has only one developer [1] even if the
 project is used by dozens of other projects and has much activity. For
 us - kde devs - we probably don't care much if a framework is being
 developed/maintained by one person, but for external potential
 framework users that will be a concern. Specially companies.

I think you're talking less about maturity and more about vitality, or 
something. Anyway, naming aside, I think Àlex was talking specifically about 
API/ABI guarantees - we offer pretty strong guarantees, and fresh projects may 
not want to commit to that until they've had some real-world usage and 
feedback. This would allow the equivalent to kdelibs' old experimental 
tagging, which was used for a couple of libraries while they settled on an 
API.

I think it could be useful, but would definitely require very careful 
communication.

Alex


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

Re: How to promote less mature Frameworks?

2014-08-15 Thread Kevin Ottens 
On Friday 15 August 2014 09:34:04 Alex Merry wrote:
 On Friday 15 August 2014 10:21:57 Mark Gaiser wrote:
  On Fri, Aug 15, 2014 at 12:12 AM, Àlex Fiestas afies...@kde.org wrote:
   Hi there
   
   At the Randa sprint we have discussed a little bit what to do with those
   frameworks that are still not mature (for example they can't commit on
   ABI/API stability) but they are ready for feedback from third party
   developers.
   
   Even though there was not consensus in the discussion this is an idea
   that
   came out during the discussion:
   
   -We introduce a Maturity level that we can use to manage expectations
   about
   the Framework (for example whether API/ABI will be kept)
   -We release Frameworks that are not ready together with the rest, but we
   have to make damn sure we manage expectations.
   
   With this we can get early feedback for new frameworks, and since we
   have
   a
   rapid release cycle we can improve them fast.
   
   What do you think?
  
  It depends on how you define maturity.
  
  For instance, if a maturity is simply a value set in each project'
  metainfo.yaml and set by those that maintain it then the maturity
  level quite frankly doesn't tell you anything.
  
  But if you decide maturity dynamically based on git activity, api/abi
  stability, number of people contributing and where the project itself
  is used in other projects (just some conditions that i can think of
  now, there is probably more). With this a project maturity actually
  has a meaning. When going for this approach it would also be nice to
  show a list of projects using Framework X. Also, i do not consider a
  project being healthy when it has only one developer [1] even if the
  project is used by dozens of other projects and has much activity. For
  us - kde devs - we probably don't care much if a framework is being
  developed/maintained by one person, but for external potential
  framework users that will be a concern. Specially companies.
 
 I think you're talking less about maturity and more about vitality, or
 something. Anyway, naming aside, I think Àlex was talking specifically about
 API/ABI guarantees - we offer pretty strong guarantees, and fresh projects
 may not want to commit to that until they've had some real-world usage and
 feedback. This would allow the equivalent to kdelibs' old experimental
 tagging, which was used for a couple of libraries while they settled on an
 API.
 
 I think it could be useful, but would definitely require very careful
 communication.

And that's the problem if we release them. If it's released with the rest 
expect people to have wrong expectations about them.

A possibility would be perhaps to produce nightly tarballs for those 
frameworks which don't have the release: true flag. This way they keep not 
being part of a release, and early adopters have something easy to grab.

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 119767: Add Hamlet and Haskell quasiquotation

2014-08-15 Thread Dominik Haumann 

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



src/syntax/data/haskell.xml
https://git.reviewboard.kde.org/r/119767/#comment45144

This question persists:

The rule 
DetectChar attribute=Normal context=List or QuasiQuote char=[/
from line 357 is included in this context.

Matching '[' will switch to List or QuasiQuote.
Since the rule above is in this context again, finding '[' will again 
switch into this context, such that the contexts add up.

That is what I meant before when asking Do you ever #pop back to the 
context code? :-)

Would it also be possible to use fallthrough and fallthroughContext like 
this:
context attribute=Normal lineEndContext=#stay name=List or 
QuasiQuote fallthrough=true fallthroughContext=#pop
and then remove the line 360?
IncludeRules context=code /


- Dominik Haumann


On Aug. 14, 2014, 8:39 p.m., Bastian Holst wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119767/
 ---
 
 (Updated Aug. 14, 2014, 8:39 p.m.)
 
 
 Review request for Kate, KDE Frameworks and Christoph Cullmann.
 
 
 Repository: ktexteditor
 
 
 Description
 ---
 
 This request request mostly contains syntax highlighting for Hamlet
 files. Hamlet is a Haskell based Template language for creating
 HTML documents. As Hamlet can be embedded into an ordinary Haskell
 file with quasi quotation, this also implements QuasiQuotation support
 for Haskell files.
 
 
 Diffs
 -
 
   src/syntax/data/hamlet.xml PRE-CREATION 
   src/syntax/data/haskell.xml 104e43ddafb2e7ca5ccc84fcf8344267e3148e05 
 
 Diff: https://git.reviewboard.kde.org/r/119767/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Bastian Holst
 


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

Re: KF5 ThreadWeaver Examples?

2014-08-15 Thread Mirko Boehm 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Brian, 

On 08/02/2014 03:54 AM, Brian Duffy wrote:
 I'm interested in toying around with ThreadWeaver in my Qt5 application. I 
 installed ThreadWeaver on my Fedora box from the repo on COPR. I can't find 
 any example code. I'm not sure where else to look. Any suggestions?

Sorry for the late response. I just came back from the Randa meeting. You can 
now find examples in the ThreadWeaver repo, and 10 pages of introduction in 
kde:kf5book.

Have fun, and if you have any questions, please let me know. 

Mirko.
- -- 
Mirko Boehm | mi...@kde.org | KDE e.V.
FSFE Fellow, FSFE Team Germany
Qt Certified Specialist and Trainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlPucEQACgkQYSSaITCTnKXLPQCdE2dW82c8cxPfWfGt3zzzv4yU
QKEAn38KGHQtReoKyXM02+EkibNAX0va
=TXiH
-END PGP SIGNATURE-
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel