Re: Helping libraries load their own translation catalogs
A Diumenge, 28 de novembre de 2010, Albert Astals Cid va escriure: A Diumenge, 28 de novembre de 2010, Ivan Cukic va escriure: On Monday, 22. November 2010. 19.05.45 Albert Astals Cid wrote: A Dilluns, 22 de novembre de 2010, David Faure va escriure: On Sunday 21 November 2010, Oswald Buddenhagen wrote: On Sun, Nov 21, 2010 at 12:46:53AM +, Albert Astals Cid wrote: It achieves that by creating a static that instructs KGlobal to load a given translation catalog on global locale creation. Just to note that this fails for catalogs that have a dash in their name Wops, that's too bad. Unless someone with more knowledge than me is able to fix my macro i'm suggesting the attached patch. It breaks current users of K_CATALOG_LOADER, but according lxr.kde.org there is none at the moment so it's not a big deal i guess :D Comments? I've commited my change. Albert Albert Cheerio
Re: Re: Helping libraries load their own translation catalogs
On Monday, 22. November 2010. 19.05.45 Albert Astals Cid wrote: A Dilluns, 22 de novembre de 2010, David Faure va escriure: On Sunday 21 November 2010, Oswald Buddenhagen wrote: On Sun, Nov 21, 2010 at 12:46:53AM +, Albert Astals Cid wrote: It achieves that by creating a static that instructs KGlobal to load a given translation catalog on global locale creation. Just to note that this fails for catalogs that have a dash in their name Cheerio -- Idleness is not doing nothing. Idleness is being free to do anything. -- Floyd Dell
Re: Helping libraries load their own translation catalogs
A Diumenge, 28 de novembre de 2010, Ivan Cukic va escriure:
On Monday, 22. November 2010. 19.05.45 Albert Astals Cid wrote:
A Dilluns, 22 de novembre de 2010, David Faure va escriure:
On Sunday 21 November 2010, Oswald Buddenhagen wrote:
On Sun, Nov 21, 2010 at 12:46:53AM +, Albert Astals Cid wrote:
It achieves that by creating a static that instructs KGlobal to
load a given translation catalog on global locale creation.
Just to note that this fails for catalogs that have a dash in their name
Wops, that's too bad.
Unless someone with more knowledge than me is able to fix my macro i'm
suggesting the attached patch.
It breaks current users of K_CATALOG_LOADER, but according lxr.kde.org there
is none at the moment so it's not a big deal i guess :D
Comments?
Albert
Cheerio
Index: kernel/kglobal.cpp
===
--- kernel/kglobal.cpp (revision 1201792)
+++ kernel/kglobal.cpp (working copy)
@@ -118,6 +118,12 @@
}
};
+KCatalogLoader::KCatalogLoader(const QString catalogName)
+{
+KGlobal::insertCatalog(catalogName);
+}
+
+
K_GLOBAL_STATIC(KGlobalPrivate, globalData)
K_GLOBAL_STATIC_WITH_ARGS(KComponentData, fakeComponent, (KGlobalPrivate::initFakeComponent()))
Index: kernel/kglobal.h
===
--- kernel/kglobal.h (revision 1201792)
+++ kernel/kglobal.h (working copy)
@@ -300,31 +300,26 @@
} NAME;
/**
- * This macro is useful in libraries where you want to make sure that
+ * This class is useful in libraries where you want to make sure that
* anyone that uses your library will get the correct catalog loaded.
+ * Just declare a static KCatalogLoader in the global namespace of one of
+ * your cpp files and that will load your catalog once
+ * the global klocale is created
*
- * @param CATALOGNAME The name of your catalog
+ * @param catalogName The name of your catalog
*
* @since 4.6
*
* Example:
* @code
- * K_CATALOG_LOADER(libkdepim)
+ * static const KCatalogLoader loader(libkdepim);
* @endcode
- *
- * @ingroup KDEMacros
*/
-#define K_CATALOG_LOADER(CATALOGNAME) \
-class KCatalogLoader##CATALOGNAME \
-{ \
-public: \
-KCatalogLoader##CATALOGNAME(); \
-}; \
-static KCatalogLoader##CATALOGNAME catalogLoader##CATALOGNAME; \
-KCatalogLoader##CATALOGNAME::KCatalogLoader##CATALOGNAME() \
-{ \
-KGlobal::insertCatalog(QLatin1String(#CATALOGNAME));\
-}
+class KCatalogLoader
+{
+public:
+KCatalogLoader(const QString catalogName);
+};
/**
* Access to the KDE global objects.
Re: Helping libraries load their own translation catalogs
A Dilluns, 22 de novembre de 2010, David Faure va escriure: On Sunday 21 November 2010, Oswald Buddenhagen wrote: On Sun, Nov 21, 2010 at 12:46:53AM +, Albert Astals Cid wrote: It achieves that by creating a static that instructs KGlobal to load a given translation catalog on global locale creation. statics in shared libraries have always been like a red flag for us. i don't know whether the reasons (some proprietary unix dynloader) are still applicable. qt has Q_CONSTRUCTOR_FUNCTION in qglobal.h nowadays. its implementation seems more complicated than necessary to me (why the integer return value?), so i wonder whether that's a workaround for something or just random baroqueness. Your message is not entirely useful because we don't know what to conclude from it :-) Can you ask the one who wrote it, or dig up the logs, to find out whether this is still needed or not, and which problems it solves? What's for sure is that K_CATALOG_LOADER will fail when using static libs, but that's not something we generally support (although WinCE uses that), and static libs means generally only one or very few apps, so they can just hardcode insertCatalog calls. Anyway, I'm fine with the patch. There's no destructor code so order-of- destruction won't be a problem, and the ctor code doesn't seem to rely on other things being created already, it will just create KGlobal if needed. (just one thing, @since 4.6 missing in the new api) I've commited it. Albert
Re: Helping libraries load their own translation catalogs
On Saturday 20 November 2010 7:46:53 pm you wrote: What do you think about the patch? Is there any way i can convince you it's safe enough for KDE 4.6 inclusion? I'm convinced.
Re: Helping libraries load their own translation catalogs
[: Albert Astals Cid :] Which this patch, your library would just have somewhere K_CATALOG_LOADER(libkdepim); and then all the programs linking to your library would automagically get the libkdepim catalog loaded. I think that it is crazy that the client code has to add library's catalogs, instead of library doing it automatically itself. So any pattern to make this possible is most welcome (and I don't see any problem in the patch). -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part.
Re: Helping libraries load their own translation catalogs
On Sunday 21 November 2010 00:46:53 Albert Astals Cid wrote: Is there any way i can convince you it's safe enough for KDE 4.6 inclusion? Albert +1 from me, if the release team are happy I'm happy, but I see it as more a bug fix than a new feature anyway. John.
Re: Helping libraries load their own translation catalogs
Quoting Albert Astals Cid aa...@kde.org: Here comes a patch that tries to fix that by moving the catalog loading responsability to the library, that is in my opinion where it should live. Great! What do you think about the patch? Is there any way i can convince you it's safe enough for KDE 4.6 inclusion? If it's ok from the release team POV, this patch would be much appreciated :) Cheers, Artur ---
Re: Helping libraries load their own translation catalogs
On Sun, Nov 21, 2010 at 12:46:53AM +, Albert Astals Cid wrote: It achieves that by creating a static that instructs KGlobal to load a given translation catalog on global locale creation. statics in shared libraries have always been like a red flag for us. i don't know whether the reasons (some proprietary unix dynloader) are still applicable. qt has Q_CONSTRUCTOR_FUNCTION in qglobal.h nowadays. its implementation seems more complicated than necessary to me (why the integer return value?), so i wonder whether that's a workaround for something or just random baroqueness.
