Re: Wrapping up about KI18n and UIC
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: Wrapping up about KI18n and UIC
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 :] >> [...] 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
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
> [: 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
>> [: 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: Wrapping up about KI18n and UIC
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: Wrapping up about KI18n and UIC
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
Re: Wrapping up about KI18n and UIC
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
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: Wrapping up about KI18n and UIC
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
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
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
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 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
Re: Wrapping up about KI18n and UIC
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
Re: Wrapping up about KI18n and UIC
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
Re: Wrapping up about KI18n and UIC
> [: 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. For Gettext-based system, empty string will not result in empty translation, but in the complete PO header, which is almost never intended. Certainly never within an UI file. > 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. > 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. (Of course, everywhere above "the programmer" can be replaced with "the maintainer" or "the developer consensus".) -- 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
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. > 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? 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 wrote:
>> [: Aleix Pol :]
>> I have been going through the list looking for what we should we do when
>> it comes to .ui file generation and i18n.
>
> I am confused by that too. Stephen's projected solution seems to me more
> elegant in principle, but I couldn't quite get if (when) it would be able
> to do all that is necessary.
Right. My solution makes the need for the current macro disappear, AFAICT.
> * Make sure no empty-string calls appear, namely tr2i18n(""),
> tr2i18n("", ""), tr2xi18n(""), tr2xi18n("", "")). I don't know if this
> still needs post-generation search-replace or not.
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?
> * Define TRANSLATION_DOMAIN if requested (for library code). I meant this
> to be an optional argument to the macro, but it could be done on the
> higher level with add_definitions(-DTRANSLATION_DOMAIN=...). No idea which
> is better.
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?
>
> * Select whether strings use ki18n semantic markup or not. I meant this to
> be controlled through an optional flag-type argument to the macro, named
> KUIT. If missing, uic would get -tr tr2i18n, and if present -tr tr2xi18n.
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?
> I would name the macro ki18n_qt_wrap_ui, because it is essentially a
> wrapper for qt_wrap_ui.
It should be obsoleted with CMAKE_AUTOUIC and a usage requirement instead.
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
> [: Aleix Pol :]
> I have been going through the list looking for what we should we do when
> it comes to .ui file generation and i18n.
I am confused by that too. Stephen's projected solution seems to me more
elegant in principle, but I couldn't quite get if (when) it would be able to
do all that is necessary.
> I'd suggest to revive jeremy's patch and adapting it to KF5 [1], I could
> help with that, but I'd like to know first if we agree that it's the best
> solution he have at the moment.
For this solution I would have the following points.
There is no need for separate ki18nuic.cmake file. Jeremy took this from KDE
4, but for this purpose that does more than necessary. The whole macro
should be located in KI18NMacros.cmake, and do only this on generated files:
* Make sure no empty-string calls appear, namely tr2i18n(""),
tr2i18n("", ""), tr2xi18n(""), tr2xi18n("", "")). I don't know if this still
needs post-generation search-replace or not.
* Include klocalizedstring.h.
* Define TRANSLATION_DOMAIN if requested (for library code). I meant this to
be an optional argument to the macro, but it could be done on the higher
level with add_definitions(-DTRANSLATION_DOMAIN=...). No idea which is
better.
* Select whether strings use ki18n semantic markup or not. I meant this to
be controlled through an optional flag-type argument to the macro, named
KUIT. If missing, uic would get -tr tr2i18n, and if present -tr tr2xi18n.
I would name the macro ki18n_qt_wrap_ui, because it is essentially a wrapper
for 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: Wrapping up about KI18n and UIC
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? 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). 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 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. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Wrapping up about KI18n and UIC
Hi, I have been going through the list looking for what we should we do when it comes to .ui file generation and i18n. 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. I'd suggest to revive jeremy's patch and adapting it to KF5 [1], I could help with that, but I'd like to know first if we agree that it's the best solution he have at the moment. When we get to all the features offered by Kelly's patches, we can just reduce the amount of code that it's calling and even deprecate it. Aleix [1] http://git.reviewboard.kde.org/r/112785/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
