Review Request 115209: Fix KDoctools build on Windows

2014-01-21 Thread Alexander Richardson

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

Review request for Documentation, KDE Frameworks and Luigi Toscano.


Repository: kdoctools


Description
---

Two separate commits: 

---

Print a message when a file is not found

This way meinproc no longer fails silently

--

Allow compiling on Windows with MSVC


Diffs
-

  CMakeLists.txt 56877a3f39b39a6d919c6b18a9c4ab1c0b5a9106 
  src/CMakeLists.txt 752604190a4b527d757d4b819dc6d85085a96e4b 
  src/meinproc.cpp f34084581205ad4f63a84823cd1a582b2f37ed69 
  src/meinproc_common.cpp 16234f70e45a703859fce42dcdb2ac1c2fdadade 
  src/xslt.cpp 79578ed8fb6cc3faccf63b8d86e29db9948b33e7 

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


Testing
---

Works on windows once https://git.reviewboard.kde.org/r/115210/ is also applied


Thanks,

Alexander Richardson

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


Review Request 115211: Mark target created by ecm_add_test as non GUI by default

2014-01-21 Thread Alexander Richardson

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

Review request for Build System, Extra Cmake Modules and KDE Frameworks.


Repository: extra-cmake-modules


Description
---

Mark target created by ecm_add_test as non GUI by default

This behaviour can be overriden by passing the GUI flag to the command


Diffs
-

  modules/ECMAddTests.cmake ff97d764d58c781d6c37dd08c8cb175ce500962e 

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


Testing
---

Oketeta unit tests wouldn't build on windows before this commit, now they do


Thanks,

Alexander Richardson

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


Review Request 115212: Fix windows build + 1 compiler warning

2014-01-21 Thread Alexander Richardson

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

Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

4 separate  commits: 


1. Fix windows build with QT_NO_CAST_FROM_ASCII


2. m_collator already returs bool, remove check for  0


3. Don't use foreach for this loop, it somehow breaks MSVC


4. Don't use uname() and getpwuid() directly

Added new functions that also do the right thing on Windows


Diffs
-

  src/systeminformation_p.h PRE-CREATION 
  src/kbugreport.cpp 56f088106becbccca5e9731abc04118a19e36ba9 
  src/CMakeLists.txt 4516a9ee3da774788c76f30f15181fa0049a9d86 
  src/kgesture.cpp 49c927803b2e16806985d758103d3e359aa58dd4 
  src/kkeysequencewidget.cpp cc9016b776c16984b83a36a2742526ede624bf5e 
  src/ksendbugmail/CMakeLists.txt 12b4926ecddeb023315f6074ab57cfe6cdee65ff 
  src/ksendbugmail/main.cpp 8f85f315f0746bb774175114b1e284e899957fd3 
  src/ksendbugmail/smtp.cpp 90b6b98467b0c220cfef18bc35cf3c07df9a8cf3 
  src/kshortcutseditoritem.cpp 086f833fc505f69a3b0dbe6fceffdb94ecd60330 

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


Testing
---

now it compiles on windows and Linux is still fine


Thanks,

Alexander Richardson

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


Re: Review Request 115210: Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows

2014-01-21 Thread Alexander Richardson

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

(Updated Jan. 22, 2014, 2:56 a.m.)


Review request for Build System, Extra Cmake Modules, KDE Frameworks, and 
kdewin.


Repository: extra-cmake-modules


Description
---

Always set DATA_INSTALL_DIR to %ALLUSERSPROFILE% on Windows

Otherwise QStandardPaths will always fail with e.g. GenericDataLocation


Diffs
-

  kde-modules/KDEInstallDirs.cmake 46e15c17d488d56f146aba0c2d420f74a22b9152 

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


Testing
---


Thanks,

Alexander Richardson

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


Re: Authors, maintainers and licenses in apidox

2014-01-21 Thread Kevin Ottens
On Tuesday 21 January 2014 17:18:36 Alex Merry wrote:
 Traditionally, the front pages of our apidox has included a list of
 authors, the maintainer(s) and the license.  This is obviously
 duplicating/summarising information stored elsewhere, and is easy to let
 get out of date.

Yes... definitely easy to get wrong. We should have only one place for that.
 
 Do we still want this information?  It would probably mean adding it to
 the README.md files.

Are we ditching the LICENSE and AUTHORS files which used to contain this type 
of information? I'm not sure we want everything in README.md.

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: Split classes into separate files?

2014-01-21 Thread Kevin Ottens
Hello,

On Wednesday 22 January 2014 00:30:19 David Gil Oliva wrote:
 I'm revising KCompletion and I have found that in kcompletion.h you can see
 the declaration of KCompletionBase (which is defined in a separate file)
 and KCompletionMatches (which is defined in kcompletion.cpp).
 
 I think I have seen that in other frameworks classes are being split into
 separate files. Should I also do it with KCompletionBase and
 KCompletionMatches?

You can, I personally consider that good practice. But it's not mandatory, so 
up to you.

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 115190: Add unit test for KWindowInfo on X11

