Re: Wrapping up about KI18n and UIC

[Aleix Pol]

On Mon, Nov 18, 2013 at 9:10 PM, Chusslove Illich wrote:

> >> [: Kevin Ottens :]
> >> Of course it should be removed when we get a proper fix via CMake 3
> >> around. But in the meantime it'll do the trick and allow removing
> >> dependencies on KDE4Support just for that.
> >
> > [: Aleix Pol :]
> > +1
> >
> > Then I suggest to let this go in:
> > https://git.reviewboard.kde.org/r/112785/diff/#index_header
>
> I don't see much point in that. To simply go on with the things, as I
> suggested, just replace every kde4_add_ui_files with qt5_wrap_ui. Later all
> these calls must be revisited anyway, to set translation domain and
> semantic
> markup flag. This holds either way; and with Stephen's solution, on
> revisiting only some new lines would be added, and qt5_wrap_ui calls left
> as
> they are.
>
> Alternatively, if one worries that with this things might be forgotten
> later
> (as Jeremy did originally), then just add KI18NMacros.cmake with a three-
> line ki18n_wrap_ui macro that passes the files to qt_wrap_ui.
>
> --
> Chusslove Illich (Часлав Илић)
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
That's not true. If you use qt5_wrap_ui nothing compiles because most of
our code will expect KLocalizedString to be included. I don't think adding
the includes is a good fix.

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

Re: Review Request 113887: Deprecate KDE4_* KAuth macros

[Hrvoje Senjan]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113887/#review43910
---


>${KAUTH_POLICY_FILES_INSTALL_DIR}
This is bogus (but e.g. KDE4_AUTH_POLICY_FILES_INSTALL_DIR is defined in 
KDELibsDependencies.cmake)

- Hrvoje Senjan


On Nov. 18, 2013, 2:22 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113887/
> ---
> 
> (Updated Nov. 18, 2013, 2:22 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Prefix them with kauth_* instead, also remove assumptions from kde4_*.
> 
> 
> Diffs
> -
> 
>   tier4/kde4support/CreateKDELibsDependenciesFile.cmake 55fb337 
>   tier2/kauth/src/kauthhelpersupport.h a9d7a53 
>   tier2/kauth/src/kauthactionreply.h a91e667 
>   tier2/kauth/src/kauthaction.h 07a5506 
>   tier2/kauth/src/ConfigureChecks.cmake f00f2fe 
>   tier2/kauth/src/CMakeLists.txt f61eee5 
>   tier2/kauth/KAuthConfig.cmake.in dee448b 
>   tier2/kauth/cmake/KAuthMacros.cmake d942d69 
>   tier4/kde4support/cmake/modules/KDE4Macros.cmake 6a63e5e 
> 
> Diff: http://git.reviewboard.kde.org/r/113887/diff/
> 
> 
> Testing
> ---
> 
> Nothing stopped building.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Wrapping up about KI18n and UIC

[Stephen Kelly]

Chusslove Illich wrote:

>> [: Stephen Kelly :]
>> This depends on Qt 5.3 and CMake master plus some trivial new generator
>> expressions. Aside from bikeshedding names of things and defaults, can
>> you see any problem with this?
> 
> Other than bikeshedding about the defaults (which I will do a bit later),
> I don't see any problems with this.

Great!

> Only one (hopefully little) thing: this syntax implies that everything
> compiled into the target will use the given settings, so later .kcfg files
> should be treated too (through an option-to-be-added to kconfig_compiler).

We'll have to see how that will work. Currently I am not familiar enough 
with the problem-domain.

Thanks,

Steve.


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

Re: Wrapping up about KI18n and UIC

[Chusslove Illich]

>> [: Chusslove Illich :]
>> [...] with Stephen's solution, on revisiting only some new lines would be
>> added, and qt5_wrap_ui calls left as they are.
>
> [: Stephen Kelly :]
> Actually, with my solution (including CMAKE_AUTOUIC) qt5_wrap_ui calls are
> removed.

Sorry, brain glitch :)

-- 
Chusslove Illich (Часлав Илић)


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: Wrapping up about KI18n and UIC

[Stephen Kelly]

Chusslove Illich wrote:

> with Stephen's solution, on
> revisiting only some new lines would be added, and qt5_wrap_ui calls left
> as they are.

Actually, with my solution (including CMAKE_AUTOUIC) qt5_wrap_ui calls are 
removed.

Thanks,

Steve.


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

Re: Wrapping up about KI18n and UIC

[Chusslove Illich]

> [: Stephen Kelly :]
> This depends on Qt 5.3 and CMake master plus some trivial new generator
> expressions. Aside from bikeshedding names of things and defaults, can you
> see any problem with this?

Other than bikeshedding about the defaults (which I will do a bit later),
I don't see any problems with this.

Only one (hopefully little) thing: this syntax implies that everything
compiled into the target will use the given settings, so later .kcfg files
should be treated too (through an option-to-be-added to kconfig_compiler).

-- 
Chusslove Illich (Часлав Илић)


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: Wrapping up about KI18n and UIC

[Chusslove Illich]

>> [: Kevin Ottens :]
>> Of course it should be removed when we get a proper fix via CMake 3
>> around. But in the meantime it'll do the trick and allow removing
>> dependencies on KDE4Support just for that.
>
> [: Aleix Pol :]
> +1
>
> Then I suggest to let this go in:
> https://git.reviewboard.kde.org/r/112785/diff/#index_header

I don't see much point in that. To simply go on with the things, as I
suggested, just replace every kde4_add_ui_files with qt5_wrap_ui. Later all
these calls must be revisited anyway, to set translation domain and semantic
markup flag. This holds either way; and with Stephen's solution, on
revisiting only some new lines would be added, and qt5_wrap_ui calls left as
they are.

Alternatively, if one worries that with this things might be forgotten later
(as Jeremy did originally), then just add KI18NMacros.cmake with a three-
line ki18n_wrap_ui macro that passes the files to qt_wrap_ui.

-- 
Chusslove Illich (Часлав Илић)


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 113685: New KColorSchemeManager to support changing color scheme in app

[Albert Astals Cid]

> On Nov. 15, 2013, 7:42 p.m., Kevin Ottens wrote:
> > tier3/kconfigwidgets/src/kcolorschememanager.cpp, line 124
> > 
> >
> > Would make sense to change the lambda so that you'd pass 16 and 24 
> > instead. It feels kinda weird otherwise. :-)
> > 
> > You can still do (size / 2) - 1 in the lambda to prepare for the 
> > fillRect calls.
> 
> Albert Astals Cid wrote:
> What about the color palettes vs theme colors issue?
> 
> Martin Gräßlin wrote:
> There is no issue at all about color palettes vs theme colors. It's just 
> the color schemes it operates on.
> 
> Albert Astals Cid wrote:
> So you're saying Boud's and Christoph comments are wrong?
> 
> Martin Gräßlin wrote:
> not at all. That are two different beast which just have the same file 
> ending. The palettes are installed to **/colors/, the color-schemes to 
> **/color-schemes/. This class only looks for files in color-schemes/, so that 
> the palettes have the same file ending doesn't matter.

Ok, point taken, so back to the "should we i18n this?" Yes, we should. This 
.colors file looks .desktop like so just by adding a ExtraDesktop.sh file (see 
kwin for example) and then using KConfig should do it. I guess we should 
probably take the discussion somewhere else?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43755
---


