On Tuesday 27 November 2012 12:33:59 Chusslove Illich wrote:
> > [: 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 re
> [: 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 kf5/ktransc
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 p
> [: 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
QLi
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
> [: 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 work out of
> the box (after you add the env var to your setup,
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
> [: 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 ins
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
> kdecore/CMake
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
kdecore/CMakeLists.txt (I didn't change any other CMakeLists.txt).
--
Chusslove
>> [: Chusslove Illich :]
>> Unfortunatelly, sometimes the programmer also does not handle the path
>> directly (e.g. icons). Any idea here?
>
> [: David Faure :]
> Well, KIconLoader could call the same method...
Oh, right. Since actually I cannot recall a case of under-the-hub paths
needing local
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
> fal
> [: 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
KLocalizedSt
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
fallback rules as for strings in PO files. Due to this, initially I tho
> [: David Faure :]
> Hi Chusslove,
>
> any progress? :-)
No progress, but I'm going to do it right now.
--
Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-f
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 splitt
> [: 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 do
On Saturday 15 September 2012 13:36:42 Chusslove Illich wrote:
> > [: David Faure :]
> > So either i18n is ported away from KLocale, or all that calendar stuff has
> > to move into the ki18n framework, at least in the short term.
>
> Since including calendar stuff into ki18n would be a temporary m
> [: David Faure :]
> So either i18n is ported away from KLocale, or all that calendar stuff has
> to move into the ki18n framework, at least in the short term.
Since including calendar stuff into ki18n would be a temporary measure that
would later have to be undone, I think it's best that I split
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 no
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. Water
22 matches
Mail list logo
