- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jun 26 2020
May 27 2020
May 26 2020
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/
May 23 2020
May 17 2020
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
May 15 2020
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.
May 11 2020
May 7 2020
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?
May 4 2020
Apr 20 2020
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.15correct?
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.
Apr 19 2020
ping? :)
In D25339#651701, @cullmann wrote:
In D25339#651701, @cullmann wrote:
Apr 18 2020
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:
- All lines are a bit higher, for me that makes reading even easier. But the rendering shall have no glitches.
- Some lines have different heights. But I assume this is hard to implement at the moment.
handle the range with multiple lines.
Apr 17 2020
Try to fill the gap if we increase the line height with representitive char.
Apr 15 2020
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
Nov 25 2019
Done.
Nov 17 2019
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).
Nov 16 2019
Add screenshot to demonstrate the problem.
Add comment about the actual characters.
Nov 7 2019
Aug 11 2019
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).
Aug 5 2019
Jan 3 2019
Jul 22 2018
Jun 6 2018
Mar 13 2018
Mar 7 2018
Not so sure why phabricator didn't set you as the commit author... sorry about that.
Mar 6 2018
In D11061#219841, @davidedmundson wrote:FWIW, there's a lovely Qt-GConf wrapper in plasma-pa/gconfitem
May I ask when this gsettings is introduced? Is it required after certain ibus version? Is there any case that this will not work?
Feb 14 2018
I sent the comment before you corrected the diff branch. LGTM.
Oh, ok.. now the diff looks normal.
Emm, mind to get rid of the .desktop part for this review?
Jan 6 2018
Jan 5 2018
In D8529#186000, @broulik wrote:Good to go, no?
Dec 4 2017
In D8798#175698, @subdiff wrote:Sorry for the long delay on a review.
Can you give a short overview on how the switching works between Xlib and libinput backend on X? So what's the runtime detection if libinput is available or not? Somebody above said mouse kcm is not available without libinput anymore with this patch. But this should not happen of course.
Naming the config option Pointer Acceleration is problematic, because libinput names another property "pointer acceleration". I think we should not change the name. Unneeded deviation from upstream. Maybe better add a tooltip with a description if people complain.
In the touchpad kcm the backends for libinput and xlib are in different files (in the same backend/x11 subfolder). Is this possible here as well?
In D8798#175698, @subdiff wrote:Sorry for the long delay on a review.
Can you give a short overview on how the switching works between Xlib and libinput backend on X? So what's the runtime detection if libinput is available or not? Somebody above said mouse kcm is not available without libinput anymore with this patch. But this should not happen of course.
Naming the config option Pointer Acceleration is problematic, because libinput names another property "pointer acceleration". I think we should not change the name. Unneeded deviation from upstream. Maybe better add a tooltip with a description if people complain.
In the touchpad kcm the backends for libinput and xlib are in different files (in the same backend/x11 subfolder). Is this possible here as well?
Nov 27 2017
@jriddell ping?
Nov 22 2017
In D8798#170892, @jriddell wrote:This disables the input kcm if libinput x11 plugin is not found. I expect this is fine, it is for ubuntu distros at least, but it might be worth asking distros if it causes them a problem.
revert the accidentally changed currentIndex in ui file when save in designer.
Whether it shows up reallys depends on your system. Especially when there's multiple mouse driver available and you may using evdev.
@apol got a chance to test it?
Nov 21 2017
Also just FYI, My PR of fcitx's gtk im module recently got merged to freedesktop runtime. https://github.com/flatpak/freedesktop-sdk-images/pull/58
Nov 17 2017
In D8798#169156, @apol wrote:In D8798#169155, @ngraham wrote:$ kcmshell5 touchpad kcm_touchpad: Using X11 backendThe file on disk is at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so (on KDE Neon and other Ubuntu-based distros)
Are you sure? because this is modifying files in kcms/input that creates a kcm_input.so... Is it a kcm that extends kcm_touchpad.so?
Fix based on comment
Nov 16 2017
Nov 13 2017
Use the new kcoreaddons function to cal the length.