2014-01-21 Thread Martin Gräßlin


 On Jan. 21, 2014, 11:42 p.m., Ben Cooksley wrote:
  I'm afraid the test fails Martin. Guess KWin and Openbox behave differently 
  in some areas.
  
  5/9 Test #5: kwindowsystem-kwindowinfox11test ..***Failed9.96 sec
  * Start testing of KWindowInfoX11Test *
  Config: Using QtTest library 5.2.2, Qt 5.2.2
  PASS   : KWindowInfoX11Test::initTestCase()
  FAIL!  : KWindowInfoX11Test::testState(max) Compared values are not the same
 Actual   (info.state())  
: 0
 Expected (static_castunsigned long(firstRun ? NET::DemandsAttention : 
  0)): 2048
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(129)]
  PASS   : KWindowInfoX11Test::testState(maxHoriz)
  FAIL!  : KWindowInfoX11Test::testState(shaded) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  FAIL!  : KWindowInfoX11Test::testState(skipTaskbar) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  FAIL!  : KWindowInfoX11Test::testState(skipPager) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  FAIL!  : KWindowInfoX11Test::testState(keep above) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  FAIL!  : KWindowInfoX11Test::testState(keep below) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  FAIL!  : KWindowInfoX11Test::testState(fullscreen) 'waitForWindow(spy, 
  window-winId(), NET::WMState)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(159)]
  PASS   : KWindowInfoX11Test::testMinimized()
  PASS   : KWindowInfoX11Test::testMappingState()
  PASS   : KWindowInfoX11Test::testWindowType(desktop)
  PASS   : KWindowInfoX11Test::testWindowType(dock)
  PASS   : KWindowInfoX11Test::testWindowType(toolbar)
  PASS   : KWindowInfoX11Test::testWindowType(menu)
  PASS   : KWindowInfoX11Test::testWindowType(dialog)
  PASS   : KWindowInfoX11Test::testWindowType(override)
  PASS   : KWindowInfoX11Test::testWindowType(override as normal)
  PASS   : KWindowInfoX11Test::testWindowType(topmenu)
  PASS   : KWindowInfoX11Test::testWindowType(topmenu as dock)
  PASS   : KWindowInfoX11Test::testWindowType(utility)
  PASS   : KWindowInfoX11Test::testWindowType(utility as dialog)
  PASS   : KWindowInfoX11Test::testWindowType(splash)
  PASS   : KWindowInfoX11Test::testWindowType(splash as dock)
  PASS   : KWindowInfoX11Test::testWindowType(dropdownmenu)
  PASS   : KWindowInfoX11Test::testWindowType(popupmenu)
  PASS   : KWindowInfoX11Test::testWindowType(popupmenu as menu)
  PASS   : KWindowInfoX11Test::testWindowType(tooltip)
  PASS   : KWindowInfoX11Test::testWindowType(notification)
  PASS   : KWindowInfoX11Test::testWindowType(ComboBox)
  PASS   : KWindowInfoX11Test::testWindowType(DNDIcon)
  PASS   : KWindowInfoX11Test::testWindowType(desktop-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(dock-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(toolbar-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(menu-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(dialog-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(override-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(topmenu-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(utility-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(splash-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(dropdownmenu-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(popupmenu-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(tooltip-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(notification-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(ComboBox-unknown)
  PASS   : KWindowInfoX11Test::testWindowType(DNDIcon-unknown)
  FAIL!  : KWindowInfoX11Test::testDesktop() 'waitForWindow(spy, 
  window-winId(), NET::WMDesktop)' returned FALSE. ()
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(304)]
  PASS   : KWindowInfoX11Test::testWindowClass()
  PASS   : KWindowInfoX11Test::testWindowRole()
  PASS   : KWindowInfoX11Test::testClientMachine()
  FAIL!  : KWindowInfoX11Test::testName() Compared values are not the same
 Actual   (info3.visibleName()) : kwindowinfox11test
 Expected (QStringLiteral(foobar)): foobar
 Loc: 
  [/srv/jenkins/workspace/kwindowsystem_master_qt5/autotests/kwindowinfox11test.cpp(436)]
  

Review Request 115213: Remove KDE4_CREATE_HTML_HANDBOOK

2014-01-21 Thread David Narváez

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

Review request for KDE Frameworks and Luigi Toscano.


Repository: kdoctools


Description
---

As discussed in Review Request 115077


Diffs
-

  KF5DocToolsMacros.cmake 191a2c5 

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


Testing
---

Searched all CMakeLists.txt files of frameworks for that macro, found nothing.


Thanks,

David Narváez

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


Re: Review Request 115190: Add unit test for KWindowInfo on X11

2014-01-21 Thread Martin Gräßlin

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

(Updated Jan. 22, 2014, 8:14 a.m.)


Review request for KDE Frameworks and Ben Cooksley.


Changes
---

installed openbox and added some fixes:
* KWin specific behavior in some tests checked for that we are running KWin
* added some sleeps for the tests which fail if they are executed directly 
after each other


Repository: kwindowsystem


Description
---

Add unit test for KWindowInfo on X11

Unit test for most methods provided by KWindowInfo. The general pattern
is to create a window, show it, test the property, change it and
verify that the change worked. This is a little bit tricky as the test
needs to interact with large parts of the window manager. In case a
property is updated by the window manager we need to send the client
message, wait till the window manager has reacted on it and updated
the property and then wait for the property update. This is mostly done
by waiting for the signal KWindowSystem::windowChanged. Unfortunately
that reports globally and not just for the window we are interested in.
So we have to filter out till we got the correct one. If there is at
the same time further interaction with the windowing system tests can
fail, but a re-run normally fixes it.

The unit test is so far written against KWin. It's possible that it
needs adjustments for succeeding on build.kde.org. Given that
KWindowInfo::actionSupported is not tested as that is clearly to
specific to the used window manager.

---

@Ben: is it possible that you try the patch on build.kde.org while it's under 
review, so that I can fix any possible failures.


Diffs (updated)
-

  autotests/CMakeLists.txt 58803aec9c807f68ff2bac227d0d9cf0305fa1f6 
  autotests/kwindowinfox11test.cpp PRE-CREATION 

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


Testing
---


Thanks,

Martin Gräßlin

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


Re: Review Request 115077: Rename Macros in KF5DocTools to KDE5_

2014-01-21 Thread David Narváez


 On Jan. 17, 2014, 6:51 p.m., Alex Merry wrote:
  KF5DocToolsMacros.cmake, lines 166-172
  https://git.reviewboard.kde.org/r/115077/diff/1/?file=234284#file234284line166
 
  These should *not* be renamed, as they are compatibility macros.  
  However, they should probably be moved to kde4support.
 
 Aleix Pol Gonzalez wrote:
 I wouldn't rename it indeed.
 
 Moving it to KDE4Support can be good indeed, although it kind of defeats 
 the purpose, as you'll need to actually depend on KDE4Support to get the 
 warning.
 
 David Narváez wrote:
 Luigi, your call.
 
 Alex Merry wrote:
 Well, most projects will start off depending on KDE4Support anyway, and 
 if you don't use it I think you should just get an error about the macro not 
 being found.
 
 Luigi Toscano wrote:
 My thoughts:
 - is the dependency on KDE4Support the first thing a ported application 
 should do? If yes, then the macros can be kept and moved; but please read on;
 - KDE4_CREATE_HTML_HANDBOOK can be completely removed. It has been 
 deprecated on Wed Aug 15 03:55:48 2007 +, 
 82f7b6ba0f8be7d314ac780b9a873e98b6be39b2, and it is not used (apart from the 
 definition in kdelibs and kf5/kdoctools).
 - KDE4_CREATE_HANDBOOK should not be renamed, and it can be moved to 
 KDE4Support (I see that it was already renamed as KDOCTOOLS_CREATE_HANDBOOK 
 in the frameworks-based code)
 - I see KDE4_SERIALIZE_TOOL has been renamed as well; but it is defined 
 in KDE4Support:
 
 http://lxr.kde.org/source/frameworks/kde4support/cmake/modules/FindKDE4Internal.cmake#455
 I'm not sure how to deal with this: probably it would be better to define 
 it here and rename it as KDOCTOOLS_blabla.
 
 Does it make sense?
 
 Alex Merry wrote:
 In general, yes, the first thing a ported application will do is replace 
 the lines to search for kdelibs4 with lines to find KDE4Support (and other 
 frameworks).
 
 I agree that KDE4_CREATE_HTML_HANDBOOK should be removed (along with any 
 other macro that didn't actually do anything in kdelibs4).  If 
 KDE4_CREATE_HANDBOOK was a useful macro in kdelibs4, it should move to 
 kde4support (and either be defined as it is here, or forward to 
 KDOCTOOLS_CREATE_HANDBOOK).
 
 I have no idea how the KDE4_SERIALIZE_TOOL thing is supposed to work, so 
 I can't comment on that.
 
 Luigi Toscano wrote:
 KDE4_SERIALIZE_TOOL is used only here (kdoctools); I suggest to rename it 
 as KDOCTOOLS_SERIALIZE_TOOL and add its definition (see 
 http://lxr.kde.org/source/kde/kdelibs/cmake/modules/FindKDE4Internal.cmake#721).
 
 KDE4_CREATE_HANDBOOK is used everytime there is documentation in 
 kdelibs4-based applications, so yes, we need to keep it somehow for migration 
 purposes :)
 
 David Narváez wrote:
 I'll split this RR into several others covering those changes.

Doesn't that serialization tool sound more like ECM? It could be useful if you 
need to serialize any kind of build.


- David


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


On Jan. 18, 2014, 1:16 p.m., David Narváez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/115077/
 ---
 
 (Updated Jan. 18, 2014, 1:16 p.m.)
 
 
 Review request for Documentation, KDE Frameworks and Luigi Toscano.
 
 
 Repository: kdoctools
 
 
 Description
 ---
 
 Part of the overall task of removing mentions of KDE4 from the code.
 
 
 Diffs
 -
 
   KF5DocToolsMacros.cmake 191a2c5 
 
 Diff: https://git.reviewboard.kde.org/r/115077/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 David Narváez
 


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


<    1   2