[: David Faure :]
For now you might want to iterate over QCoreApplication::libraryPaths() by
hand and try to load it (without suffix), and if that fails, keep
iterating.
I pushed this now, so kservice dependency is removed.
Instead of trying to load, I checked for existence of
On Sunday 25 November 2012 13:49:48 Chusslove Illich wrote:
[: David Faure :]
I think this should be QLibrary(kf5/ktranscript), and ensuring the file
on disk is called ktranscript.so (no lib in front).
I forgot to say I tried that too :)
OK I'm having the same problem with a plugin I
On Sunday 25 November 2012 00:59:59 Chusslove Illich wrote:
[: David Faure :]
Porting from KLibrary to QLibrary really brings up only one question, how
to locate ktranscript.so. But since the idea is that QT_PLUGIN_PATH must
be set to the KF5 install prefix + /lib/plugins, it might just
[: David Faure :]
I think this should be QLibrary(kf5/ktranscript), and ensuring the file
on disk is called ktranscript.so (no lib in front).
I forgot to say I tried that too :) Here's the sequence:
$ grep 'QLib.*ktranscript' $SRCDIR/kdecore/localization/klocalizedstring.cpp
QLibrary
On Sunday 18 November 2012 20:53:36 Chusslove Illich wrote:
[: David Faure :]
Yes, please compile whatever you have ;)
Ok, I pushed it.
I'm a bit surprised that ki18n depends on kservice, since kservice wants
to depend on i18n (automatic catalog loading). I guess ki18n uses plugins,
On Sunday 18 November 2012 00:28:35 Chusslove Illich wrote:
I have now split out ki18n, made sure that kdelibs compile and that KLocale
and KLocalizedString tests work, and have it as single humongous patch.
Should I just commit it, or something else? I attach only the diff to
[: David Faure :]
Yes, please compile whatever you have ;)
Ok, I pushed it.
I'm a bit surprised that ki18n depends on kservice, since kservice wants
to depend on i18n (automatic catalog loading). I guess ki18n uses plugins,
so the fix will be to port that to pure Qt plugin loading instead.
On Sunday 04 November 2012 12:03:18 Chusslove Illich wrote:
While splitting out public methods dealing with translation from KLocale, I
got a doubt about localizedFilePath(). For a given file path, it returns the
localized file path, if available, according to the same language list and
[: Chusslove Illich :]
While splitting out public methods dealing with translation from KLocale
[...]
For completeness, also the overview of what I do with other methods (no
comment needed except for objections :):
All translateRaw*() methods are removed. They were used only by
On Sunday 16 September 2012 19:22:26 Chusslove Illich wrote:
[: David Faure :]
Anyhow, I recommend splitting in place (in kdecore), first, to have
commits that do the splitting, separated from the commits that do the
moving. I can even do the moving once you've done the API splitting :-)
[: David Faure :]
Anyhow, I recommend splitting in place (in kdecore), first, to have
commits that do the splitting, separated from the commits that do the
moving. I can even do the moving once you've done the API splitting :-)
Well that's totally great. I was thinking of asking about doing
On Tuesday 11 September 2012 13:15:37 Chusslove Illich wrote:
[: David Faure :]
Is it also part of your plans to remove i18n()'s dependency on KLocale?
I consider it rather an orthogonal matter. I will anyway remove all Gettext-
related stuff from KLocale, before doing anything about
[: David Faure :]
Is it also part of your plans to remove i18n()'s dependency on KLocale?
I consider it rather an orthogonal matter. I will anyway remove all Gettext-
related stuff from KLocale, before doing anything about replacing *gettext()
calls themselves.
This is what's blocking me now,
On Wednesday 05 September 2012 10:48:54 Chusslove Illich wrote:
Next I plan to rewrite
klocalizedstring.h, such that it reflects the planned changes, but most
importantly to have more comprehensive doc appropriate for a standalone
component. After we review it, I go adapting the code.
14 matches
Mail list logo