On Nov. 18, 2013, 8:44 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113685/
> ---
> 
> (Updated Nov. 18, 2013, 8:44 a.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and 
> Boudewijn Rempt.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This class is inspired by functionality offered by e.g. Krita and
> Digikam to allow the user to select a different color scheme for the
> application.
> 
> This manager simplifies this task and also ensures that the required
> property on QApplication is set, so that a QStyle can pass the scheme
> to the window manager/compositor for the windows of the application.
> 
> @boud and @cgilles: please have a look whether this approach is sufficient 
> for your usecases in digkam and Krita.
> 
> 
> Diffs
> -
> 
>   tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 
>   tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION 
>   tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 
> 
> Diff: http://git.reviewboard.kde.org/r/113685/diff/
> 
> 
> Testing
> ---
> 
> see demo application
> 
> 
> 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 113631: Allow compiling kwindowsystem on Windows

[Nicolás Alvarez]

> On Nov. 18, 2013, 3:39 p.m., Nicolás Alvarez wrote:
> > Ship It!

This has been incubating for long enough. Remember Patrick's comment though :)


- Nicolás


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113631/#review43905
---


On Nov. 10, 2013, 12:46 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113631/
> ---
> 
> (Updated Nov. 10, 2013, 12:46 p.m.)
> 
> 
> Review request for KDE Frameworks, Patrick Spendrin and Patrick von Reth.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Allow compiling kwindowsystem on Windows
> 
> 
> Diffs
> -
> 
>   tier1/CMakeLists.txt 277b3f0 
>   tier1/kwindowsystem/CMakeLists.txt dc8fcae 
>   tier1/kwindowsystem/src/CMakeLists.txt d9d141e 
>   tier1/kwindowsystem/src/kkeyserver_win.h 6328f41 
>   tier1/kwindowsystem/src/kstartupinfo.h 39c2935 
>   tier1/kwindowsystem/src/kstartupinfo.cpp 402cc97 
>   tier1/kwindowsystem/src/kwindowinfo_win.cpp d392fe9 
>   tier1/kwindowsystem/src/kwindowsystem.h 0c6a930 
>   tier1/kwindowsystem/src/kwindowsystem_win.cpp 23a6616 
> 
> Diff: http://git.reviewboard.kde.org/r/113631/diff/
> 
> 
> Testing
> ---
> 
> Compiles (Windows 7, VS 2012 x64)
> 
> 
> 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 113631: Allow compiling kwindowsystem on Windows

[Nicolás Alvarez]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113631/#review43905
---

Ship it!


Ship It!

- Nicolás Alvarez


On Nov. 10, 2013, 12:46 p.m., Alexander Richardson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113631/
> ---
> 
> (Updated Nov. 10, 2013, 12:46 p.m.)
> 
> 
> Review request for KDE Frameworks, Patrick Spendrin and Patrick von Reth.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Allow compiling kwindowsystem on Windows
> 
> 
> Diffs
> -
> 
>   tier1/CMakeLists.txt 277b3f0 
>   tier1/kwindowsystem/CMakeLists.txt dc8fcae 
>   tier1/kwindowsystem/src/CMakeLists.txt d9d141e 
>   tier1/kwindowsystem/src/kkeyserver_win.h 6328f41 
>   tier1/kwindowsystem/src/kstartupinfo.h 39c2935 
>   tier1/kwindowsystem/src/kstartupinfo.cpp 402cc97 
>   tier1/kwindowsystem/src/kwindowinfo_win.cpp d392fe9 
>   tier1/kwindowsystem/src/kwindowsystem.h 0c6a930 
>   tier1/kwindowsystem/src/kwindowsystem_win.cpp 23a6616 
> 
> Diff: http://git.reviewboard.kde.org/r/113631/diff/
> 
> 
> Testing
> ---
> 
> Compiles (Windows 7, VS 2012 x64)
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

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

Re: error: KF5::KDBusAddons-NOTFOUND

[Sebastian Kügler]

On Monday, November 18, 2013 17:53:07 Aleix Pol wrote:
> On Mon, Nov 18, 2013 at 5:43 PM, Sebastian Kügler  wrote:
> It seems subject broke over the weekend. kactivities fails to compile:
> 
> c++: error: KF5::KDBusAddons-NOTFOUND: No such file or directory
> 
> kactivities uses:
> 
> find_package (KF5 CONFIG REQUIRED KDBusAddons)
> 
> so it's pretty bare-bones.
> 
> Could someone have a look or suggest a fix?

> There's no warning or error in cmake configuration time?
> You can trigger it with "make rebuild_cache"

There's no warning, it even suggests that KDBusAddons has been found.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Wrapping up about KI18n and UIC

[Aleix Pol]

On Mon, Nov 18, 2013 at 5:59 PM, Kevin Ottens  wrote:

> On Monday 18 November 2013 17:41:49 Aleix Pol wrote:
> > On Mon, Nov 18, 2013 at 4:17 PM, Kevin Ottens  wrote:
> > > Right, we need to cater to that need too. Since that's tied to ki18n
> use,
> > > what about putting that wrapper macro in ki18n for the time being?
> > >
> > > Of course it should be removed when we get a proper fix via CMake 3
> > > around. But in the meantime it'll do the trick and allow removing
> > > dependencies on KDE4Support just for that.
> >
> > +1
> >
> > Then I suggest to let this go in:
> > https://git.reviewboard.kde.org/r/112785/diff/#index_header
>
> Unfortunately it's still not a wrapper macro... But since we want to treat
> it
> as a temporary solution, let's assume that's OK for now. Will give the
> ship it
> in a couple of minutes.
>
> Cheers.
> --
> 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
>
>
It can't be a wrapper macro yet, since we need to play with the file
generation until the include feature lands in Qt 5.3.

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

Re: error: KF5::KDBusAddons-NOTFOUND

[Martin Klapetek]

On Mon, Nov 18, 2013 at 5:53 PM, Aleix Pol  wrote:

> On Mon, Nov 18, 2013 at 5:43 PM, Sebastian Kügler  wrote:
>
>> It seems subject broke over the weekend. kactivities fails to compile:
>>
>> c++: error: KF5::KDBusAddons-NOTFOUND: No such file or directory
>>
>> kactivities uses:
>>
>> find_package (KF5 CONFIG REQUIRED KDBusAddons)
>>
>> so it's pretty bare-bones.
>>
>> Could someone have a look or suggest a fix?
>>
>
I have the same problem with Workspace failing on KNewStuff (note that it's
during linking):

Scanning dependencies of target kcm_kwindecoration
Linking CXX shared module ../../../lib/kcm_kwin_scripts.so
c++: error: KF5::KNewStuff-NOTFOUND: No such file or directory
make[2]: *** [lib/kcm_kwin_scripts.so] Error 1
make[1]: *** [kwin/kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs


There's no warning or error in cmake configuration time?
> You can trigger it with "make rebuild_cache"
>

Nope, KNewStuff is happily found, no error or warning.

Cheers
-- 
Martin Klapetek | KDE Developer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: error: KF5::KDBusAddons-NOTFOUND

[Aleix Pol]

On Mon, Nov 18, 2013 at 5:43 PM, Sebastian Kügler  wrote:

> It seems subject broke over the weekend. kactivities fails to compile:
>
> c++: error: KF5::KDBusAddons-NOTFOUND: No such file or directory
>
> kactivities uses:
>
> find_package (KF5 CONFIG REQUIRED KDBusAddons)
>
> so it's pretty bare-bones.
>
> Could someone have a look or suggest a fix?
>
> Thanks,
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

There's no warning or error in cmake configuration time?
You can trigger it with "make rebuild_cache"

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

Re: Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros

[Kevin Ottens]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112785/#review43904
---

Ship it!


After discussion on the mailing list, let's get that in for the time being. It 
is to be considered as a temporary solution and will be removed when CMake 3 
will be available.

- Kevin Ottens


On Sept. 17, 2013, 7:56 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112785/
> ---
> 
> (Updated Sept. 17, 2013, 7:56 p.m.)
> 
> 
> Review request for KDE Frameworks and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> It builds and installs, but doesn't seem to be usable from within kdelibs, 
> i.e. ki18n_wrap_ui in knewstuff/src/CMakeLists.txt fails with this. I suspect 
> one more thing is needed to make it work from within kdelibs builds.
> 
> 
> Diffs
> -
> 
>   tier2/ki18n/CMakeLists.txt d0ed448 
>   tier2/ki18n/KI18nConfig.cmake.in 18b6e2f 
>   tier2/ki18n/cmake/KI18NMacros.cmake PRE-CREATION 
>   tier2/ki18n/cmake/ki18nuic.cmake PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112785/diff/
> 
> 
> Testing
> ---
> 
> Builds and installs into PREFIX/lib64/cmake/KI18N next to KI18nConfig.cmake
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

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

Re: Wrapping up about KI18n and UIC

[Kevin Ottens]

On Monday 18 November 2013 17:41:49 Aleix Pol wrote:
> On Mon, Nov 18, 2013 at 4:17 PM, Kevin Ottens  wrote:
> > Right, we need to cater to that need too. Since that's tied to ki18n use,
> > what about putting that wrapper macro in ki18n for the time being?
> >
> > Of course it should be removed when we get a proper fix via CMake 3
> > around. But in the meantime it'll do the trick and allow removing
> > dependencies on KDE4Support just for that.
>
> +1
>
> Then I suggest to let this go in:
> https://git.reviewboard.kde.org/r/112785/diff/#index_header

Unfortunately it's still not a wrapper macro... But since we want to treat it
as a temporary solution, let's assume that's OK for now. Will give the ship it
in a couple of minutes.

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

error: KF5::KDBusAddons-NOTFOUND

[Sebastian Kügler]

It seems subject broke over the weekend. kactivities fails to compile:

c++: error: KF5::KDBusAddons-NOTFOUND: No such file or directory

kactivities uses:

find_package (KF5 CONFIG REQUIRED KDBusAddons)

so it's pretty bare-bones.

Could someone have a look or suggest a fix?

Thanks,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Wrapping up about KI18n and UIC

[Aleix Pol]

On Mon, Nov 18, 2013 at 4:17 PM, Kevin Ottens  wrote:

> On Monday 18 November 2013 13:27:19 Aleix Pol wrote:
> > So would it be that bad to have a macro of ours that ends up being just a
> > wrapper to qt5_wrap_ui?
> >
> > Otherwise, this delays the possibility to help the ongoing porting
> process
> > by extending a mandatory dependency on KDE4Support.
>
> Right, we need to cater to that need too. Since that's tied to ki18n use,
> what
> about putting that wrapper macro in ki18n for the time being?
>
> Of course it should be removed when we get a proper fix via CMake 3 around.
> But in the meantime it'll do the trick and allow removing dependencies on
> KDE4Support just for that.
>
> Cheers.
> --
> 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
>
>
+1

Then I suggest to let this go in:
https://git.reviewboard.kde.org/r/112785/diff/#index_header

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

Re: Wrapping up about KI18n and UIC

[Kevin Ottens]

On Monday 18 November 2013 13:27:19 Aleix Pol wrote:
> So would it be that bad to have a macro of ours that ends up being just a
> wrapper to qt5_wrap_ui?
>
> Otherwise, this delays the possibility to help the ongoing porting process
> by extending a mandatory dependency on KDE4Support.

Right, we need to cater to that need too. Since that's tied to ki18n use, what
about putting that wrapper macro in ki18n for the time being?

Of course it should be removed when we get a proper fix via CMake 3 around.
But in the meantime it'll do the trick and allow removing dependencies on
KDE4Support just for that.

Cheers.
--
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 113863: Remove WINCE specific cmake code paths

[Aleix Pol Gonzalez]

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

(Updated Nov. 18, 2013, 2:50 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and KDE Frameworks.


Repository: kdelibs


Description
---

Removes WINCE specific code. It's not a supported platform anymore.


Diffs
-

  tier1/kcoreaddons/src/lib/CMakeLists.txt a1f81f7 
  tier1/kcoreaddons/src/lib/util/kuser_wince.cpp b96e4dc 
  tier3/kinit/src/kdeinit/CMakeLists.txt 4ef0a9b 
  tier3/kio/src/CMakeLists.txt 3800e85 
  tier3/kprintutils/src/CMakeLists.txt da0b7d5 
  tier4/kde4support/src/CMakeLists.txt 9046c96 

Diff: http://git.reviewboard.kde.org/r/113863/diff/


Testing
---

still builds.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 113863: Remove WINCE specific cmake code paths

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113863/#review43894
---


This review has been submitted with commit 
faea76aa5b40bedaa1dcd5101a25f80b7ebeb0cd by Aleix Pol to branch frameworks.

- Commit Hook


On Nov. 18, 2013, 2:34 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113863/
> ---
> 
> (Updated Nov. 18, 2013, 2:34 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Removes WINCE specific code. It's not a supported platform anymore.
> 
> 
> Diffs
> -
> 
>   tier1/kcoreaddons/src/lib/CMakeLists.txt a1f81f7 
>   tier1/kcoreaddons/src/lib/util/kuser_wince.cpp b96e4dc 
>   tier3/kinit/src/kdeinit/CMakeLists.txt 4ef0a9b 
>   tier3/kio/src/CMakeLists.txt 3800e85 
>   tier3/kprintutils/src/CMakeLists.txt da0b7d5 
>   tier4/kde4support/src/CMakeLists.txt 9046c96 
> 
> Diff: http://git.reviewboard.kde.org/r/113863/diff/
> 
> 
> Testing
> ---
> 
> still builds.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 113863: Remove WINCE specific cmake code paths

[Stephen Kelly]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113863/#review43892
---

Ship it!


Ship It!

- Stephen Kelly


On Nov. 18, 2013, 2:34 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113863/
> ---
> 
> (Updated Nov. 18, 2013, 2:34 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Removes WINCE specific code. It's not a supported platform anymore.
> 
> 
> Diffs
> -
> 
>   tier1/kcoreaddons/src/lib/CMakeLists.txt a1f81f7 
>   tier1/kcoreaddons/src/lib/util/kuser_wince.cpp b96e4dc 
>   tier3/kinit/src/kdeinit/CMakeLists.txt 4ef0a9b 
>   tier3/kio/src/CMakeLists.txt 3800e85 
>   tier3/kprintutils/src/CMakeLists.txt da0b7d5 
>   tier4/kde4support/src/CMakeLists.txt 9046c96 
> 
> Diff: http://git.reviewboard.kde.org/r/113863/diff/
> 
> 
> Testing
> ---
> 
> still builds.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 113863: Remove WINCE specific cmake code paths

[Aleix Pol Gonzalez]

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

(Updated Nov. 18, 2013, 2:34 p.m.)


Review request for Build System and KDE Frameworks.


Repository: kdelibs


Description
---

Removes WINCE specific code. It's not a supported platform anymore.


Diffs (updated)
-

  tier1/kcoreaddons/src/lib/CMakeLists.txt a1f81f7 
  tier1/kcoreaddons/src/lib/util/kuser_wince.cpp b96e4dc 
  tier3/kinit/src/kdeinit/CMakeLists.txt 4ef0a9b 
  tier3/kio/src/CMakeLists.txt 3800e85 
  tier3/kprintutils/src/CMakeLists.txt da0b7d5 
  tier4/kde4support/src/CMakeLists.txt 9046c96 

Diff: http://git.reviewboard.kde.org/r/113863/diff/


Testing
---

still builds.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 113887: Deprecate KDE4_* KAuth macros

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113887/#review43891
---


This review has been submitted with commit 
664d10a82b2bb3e2e033effbf3a42ccf96b98285 by Aleix Pol to branch frameworks.

- Commit Hook


On Nov. 15, 2013, 5:34 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113887/
> ---
> 
> (Updated Nov. 15, 2013, 5:34 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Prefix them with kauth_* instead, also remove assumptions from kde4_*.
> 
> 
> Diffs
> -
> 
>   tier4/kde4support/CreateKDELibsDependenciesFile.cmake 55fb337 
>   tier2/kauth/src/kauthhelpersupport.h a9d7a53 
>   tier2/kauth/src/kauthactionreply.h a91e667 
>   tier2/kauth/src/kauthaction.h 07a5506 
>   tier2/kauth/src/ConfigureChecks.cmake f00f2fe 
>   tier2/kauth/src/CMakeLists.txt f61eee5 
>   tier2/kauth/KAuthConfig.cmake.in dee448b 
>   tier2/kauth/cmake/KAuthMacros.cmake d942d69 
>   tier4/kde4support/cmake/modules/KDE4Macros.cmake 6a63e5e 
> 
> Diff: http://git.reviewboard.kde.org/r/113887/diff/
> 
> 
> Testing
> ---
> 
> Nothing stopped building.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 113887: Deprecate KDE4_* KAuth macros

[Aleix Pol Gonzalez]

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

(Updated Nov. 18, 2013, 2:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for Build System and KDE Frameworks.


Repository: kdelibs


Description
---

Prefix them with kauth_* instead, also remove assumptions from kde4_*.


Diffs
-

  tier4/kde4support/CreateKDELibsDependenciesFile.cmake 55fb337 
  tier2/kauth/src/kauthhelpersupport.h a9d7a53 
  tier2/kauth/src/kauthactionreply.h a91e667 
  tier2/kauth/src/kauthaction.h 07a5506 
  tier2/kauth/src/ConfigureChecks.cmake f00f2fe 
  tier2/kauth/src/CMakeLists.txt f61eee5 
  tier2/kauth/KAuthConfig.cmake.in dee448b 
  tier2/kauth/cmake/KAuthMacros.cmake d942d69 
  tier4/kde4support/cmake/modules/KDE4Macros.cmake 6a63e5e 

Diff: http://git.reviewboard.kde.org/r/113887/diff/


Testing
---

Nothing stopped building.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 113883: Rename translation catalogue kfileaudiopreview4 to kfileaudiopreview

[Alex Merry]

> On Nov. 15, 2013, 12:32 p.m., Aleix Pol Gonzalez wrote:
> > Why do you need to drop the version? In similar cases we've been bumping to 
> > 5...
> 
> Kevin Ottens wrote:
> Yeah I'm surprised as well... OTOH that's a regular library, we don't 
> mention the version name for those (unlike for executables like kded)
> 
> Albert Astals Cid wrote:
> FWIW This is not about library versioning but about the po catalog naming.
> 
> Alex Merry wrote:
> I have no preference either way, only that it shouldn't be "4".
> 
> Chusslove Illich wrote:
> >> [: Albert Astals Cid :]
> >> FWIW This is not about library versioning but about the po catalog
> >> naming.
> >
> > [: Alex Merry :]
> > I have no preference either way, only that it shouldn't be "4".
> 
> The reason why that "4" appeared was to enable kdelibs from KDE 3 and KDE 
> 4
> to be installed in the same path. So the action now depends on whether the
> same should be possible for KDE 3 kdelibs and KF5. If not, "4" can be
> dropped, if yes, it must be bumped to "5".
>

So I've changed it to include "5", since that seems like the less contentious 
solution.


- Alex


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113883/#review43729
---


On Nov. 15, 2013, 9:10 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113883/
> ---
> 
> (Updated Nov. 15, 2013, 9:10 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Rename translation catalogue kfileaudiopreview4 to kfileaudiopreview
> 
> 
> Diffs
> -
> 
>   staging/kmediaplayer/src/kfileaudiopreview/Messages.sh 71c7067 
>   staging/kmediaplayer/src/kfileaudiopreview/kfileaudiopreview.cpp 04efb24 
>   staging/kmediaplayer/src/kfileaudiopreview/mediacontrols_p.h bb36ab1 
> 
> Diff: http://git.reviewboard.kde.org/r/113883/diff/
> 
> 
> Testing
> ---
> 
> Builds.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

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

applications assert when no sycoca was generated before start

[Harald Sitter]

ahoy,

I just noticed that frameworks applications explode when started
without a sycoca:

Trying to open ksycoca from "/home/me/.project-neon5-kde//cache/ksycoca5"
Trying to open global ksycoca from
"/home/me/.project-neon5-kde//local/share/kde5/services/ksycoca5"
Still no database...
ASSERT: "str" in file
/build/buildd/project-neon5-kdelibs-0.0+git20131112+r97303~d1059d8+neon11~ubuntu13.10.1/tier3/kservice/src/services/kservicetypefactory.cpp,
line 36

^ Supposedly kbuildsycoca5 should be run at this point.

This only happens when one removes the cache after kdeinit5 was run.

e.g.
kdeinit5
rm -rf .kde
plasma-shell

Confirmed to be the case with at least plasma-shell and kwin.

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

Re: Review Request 112896: Rework NETWM classes

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112896/#review43888
---


This review has been submitted with commit 
d981e6e6be947a3e977332ef170ef2643a6c4174 by Martin Gräßlin to branch frameworks.

- Commit Hook


On Nov. 8, 2013, 3:14 p.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112896/
> ---
> 
> (Updated Nov. 8, 2013, 3:14 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This is a patch series, if needed I can push the branch.
> 
> The patches address the following topics:
> * add unit tests for NETRootInfo and NETWinInfo which do not require a 
> running window manager. Test coverage of netwm.h is:
>   ** line coverage: 75 %
>   ** functions coverage: 84 %
>   ** branch coverage: 62 %
>   The tests start their own Xvfb to have a clean state and not mess up with 
> the Window Manager of a user or cause followint tests to fail on the CI system
> * areas which are covered by unit tests are changed from XLib to XCB. This 
> mostly affects changing and reading window properties
> * API is changed from XLib types to XCB types. E.g. xcb_window_t instead of 
> Window. Note: this is an API break, which I consider as necessary, given that 
> especially the type "Window" is problematic.
> * several bugs which were discovered through the added tests are fixed
> * NETWinInfo2 is merged into NETWinInfo (marked as TODO KDE5)
> * Small wrapper class for intern atom added to KXUtils. Similar code already 
> in usage in KWin.
> 
> 
> =
> Commits:
> 
> commit 2e50845a5d0df436106aeb776e3936691c32a753
> Author: Martin Gräßlin 
> Date:   Mon Sep 23 14:31:42 2013 +0200
> 
> Use XCB for reading properties in NETRootInfo::update
> 
> Viewport handling was incorrect and is adjusted to be read correctly.
> 
> commit 23887726c03c49b4e0021c01f319653d3b9f36c5
> Author: Martin Gräßlin 
> Date:   Mon Sep 23 11:41:26 2013 +0200
> 
> Use XCB for reading properties in NETWinInfo::update
> 
> Those areas which are covered by unit tests are migrated from
> XGetWindowProperty to the xcb variant.
> 
> BlocksCompositing had an incorrect read - it expected a string atom,
> but actually uses a cardinal. This bug is fixed.
> 
> commit 2731ebbc85eddb885700232f98e0e429cb0e066b
> Author: Martin Gräßlin 
> Date:   Mon Sep 23 09:41:28 2013 +0200
> 
> Use XCB to change the Client dependent properties of NETWinInfo
> 
> Those properties for which we have unit tests are changed to XCB to
> either change or delete the property.
> 
> commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a
> Author: Martin Gräßlin 
> Date:   Fri Sep 20 09:58:09 2013 +0200
> 
> Unit test for Client aspect of NETWinInfo
> 
> Similar to the NETWinInfo test with WindowManager aspect, just
> verifying the properties which can only be set by a Client.
> 
> The test found highlights a few possible problems:
>  * for some window types a fallback type is specified, but the lenght
>is set to 1, thus the fallback type is not set at all
>  * Fullscreen monitors property is not handled in the event function
> 
> commit 2731ebbc85eddb885700232f98e0e429cb0e066b
> Author: Martin Gräßlin 
> Date:   Mon Sep 23 09:41:28 2013 +0200
> 
> Use XCB to change the Client dependent properties of NETWinInfo
> 
> Those properties for which we have unit tests are changed to XCB to
> either change or delete the property.
> 
> commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a
> Author: Martin Gräßlin 
> Date:   Fri Sep 20 09:58:09 2013 +0200
> 
> Unit test for Client aspect of NETWinInfo
> 
> Similar to the NETWinInfo test with WindowManager aspect, just
> verifying the properties which can only be set by a Client.
> 
> The test found highlights a few possible problems:
>  * for some window types a fallback type is specified, but the lenght
>is set to 1, thus the fallback type is not set at all
>  * Fullscreen monitors property is not handled in the event function
> 
> commit 448f200ecdd642d1a4c85522eaa7d28072cda873
> Author: Martin Gräßlin 
> Date:   Thu Sep 19 13:57:03 2013 +0200
> 
> Use XCB to change the WM dependent properties of NETWinInfo
> 
> Those properties for which we have unit tests are changed to XCB to
> either change or delete the property.
> 
> commit 736024c6c6233a9c66a03972b9dbfbd2e6d383f4
> Author: Martin Gräßlin 
> Date:   Thu Sep 19 13:16:03 2013 +0200
> 
> Add unit test for window manager aspect of NETWinInfo
> 
> Similar to the test for NETRootInfo it tests setting the properties
> whi

Re: Review Request 112896: Rework NETWM classes

[Martin Gräßlin]

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

(Updated Nov. 18, 2013, 1:21 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

This is a patch series, if needed I can push the branch.

The patches address the following topics:
* add unit tests for NETRootInfo and NETWinInfo which do not require a running 
window manager. Test coverage of netwm.h is:
  ** line coverage: 75 %
  ** functions coverage: 84 %
  ** branch coverage: 62 %
  The tests start their own Xvfb to have a clean state and not mess up with the 
Window Manager of a user or cause followint tests to fail on the CI system
* areas which are covered by unit tests are changed from XLib to XCB. This 
mostly affects changing and reading window properties
* API is changed from XLib types to XCB types. E.g. xcb_window_t instead of 
Window. Note: this is an API break, which I consider as necessary, given that 
especially the type "Window" is problematic.
* several bugs which were discovered through the added tests are fixed
* NETWinInfo2 is merged into NETWinInfo (marked as TODO KDE5)
* Small wrapper class for intern atom added to KXUtils. Similar code already in 
usage in KWin.


=
Commits:

commit 2e50845a5d0df436106aeb776e3936691c32a753
Author: Martin Gräßlin 
Date:   Mon Sep 23 14:31:42 2013 +0200

Use XCB for reading properties in NETRootInfo::update

Viewport handling was incorrect and is adjusted to be read correctly.

commit 23887726c03c49b4e0021c01f319653d3b9f36c5
Author: Martin Gräßlin 
Date:   Mon Sep 23 11:41:26 2013 +0200

Use XCB for reading properties in NETWinInfo::update

Those areas which are covered by unit tests are migrated from
XGetWindowProperty to the xcb variant.

BlocksCompositing had an incorrect read - it expected a string atom,
but actually uses a cardinal. This bug is fixed.

commit 2731ebbc85eddb885700232f98e0e429cb0e066b
Author: Martin Gräßlin 
Date:   Mon Sep 23 09:41:28 2013 +0200

Use XCB to change the Client dependent properties of NETWinInfo

Those properties for which we have unit tests are changed to XCB to
either change or delete the property.

commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a
Author: Martin Gräßlin 
Date:   Fri Sep 20 09:58:09 2013 +0200

Unit test for Client aspect of NETWinInfo

Similar to the NETWinInfo test with WindowManager aspect, just
verifying the properties which can only be set by a Client.

The test found highlights a few possible problems:
 * for some window types a fallback type is specified, but the lenght
   is set to 1, thus the fallback type is not set at all
 * Fullscreen monitors property is not handled in the event function

commit 2731ebbc85eddb885700232f98e0e429cb0e066b
Author: Martin Gräßlin 
Date:   Mon Sep 23 09:41:28 2013 +0200

Use XCB to change the Client dependent properties of NETWinInfo

Those properties for which we have unit tests are changed to XCB to
either change or delete the property.

commit 1bb85e440ec0004ef6b18b6fa1855c08c8f6697a
Author: Martin Gräßlin 
Date:   Fri Sep 20 09:58:09 2013 +0200

Unit test for Client aspect of NETWinInfo

Similar to the NETWinInfo test with WindowManager aspect, just
verifying the properties which can only be set by a Client.

The test found highlights a few possible problems:
 * for some window types a fallback type is specified, but the lenght
   is set to 1, thus the fallback type is not set at all
 * Fullscreen monitors property is not handled in the event function

commit 448f200ecdd642d1a4c85522eaa7d28072cda873
Author: Martin Gräßlin 
Date:   Thu Sep 19 13:57:03 2013 +0200

Use XCB to change the WM dependent properties of NETWinInfo

Those properties for which we have unit tests are changed to XCB to
either change or delete the property.

commit 736024c6c6233a9c66a03972b9dbfbd2e6d383f4
Author: Martin Gräßlin 
Date:   Thu Sep 19 13:16:03 2013 +0200

Add unit test for window manager aspect of NETWinInfo

Similar to the test for NETRootInfo it tests setting the properties
which can only be set by the window manager. Also running in its own
Xvfb.

commit 480842406c2c070280a8be8ae3e4af93674369f3
Author: Martin Gräßlin 
Date:   Thu Sep 19 07:20:57 2013 +0200

Merge NETWinInfo2 into NETWinInfo

Class only existed for BIC changes and had a TODO remove KDE5 marker.

commit 4e71654d95715f5b44efef80fb95fa9bee295b6c
Author: Martin Gräßlin 
Date:   Thu Sep 19 07:16:00 2013 +0200

Drop desktop argument from NETRootInfo::(set)DesktopGeometry

The desktop argument was only there because of a different semantic in
an early draft of NETwm and completely unused. Doe

Re: Review Request 112913: Move KModifierKeyInfo from GuiAddons to KWindowSystem

[Martin Gräßlin]

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

(Updated Nov. 18, 2013, 2:19 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

As discussed in https://git.reviewboard.kde.org/r/112443/

It's quite windowing system specific and only implemented for X11 so
it makes more sense in the framework which is about the windowing
system specific code.


Diffs
-

  tier1/kguiaddons/src/lib/CMakeLists.txt dc6aafa 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.h a5b1785 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfo.cpp 7068d6f 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider.cpp 696c577 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_dummy.cpp 7913d29 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_p.h ee8e82e 
  tier1/kguiaddons/src/lib/util/kmodifierkeyinfoprovider_x11.cpp 2f28d41 
  tier1/kguiaddons/tests/CMakeLists.txt 4d91ed8 
  tier1/kguiaddons/tests/kmodifierkeyinfotest.cpp 39984a0 
  tier1/kwindowsystem/src/CMakeLists.txt 31fb53e 
  tier1/kwindowsystem/src/kmodifierkeyinfo.h PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfo.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_dummy.cpp PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_p.h PRE-CREATION 
  tier1/kwindowsystem/src/kmodifierkeyinfoprovider_x11.cpp PRE-CREATION 
  tier1/kwindowsystem/tests/CMakeLists.txt 5cf5868 
  tier1/kwindowsystem/tests/kmodifierkeyinfotest.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/112913/diff/


Testing
---

compiled


Thanks,

Martin Gräßlin

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

Re: Wrapping up about KI18n and UIC

[Stephen Kelly]

Kevin Ottens wrote:

>> You have enough credibility that people would believe it and spread it,
>> but it is not true. That's not how backward compatibility works in CMake.
> 
> I know, I was more thinking about the natural spreading of new version in
> distros. The time they package stuff and that ends up in released
> versions.

Ah, I misunderstood, sorry.

Thanks,

Steve.


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

Re: Wrapping up about KI18n and UIC

[Kevin Ottens]

On Monday 18 November 2013 12:49:39 Stephen Kelly wrote:
> Stephen Kelly wrote:
> >> It'd need to be released quite a bit before us to
> >> be something we can consider as a dependency. At that point I'm
> >> considering having 2.8.12 as dependency for the release (so that it got
> >> time to spread, sounds less likely with CMake 3).
> >
> > I don't understand. Why is CMake 3 not likely to spread?
>
> My point here was that suggesting with a wink and a nudge that CMake 3.0.0
> is highly likely to have lots of incompatibilities (as I guessed you were
> doing?) and therefore not spread is not appropriate.

Not at all what I was doing. :-)

> You have enough credibility that people would believe it and spread it, but
> it is not true. That's not how backward compatibility works in CMake.

I know, I was more thinking about the natural spreading of new version in
distros. The time they package stuff and that ends up in released versions.

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: Wrapping up about KI18n and UIC

[Aleix Pol]

On Mon, Nov 18, 2013 at 12:50 PM, Stephen Kelly  wrote:

> Kevin Ottens wrote:
> > 10% chance? 50%? 80%?
> >
> > Basically what's the time frame for CMake 3.
>
> I'll be 90% surprised if it is not released in January, or maybe February.
>
> Thanks,
>
> Steve.
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>

So would it be that bad to have a macro of ours that ends up being just a
wrapper to qt5_wrap_ui?

Otherwise, this delays the possibility to help the ongoing porting process
by extending a mandatory dependency on KDE4Support.

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

Re: Wrapping up about KI18n and UIC

[Stephen Kelly]

Kevin Ottens wrote:
> 10% chance? 50%? 80%?
> 
> Basically what's the time frame for CMake 3.

I'll be 90% surprised if it is not released in January, or maybe February.

Thanks,

Steve.


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

Re: Wrapping up about KI18n and UIC

[Stephen Kelly]

Stephen Kelly wrote:

>> It'd need to be released quite a bit before us to
>> be something we can consider as a dependency. At that point I'm
>> considering having 2.8.12 as dependency for the release (so that it got
>> time to spread, sounds less likely with CMake 3).
> 
> I don't understand. Why is CMake 3 not likely to spread?

My point here was that suggesting with a wink and a nudge that CMake 3.0.0 
is highly likely to have lots of incompatibilities (as I guessed you were 
doing?) and therefore not spread is not appropriate. 

You have enough credibility that people would believe it and spread it, but 
it is not true. That's not how backward compatibility works in CMake.

Thanks,

Steve.


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

Build failed in Jenkins: kdelibs_frameworks_qt5 #1696

[KDE CI System]

See 

Changes:

[agateau] Hackish fix for build failure in kde-runtime

--
[...truncated 3943 lines...]
[ 32%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storagevolume.cpp.o
[ 32%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeportablemediaplayer.cpp.o
[ 32%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_server_interface.cpp.o
[ 32%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_serviceresolver_interface.cpp.o
[ 32%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_entrygroup_interface.cpp.o
[ 32%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_domainbrowser_interface.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storageaccess.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/video.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kservicegroupfactory.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/smartcardreader.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/internetgateway.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeprocessor.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakestorage.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakestorageaccess.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakevideo.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kserviceoffer.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kservicetype.cpp.o
[ 33%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_servicebrowser_interface.cpp.o
[ 33%] [ 33%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/avahi_servicetypebrowser_interface.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakevolume.cpp.o
[ 33%] Building CXX object 
tier2/dnssd/src/CMakeFiles/KDNSSD.dir/KDNSSD_automoc.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakeacadapter.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kservicetypefactory.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kservicetypeprofile.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kservicetypetrader.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakesmartcardreader.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakeaudiointerface.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakebattery.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakeblock.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakebutton.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakekeyboard.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/shared/rootdevice.cpp.o
Linking CXX shared library libKDNSSD.so
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/shared/cpufeatures.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/udev/utils.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/ktraderparse.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/ktraderparsetree.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakepointingdevice.cpp.o
[ 33%] Built target KDNSSD
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/fakehw/fakecamera.cpp.o
[ 33%] Building C object 
tier3/kservice/src/CMakeFiles/KService.dir/services/yacc.c.o
[ 33%] Building C object 
tier3/kservice/src/CMakeFiles/KService.dir/services/lex.c.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/services/kplugininfo.cpp.o
[ 33%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/ksycoca.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/udev/udevdevice.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/udev/udevmanager.cpp.o
[ 33%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/udev/udevdeviceinterface.cpp.o
[ 33%] Building CXX object 
t

Re: Wrapping up about KI18n and UIC

[Kevin Ottens]

On Sunday 17 November 2013 18:53:36 Stephen Kelly wrote:
> Kevin Ottens wrote:
> > On Friday 15 November 2013 16:28:10 Stephen Kelly wrote:
> >> Aleix Pol wrote:
> >> > I see that Stephen Kelly has been doing some work on Qt and cmake to
> >> > make it possible to integrate these properly, but also those changes
> >> > will get in cmake 3 and Qt 5.3 which are not among our dependencies.
> >>
> >> CMake 3 will probably be out when releasing KI18n. Only KArchive and
> >> threadweaver are part of the December release.
> >
> > "Probably" as in what?
>
> I don't understand the question.

10% chance? 50%? 80%?

Basically what's the time frame for CMake 3.

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

Jenkins build is back to normal : plasma-framework_master_qt5 #906

[KDE CI System]

See 

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

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

[Martin Gräßlin]

> On Nov. 15, 2013, 8:42 p.m., Kevin Ottens wrote:
> > tier3/kconfigwidgets/src/kcolorschememanager.cpp, line 124
> > 
> >
> > Would make sense to change the lambda so that you'd pass 16 and 24 
> > instead. It feels kinda weird otherwise. :-)
> > 
> > You can still do (size / 2) - 1 in the lambda to prepare for the 
> > fillRect calls.
> 
> Albert Astals Cid wrote:
> What about the color palettes vs theme colors issue?
> 
> Martin Gräßlin wrote:
> There is no issue at all about color palettes vs theme colors. It's just 
> the color schemes it operates on.
> 
> Albert Astals Cid wrote:
> So you're saying Boud's and Christoph comments are wrong?

not at all. That are two different beast which just have the same file ending. 
The palettes are installed to **/colors/, the color-schemes to 
**/color-schemes/. This class only looks for files in color-schemes/, so that 
the palettes have the same file ending doesn't matter.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43755
---


On Nov. 18, 2013, 9:44 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113685/
> ---
> 
> (Updated Nov. 18, 2013, 9:44 a.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and 
> Boudewijn Rempt.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This class is inspired by functionality offered by e.g. Krita and
> Digikam to allow the user to select a different color scheme for the
> application.
> 
> This manager simplifies this task and also ensures that the required
> property on QApplication is set, so that a QStyle can pass the scheme
> to the window manager/compositor for the windows of the application.
> 
> @boud and @cgilles: please have a look whether this approach is sufficient 
> for your usecases in digkam and Krita.
> 
> 
> Diffs
> -
> 
>   tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 
>   tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION 
>   tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 
> 
> Diff: http://git.reviewboard.kde.org/r/113685/diff/
> 
> 
> Testing
> ---
> 
> see demo application
> 
> 
> 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 113685: New KColorSchemeManager to support changing color scheme in app

[Boudewijn Rempt]

On Monday 18 November 2013 Nov 09:17:07 Albert Astals Cid wrote:
> 
> So you're saying Boud's and Christoph comments are wrong?
> 

My comment was meant to convey that color palettes have nothing to do with this 
patch -- they're a red herring here.
-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

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

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

[Albert Astals Cid]

> On Nov. 15, 2013, 7:42 p.m., Kevin Ottens wrote:
> > tier3/kconfigwidgets/src/kcolorschememanager.cpp, line 124
> > 
> >
> > Would make sense to change the lambda so that you'd pass 16 and 24 
> > instead. It feels kinda weird otherwise. :-)
> > 
> > You can still do (size / 2) - 1 in the lambda to prepare for the 
> > fillRect calls.
> 
> Albert Astals Cid wrote:
> What about the color palettes vs theme colors issue?
> 
> Martin Gräßlin wrote:
> There is no issue at all about color palettes vs theme colors. It's just 
> the color schemes it operates on.

So you're saying Boud's and Christoph comments are wrong?


- Albert


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43755
---


On Nov. 18, 2013, 8:44 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113685/
> ---
> 
> (Updated Nov. 18, 2013, 8:44 a.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and 
> Boudewijn Rempt.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This class is inspired by functionality offered by e.g. Krita and
> Digikam to allow the user to select a different color scheme for the
> application.
> 
> This manager simplifies this task and also ensures that the required
> property on QApplication is set, so that a QStyle can pass the scheme
> to the window manager/compositor for the windows of the application.
> 
> @boud and @cgilles: please have a look whether this approach is sufficient 
> for your usecases in digkam and Krita.
> 
> 
> Diffs
> -
> 
>   tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 
>   tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION 
>   tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 
> 
> Diff: http://git.reviewboard.kde.org/r/113685/diff/
> 
> 
> Testing
> ---
> 
> see demo application
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Build failed in Jenkins: kdelibs_frameworks_qt5 #1695

[KDE CI System]

See 

Changes:

[mgraesslin] Reimplement KXUtils::createPixmapFromHandle with XCB

--
[...truncated 3844 lines...]
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halblock.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halbutton.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/udev/udevbutton.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/udev/udevkeyboard.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halcamera.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halcdrom.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/udev/udevpointingdevice.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/shared/udevqtclient.cpp.o
Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/kmemfile.cpp.o
[ 36%] [ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/shared/udevqtdevice.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/haldeviceinterface.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/haldvbinterface.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halfstabhandling.cpp.o
[ 36%] [ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halacadapter.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halaudiointerface.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halgenericinterface.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halbattery.cpp.o
[ 36%] [ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halblock.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/haldevice.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halbutton.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halmanager.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halnetworkinterface.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halserialinterface.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halcamera.cpp.o
[ 36%] [ 36%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/klibrary.cpp.o
Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kpluginfactory.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halopticaldisc.cpp.o
[ 36%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kpluginloader.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halcdrom.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/haldeviceinterface.cpp.o
[ 36%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kplugintrader.cpp.o
[ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/haldvbinterface.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halportablemediaplayer.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halfstabhandling.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halprocessor.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/halgenericinterface.cpp.o
[ 36%] [ 36%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halstorageaccess.cpp.o
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/backends/hal/haldevice.cpp.o
[ 36%] 
:
 In member function ‘KPluginFactory* KPluginLoader::factory()’:
:222:48:
 warning: ‘KPluginFactory* KLibrary::factory(const char*)’ is deprecated 
(declared at 
:58)
 [-Wdeprecated-declarations]
Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halstorage.cpp.o
[ 37%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/hal/halvideo.cpp.o
[ 37%] Building CXX object 
tier1/solid/src/solid/CMake

Build failed in Jenkins: kdelibs_frameworks_qt5 #1694

[KDE CI System]

See 

--
[...truncated 4642 lines...]
Scanning dependencies of target kdirwatchtest_gui
[ 41%] Building CXX object 
tier1/kcoreaddons/tests/CMakeFiles/kdirwatchtest_gui.dir/kdirwatchtest_gui.cpp.o
Scanning dependencies of target fixx11h_test
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/fixx11h_test.dir/fixx11h_test.cpp.o
Linking CXX executable kaboutdatatest
[ 41%] Built target kstringhandlertest
[ 41%] Scanning dependencies of target fixx11h_test2
Building CXX object 
tier1/kcoreaddons/tests/CMakeFiles/kdirwatchtest_gui.dir/kdirwatchtest_gui_automoc.cpp.o
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/fixx11h_test2.dir/fixx11h_test2.cpp.o
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/fixx11h_test.dir/fixx11h_test_automoc.cpp.o
[ 41%] Built target kcompositejobtest
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/fixx11h_test2.dir/fixx11h_test2_automoc.cpp.o
Linking CXX executable fixx11h_test
[ 41%] Built target kurlmimedatatest
Linking CXX executable fixx11h_test2
Scanning dependencies of target kstartupinfo_unittest
[ 41%] [ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kstartupinfo_unittest.dir/kstartupinfo_unittest.cpp.o
Built target kaboutdatatest
Scanning dependencies of target kmanagerselectiontest
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kmanagerselectiontest.dir/kmanagerselectiontest.cpp.o
Scanning dependencies of target kwindoweffectstest
[ 41%] Linking CXX executable kdirwatchtest_gui
Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kwindoweffectstest.dir/kwindoweffectstest.cpp.o
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kstartupinfo_unittest.dir/kstartupinfo_unittest_automoc.cpp.o
Linking CXX executable kstartupinfo_unittest
[ 41%] Built target fixx11h_test
[ 41%] [ 41%] Built target fixx11h_test2
[ 41%] Scanning dependencies of target kxmessages_unittest
Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kwindoweffectstest.dir/kwindoweffectstest_automoc.cpp.o
Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kmanagerselectiontest.dir/kmanagerselectiontest_automoc.cpp.o
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kxmessages_unittest.dir/kxmessages_unittest.cpp.o
Linking CXX executable kwindoweffectstest
[ 41%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kxmessages_unittest.dir/kxmessages_unittest_automoc.cpp.o
Linking CXX executable kmanagerselectiontest
[ 41%] Built target kdirwatchtest_gui
[ 41%] Scanning dependencies of target setmainwindowtest
Generating opcodes.h, opcodes.cpp, machine.cpp
[ 41%] Building CXX object 
tier1/kwindowsystem/tests/CMakeFiles/setmainwindowtest.dir/setmainwindowtest.cpp.o
icemaker -41.9 for KJS/FrostByte
Generating bytecode instruction selection tables and VM dispatcher...
[ 41%] [ 41%] Built target kstartupinfo_unittest
Generating date_object.lut.h
Linking CXX executable kxmessages_unittest
[ 41%] Built target kwindoweffectstest
[ 41%] Generating number_object.lut.h
Scanning dependencies of target KAuth
[ 41%] [ 41%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthaction.cpp.o
Building CXX object tier2/kauth/src/CMakeFiles/KAuth.dir/kauthactionreply.cpp.o
[ 41%] Generating string_object.lut.h
[ 41%] Building CXX object 
tier1/kwindowsystem/tests/CMakeFiles/setmainwindowtest.dir/setmainwindowtest_automoc.cpp.o
[ 41%] Built target kmanagerselectiontest
[ 41%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthexecutejob.cpp.o
Linking CXX executable setmainwindowtest
[ 41%] Generating array_object.lut.h
[ 41%] Generating math_object.lut.h
[ 41%] Generating json_object.lut.h
[ 41%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthobjectdecorator.cpp.o
[ 41%] Generating regexp_object.lut.h
[ 41%] Generating authadaptor.cpp, authadaptor.h
[ 41%] Built target kxmessages_unittest
[ 41%] Generating authadaptor.moc
[ 41%] [ 41%] Generating lexer.lut.h
Built target setmainwindowtest
[ 41%] [ 41%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/AuthBackend.cpp.o
Scanning dependencies of target KCrash
Building CXX object tier2/kauth/src/CMakeFiles/KAuth.dir/BackendsManager.cpp.o
[ 41%] [ 41%] Building CXX object 
tier2/kcrash/src/CMakeFiles/KCrash.dir/kcrash.cpp.o
Generating jobviewifacev2.cpp, jobviewifacev2.h
[ 41%] Generating jobviewserverinterface.cpp, jobviewserverinterface.h
Scanning dependencies of target kauth_tests_static
[ 41%] Building CXX object 
tier2/kauth/autotests/CMakeFiles/kauth_tests_static.dir/__/src/kauthaction.cpp.o
[ 41%] Generating jobviewiface.cpp, jobviewiface.h
[ 41%] [ 41%] Generating jobviewserverinterface.moc
Generating jobviewifacev2.moc
[ 41%] [ 41%] Generating jobviewiface.moc
Building CXX object tier2/kauth/src/CMakeFiles/KAuth.dir/HelperProxy.cpp.o
Scanning 

Re: Review Request 112755: Reimplement KXUtils::createPixmapFromHandle with XCB

[Martin Gräßlin]

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

(Updated Nov. 18, 2013, 8:58 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kdelibs


Description
---

Implements the createPixmapFromHandle by getting the image for the pixmaps and 
using it as either the Pixmap or the bitmap mask.


Diffs
-

  tier1/kwindowsystem/src/kxutils.cpp 33bd678 
  tier1/kwindowsystem/src/kxutils_p.h 84d639b 
  tier1/kwindowsystem/tests/CMakeLists.txt 0060903 
  tier1/kwindowsystem/tests/createpixmapfromhandletest.cpp PRE-CREATION 

Diff: http://git.reviewboard.kde.org/r/112755/diff/


Testing
---

Adjusted KWin to take this codepath and say thanks to Iceweasel for having a 
mask


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 112755: Reimplement KXUtils::createPixmapFromHandle with XCB

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112755/#review43873
---


This review has been submitted with commit 
b025c4be103313b59a9c37ec9cc907a245df293b by Martin Gräßlin to branch frameworks.

- Commit Hook


On Nov. 6, 2013, 6:28 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112755/
> ---
> 
> (Updated Nov. 6, 2013, 6:28 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Implements the createPixmapFromHandle by getting the image for the pixmaps 
> and using it as either the Pixmap or the bitmap mask.
> 
> 
> Diffs
> -
> 
>   tier1/kwindowsystem/src/kxutils.cpp 33bd678 
>   tier1/kwindowsystem/src/kxutils_p.h 84d639b 
>   tier1/kwindowsystem/tests/CMakeLists.txt 0060903 
>   tier1/kwindowsystem/tests/createpixmapfromhandletest.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112755/diff/
> 
> 
> Testing
> ---
> 
> Adjusted KWin to take this codepath and say thanks to Iceweasel for having a 
> mask
> 
> 
> 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 113685: New KColorSchemeManager to support changing color scheme in app

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113685/#review43872
---


This review has been submitted with commit 
1bfaf65b70e077d72c0537734e7c49c74e2ebf4e by Martin Gräßlin to branch frameworks.

- Commit Hook


On Nov. 14, 2013, 5:50 a.m., Martin Gräßlin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113685/
> ---
> 
> (Updated Nov. 14, 2013, 5:50 a.m.)
> 
> 
> Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and 
> Boudewijn Rempt.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> This class is inspired by functionality offered by e.g. Krita and
> Digikam to allow the user to select a different color scheme for the
> application.
> 
> This manager simplifies this task and also ensures that the required
> property on QApplication is set, so that a QStyle can pass the scheme
> to the window manager/compositor for the windows of the application.
> 
> @boud and @cgilles: please have a look whether this approach is sufficient 
> for your usecases in digkam and Krita.
> 
> 
> Diffs
> -
> 
>   tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 
>   tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION 
>   tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION 
>   tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 
> 
> Diff: http://git.reviewboard.kde.org/r/113685/diff/
> 
> 
> Testing
> ---
> 
> see demo application
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

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

Build failed in Jenkins: kdelibs_frameworks_qt5 #1693

[KDE CI System]

See 

Changes:

[mgraesslin] New KColorSchemeManager to support changing color scheme in app

--
[...truncated 4763 lines...]
[ 48%] Built target fixx11h_test
[ 48%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kwindoweffectstest.dir/kwindoweffectstest_automoc.cpp.o
[ 48%] Built target fixx11h_test2
Scanning dependencies of target kxmessages_unittest
[ 48%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kxmessages_unittest.dir/kxmessages_unittest.cpp.o
Linking CXX executable kurlmimedatatest
Scanning dependencies of target setmainwindowtest
[ 48%] Building CXX object 
tier1/kwindowsystem/tests/CMakeFiles/setmainwindowtest.dir/setmainwindowtest.cpp.o
[ 48%] [ 48%] Built target kurlmimedatatest
[ 48%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kstartupinfo_unittest.dir/kstartupinfo_unittest_automoc.cpp.o
Generating opcodes.h, opcodes.cpp, machine.cpp
icemaker -41.9 for KJS/FrostByte
Generating bytecode instruction selection tables and VM dispatcher...
[ 48%] Generating date_object.lut.h
Scanning dependencies of target KAuth
[ 48%] [ 48%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthaction.cpp.o
Generating number_object.lut.h
[ 48%] Generating string_object.lut.h
Linking CXX executable kdirwatchtest_gui
[ 48%] Generating array_object.lut.h
[ 48%] Built target kdirwatchtest_gui
[ 48%] [ 48%] Generating math_object.lut.h
Building CXX object tier2/kauth/src/CMakeFiles/KAuth.dir/kauthactionreply.cpp.o
[ 48%] Generating json_object.lut.h
[ 48%] Generating regexp_object.lut.h
[ 48%] Generating authadaptor.cpp, authadaptor.h
[ 48%] Generating lexer.lut.h
[ 48%] Generating authadaptor.moc
[ 48%] Building CXX object 
tier1/kwindowsystem/tests/CMakeFiles/setmainwindowtest.dir/setmainwindowtest_automoc.cpp.o
Linking CXX executable kstartupinfo_unittest
Scanning dependencies of target KJS
Scanning dependencies of target kauth_tests_static
[ 48%] [ 48%] Building CXX object 
tier2/kauth/autotests/CMakeFiles/kauth_tests_static.dir/__/src/kauthaction.cpp.o
Building CXX object tier1/kjs/src/kjs/CMakeFiles/KJS.dir/ustring.cpp.o
[ 48%] Building CXX object 
tier1/kjs/src/kjs/CMakeFiles/KJS.dir/date_object.cpp.o
Linking CXX executable setmainwindowtest
[ 48%] Built target kstartupinfo_unittest
[ 48%] Building CXX object 
tier2/kauth/autotests/CMakeFiles/kauth_tests_static.dir/__/src/kauthactionreply.cpp.o
[ 48%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthexecutejob.cpp.o
[ 48%] Built target setmainwindowtest
Scanning dependencies of target KCrash
Linking CXX executable kmanagerselectiontest
[ 48%] Building CXX object tier2/kcrash/src/CMakeFiles/KCrash.dir/kcrash.cpp.o
[ 48%] Building CXX object 
tier1/kwindowsystem/autotests/CMakeFiles/kxmessages_unittest.dir/kxmessages_unittest_automoc.cpp.o
Linking CXX executable kxmessages_unittest
[ 48%] Built target kmanagerselectiontest
[ 48%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/kauthobjectdecorator.cpp.o
Linking CXX executable kwindoweffectstest
[ 48%] Built target kxmessages_unittest
[ 48%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/AuthBackend.cpp.o
[ 48%] Built target kwindoweffectstest
[ 48%] Building CXX object 
tier2/kauth/src/CMakeFiles/KAuth.dir/BackendsManager.cpp.o
[ 48%] Building C object tier2/kcrash/src/CMakeFiles/KCrash.dir/strlcpy-fake.c.o
[ 48%] [ 48%] Generating jobviewifacev2.cpp, jobviewifacev2.h
Building CXX object tier2/kcrash/src/CMakeFiles/KCrash.dir/KCrash_automoc.cpp.o
[ 48%] [ 48%] Generating notifications_interface.cpp, notifications_interface.h
Generating jobviewserverinterface.cpp, jobviewserverinterface.h
[ 48%] Generating jobviewiface.cpp, jobviewiface.h
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName.In6' found; 
suggest updating to 'org.qtproject.QtDBus.QtTypeName.In6'
[ 48%] [ 48%] Generating jobviewserverinterface.moc
[ 48%] Generating knotify_interface.cpp, knotify_interface.h
Generating jobviewiface.moc
[ 48%] Generating jobviewifacev2.moc
[ 48%] Generating statusnotifieritemadaptor.cpp, statusnotifieritemadaptor.h
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName' found; suggest 
updating to 'org.qtproject.QtDBus.QtTypeName'
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName' found; suggest 
updating to 'org.qtproject.QtDBus.QtTypeName'
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName' found; suggest 
updating to 'org.qtproject.QtDBus.QtTypeName'
Warning: deprecated annotation 'com.trolltech.QtDBus.QtTypeName' found; suggest 
updating to 'org.qtproject.QtDBus.QtTypeName'
[ 48%] Generating statusnotifierwatcher_interface.cpp, 
statusnotifierwatcher_interface.h
[ 48%] Scanning dependencies of target KCompletion
[ 48%] Building CXX object tier1/kjs/src/kjs/CMakeFiles/KJS.dir/collector.cpp.o
Generating knotify_interface.moc
[ 48%] Generating statusnotifieritemadaptor.moc
[ 48

Re: Review Request 113685: New KColorSchemeManager to support changing color scheme in app

[Martin Gräßlin]

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

(Updated Nov. 18, 2013, 8:44 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Albert Astals Cid, Gilles Caulier, and 
Boudewijn Rempt.


Repository: kdelibs


Description
---

This class is inspired by functionality offered by e.g. Krita and
Digikam to allow the user to select a different color scheme for the
application.

This manager simplifies this task and also ensures that the required
property on QApplication is set, so that a QStyle can pass the scheme
to the window manager/compositor for the windows of the application.

@boud and @cgilles: please have a look whether this approach is sufficient for 
your usecases in digkam and Krita.


Diffs
-

  tier3/kconfigwidgets/tests/kcolorschemedemo.cpp PRE-CREATION 
  tier3/kconfigwidgets/src/CMakeLists.txt 36ffca8 
  tier3/kconfigwidgets/src/kcolorschememanager.h PRE-CREATION 
  tier3/kconfigwidgets/src/kcolorschememanager.cpp PRE-CREATION 
  tier3/kconfigwidgets/src/kcolorschememanager_p.h PRE-CREATION 
  tier3/kconfigwidgets/tests/CMakeLists.txt f66dc32 

Diff: http://git.reviewboard.kde.org/r/113685/diff/


Testing
---

see demo application


Thanks,

Martin Gräßlin

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

Build failed in Jenkins: kdelibs_frameworks_qt5 #1692

[KDE CI System]

See 

Changes:

[steveire] Add missing file.

--
[...truncated 3843 lines...]
[ 24%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/ksycocadict.cpp.o
[ 25%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/ksycocaentry.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/opticaldisc.cpp.o
[ 25%] Built target KDNSSD
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/opticaldisc.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/portablemediaplayer.cpp.o
[ 25%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/ksycocafactory.cpp.o
:
 In static member function ‘static QList 
KPluginInfo::fromServices(const List&, const KConfigGroup&)’:
:234:29:
 warning: ‘KPluginInfo::KPluginInfo(KService::Ptr)’ is deprecated (declared at 
:137)
 [-Wdeprecated-declarations]
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/portablemediaplayer.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/processor.cpp.o
[ 25%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/sycoca/kmemfile.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/processor.cpp.o
[ 25%] [ 25%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kpluginfactory.cpp.o
Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/klibrary.cpp.o
[ 25%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kpluginloader.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storagedrive.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storagevolume.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storageaccess.cpp.o
[ 25%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/video.cpp.o
[ 26%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storagedrive.cpp.o
:
 In member function ‘virtual QObject* KPluginFactory::create(const char*, 
QWidget*, QObject*, const QVariantList&, const QString&)’:
:138:114:
 warning: ‘virtual KParts::Part* KPluginFactory::createPartObject(QWidget*, 
QObject*, const char*, const QStringList&)’ is deprecated (declared at 
:112)
 [-Wdeprecated-declarations]
:143:62:
 warning: ‘virtual QObject* KPluginFactory::createObject(QObject*, const char*, 
const QStringList&)’ is deprecated (declared at 
:102)
 [-Wdeprecated-declarations]
[ 26%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/smartcardreader.cpp.o
[ 26%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/internetgateway.cpp.o
[ 26%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storagevolume.cpp.o
[ 26%] Building CXX object 
tier3/kservice/src/CMakeFiles/KService.dir/plugin/kplugintrader.cpp.o
:
 In member function ‘KPluginFactory* KPluginLoader::factory()’:
:222:48:
 warning: ‘KPluginFactory* KLibrary::factory(const char*)’ is deprecated 
(declared at 
:58)
 [-Wdeprecated-declarations]
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeacadapter.cpp.o
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storageaccess.cpp.o
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeaudiointerface.cpp.o
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/video.cpp.o
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakebattery.cpp.o
[ 27%] Building CXX object 
tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeblock.cpp.o
[ 27

Re: Wrapping up about KI18n and UIC

[Stephen Kelly]

Chusslove Illich wrote:

>> [: Stephen Kelly :]
>> If such calls are generated by uic, then that is a bug in Qt (which
>> should have been reported years ago), and should be fixed in Qt, right?
> 
> Maybe, I'm not sure of the conventions of Qt Linguist.

I created a .ui file with a QLabel with an empty text property. I ran uic on 
the file and it generated

void retranslateUi(QWidget *Form)
{
Form->setWindowTitle(QApplication::translate("Form", "Form", 0));
label->setText(QString());
}

Unless you have a counter-example, I suggest that uic may have had a bug in 
the past regarding empty strings. That bug was apparently not reported by 
KDE, but it now no longer exists.

>> How would anyone know what to define it to? You said before it is not
>> always the target name. How would someone know whether to make it the
>> target name or not?
> 
> The programmer picks the translation domain name however desired (only it
> must not match any other translation domain anywhere in the world; just
> like an executable name). For a small application named with single
> pure-ASCII word, for example, it is typically chosen as the all-lowercase
> name of the application. The programmer may choose to have any number of
> translation domains, covering different parts of the code, depending on
> its size and organization.

Ok, why would someone using KI18n choose a translation domain which is not 
the lowercased target name? Can't we make that the default, and provide a 
way to override it (if really necessary)?

>> When should semantic markup be used or not? I mean, how would someone
>> using the macro know whether to specify that tr2i18n or tr2xi18n should
>> be used?
> 
> The programmer decides whether to use semantic markup or not, based on
> personal convenience and aesthetics. The default should be no semantic
> markup (tr2i18n), hence the flag type argument to activate it if desired.

I suggest a patch something like this:

diff --git a/tier2/ki18n/KI18nConfig.cmake.in 
b/tier2/ki18n/KI18nConfig.cmake.in
index 8f31c27..83632be 100644
--- a/tier2/ki18n/KI18nConfig.cmake.in
+++ b/tier2/ki18n/KI18nConfig.cmake.in
@@ -5,3 +5,14 @@ find_dependency(KJS "@KF5_VERSION@")
 
 include("${CMAKE_CURRENT_LIST_DIR}/KI18nTargets.cmake")
 
+set(autouic_options
+  -include klocalizedstring.h
+  -tr tr2$<$>:x>i18n
+)
+set_property(TARGET KF5::KI18n APPEND PROPERTY INTERFACE_AUTOUIC_OPTIONS 
"${autouic_options}")
+set(domain_logic
+  $<$>:
$>$>:$>>>
+)
+set_property(TARGET KF5::KI18n APPEND PROPERTY 
INTERFACE_COMPILE_DEFINITIONS "-DTRANSLATION_DOMAIN=${domain_logic}")
+unset(autouic_options)
+unset(domain_logic)

 
That way, the uic options are a 'usage requirement'. See my recent blog post 
for more background on usage requirements:

 http://www.kdab.com/modern-cmake-with-qt-and-boost/

Anyone using AUTOUIC and linking transitively with KF5::KI18n will 
automatically invoke uic with the -include and with the appropriate -tr 
function. The downstream can choose to use tr2i18n by setting the 
NO_KUIT_SEMANTIC target property.

 set_property(TARGET gwenview PROPERTY NO_KUIT_SEMANTIC TRUE)

You can wrap that in a macro if you wish. The default is to use KUIT.

The translation domain is the target name, transformed into a C identifier 
and lowercased, by default. The user can override that by setting the 

 set_property(TARGET konsole PROPERTY TRANSLATION_DOMAIN kdekonsole)

You can wrap that in a macro if you wish. 

This depends on Qt 5.3 and CMake master plus some trivial new generator 
expressions. Aside from bikeshedding names of things and defaults, can you 
see any problem with this?

Thanks,

Steve.


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