Nice. Could the same technique be applied for keyboardlayout applet?
Currently, it glows a bit on hover when showing a flag icon only. No such effect when in text label mode.

In T13722#256068, @ndavis wrote:

Actually, a Text/Label element would be better for showing emojis at small sizes because it supports subpixel antialiasing.

Even so, seems old hand-made PNGs drawn on pixel-by-pixel basis give the best result at smallest size, so I doubt we need to smash it to something else. Rather than adding on top, maybe.

Relevant setting, true by default:
https://doc.qt.io/qt-5/qml-qtquick-image.html#smooth-prop
I wonder if it makes any impact when scaling up in several sizes, 2x or more..

Thanks for the in-depth description and clarification.

The solution to the blurriness problem would be to make pixel aligned flags for every icon size we might use.

I asked upstream to see what reaction would be for providing smaller variants of the icons:
https://github.com/hfg-gmuend/openmoji/issues/317

The solution to the blurriness problem would be to make pixel aligned flags for every icon size we might use.

Do you mean in raster?

That's just what happens when you don't make images for the exact size you will be using them at

So what should be the solution? I thought strong point of SVG is it doesn't tied to any particular size.

@driglu4it we also have problem with blurring SVG icons on small sizes, could you also provide the screenshots?

I think it would be cool if we just started with anything.
Just need to watch new icons looks not worse in small scale than kdelibs4suppors's ones.

Yes, I was saying that Twemoji was more detailed and correct than OpenMoji.

The idea was having more details is not necessary good for this particular case. I thought having flags somewhat abstracted is what we need here, and only OpenMoji suits that idea what I can see.
Maybe I'm wrong, need to see it in actual scale in comparison.

It seems to me Twemoji still has much more details for that flag.
Anyway, could we have more than one flag vendors available?
Ideally, they should be just auto-generated from that vendors, shall the modifications needed at all.

In T13722#247618, @bam wrote:

What do you think about Openmoji? Sharp corners but thick black outline. Still might look good, IMO.

That outline is just a separate SVG element (<g id="line">), should be easy to remove automatically.

Marble has full-fledged flags from Widipedia, they are not suit well our needs: https://invent.kde.org/education/marble/-/tree/master/data/flags
The only abstracted variant I faced is OpenMoji, for comparison: https://emojipedia.org/flag-afghanistan/

Thanks Noah. Yes that support burden frightens me also (not sure how often they are updating, though).
What do you think about Openmoji? Sharp corners but thick black outline. Still might look good, IMO.
And about the corners, maybe round corners are not that bad?
Or just create several flag themes, one for each emoji vendor?
Too many questions, I know.

Advantage of "real" icon is that it supports overlay text on top (IconItem), and can be highlighted in a standard way (with Active mode).
So it's still a reasonable alternative over emoji I think.
@mart

Not a revert but rather rollback of SNI part:
https://invent.kde.org/plasma/kwin/-/merge_requests/560

We are going to revert this in favor of https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/181:
it supports all the existing functional here plus missing one (problem with short layout names was solved):

• flags and/or short text for the layouts

If any objections, please tell.

Thanks for clarifying.

In D6628#676721, @mak wrote:

So, this change looks fine to me now, as it is :-)

And yet it was changed again! :-D
https://github.com/KDE/plasma-desktop/commit/05c230733a1b9d16c0e52eb54955c62d340b94e3

Starting version 2.0, it is no longer valid to use the + operator in a license identifier

should we address it?
https://en.wikipedia.org/wiki/Software_Package_Data_Exchange#Deprecated_syntax

I wonder if we could "share" that .xml between server and client somehow..

Does it mean we now have to manually synchronize DBus API here in .xml and on KWin side?

In T13722#242348, @ndavis wrote:

...
non-waving flags: https://emojipedia.org/twitter/

Thanks for input everyone.
About option 2, if someone knows emoji font resemble these: https://lxr.kde.org/source/frameworks/kdelibs4support/src/l10n/ (the flags are inside 2-letter dirs, installing to kf5/locale/countries/%1/flag.png), please let us know. I think non-waving version is preferable.

Is it documented anywhere how one can build Plasma with -DCMAKE_CXX_COMPILER_LAUNCHER=ccache?

BTW, GDM seems already run so :)

This seem had already been fixed : https://phabricator.kde.org/R256:03011c6e3c689c3e13c91e964000fd66fbb80daf

(redudant) rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

move snapd-glib also

rebase

minor corrections

Not needed any more

rebase

rebase

remove wrapper script

@apol I don't have development account, so probably I can't.
I would be gratitude if you land it then. Thanks

move yaml also

keep yaml

@apol Last but not least, you could give me a New Year present accepting this patch :-P

... and using FLATPAK_USER_DIR instead of XDG_DATA_HOME

Also, there is other improvement such as 'exec'

The clue part here is removing the wrapper.sh file.
Also, I don't think we should make a separate module just for the wrapper.

In D17662#379187, @apol wrote:

Why is this better? please provide a better description.

addresses binary-factory build