icons in filelight on windows
Servas! Icons in filelight on windows are partially broken and I am not quite sure why. What appears to happen is that the breeze icons are inside the qresource system but don't get used by kirigami components because they want to look in breeze-internal (which isn't actually resolving through kiconthemes and as far as I can tell not in :/icons/* which is probably why it fails to resolve). So then kiconthemes goes "yo, this be missing, let's try fallback" except the fallback apparently is hicolor and doesn't exist because we are on windows but it exists in the qrc why that doesn't work is anyone's guess though. [7244] kf.iconthemes: Icon theme "breeze-internal" not found. [7244] kf.iconthemes: Couldn't find current icon theme, falling back to default. [7244] kf.iconthemes: Standard icon theme "hicolor" not found! As ever I also don't know why filelight was ported to qt6 without review by anyone. It's been a broken mess ever since, preventing me from making a new release to the windows store. Everything is sad and I don't know what to do about it. Please help! :((
Re: KStars: Cannot change language
El divendres, 21 de juny del 2024, a les 19:53:04 (CEST), Albert Astals Cid va escriure: > El divendres, 21 de juny del 2024, a les 10:31:50 (CEST), Jasem Mutlaq va > > escriure: > > Hello, > > > > We have an issue with the recent versions of KStars is that language > > cannot > > be switched by users. This affects MacOS, Windows, and Linux, whether > > packaged or built from source. > > > > How to debug this issue? I can't see anything in the logs about the > > language switch issue. For example, I tried changing the language to > > German > > but the interface is still in English. Which component of KDE Frameworks > > is > > handling this at the backend? Any environment variables to check or watch > > out for? > > > > Any pointers would be appreciated. > > Starting kstars says > > kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: > "Count of captures stored for the job, based on its sequence job.\nThis is > a summary, additional specific frame types may be required to complete the > job." msgid_plural: "" msgctxt: "" > > > Fixed by > > https://invent.kde.org/education/kstars/-/merge_requests/1266 > > This fixes the issue. Ah i see you fixed it in a bit more rudimentary way, that also works I guess. Cheers, Albert > > Cheers, > Albert > > > -- > > Best Regards, > > Jasem Mutlaq
Re: KStars: Cannot change language
El divendres, 21 de juny del 2024, a les 10:31:50 (CEST), Jasem Mutlaq va escriure: > Hello, > > We have an issue with the recent versions of KStars is that language cannot > be switched by users. This affects MacOS, Windows, and Linux, whether > packaged or built from source. > > How to debug this issue? I can't see anything in the logs about the > language switch issue. For example, I tried changing the language to German > but the interface is still in English. Which component of KDE Frameworks is > handling this at the backend? Any environment variables to check or watch > out for? > > Any pointers would be appreciated. Starting kstars says kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "Count of captures stored for the job, based on its sequence job.\nThis is a summary, additional specific frame types may be required to complete the job." msgid_plural: "" msgctxt: "" Fixed by https://invent.kde.org/education/kstars/-/merge_requests/1266 This fixes the issue. Cheers, Albert > > -- > Best Regards, > Jasem Mutlaq
Re: KStars: Cannot change language
On Freitag, 21. Juni 2024 10:31:50 CEST Jasem Mutlaq wrote: > We have an issue with the recent versions of KStars is that language cannot > be switched by users. This affects MacOS, Windows, and Linux, whether > packaged or built from source. > > How to debug this issue? I can't see anything in the logs about the > language switch issue. For example, I tried changing the language to German > but the interface is still in English. Which component of KDE Frameworks is > handling this at the backend? Any environment variables to check or watch > out for? > > Any pointers would be appreciated. On Sonntag, 2. Juni 2024 13:36:58 CEST I wrote in reply to your previous message with subject "Re: Cannot change language": I have just built the current master version (which calls itself 3.7.1 Stable) with KDE Frameworks 5.115.0 and Qt 5.15.12 (on openSUSE Tumbleweed). I could switch the language (via Help -> Configure Language) to different languages. I have built kstars without the optional dependencies INDI, Nova, ERFA, LibRaw, LibXISF, Qt5Keychain. Maybe one of those dependencies messes with the LANGUAGE environment variable that KDE Frameworks use for overriding the system language. Or Qt 5.15.13 is messed up. === Did you try building kstars without optional dependencies to verify my observation that with such a build changing the language works? Two KDE Frameworks are involved in changing the language. KXMLGui provides the language switching dialog. Moreover it loads the configured language and sets the environment variable LANGUAGE. KI18n loads the translations for the language(s) in the LANGUAGE variable. On Linux the configured languages are stored in/read from the file ~/.config/klanguageoverridesrc Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: KStars: Cannot change language
Thanks. Just to be clear, I'm talking about changing language from Help -->
Configure Language dialog that is standard in KDE applications.
[image: Screenshot_20240621_121812.png]
--
Best Regards,
Jasem Mutlaq
On Fri, Jun 21, 2024 at 12:16 PM Konstantin Kharlamov
wrote:
> Looking at the repo, I see the `po/` dir which implies it's using GNU
> gettext for translation. Fairly standard choice. Strings are marked for
> translation by using a `_` macro, like `_("My english text")`.
>
> I don't remember the details, but it basically has something like a
> database of such texts and their lines with the according translations.
> When it needs to represent a translated string it basically does so by
> searching in that db.
>
> Language may be changed by different means. On Linux and Unix systems
> it's usually variables such as `LANG`. So e.g. `LANG=en_US.UTF-8
> kstars` should launch it with english language.
>
> If you have a way to switch language via interface, I presume it is
> handled by some gettext API that overrides whatever's being told by
> env. variables.
>
> HTH
>
> On Fri, 2024-06-21 at 11:31 +0300, Jasem Mutlaq wrote:
> > Hello,
> >
> > We have an issue with the recent versions of KStars is that language
> > cannot be switched by users. This affects MacOS, Windows, and Linux,
> > whether packaged or built from source.
> >
> > How to debug this issue? I can't see anything in the logs about the
> > language switch issue. For example, I tried changing the language to
> > German but the interface is still in English. Which component of KDE
> > Frameworks is handling this at the backend? Any environment variables
> > to check or watch out for?
> >
> > Any pointers would be appreciated.
> >
> > --
> > Best Regards,
> > Jasem Mutlaq
> >
>
>
Re: KStars: Cannot change language
Looking at the repo, I see the `po/` dir which implies it's using GNU
gettext for translation. Fairly standard choice. Strings are marked for
translation by using a `_` macro, like `_("My english text")`.
I don't remember the details, but it basically has something like a
database of such texts and their lines with the according translations.
When it needs to represent a translated string it basically does so by
searching in that db.
Language may be changed by different means. On Linux and Unix systems
it's usually variables such as `LANG`. So e.g. `LANG=en_US.UTF-8
kstars` should launch it with english language.
If you have a way to switch language via interface, I presume it is
handled by some gettext API that overrides whatever's being told by
env. variables.
HTH
On Fri, 2024-06-21 at 11:31 +0300, Jasem Mutlaq wrote:
> Hello,
>
> We have an issue with the recent versions of KStars is that language
> cannot be switched by users. This affects MacOS, Windows, and Linux,
> whether packaged or built from source.
>
> How to debug this issue? I can't see anything in the logs about the
> language switch issue. For example, I tried changing the language to
> German but the interface is still in English. Which component of KDE
> Frameworks is handling this at the backend? Any environment variables
> to check or watch out for?
>
> Any pointers would be appreciated.
>
> --
> Best Regards,
> Jasem Mutlaq
>
KStars: Cannot change language
Hello, We have an issue with the recent versions of KStars is that language cannot be switched by users. This affects MacOS, Windows, and Linux, whether packaged or built from source. How to debug this issue? I can't see anything in the logs about the language switch issue. For example, I tried changing the language to German but the interface is still in English. Which component of KDE Frameworks is handling this at the backend? Any environment variables to check or watch out for? Any pointers would be appreciated. -- Best Regards, Jasem Mutlaq
Re: KDE Gear projects with failing CI (master) (18 June 2024)
> With make the problem doesn't seem to occur because it looks like the > Makefiles serialize building of Test8 and Test8_cmake so that Test8_cmake > is always built after Test8 where Test8 creates the headers that > Test8_cmake uses. With ninja the builds of both targets don't seem to be > serialized so that Test8_cmake could be built before Test8. -> Fail! With that info, we got a fix in, but that won't fix CI since it uses tarballs, should we get https://invent.kde.org/frameworks/kconfig/-/merge_requests/314/diffs added as a patch to Craft? In the meantime building of the KConfig tests has been disabled in Craft. We can just wait for KF 6.4. Actually, I'm wondering why we build tests in Craft at all. Craft doesn't run the tests, the tests are not packaged _and_ the purpose of the Craft jobs isn't CI. I'd say we should probably disable building of tests in general in Craft. Building them is just a waste of energy and time and I fail to see any benefit. When/if we want to start running the tests in Craft then we can simply re-enable their build. Ok, guess that would make sense and save power we just waste ATM. Greetings Christoph
Re: KDE Gear projects with failing CI (master) (18 June 2024)
On Freitag, 21. Juni 2024 00:36:45 CEST Albert Astals Cid wrote: > El dimecres, 19 de juny del 2024, a les 9:07:50 (CEST), Ingo Klöcker va > > escriure: > > On Mittwoch, 19. Juni 2024 00:49:14 CEST Albert Astals Cid wrote: > > > kdenlive - 2nd week > > > > > > * https://invent.kde.org/multimedia/kdenlive/-/pipelines/716283 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > isoimagewriter - NEW > > > > > > * https://invent.kde.org/utilities/isoimagewriter/-/pipelines/716655 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > > > neochat - NEW > > > > > > * https://invent.kde.org/network/neochat/-/pipelines/716759 > > > > > > * craft_appimage_qt6_x86_64 fails > > > > All of these fail because the tests of kconfig don't build. I'm wondering > > why not all AppImage builds of all projects fail. > > > > The cause for the failing (or highly unstable) builds of the tests of > > kconfig is an error in the test design. Here's what I wrote late last > > night > > in #kde-craft:kde.org. > > > > === > > There is a pair of tests, e.g. Test8 and Test8_cmake where the latter is > > supposed to test that cmake can generate a .kcfgc file. The problem is > > that > > both tests share the same test8main.cpp which includes a test8a.h. This > > test8a.h is generated via test8a.kcfg[c] for Test8, but for Test8_cmake > > test8a_cmake.h is generated via a test8a_cmake.kcfg[c]. If for some reason > > Test8_cmake is built before Test8 then test8main.cpp doesn't find > > test8a.h. > > I'm not yet sure how to fix this. Maybe we need to create patched copies > > of > > testXmain.cpp which includes a testXx_cmake.h instead of a testXx.h. Or > > maybe we put both tests in separate subdirs and don't append _cmake to the > > files used for the TestX_cmake tests. That's feels like a cleaner solution > > also because it better isolates the two tests from each other. > > === > > > > With make the problem doesn't seem to occur because it looks like the > > Makefiles serialize building of Test8 and Test8_cmake so that Test8_cmake > > is always built after Test8 where Test8 creates the headers that > > Test8_cmake uses. With ninja the builds of both targets don't seem to be > > serialized so that Test8_cmake could be built before Test8. -> Fail! > > With that info, we got a fix in, but that won't fix CI since it uses > tarballs, should we get > https://invent.kde.org/frameworks/kconfig/-/merge_requests/314/diffs > added as a patch to Craft? In the meantime building of the KConfig tests has been disabled in Craft. We can just wait for KF 6.4. Actually, I'm wondering why we build tests in Craft at all. Craft doesn't run the tests, the tests are not packaged _and_ the purpose of the Craft jobs isn't CI. I'd say we should probably disable building of tests in general in Craft. Building them is just a waste of energy and time and I fail to see any benefit. When/if we want to start running the tests in Craft then we can simply re-enable their build. Regards, Ingo signature.asc Description: This is a digitally signed message part.
