[kdevelop] [Bug 384779] The line with error is highlighted as wrong even when the error is fixed.
https://bugs.kde.org/show_bug.cgi?id=384779 Thomas Schöps changed: What|Removed |Added Resolution|--- |FIXED CC||tom.scho...@gmail.com Status|REPORTED|RESOLVED --- Comment #4 from Thomas Schöps --- Should be fixed by: https://invent.kde.org/kde/kdevelop/merge_requests/18 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]
https://bugs.kde.org/show_bug.cgi?id=379669 --- Comment #38 from Thomas Schöps --- Yes, I could imagine that there are such problems and the procedure that you describe might be better. But I am not knowledgeable enough about the KDevelop architecture to make any well-informed decisions here. What I can tell is that my workaround "works for me" (TM), at least I haven't seen related issues since I started using it, and thus I proposed a merge request for it now since it appears that it at least improves over the current situation: https://invent.kde.org/kde/kdevelop/merge_requests/61 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 379669] KDevelop continues to hang on exit in itemrepository.h [Bucket::deleteItem]
https://bugs.kde.org/show_bug.cgi?id=379669 Thomas Schöps changed: What|Removed |Added CC||tom.scho...@gmail.com --- Comment #36 from Thomas Schöps --- Contrary to a previous comment, I have the impression that the language plugins may be unloaded before the final DUChain cleanup: see https://invent.kde.org/kde/kdevelop/blob/master/kdevplatform/shell/core.cpp#L429 , where I think that d->pluginController->cleanup(); will cause the plugins to be unloaded, while the DUChain shutdown only happens a few lines below. Thus I currently test the following change in an attempt to fix the bug reported here: index 19146ba42d..417b4f7e7f 100644 @@ -428,2 +428,6 @@ void Core::cleanup() d->languageController->backgroundParser()->waitForIdle(); + +DUChain::self()->shutdown(); + +// Only unload plugins after the DUChain shutdown to prevent issues with non-loaded factories for types d->pluginController->cleanup(); @@ -436,4 +440,2 @@ void Core::cleanup() d->languageController->cleanup(); - -DUChain::self()->shutdown(); } So far, I didn't encounter the bug with this change applied, but since it only happened occasionally, this doesn't necessarily mean that it is fixed. Also, since I am not familiar with the overall KDevelop architecture, I don't know whether this change in shutdown order may introduce subtle issues that I am not aware of. So far, I haven't noticed issues. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 364239] Snippet keyboard shortcut doesn't work
https://bugs.kde.org/show_bug.cgi?id=364239 --- Comment #8 from Thomas Schöps --- I wasn't sure whether "Each new instance requires the Snippets tool to be re-enabled." describes another issue that might still be open. But probably yes. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 391450] Option to disable drag and drop text
https://bugs.kde.org/show_bug.cgi?id=391450 Thomas Schöps changed: What|Removed |Added Latest Commit||https://commits.kde.org/kte ||xteditor/c0321472330bfdeb14 ||bf08fe4028a8eb8dfbd7fa Resolution|NOT A BUG |FIXED --- Comment #2 from Thomas Schöps --- Git commit c0321472330bfdeb14bf08fe4028a8eb8dfbd7fa by Thomas Schoeps. Committed on 08/07/2019 at 17:19. Pushed by thomassc into branch 'master'. Add setting to enable/disable text drag-and-drop (on by default) Summary: This change adds a setting to enable or disable the ability to move the selected text by drag-and-drop. It is on by default, which means the default behavior is not changed. Disabling this setting is useful for people like me who generally use Ctrl-X/V for moving text. For those, the drag-and-drop is never intended, but sometimes triggered accidentally, so it is good to be able to remove this pitfall. Test Plan: I tested it manually. Reviewers: #ktexteditor, cullmann Reviewed By: #ktexteditor, cullmann Subscribers: ahmadsamir, dhaumann, cullmann, kwrite-devel, kde-frameworks-devel Tags: #kate, #frameworks Differential Revision: https://phabricator.kde.org/D22315 M +7-0src/dialogs/editconfigwidget.ui M +3-0src/dialogs/katedialogs.cpp M +1-0src/utils/kateconfig.cpp M +6-0src/utils/kateconfig.h M +2-2src/view/kateviewinternal.cpp https://commits.kde.org/ktexteditor/c0321472330bfdeb14bf08fe4028a8eb8dfbd7fa -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 364239] Snippet keyboard shortcut doesn't work
https://bugs.kde.org/show_bug.cgi?id=364239 Thomas Schöps changed: What|Removed |Added CC||tom.scho...@gmail.com --- Comment #6 from Thomas Schöps --- The shortcut for a new snippet not working, and shortcuts in general not working while the snippets tool view is minimized should be fixed now: https://phabricator.kde.org/D22309 https://phabricator.kde.org/D22308 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 404907] ktexteditor: lineheight regression
https://bugs.kde.org/show_bug.cgi?id=404907 --- Comment #7 from Thomas Schöps --- Thanks for adding the image. Comparing the correct and the incorrect version in GIMP, it seems that the patch causes no difference in line height for the font used here. So, the problem must come from the other part of the change: the removal of the second drawing pass workaround. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 404907] ktexteditor: lineheight regression
https://bugs.kde.org/show_bug.cgi?id=404907 --- Comment #5 from Thomas Schöps --- It seems that both uploaded images are the same and both show the incorrect state. I couldn't reproduce this here since the emojis fit into the line with the font that is used here. I am wondering whether the emojis already extended beyond the line height before, but that was hidden by the workaround with the second drawing pass that was applied there. To determine this, it might perhaps be helpful to have a screenshot of the correct state in which the cursor is in one of the lines with an emoji (since this line's background should be of a different color then, making the line height visible). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 403868] Bottom of text lines is sometimes cut off
https://bugs.kde.org/show_bug.cgi?id=403868 --- Comment #7 from Thomas Schöps --- Could it be that the real issue here is that there is a mismatch between the line height used in KTextEditor and the line height used internally in Qt for drawing? I had a look at https://github.com/qt/qtbase/blob/5.12/src/gui/text/qtextlayout.cpp (line 2270 at the moment) where the text height is set as: qreal height = maxY + fontHeight - minY; with fontHeight: qreal fontHeight = font.ascent() + font.descent(); For testing I then replaced the font height setting in KateRenderer::updateFontHeight() to match this with: m_fontHeight = qMax(1, qCeil(config()->fontMetrics().ascent() + config()->fontMetrics().descent())); The old resulting value was 14, the new one 15. From some short testing it seems that this makes the related issues disappear (at least for the font that is used on my system by default). I don't have more time to look into this right now though. The Qt code also seems to have a mechanism to adjust the font height according to the glyphs somehow (with maxY and minY). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 403868] Bottom of text lines is sometimes cut off
https://bugs.kde.org/show_bug.cgi?id=403868 --- Comment #4 from Thomas Schöps --- I am using Qt 5.12.0 (both for compiling and at runtime according to the libraries tab in KWrite's about dialog). I can reproduce the behavior described in the bugreport you linked as well. Indeed, it seems like this might have the same issue (perhaps not redrawing the full height of text lines?). As I described, it also happens in other cases though, not only for the last line. And these cases seem more severe, as it might e.g. make underscores invisible. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 403868] Bottom of text lines is sometimes cut off
https://bugs.kde.org/show_bug.cgi?id=403868 --- Comment #1 from Thomas Schöps --- Created attachment 117791 --> https://bugs.kde.org/attachment.cgi?id=117791&action=edit Screenshot showing another way the bug seems to show up Another way this bug seems to show up is if doing a multi-line text selection backwards (drag from the end to the start, not the start to the end). Single-line selections don't seem to trigger it. Then, if the multi-line selection is cleared by clicking another point in the document, the blue selection background remains at the bottom of the last line of the selection. See the second attached screenshot. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 403868] New: Bottom of text lines is sometimes cut off
https://bugs.kde.org/show_bug.cgi?id=403868 Bug ID: 403868 Summary: Bottom of text lines is sometimes cut off Product: frameworks-ktexteditor Version: unspecified Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: tom.scho...@gmail.com Target Milestone: --- Created attachment 117788 --> https://bugs.kde.org/attachment.cgi?id=117788&action=edit Screenshot showing the issue SUMMARY In recent versions of KTextEditor-based applications (KWrite, KDevelop), the bottom of text lines is sometimes cut off, to the extent that underscores become invisible. It happens to new text lines that enter the view from the top when scrolling upwards (maybe also in other cases, not sure whether this is the only trigger). When scrolling downwards, everything is fine. The behavior depends on how the scrolling is done: * When using the mouse wheel (scrolling by 3 lines at once), every 3rd line is cut off * When dragging the mouse in the minimap, almost every line is cut off * When scrolling is invoked by the cursor going beyond the top of the view, no line is cut off. When setting the cursor within some lines affected by the bug, the line with the cursor and the line above it return to normal state. This seems to be a regression, since old versions of KWrite etc. worked fine. Unfortunately, I don't know when it was introduced. The attached screenshot demonstrates the bug, showing two versions of KWrite running on the same system. On the left is a current self-compiled version of KWrite after scrolling up within the document with the mouse wheel. Every line contains the same text, including underscores. Look for the missing underscores in every 3rd line (also, the 'g's in 'testing' are cut off, so it does not only affect underscores). On the right is an old version of KWrite (I think it is the distribution-provided version of Kubuntu 14.04), for which the same actions were done, which does not show the bug. STEPS TO REPRODUCE 1. Using e.g. KWrite, write some text containing underscores that exceeds the view height 2. Starting from the bottom of the document, scroll up by dragging on the minimap 3. Text lines coming into view will be cut off VERSION Applies to recent versions of the software, including the current master, I believe. -- You are receiving this mail because: You are watching all bug changes.
