You can try to install one from your distro to check the actual content. index.theme is generated during the "configure & make".

In D29668#669069, @dfaure wrote:

What are the values of Context and Type?

"Legacy" and "UI" ?

I can't see anything in index.theme https://ftp.gnome.org/pub/GNOME/sources/adwaita-icon-theme/3.36/

In D29789#672335, @dhaumann wrote:

I like this patch. In fact, I observed over the past years again and again that sometimes, especially if chinese or similar letters are included, the baseline is wrong in Kate, leading to much more overpainting that needed.
If this patch fixes this, then I'm all for it. Or let's put it like this: The current implementation is wrong, this patch looks less wrong than the current state :-)

+1

This is my another try as an alternative solution to D25339. Actually this works surprisingly good IMHO, at least for CJK users for most cases.

Actually I was trying to use this approach in the patch because I was afraid that variable line height may need to estimate the whole document height to make scroll work correctly.

In D25339#665432, @rjvbb wrote:

With "we've ever seen" you do mean that lineheight only changes when a line that requires it scrolls into view?

Though line height won't shrink during the edit phase, it will back to the actual value upon save.

Have you tried to reset the max. lineheight on each redraw (I presume the scrollbars could give you a signal that a view scroll/jump was initiated, if need be).
Something tells me that it'd be nicer if lineheight always is as small as possible. Imagine you're using a smallish window to edit a document that just has some of these "offending", much higher characters at the bottom. If it gets into view only once, lineheight increases and it's as if you lose a lot of screen estate until you save the document. Now I mustn't be the only one who often doesn't save for a while, esp. when doing things like moving blocks of text around, and it's exactly in that kind of scenario where having to save to get a more space-efficient rendering back can be very annoying.

As long as you can determine the max. lineheight required for the view that's about to be drawn before the view is actually drawn there should be no glitches. You'd just see a jump in lineheight and there would probably be an interesting problem to tackle with edge cases where the higher glyphs fall outside the view area because of the increased lineheight, but that's something your current implementation cannot avoid completely either. As to the changing lineheight: I think users will understand why it happens and get used to it. It's comparable to what you see in graphics programmes that show cursor co-ordinates next to the cursor; that indicator has to jump when it would get "pushed out" of the view, and that doesn't even feel weird.

I presume your new approach would work not just for CJK characters, but also for anything else that changes the lineheight. That's and advantage but could also lead to regressions for some (who never use CJK characters or who, like me, wouldn't care how they display because they can't read them anyway). Emoticons come to mind; here too I don't really care if they get cut off. Scrap that, I *really* don't care if they are...

I'm not sure if this is the right way to do it or it might cause any glitch, but here we go. Upon line rendering, update the maximum height we've ever seen.

Use actual line height instead of representitive character.

In D25339#663915, @fakefred wrote:

I second the as-an-option proposal. Hey, why not automatically increase the line height when CJK characters are detected?

In D28859#652379, @davidedmundson wrote:

So the problem we're solving is that we want to go

Qt5.12 - QQC2.5
Qt5.13 - QQC2.6
Qt5.14 - QQC2.7
Qt5.15 - QQC2.15

correct?

We now know all Qt5 versions, and we know that Qt6 won't have versions.

I don't see why need this complicated thing instead of an "if" statement on Qt5QuickControls2_VERSION_MINOR

Just to correct it, the change is since 5.12.
5.11 -> 5.4
5.12 -> 5.12

Just fix the version by if-else check.

Fix the blank text issue by alway setLineWidth.

Clean up the code a little bit and adding comments. Also fix a small bug if m_fontHeight has
big difference with m_fontMetrics's height.

ping? :)

In D25339#651701, @cullmann wrote:

Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).

In D25339#651701, @cullmann wrote:

Hmm, after applying this patch, for me, no text is visible at all.
By selecting a bit stuff, one at least sees an outline (CMakeLists.txt of ktexteditor toplevel dir).

Add a screenshot to demostrate the change.

Fix the handling when layout formats has background.

In D25339#563937, @cullmann wrote:

Actually, I could live with:

1. All lines are a bit higher, for me that makes reading even easier. But the rendering shall have no glitches.
2. Some lines have different heights. But I assume this is hard to implement at the moment.

handle the range with multiple lines.

Try to fill the gap if we increase the line height with representitive char.

In D28859#649191, @davidedmundson wrote:

I don't understand.

We're still running this at compile time, so what's the practical difference?

fix header

Done.

Any idea about how konsole derive the value?.. I'm not so sure if they did a better job (probably not because IIRC I have seen similar issue in konsole).

Add screenshot to demonstrate the problem.

Add comment about the actual characters.

This change doesn't serve any real functionality of kimpanel. It doesn't show the current input method in tray, doesn't hide or show up. And kimpanel usually consist multiple icons. While it's doubt whether we need that much for certain input method (currently user can blacklist some by hand), but being able to show some important ones should not be removed. (on windows, there're two icon for chinese case).