D8351: API dox: add note about calling setApplicationDomain after QApp creation

Friedrich W. H. Kossebau noreply at phabricator.kde.org
Tue Feb 6 13:51:47 UTC 2018


kossebau added a comment.


  In https://phabricator.kde.org/D8351#161562, @ilic wrote:
  
  > Well... it's a tough situation. It is not by design that `i18n` calls should in any way depend on creation of `QApplication`, and also any library may place an `i18n` call before the main program creates `QApplication`. The only solution I see is that environment is rechecked at every `i18n` call. This would be easy to do (just replacing every `s->languages` with a newly implemented `s->getLanguages()`), but I've no idea what would be the performance hit of that.
  
  
  Thanks for reply, @ilic, sorry for not having picked up immediately, as I agree it's tough and I set the topic aside a little to have some thoughts develop in the back of my mind.
  
  One problem that i see with rechecking the environment at every i18n call is that this potentially could result in inconsistent UI. Because the average applications using KI18n is not written to support switching UI localization on the fly. Incl. KXMLGUI's language switching support, which only injects its settings at a roughly defined point in time, as part of the post-handlers of the Q*App instance creation.
  
  So I would agree with @dfaure that for the current KI18n usage (which is somewhat coupled with KXMLGUI's language switching support) we should just stick formally to what technically is needed right now: only doing UI locale-based things after the Q*App instance is created and thus after everything related to localization is setup and prepared (and will stay to the end of the Q*App instance lifetime.
  
  So would push this change upcoming WE, Feb 10/11, finally, unless someone objects.
  
  ((In time for Qt6/KF6 we should perhaps revisit this and hopefully have some people work on adding proper infrastructure and usage patterns to allow such switching UI localization on the fly. It's pretty sad that Web apps, which are younger, are better here))

REPOSITORY
  R249 KI18n

BRANCH
  addNoteAboutCallingSetAppDomainAfterQApp

REVISION DETAIL
  https://phabricator.kde.org/D8351

To: kossebau, #frameworks, ilic, ltoscano, dfaure
Cc: dfaure, michaelh, ngraham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180206/528d07ca/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list