According to https://community.kde.org/KDE_Gear/24.02_Release_notes, Kopete will no longer be a part of Gear starting with 24.02.

Still relevant: https://invent.kde.org/graphics/okular/-/blob/047400294d4a0a8798d7045f0d6745c3f0b6eb8c/CMakeLists.txt#L268

Closing due to the lack of interest; if still relevant, please reopen in a non-language-specific location.

Closing due to the lack of interest

Сделал

Актуальные советы из этого обсуждения добавил на сайт; новые можно присылать как MR в репозиторий сайта.

Unsubscribed Sysadmin for now.

How much value do these glossaries add on top of https://l10n.kde.org/dictionary/search-translations.php ?

Probably needs some metadata editing to show up on https://apps.kde.org/labplot2

In D29881#676882, @loisspitz wrote:

In D29881#676870, @IlyaBizyaev wrote:

The link you sent refers to https://rabbitictranslator.com/wordpress/index.php/2020/01/19/contributing-to-kde-localization/, please read it — you submit translations to wrong places and wrong people.

I think i did not write it clear. The strings are for skrooge. The link is how I made this diff. Sorry for that obscurities.

The link you sent refers to https://rabbitictranslator.com/wordpress/index.php/2020/01/19/contributing-to-kde-localization/, please read it — you submit translations to wrong places and wrong people.

In Android, there's now by default no back button, but a gesture.
On iOS, navigating back is also swipe-based AFAIK.
I don't see why Plasma Mobile would need a back button. Moreover, I still believe the consensus was that the bottom panel will eventually go away entirely, as long as it doesn't break VM testing.

I agree with Carl here. The proposed program document is very detailed on requirements that volunteers have to fulfill to comply, which adds extra bureaucratic burden and increases the entry barrier, but is scarce on rewards. Personally, I do not see the benefit of getting the Russian community enrolled in this program. Event swag? I'm confident the e.V. would reimburse it for an otherwise organized local event, too. Certificates? Not sure if those have any value. It could be my time limit speaking, though.

Will do, but I think it's not really resolved if it crashes unless that file is translated...

Currently localization doesn't work at all for this subsection, failing with a server error.
https://kde.org/applications/ru/education/org.kde.gcompris

Seems to be agreed on, yet stalled

Maybe also /var/lib/docker?

How will that approach handle visual differences between application controls and Plasma controls?
An example is Kubuntu's default theme combo, which I also use on my machine: Breeze (default, light) for apps and Breeze Dark for Plasma. Light apps and a visually distinct dark panel are not an esoteric combo, some other workspaces default to it, e.g.:

• GNOME

• ChromeOS

When I updated my parents' PC, they lost the TeamViewer desktop icon because it became monochrome.
Confirmed locally, the TeamViewer icon in the Dashboard menu is also monochrome.
This does not happen to the recently introduced Flameshot icon, so what's the difference here?

https://vk.com/@kde_ru-nedelya-19-04

On the screenshots, the notifications block tab bars and toolbars in 3 apps :)
Are you sure it's more convenient?

https://vk.com/@kde_ru-nedelya-05-04

Inserting the SIM card can/should only be done when the phone is powered off

As an idea, the most common request has been to provide an up-to-date and regularly updated ISO for x86_64. As of now, that image is still from 02.2019.

I don't have enough CMake knowledge to give code comments, but here are some things I can notice in case they help in review:

1. The function specifically mentions Cargo workspace, which is basically a Rust alternative to TEMPLATE = subdirs in qmake. It doesn't seem though that the current implementation has code specific for this project type, and it can probably work just as well for normal executable and library projects. Am I missing something? If it can't, how would developers use this ECM module if they don't need the workspace? Can it be generalized?
2. In the implementation that I mentioned, the resulting target gets a name that we can use directly, whereas in your usage example you have to manually use an artifact variable to actually be able to link. You also manually specify the shared library extension; will this require a platform-dependent wrapper in end user's CMakeLists to be able to use this on e.g. Windows?

Thank you for your work :)

In D28444#639020, @cblack wrote:

CMake needs to know what files Cargo wants to build in order to invoke it only when Rust files change. There's no reason to invoke Cargo every time make is ran when CMake has the ability to keep track of dirty files.

In D28444#638877, @cblack wrote:

CMake needs to know when the Rust source has changed so it can rebuild it

In D28444#638430, @cblack wrote:

more than half of Ikona's CMakeLists.txt is boilerplate dedicated to integrating Rust with the rest of the project

I'm not good at CMake modules, but maybe this code (which I used in a project) is useful:
https://github.com/Devolutions/CMakeRust

It seems that of released distros, only Fedora has vokoscreenNG in repositories so far

Опубликовано, спасибо!

In D27617#630339, @davidre wrote:

Huh that case is working what I found that IconName and OverlayIconName is currently broken, see D28107.
IconName and OverlayIconPixmap` work fine here

If it doesn't for you please file a bug so we can investigate that.

Btw that overlay is always as tiny as on your screenshot, so not usable for a counter

In D27617#630228, @ngraham wrote:

So... how do we fix this so that you can use a nice monochrome Breeze icon in your system tray? Whose code needs to change?

This breaks for people using Breeze for apps and Breeze Dark for Plasma:

pass environemnt variable TDESKTOP_DISABLE_TRAY_COUNTER=1 to telegram-desktop also make it follows KDE color scheme

This is not a solution; we need to make sure things work by default and not in terminal-hackish way. So for a novice user with default Kubuntu settings and an official Telegram build, "the icon is broken in KDE" now.
Tbh I'd rather we didn't interfere with 3rd-party apps at all.

In T12814#223341, @tfella wrote:

In T12814#223340, @muesli wrote:

Also not opposed to a Kirigami front-end and happy to provide help here. I'm not sure the Go backend is well-suited for the entire KDE infrastructure, though.

Neither is Rust, we're still using it in some applications though, so that should not be a problem i guess?

https://vk.com/@kde_ru-nedelya-08-03

https://vk.com/@kde_ru-plasma-mobile-sprint-2020

For color schemes that have contrasting titlebar and content colors, this patch makes application headers look giant...