Review Request 112785: Add ki18n_wrap_ui macro to ki18nMacros
Chusslove Illich
caslav.ilic at gmx.net
Mon Oct 14 12:20:27 UTC 2013
> On Sept. 23, 2013, 12:37 p.m., Kevin Ottens wrote:
> > I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least partly.
>
> Jeremy Whiting wrote:
> well, qt5_wrap_ui wasn't around when this was created (as kde4_add_ui_files iirc). All I did was copy it and rename it. didn't look into making it use qt5_wrap_ui.
>
> Kevin Ottens wrote:
> Could you please look into it?
>
> Chusslove Illich wrote:
> This is why I asked Jeremy in the other review, that motivated this one, to
> commit using the plain qt5_wrap_ui, until I get to doing the proper thing
> for k18n_wrap_ui.
>
> Yes, in spirit k18n_wrap_ui should be a wrapper for qt5_wrap_ui, and thus I
> would call it k18n_qt5_wrap_ui. If uic would have some additional command
> line options, k18n_wrap_ui would internally really be a wrapper for
> qt5_wrap_ui; but without these options, it may end up just copying the code
> (little as there is) from qt5_wrap_ui and adding its own stuff atop.
> k18n_qt5_wrap_ui must also have its own macro options to support the new/
> modified ki18n functionality (namely setting the translation domain and
> activating the KUIT markup processing).
>
>
> Jeremy Whiting wrote:
> Ok, I'll leave this alone for now, and just #include <klocalizedstring.h> where we were depending on that being added to the ui_*.h files before.
>
> Kevin Ottens wrote:
> Is this patch abandoned or it'll see another revision soon?
>
> Chusslove Illich wrote:
> It should see another revision soon, from me. Or maybe that should be
> another review (different submitter)? The topic is the same...
>
> Stephen Kelly wrote:
> Actually, uic should get a command line option to add an include.
>
> Then no macro will be needed at all (with the next CMake release - CMake 3.0)
>
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6368bd717e1cee3b947667ea0eaee78f187a2b3b
>
> All that would be needed is
>
> set(CMAKE_AUTOUIC_OPTIONS -tr i18n -include klocalizedstring.h)
>
> in KI18nConfig.cmake.
>
> Aleix Pol Gonzalez wrote:
> Well, we certainly don't want on /all/ calls to uic. When uic is used with projects that don't use ki18n, this shouldn't be applied.
>
> Stephen Kelly wrote:
> Projects which use KI18nConfig.cmake do though, yesno?
>
> Maybe we can encode it into the KF5::KI18n target instead though. That would be a much better solution.
>
>
>
> Chusslove Illich wrote:
> Another needed option to uic is to define a macro, for setting
> TRANSLATION_DOMAIN in library code. Then, it must be possible to set whether
> ordinary or KUIT markup calls are used, i.e. whether -tr tr2i18n or
> -tr tr2xi18n. So I intended that k18n_qt5_wrap_ui looks something like:
>
> ki18n_qt5_wrap_ui(outfilevar [DOMAIN <domain>] [KUIT] uifiles...)
>
> and internally call uic with proper options. For example:
>
> ki18n_qt5_wrap_ui(foolib_SRCS DOMAIN "foolib" KUIT
> fooconfig.ui
> foo.ui
> ...
> )
>
> Before uic gets these options, ki18n_qt5_wrap_ui would internally do what
> qt5_wrap_ui does plus the makeshift stuff to do the rest (as in KDE 4).
>
>
> Stephen Kelly wrote:
>
> > Another needed option to uic is to define a macro, for setting
> > TRANSLATION_DOMAIN in library code.
>
> Assuming you mean a preprocessor macro, that can be set from CMake as a -D, right?
>
> I think it would be easier to get the -include in than the -domain, so that should be aimed for separately and first.
>
> Chusslove Illich wrote:
> Right, a preprocessor macro. And I meant setting it by implementing the
> -define option in uic, rather than the more specific -domain.
>
> But how to set all this information is just a matter of convenience. If
> add_definitions plus qt5_wrap_ui with explicit -tr option (and -include
> unless CMAKE_AUTOUIC_OPTIONS is used) is deemed good enough, then
> ki18n_qt5_wrap_ui is not needed indeed.
>
>
> Stephen Kelly wrote:
>
> > But how to set all this information is just a matter of convenience. If
> > add_definitions plus qt5_wrap_ui
>
> That would also not be needed. The required options to uic would be used simply by linking to KI18n.
>
So, one must be able to set two things. Add the TRANSLATION_DOMAIN macro;
this can be done by add_definitions. Choose whether -tr tr2i18n or
-tr tr2xi18n is issued to uic; how can this be done?
- Chusslove
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112785/#review40518
-----------------------------------------------------------
On Sept. 17, 2013, 9: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, 9: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131014/14407f3e/attachment.html>
More information about the Kde-frameworks-devel
mailing list