[konsole] [Bug 482481] Konsole forces full hinting (hintfull) despite both fontconfig and KDE settings
https://bugs.kde.org/show_bug.cgi?id=482481 --- Comment #7 from Matt Whitlock --- Created attachment 171664 --> https://bugs.kde.org/attachment.cgi?id=171664&action=edit an alternative fix that doesn't override fontconfig To fix the original issue without overriding the user's font configuration, the letter spacing can be adjusted to force the horizontal advance to be an integer. See the attached patch, which completely fixes the issue on my system. I now have a normal terminal font with full hinting, a bold variant of it with no hinting, and no weird space issues. In other words, Konsole's appearance now matches how it was in KDE 5. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 482481] Konsole forces full hinting (hintfull) despite both fontconfig and KDE settings
https://bugs.kde.org/show_bug.cgi?id=482481 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #6 from Matt Whitlock --- (In reply to ninjalj from comment #2) > https://invent.kde.org/utilities/konsole/-/merge_requests/911 I reverted this misguided hack, and now my Konsole respects my fontconfig again. Thanks for the tip. Now I'm wondering if Kate/KWrite's newly uglified font rendering in KDE 6 has the same root cause… -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 479891] Some text glyphs in QML software are vertically mis-aligned or squished when using a fractional scale factor
https://bugs.kde.org/show_bug.cgi?id=479891 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 484639] Fallback to Breeze ignored by KIconLoader because of wrong global initialization order
https://bugs.kde.org/show_bug.cgi?id=484639 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 464868] Create UI to generate and use a custom Libinput acceleration profile
https://bugs.kde.org/show_bug.cgi?id=464868 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 379294] Implement OSC 8 hyperlink support
https://bugs.kde.org/show_bug.cgi?id=379294 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 383379] Modernize Input Devices section to work with Libinput
https://bugs.kde.org/show_bug.cgi?id=383379 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 350688] Mouse acceleration setting has no effect with libinput
https://bugs.kde.org/show_bug.cgi?id=350688 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384695] Configurable horizontal scrolling key (ALT or SHIFT) + WHEEL
https://bugs.kde.org/show_bug.cgi?id=384695 --- Comment #9 from Matt Whitlock --- (In reply to sevens from comment #7) > Current behavior of `Shift+Wheel` (scroll an entire screen's worth of > content[…]) is also useful IMO but could maybe use a different shortcut? Personally, I would like to see the effects of Shift and Alt (on scrolling behavior of Qt/KDE applications) reversed from what they are now. Shift should scroll the alternative axis, and Alt should activate speed scrolling. That would then agree with every other GUI toolkit. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384695] Configurable horizontal scrolling key (ALT or SHIFT) + WHEEL
https://bugs.kde.org/show_bug.cgi?id=384695 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #8 from Matt Whitlock --- This behavior comes from Qt. Specifically, QXcbConnection transposes the native wheel event's scroll deltas when populating the QWheelEvent's angleDelta if the Alt modifier key is held. (Search https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp for "angleDelta.transposed()".) Then, much further down the line, QScrollView reads the angleDelta from the QWheelEvent and fires appropriate signals to the relevant scroll bar(s). So, any new configuration option would need to affect which modifier key QXcbConnection tests for while translating the native wheel events. In short, this is not the responsibility of KDE or of QScrollView but rather of QXcbConnection, which lives in QtBase. See this Qt bug: https://bugreports.qt.io/browse/QTBUG-75949 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 380454] Akonadi IMAP resource neglects to reconnect failed control socket while IDLE connection remains live
https://bugs.kde.org/show_bug.cgi?id=380454 --- Comment #2 from Matt Whitlock --- I don't use Akonadi anymore. I switched to a mail client designed for IMAP (Trojitá). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 459366] KWrite remembers cursor position when closing the file and opening it again
https://bugs.kde.org/show_bug.cgi?id=459366 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #5 from Matt Whitlock --- I'd request that restoration of the cursor position be a *variable* that can be configured per file mode. I can see it being useful for some filetypes, but it is extra annoying when I use KWrite as my $GIT_EDITOR and I start typing a Git commit message, only to discover that my cursor started up somewhere down in the comment block below the blank first line. An alternative/additional suggestion would be to restore the cursor position upon load *only if* the file modification time matches what it was when the cursor position was saved. If the file had been modified in the interim, then the saved cursor position likely is garbage and should be disregarded. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 423920] Erroneous lambda expression crashes KDevelop in C++17 mode with clang 10.0.1
https://bugs.kde.org/show_bug.cgi?id=423920 Matt Whitlock changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #3 from Matt Whitlock --- My "Steps To Reproduce" no longer reproduce the crash on KDevelop 5.9.220802, so I'd guess this bug was fixed at some point. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 Matt Whitlock changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #33 from Matt Whitlock --- I'm the original reporter on this bug. This is no longer affecting me. I haven't had to manually open/start KDE Connect on my phone within my recollection. It Just Works™. And I'm no longer using the workaround of locking the app in my app switcher. I don't see a persistent notification for it, but maybe I hid that at some point. Irregardless¹, I currently have no complaints. __ ¹ “‘Irregardless’ isn't even a word.” “Yes, it is; it means ‘without lack of regard.’” -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 109374] Having mouse buttons or scrolls be usable as hotkeys in KGlobalAccel
https://bugs.kde.org/show_bug.cgi?id=109374 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 446531] Plasma crashed inMpris2Engine::serviceOwnerChanged() after closing all running apps with middle-click on their entries in task manager
https://bugs.kde.org/show_bug.cgi?id=446531
Matt Whitlock changed:
What|Removed |Added
CC||k...@mattwhitlock.name
--- Comment #4 from Matt Whitlock ---
I think I experienced the same issue on Plasma Frameworks 5.91.0, Plasma
Workspace 5.24.2…
Application: Plasma (plasmashell), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 QHashData::nextNode (node=node@entry=0x55e5ee669d10) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/tools/qhash.cpp:591
#7 0x7f96f4bf8e49 in QHash::iterator::operator++ (this=) at
/usr/include/qt5/QtCore/qhash.h:351
#8 QHash::erase (this=0x7f96b4098db8,
it=it@entry=...) at /usr/include/qt5/QtCore/qhash.h:879
#9 0x7f96f4bf82af in QHash::erase
(it=..., this=) at /usr/include/qt5/QtCore/qhash.h:409
#10 Plasma::DataEngine::removeSource (this=this@entry=0x55e5ec114dd0,
source=...) at ../plasma-framework-5.91.0/src/plasma/dataengine.cpp:295
#11 0x7f96b1087a3f in Mpris2Engine::serviceOwnerChanged
(this=0x55e5ec114dd0, serviceName=..., oldOwner=..., newOwner=...) at
../plasma-workspace-5.24.2/dataengines/mpris2/mpris2engine.cpp:71
#12 0x7f96b10896eb in QtPrivate::FunctorCall, QtPrivate::List, void, void
(Mpris2Engine::*)(QString const&, QString const&, QString const&)>::call
(arg=, o=, f=) at
/usr/include/qt5/QtCore/qobjectdefs_impl.h:152
#13 QtPrivate::FunctionPointer::call, void> (arg=, o=, f=) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:185
#14 QtPrivate::QSlotObject, void>::impl (which=, this_=,
r=, a=, ret=) at
/usr/include/qt5/QtCore/qobjectdefs_impl.h:418
#15 0x7f96f2afe805 in QtPrivate::QSlotObjectBase::call (a=0x7ffe00d38570,
r=0x55e5ec114dd0, this=0x55e5ecc31d60) at
../../include/QtCore/../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qobjectdefs_impl.h:398
#16 doActivate (sender=0x55e5ec420890, signal_index=5,
argv=0x7ffe00d38570) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qobject.cpp:3886
#17 0x7f96f2af81af in QMetaObject::activate
(sender=sender@entry=0x55e5ec420890, m=m@entry=0x7f96f34ba6a0
,
local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x7ffe00d38570)
at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qobject.cpp:3946
#18 0x7f96f349c1b8 in QDBusServiceWatcher::serviceOwnerChanged
(this=this@entry=0x55e5ec420890, _t1=..., _t2=..., _t3=...) at
.moc/moc_qdbusservicewatcher.cpp:242
#19 0x7f96f349cb1a in QDBusServiceWatcherPrivate::_q_serviceOwnerChanged
(newOwner=..., oldOwner=..., service=..., this=) at
../../../qtbase-c2ea67ecefe049f6e9bb8f910d7f9c60319d8619/src/dbus/qdbusservicewatcher.cpp:76
#20 QDBusServiceWatcher::qt_static_metacall (_o=, _c=, _id=, _a=) at
.moc/moc_qdbusservicewatcher.cpp:116
#21 0x7f96f349cfab in QDBusServiceWatcher::qt_metacall
(this=0x55e5ec420890, _c=QMetaObject::InvokeMetaMethod, _id=3,
_a=0x7ffe00d386d0) at .moc/moc_qdbusservicewatcher.cpp:197
#22 0x7f96f3445a0a in QDBusConnectionPrivate::deliverCall (this=, object=, msg=..., metaTypes=..., slotIdx=)
at
../../include/QtCore/../../../qtbase-c2ea67ecefe049f6e9bb8f910d7f9c60319d8619/src/corelib/tools/qvarlengtharray.h:190
#23 0x7f96f2af4f0e in QObject::event (this=0x55e5ec420890,
e=0x7f96e0147820) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qobject.cpp:1314
#24 0x7f96f3807edf in QApplicationPrivate::notify_helper (this=, receiver=0x55e5ec420890, e=0x7f96e0147820) at
../../../qtbase-c9fde86b0a2440133bc08f4811b6ca793be47f0a/src/widgets/kernel/qapplication.cpp:3632
#25 0x7f96f2aca60a in QCoreApplication::notifyInternal2
(receiver=0x55e5ec420890, event=0x7f96e0147820) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qcoreapplication.cpp:1064
#26 0x7f96f2acd373 in QCoreApplicationPrivate::sendPostedEvents
(receiver=0x0, event_type=0, data=0x55e5ebc97e20) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qcoreapplication.cpp:1821
#27 0x7f96f2b1ee43 in postEventSourceDispatch (s=0x55e5ebd6cf20) at
../../../qtbase-f4ac0b55c37f2b594ffbe639db43dac365825c7c/src/corelib/kernel/qeventdispatcher_glib.cpp:277
#28 0x7f96f0f5f4cc in g_main_dispatch (context=0x7f96e8005000) at
../glib-2.70.4/glib/gmain.c:3381
#29 g_main_context_dispatch (context=0x7f96e8005000) at
../glib-2.70.4/glib/gmain.c:4099
#30 0x7f96f0f5f738 in g_main_context_iterate
(context=context@entry=0x7f96e8005000, block=block@entry=1,
dispatch=dispatch@entry=1, self=) at
../glib-2.70.4/glib/gmain.c:4175
#31 0x7f96f0f5f7df in g_main_context_iteration (context=0x7f96e8005000,
may_block=1) at ../glib-2.70.4/glib/gmain.c:4240
#32 0x7f96f2b1e508 in QEventDispatcherGlib::processEvents
(this=0x55e5ebd72eb0, flags=..
[kwin] [Bug 450118] Regression: KWin 5.24.0 renders window borders with gradient in wrong direction
https://bugs.kde.org/show_bug.cgi?id=450118 Matt Whitlock changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Matt Whitlock --- Confirming that 86da8e9e369523939a3e7a1ad2eade4ee2457105 fixes the problem for me. https://invent.kde.org/plasma/kwin/-/commit/86da8e9e369523939a3e7a1ad2eade4ee2457105 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450118] Regression: KWin 5.24.0 renders window borders with gradient in wrong direction
https://bugs.kde.org/show_bug.cgi?id=450118 --- Comment #2 from Matt Whitlock --- Git bisection reveals 3b4d5583713e4dbba046cc79f02c6c8c356ed43b as the culprit. https://invent.kde.org/plasma/kwin/-/commit/3b4d5583713e4dbba046cc79f02c6c8c356ed43b -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450118] Regression: KWin 5.24.0 renders window borders with gradient in wrong direction
https://bugs.kde.org/show_bug.cgi?id=450118 --- Comment #1 from Matt Whitlock --- Created attachment 146653 --> https://bugs.kde.org/attachment.cgi?id=146653&action=edit KCalc on KWin 5.24.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450118] New: Regression: KWin 5.24.0 renders window borders with gradient in wrong direction
https://bugs.kde.org/show_bug.cgi?id=450118 Bug ID: 450118 Summary: Regression: KWin 5.24.0 renders window borders with gradient in wrong direction Product: kwin Version: 5.24.0 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: k...@mattwhitlock.name Target Milestone: --- Created attachment 146652 --> https://bugs.kde.org/attachment.cgi?id=146652&action=edit KCalc on KWin 5.23.5 SUMMARY See the attached comparison. The only system changes between the two screenshots were upgrading KWaylandServer and KWin from 5.23.5 to 5.24.0. (KWin 5.23.5 won't build against KWaylandServer 5.24.0.) The left and right window borders appear to have their gradients painted left-to-right rather than top-to-bottom. STEPS TO REPRODUCE 1. Install KWin 5.24.0. 2. Choose Oxygen as your window decoration style. OBSERVED RESULT Left and right window borders have gradients painted left-to-right with brighter edge on the left. EXPECTED RESULT Left and right window borders have gradients painted top-to-bottom with brighter edge at the top. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 441551] plasmashell leaks memory over time
https://bugs.kde.org/show_bug.cgi?id=441551 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #4 from Matt Whitlock --- To all who are experiencing this issue, please retest with Plasma Frameworks 5.86.0 or newer. https://invent.kde.org/frameworks/plasma-framework/-/commit/73782c8b39d1cc41fef003acca8df75ccdf384e4 -- You are receiving this mail because: You are watching all bug changes.
[trojita] [Bug 365299] make transition from qtwebkit to qtwebengine
https://bugs.kde.org/show_bug.cgi?id=365299 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #21 from Matt Whitlock --- As of 2 Aug 2021, Gentoo has hard-masked Trojitá due to unpatched security vulnerabilities in QtWebkit. Of course I can manually unmask the ebuilds and eventually copy them into a local repo when Gentoo deletes them, but I fear it's only a matter of time before someone figures out a remote-code-execution vulnerability that's exploitable via Trojitá's HTML email viewer, and with no further updates to QtWebkit indefinitely, running Trojitá is going to become a liability. I second the sentiment that I would prefer to continue using Trojitá even without support for rendering HTML mail parts. Maybe QtWebkit can be ripped out and replaced with nothing if it's too hard to switch to QtWebEngine? No other mail clients are even remotely usable. Trojitá isn't perfect, but it's the best there is. :( (In reply to Thomas Rohloff from comment #20) > What about trojita saving the html to /tmp, then opening it with an external > browser from there? That doesn't work because there would be no way to pass attached parts to the external browser (e.g., for images). Jan mentioned this in Comment 6. -- You are receiving this mail because: You are watching all bug changes.
[Heaptrack] [Bug 439897] Heaptrack produces impossible/incorrect stack traces
https://bugs.kde.org/show_bug.cgi?id=439897 --- Comment #6 from Matt Whitlock --- (In reply to Milian Wolff from comment #5) > can you please try the latest master and see if you are still seeing this > breakage? Yes, that fixed it. I no longer get nonsense traces in Heaptrack, and I actually managed to find and patch that leak in plasmashell! > Quite frankly, I'm super stumped by this breakage as I mentioned in the > commit message for the workaround I implemented now... I think it should be expected that the instruction pointer addresses that are on the stack should point at the instruction just after the call instruction, as that's how the hardware works. (The call instruction pushes the address of the *next* instruction before branching to the target of the call. That saves having to re-decode the call instruction upon later return from the subroutine to determine how large the call instruction's operand is and thus where the next instruction begins.) > I just wonder how it could ever have worked at this > stage. Considering how many people have used heaptrack in the past... Maybe Heaptrack's stack traces have been "good enough," or maybe libunwind used to adjust the IPs in the stack trace to point at the call instructions but stopped doing that at some point. Technically, I am not sure that subtracting a constant 1 from the addresses is quite valid, as then you'll end up pointing at part of the call instruction's operand rather than at the call instruction's opcode, but maybe that's good enough to determine an accurate source code location for the function call. -- You are receiving this mail because: You are watching all bug changes.
[Heaptrack] [Bug 439897] Heaptrack produces impossible/incorrect stack traces
https://bugs.kde.org/show_bug.cgi?id=439897 --- Comment #2 from Matt Whitlock --- (In reply to Milian Wolff from comment #1) > Since you are using gentoo: Are the debug symbols you are using for > plasmashell and qt and so forth matching the build that you profiled? Yes. The debug symbols get installed (beneath /usr/lib/debug) at the same time as the binaries are installed to the live file system by the package manager. The debug symbols are produced in the same build process that produces the executable/library binaries and are then split apart from the binaries to be filed separately. Gentoo doesn't use separate packages for debug symbols like some distros do. > Is this easily reproducible for me somehow? I'm not sure. Have you tried Heaptrack with GCC 11 yet? I am thinking there may be an issue with the debug info that the compiler is generating, as I am seeing impossible stack traces in GDB while interactively debugging my own programs too. What I observe is that a stack frame will show as belonging to a leaf function that has already returned, and in fact the frame that called the leaf function is not represented separately in the stack trace, but rather the frame that shows as the leaf function *is* the frame that called the leaf function, and the information about the caller of the leaf function is absent from the stack trace. It is as though GCC is *overwriting* the source location information in the current stack frame when it invokes the (presumably inlined) leaf function and then forgets to restore it when it's finished with the leaf function. That would explain why my Heaptrack output is making no sense to me and has been utterly useless for tracking down a memory leak. -- You are receiving this mail because: You are watching all bug changes.
[Heaptrack] [Bug 439897] New: Heaptrack produces impossible/incorrect stack traces
https://bugs.kde.org/show_bug.cgi?id=439897 Bug ID: 439897 Summary: Heaptrack produces impossible/incorrect stack traces Product: Heaptrack Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: m...@milianw.de Reporter: k...@mattwhitlock.name Target Milestone: --- SUMMARY I'm trying to use Heaptrack to find a memory leak in plasmashell, but Heaptrack is producing some nonsensical stack traces that purport to contain impossible calls. STEPS TO REPRODUCE 1. heaptrack plasmashell 2. (use plasmashell for a bit to exercise a suspected leak) 3. kquitapp5 plasmashell 4. heaptrack --analyze heaptrack.plasmashell.*.zst or heaptrack_print heaptrack.plasmashell.*.zst OBSERVED RESULT Analysis contains "impossible" stack traces like (for example): 94095 calls with 0B peak consumption from: QString::reallocData(unsigned int, bool) at ../../../qtbase-everywhere-src-5.15.2/src/corelib/text/qstring.cpp:2372 in /usr/lib64/libQt5Core.so.5 QString::resize(int) at ../../../qtbase-everywhere-src-5.15.2/src/corelib/text/qstring.cpp:2289 in /usr/lib64/libQt5Core.so.5 std::__atomic_base<>::load(std::memory_order) const at /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:481 in /usr/lib64/libQt5Core.so.5 int QAtomicOps<>::loadRelaxed<>(std::atomic<> const&) at ../../../qtbase-everywhere-src-5.15.2/include/QtCore/../../src/corelib/thread/qatomic_cxx11.h:239 QBasicAtomicInteger<>::loadRelaxed() const at ../../../qtbase-everywhere-src-5.15.2/include/QtCore/../../src/corelib/thread/qbasicatomic.h:107 QtPrivate::RefCount::isShared() const at ../../../qtbase-everywhere-src-5.15.2/include/QtCore/../../src/corelib/tools/qrefcount.h:101 QString::detach() at ../../../qtbase-everywhere-src-5.15.2/include/QtCore/../../src/corelib/text/qstring.h:1088 QString::data() at ../../../qtbase-everywhere-src-5.15.2/include/QtCore/../../src/corelib/text/qstring.h:1084 operator>>(QDataStream&, QString&) at ../../../qtbase-everywhere-src-5.15.2/src/corelib/text/qstring.cpp:10418 QDataStream& QtPrivate::readArrayBasedContainer<>(QDataStream&, QVector<>&) at /usr/include/qt5/QtCore/qdatastream.h:257 in /usr/lib64/libKF5Service.so.5 KServicePrivate::load(QDataStream&) at ../kservice-5.84.0/src/services/kservice.cpp:324 in /usr/lib64/libKF5Service.so.5 KService::KService(QDataStream&, int) at ../kservice-5.84.0/src/services/kservice.cpp:384 in /usr/lib64/libKF5Service.so.5 KServiceFactory::createEntry(int) const at ../kservice-5.84.0/src/services/kservicefactory.cpp:207 in /usr/lib64/libKF5Service.so.5 KServiceFactory::serviceOffers(int, int) at ../kservice-5.84.0/src/services/kservicefactory.cpp:301 in /usr/lib64/libKF5Service.so.5 KServiceTypeTrader::defaultOffers(QString const&, QString const&) const at ../kservice-5.84.0/src/services/kservicetypetrader.cpp:114 in /usr/lib64/libKF5Service.so.5 KServiceTypeTrader::query(QString const&, QString const&) const at ../kservice-5.84.0/src/services/kservicetypetrader.cpp:144 in /usr/lib64/libKF5Service.so.5 QString::~QString() at /usr/include/qt5/QtCore/qstring.h:1307 in /usr/lib64/libnotificationmanager.so.1 NotificationManager::Notification::Private::serviceForDesktopEntry(QString const&) at /usr/include/qt5/QtCore/qstring.h:1307 QExplicitlySharedDataPointer<>::operator bool() const at /usr/include/qt5/QtCore/qshareddata.h:176 in /usr/lib64/libnotificationmanager.so.1 NotificationManager::Notification::Private::setDesktopEntry(QString const&) at ../plasma-workspace-5.22.3/libnotificationmanager/notification.cpp:303 QString::~QString() at /usr/include/qt5/QtCore/qstring.h:1307 in /usr/lib64/libnotificationmanager.so.1 NotificationManager::Notification::Private::processHints(QMap<> const&) at ../plasma-workspace-5.22.3/libnotificationmanager/notification.cpp:345 NotificationManager::ServerPrivate::Notify(QString const&, unsigned int, QString const&, QString const&, QString const&, QStringList const&, QMap<> const&, int) at ../plasma-workspace-5.22.3/libnotificationmanager/server_p.cpp:184 in /usr/lib64/libnotificationmanager.so.1 NotificationsAdaptor::Notify(QString const&, unsigned int, QString const&, QString const&, QString const&, QStringList const&, QMap<> const&, int) at libnotificationmanager/notificationsadaptor.cpp:70 in /usr/lib64/libnotificationmanager.so.1 NotificationsAdaptor::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) at libnotificationmanager/notificationsadaptor.moc:185 in /usr/lib64/libnotificationm
[Heaptrack] [Bug 439307] New: heaptrack launch script help text shows wrong option name for --output-file
https://bugs.kde.org/show_bug.cgi?id=439307 Bug ID: 439307 Summary: heaptrack launch script help text shows wrong option name for --output-file Product: Heaptrack Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: m...@milianw.de Reporter: k...@mattwhitlock.name Target Milestone: --- The output from "heaptrack --help" claims the existence of an option "-o, --output", but actually trying to specify an "--output" argument yields: Error: Debuggee "--output" was not found. Examining the script source reveals that the actual name of the long option is "--output-file". The usage help text should be corrected. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 423920] New: Erroneous lambda expression crashes KDevelop in C++17 mode with clang 10.0.1
https://bugs.kde.org/show_bug.cgi?id=423920
Bug ID: 423920
Summary: Erroneous lambda expression crashes KDevelop in C++17
mode with clang 10.0.1
Product: kdevelop
Version: 5.5.2
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: Language Support: CPP (Clang-based)
Assignee: kdevelop-bugs-n...@kde.org
Reporter: k...@mattwhitlock.name
Target Milestone: ---
SUMMARY
The presence of a certain erroneous lambda expression in C++ source code is
enough to crash KDevelop when parsing using the "c++17" profile.
STEPS TO REPRODUCE
1. Create a new empty C++ project.
2. Add a file "bug.cpp" with the following contents:
struct NotCopyable {
NotCopyable(const NotCopyable &) = delete;
NotCopyable & operator=(const NotCopyable &) = delete;
};
auto foo(const NotCopyable &bug) {
return [bug]() { };
}
3. Set project's C++ Profile to "c++17".
OBSERVED RESULT
KDevelop crashes (SIGSEGV) with the following backtrace:
#0 0x7fff7e0158e4 in clang::cxcursor::MakeCXCursor(clang::Stmt const*,
clang::Decl const*, CXTranslationUnitImpl*, clang::SourceRange) [clone
.localalias] () from /usr/lib/llvm/10/lib64/libclang.so.10
#1 0x7fff7dfec565 in
clang::cxcursor::CursorVisitor::EnqueueWorkList(llvm::SmallVector&, clang::Stmt const*) () from /usr/lib/llvm/10/lib64/libclang.so.10
#2 0x7fff7e000acc in clang::cxcursor::CursorVisitor::Visit(clang::Stmt
const*) () from /usr/lib/llvm/10/lib64/libclang.so.10
#3 0x7fff7e00024c in
clang::cxcursor::CursorVisitor::RunVisitorWorkList(llvm::SmallVector&) () from /usr/lib/llvm/10/lib64/libclang.so.10
#4 0x7fff7e000ad7 in clang::cxcursor::CursorVisitor::Visit(clang::Stmt
const*) () from /usr/lib/llvm/10/lib64/libclang.so.10
#5 0x7fff7dffa7cb in
clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) () from
/usr/lib/llvm/10/lib64/libclang.so.10
#6 0x7fff7e00269e in clang_visitChildren () from
/usr/lib/llvm/10/lib64/libclang.so.10
#7 0x7fff91daa900 in (anonymous
namespace)::Visitor::buildCompoundStatement<(CXCursorKind)144> (cursor=...,
this=) at
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/g++-v10/bits/move.h:101
#8 (anonymous namespace)::visitCursor (cursor=..., parent=...,
data=0x7fffabffea80) at
../kdevelop-5.5.2/plugins/clang/duchain/builder.cpp:1592
#9 0x7fff7e0006de in
clang::cxcursor::CursorVisitor::RunVisitorWorkList(llvm::SmallVector&) () from /usr/lib/llvm/10/lib64/libclang.so.10
#10 0x7fff7e000ad7 in clang::cxcursor::CursorVisitor::Visit(clang::Stmt
const*) () from /usr/lib/llvm/10/lib64/libclang.so.10
#11 0x7fff7dffa7cb in
clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) () from
/usr/lib/llvm/10/lib64/libclang.so.10
#12 0x7fff7e00269e in clang_visitChildren () from
/usr/lib/llvm/10/lib64/libclang.so.10
#13 0x7fff91daa900 in (anonymous
namespace)::Visitor::buildCompoundStatement<(CXCursorKind)144> (cursor=...,
this=) at
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/g++-v10/bits/move.h:101
#14 (anonymous namespace)::visitCursor (cursor=..., parent=...,
data=0x7fffabffea80) at
../kdevelop-5.5.2/plugins/clang/duchain/builder.cpp:1592
#15 0x7fff7dffacae in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool)
() from /usr/lib/llvm/10/lib64/libclang.so.10
#16 0x7fff7dfff7c8 in
clang::cxcursor::CursorVisitor::VisitFunctionDecl(clang::FunctionDecl*) () from
/usr/lib/llvm/10/lib64/libclang.so.10
#17 0x7fff7dffa837 in
clang::cxcursor::CursorVisitor::VisitChildren(CXCursor) () from
/usr/lib/llvm/10/lib64/libclang.so.10
#18 0x7fff7e00269e in clang_visitChildren () from
/usr/lib/llvm/10/lib64/libclang.so.10
#19 0x7fff91d8fdb2 in (anonymous
namespace)::Visitor::buildDeclaration<(CXCursorKind)8,
KDevelop::FunctionDefinition, true> (this=this@entry=0x7fffabffea80,
cursor=...) at
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/include/g++-v10/bits/move.h:101
#20 0x7fff91dac14d in (anonymous
namespace)::Visitor::dispatchCursor<(CXCursorKind)8, (Decision)1, (Decision)0>
(parent=..., cursor=..., this=0x7fffabffea80) at
../kdevelop-5.5.2/plugins/clang/duchain/builder.cpp:942
#21 (anonymous namespace)::Visitor::dispatchCursor<(CXCursorKind)8>
(parent=..., cursor=..., this=0x7fffabffea80) at
../kdevelop-5.5.2/plugins/clang/duchain/builder.cpp:936
#22 (anonymous namespace)::visitCursor (cursor=..., parent=...,
data=0x7fffabffea80) at
../kdevelop-5.5.2/plugins/clang/duchain/builder.cpp:1549
#23 0x7fff7dffacae in clang::cxcursor::CursorVisitor::Visit(CXCursor, bool)
() from /usr/lib/llvm/10/lib64/libclang.so.10
#24 0x7fff7dffb6d5 in
clang::cxcursor::CursorVisitor::handleDeclForVisitation(clang::Decl const*) ()
from /usr/lib/llvm/10/lib64/libclang.so.10
#25 0x7fff7dffb8d8 in
clang::cxcursor::CursorVisitor::VisitDeclContext(clang::DeclContext*) () from
/usr/lib/llvm/10/lib64/libclang.so.10
#26
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704 --- Comment #6 from Matt Whitlock --- (In reply to Aaron Puchert from comment #5) > I hope you don't mind. Not at all! I'm glad you were able to come up with an incantation that makes Clang crash when run from the command line. Thanks for catching my pass and running with it. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421704] `#include ` with parser set to c++2a causes a crash
https://bugs.kde.org/show_bug.cgi?id=421704 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #4 from Matt Whitlock --- The crash occurs because includes , which includes a code pattern that triggers a bug. For a minimal reproducer, see Bug 422716 Comment 2. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 422716] using gcc10 as compiler while including crashes kdevelop
https://bugs.kde.org/show_bug.cgi?id=422716
Matt Whitlock changed:
What|Removed |Added
CC||k...@mattwhitlock.name
--- Comment #2 from Matt Whitlock ---
The following is a minimal reproducer of the crash...
/* BEGIN bug.h */
#include
template
concept Foo = true;
template
struct Bug
{
template T>
Bug(T&&) requires true
{ }
template T>
Bug(T&&)
{ }
};
template
Bug(T1, T2) -> Bug;
/* END bug.h */
/* BEGIN bug.cpp */
#include "bug.h"
/* END bug.cpp */
Place bug.h and bug.cpp in a KDevelop project in C++2a mode. Kaboom!
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 171295] Allow shortcuts for input devices other than the keyboard (mouse, lirc, bluetooth, joystick, etc)
https://bugs.kde.org/show_bug.cgi?id=171295 --- Comment #26 from Matt Whitlock --- (In reply to Nate Graham from comment #25) > I'd really like this particularly for the case of many-button mice. I'd like > to be able to assign the side keys to "next/previous" tab. I have a mouse with 12 evdev buttons (scroll up and scroll down are "buttons," even though they're physically triggered by a wheel), and I use 'xbindkeys' and 'xte' to map them all to useful actions. I have 'xbindkeys' in my session's 'autostart' configuration, and my ~/.xbindkeys contains the following: "xte 'key XF86Back'" b:8 "xte 'key XF86Forward'" b:9 "xte 'key XF86Search'" b:10 "xte 'keydown Super_L' 'key Prior' 'keyup Super_L'" b:11 "xte 'keydown Super_L' 'key Next' 'keyup Super_L'" b:12 "xte 'keydown Control_L' 'key Prior' 'keyup Control_L'" b:13 "xte 'keydown Control_L' 'key Next' 'keyup Control_L'" b:14 "killall -HUP gpg-agent ; dbus-send --type=method_call --dest=org.kde.kwalletd5 /modules/kwalletd5 org.kde.KWallet.closeAllWallets ; dbus-send --type=method_call --dest=org.kde.kwalletd /modules/kwalletd org.kde.KWallet.closeAllWallets ; dbus-send --type=method_call --dest=org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver.Lock ; sleep 1 ; xset dpms force off" Release + XF86Sleep "sleep 1 ; xset dpms force off" Shift + Release + XF86Sleep This gives me the following mappings: - Rocking the school wheel to the left or right switches to the previous or next tab in most applications. - Clicking the button above or below the scroll wheel switches to the next or previous virtual desktop. - Pushing the forward or back thumb button goes forward or back in the navigation history of web browsers, file explorers, and some other apps. - Pushing the center side button presents all windows in KWin. (I have XF86Search configured as a hotkey in KWin.) - Pressing the Sleep key on my keyboard locks all wallets, locks my session, and turns off my monitor. - Pressing Shift+Sleep just turns off my monitor. I've used this configuration (and mouse) for over a decade with great success. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 363932] Device Notifier fails to ignore LUKS volume despite solid rules
https://bugs.kde.org/show_bug.cgi?id=363932 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #3 from Matt Whitlock --- I have the same issue, though my LUKS volumes are non-removable (and I have Device Notifier configured to show all devices). Despite that I have set UDISKS_IGNORE="1" on my LUKS volumes, Device Notifier still shows them. As in Comment 2, solid-hardware5 shows 'StorageAccess.ignored' and 'StorageVolume.ignored' are both true. Device Notifier respects the 'ignored' hints on my non-LUKS volumes, but it apparently ignores the hint on LUKS volumes. I am on Plasma 5.18.3. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 416001] Font Preview in profile settings window does not display font in monospace style
https://bugs.kde.org/show_bug.cgi?id=416001 --- Comment #9 from Matt Whitlock --- I haven't upgraded Qt yet, but my expectation is that this bug is no more. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 416001] Font Preview in profile settings window does not display font in monospace style
https://bugs.kde.org/show_bug.cgi?id=416001 --- Comment #7 from Matt Whitlock --- Adding the following to a script in ~/.config/plasma-workspace/env/ and restarting my KDE session makes my Konsole behave correctly again: # work around https://bugreports.qt.io/browse/QTBUG-80967 export QT_ENABLE_HIGHDPI_SCALING=0 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 416001] Font Preview in profile settings window does not display font in monospace style
https://bugs.kde.org/show_bug.cgi?id=416001 --- Comment #6 from Matt Whitlock --- These reports appear to regard the exact same issue: https://phabricator.kde.org/D26185 https://bugreports.qt.io/browse/QTBUG-80967 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 416001] Font Preview in profile settings window does not display font in monospace style
https://bugs.kde.org/show_bug.cgi?id=416001 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #5 from Matt Whitlock --- Created attachment 125011 --> https://bugs.kde.org/attachment.cgi?id=125011&action=edit hinting_comparison_among_apps.png I just rebooted my system after some updates, and now I too am seeing that Konsole no longer respects my hinting configuration for DejaVu Sans Mono. I have hinting disabled system-wide except for small sizes of DejaVu Sans Mono. Here is my ~/.config/fontconfig/fonts.conf: ~/.fonts false rgb false hintnone DejaVu Sans Mono normal 15 true hintfull Fontconfig definitely picks up my override: $ fc-match -v 'Consolas' | fgrep -e hint -e file hintstyle: 0(i)(w) hinting: False(w) autohint: False(s) file: "/usr/local/share/fonts/win10/consola.ttf"(w) $ fc-match -v 'Noto Sans Mono' | fgrep -e hint -e file hintstyle: 0(i)(w) hinting: False(w) autohint: False(s) file: "/usr/share/fonts/noto/NotoSansMono-Regular.ttf"(w) $ fc-match -v 'DejaVu Sans Mono' | fgrep -e hint -e file hintstyle: 3(i)(w) hinting: True(w) autohint: False(s) file: "/usr/share/fonts/dejavu/DejaVuSansMono.ttf"(w) But Konsole ignores my override and renders DejaVu Sans Mono without hinting. Some other KDE applications, such as KCharSelect, do respect my hinting override, but others, such as Kate, do not. Chromium does. See my attached screen shot for comparisons. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 415537] Syntax highlighter fails on C++17 if-statement with initializer
https://bugs.kde.org/show_bug.cgi?id=415537
--- Comment #2 from Matt Whitlock ---
Analogous concerns apply for switch-statement with initializer.
/* BEGIN example2.cpp */
#include
#include
#include
unsigned parse_uint_clamp(const char *begin, const char *end) {
unsigned v;
switch (auto [ptr, ec] = std::from_chars(begin, end, v); ec) { // broken
case std::errc { }:
if (ptr != end) { // broken
return 0;
}
return v;
case std::errc::result_out_of_range:
return std::numeric_limits::max();
default:
throw std::system_error(std::make_error_code(ec)); // broken
}
}
/* END example2.cpp */
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 415537] New: Syntax highlighter fails on C++17 if-statement with initializer
https://bugs.kde.org/show_bug.cgi?id=415537
Bug ID: 415537
Summary: Syntax highlighter fails on C++17 if-statement with
initializer
Product: kdevelop
Version: 5.4.5
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: minor
Priority: NOR
Component: Language Support: CPP (Clang-based)
Assignee: kdevelop-bugs-n...@kde.org
Reporter: k...@mattwhitlock.name
Target Milestone: ---
SUMMARY
/* BEGIN example.cpp */
#include
#include
std::mutex mutex;
extern std::optional froop();
extern void frob(int val = 0);
void func1() {
std::unique_lock lock { mutex, std::try_to_lock }; // OK
// if-statement with expression condition
if (lock) { // OK
frob();
lock.unlock(); // OK
}
}
void func2() {
// if-statement with declaration condition
if (std::unique_lock lock { mutex, std::try_to_lock }) { // OK
frob();
lock.unlock(); // OK
}
}
void func3() {
// if-statement with initializer and expression condition
if (std::unique_lock lock { mutex, std::try_to_lock }; // broken
lock.owns_lock()) // broken
{
frob();
lock.unlock(); // broken
}
}
void func4() {
// if-statement with initializer and declaration condition
if (std::unique_lock lock { mutex }; // broken
auto optval = froop()) // OK
{
frob(*optval); // OK
lock.unlock(); // broken
}
}
/* END example.cpp */
OBSERVED RESULT
* If-statement initializers are not fully syntax highlighted. (Only
context-insensitive highlighting, such as Kate would do, is performed.)
* All variables declared via if-statement initializers are not highlighted at
subsequent uses, including within the condition expression of the if-statement.
* Note that code completion works as it should.
EXPECTED RESULT
* KDevelop's syntax highlighter should understand the C++17 if-statement with
initializer syntax.
* Local variables declared in if-statement initializers should be colored as
local variables, both when used in the succeeding if-statement conditions and
when used in the statement body/bodies.
* Note that local variables declared in if-statement initializers are in scope
throughout both the "true" body and the "false" (else) body (if there is one).
This is the same scoping rule as for if-statement declaration conditions.
SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.65.0
Qt Version: 5.14.0
--
You are receiving this mail because:
You are watching all bug changes.
[kdelibs] [Bug 255070] KUrl::populateMimeData does not escape URL copies into QMimeData
https://bugs.kde.org/show_bug.cgi?id=255070 --- Comment #8 from Matt Whitlock --- I stopped using Konqueror a long time ago because it wasn't keeping up with Chromium. I no longer keep it installed, so I have no stake in this bug report anymore. Feel free to close, as there are no other commenters reporting the same issue. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 304148] Konsole 4.8.4 crashed in CompactHistoryLine
https://bugs.kde.org/show_bug.cgi?id=304148 --- Comment #7 from Matt Whitlock --- (In reply to Andrew Crouthamel from comment #6) > re-test if the bug is valid I have no means of reproducing this crash on demand, and I have not experienced it again. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 205854] Automatic trash cleanup only triggers when a new file is trashed
https://bugs.kde.org/show_bug.cgi?id=205854 --- Comment #5 from Matt Whitlock --- Another data point. I had 3 files in my Trash with ctimes older than 90 days ago. Immediately after I checked this, I moved one file to the Trash (via the context menu in a File Open dialog in a KDE application), and then I immediately checked my Trash again and found 0 files with ctimes older than 90 days ago. So indeed trashing a file triggered the cleanup. It just doesn't trigger spontaneously. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 205854] Manual methods to trigger configured Trash cleanup
https://bugs.kde.org/show_bug.cgi?id=205854 Matt Whitlock changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #3 from Matt Whitlock --- (In reply to Nate Graham from comment #1) > Is this still the way it works with KDE Frameworks 5.45 or greater? This report still applies as of KDE Frameworks 5.51. I have my Trash configured to delete files older than 90 days, yet I still have files with ctimes older than 90 days ago in my ~/.local/share/Trash/files directory. Indeed, I still have files with ctimes older than 97 days ago. $ find ~/.local/share/Trash/files -type f -ctime +97 | wc -l 2 $ find ~/.local/share/Trash/files -type f -ctime +98 | wc -l 0 If your assertion is that there is a periodic background process that should be cleaning expired files out of the Trash, then could you tell me how often this process is supposed to run? My KDE session has been logged in continuously for the last 14 days (since 11 October), yet evidently no process has cleaned the Trash. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 372552] More than one target in Build Sequence doesn't build anything
https://bugs.kde.org/show_bug.cgi?id=372552 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #8 from Matt Whitlock --- (In reply to Jakub Schmidtke from comment #7) > And yes, I have no idea why there even IS a "build sequence" list, > if it doesn't support building multiple things... It does support building multiple *projects*. It just doesn't support building multiple *targets* within one project. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 394436] Serius memory leak when realigning folderview widget icons.
https://bugs.kde.org/show_bug.cgi?id=394436 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget with QSG_RENDER_LOOP=basic
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #120 from Matt Whitlock --- (In reply to Ovidiu Chi from comment #117) > > I am running a slideshow of 2560x1600 images every 2 seconds with > > QSG_RENDER_LOOP=basic > > @Matt, You'd have to start the slideshow then, after a little while(a few > seconds), change the duration (e.g. from 3s to 2s). Okay, I have restarted plasmashell with QSG_RENDER_LOOP=basic QSG_INFO=1, and I do indeed see this in the output: qt.scenegraph.general: QSG: basic render loop I set a slideshow at an interval of 3 seconds and started monitoring plasmashell's memory usage and VRAM usage. It has been a few minutes, and I see no extreme rise in memory usage. (Plasmashell, since it hosts a garbage-collected runtime environment, does grow in memory usage for a little while after startup until it is "warm.") Something I forgot to mention before: I do make sure to show some tooltips in the task switcher, pop up the applications menu, pop up the calendar, etc., to be certain that there are some previously rendered but now hidden windows. This was the trigger of the logic bug originally. Now I change the slideshow interval from 3 seconds to 2 seconds. I observe no extreme increase in plasmashell's memory usage or VRAM usage. Plasmashell's usage still gently rises over time, due to the other leak, which is still unaddressed, but the major VRAM leak is not present. (In reply to David Edmundson from comment #118) > Qt [switches] based on graphic driver. Some don't support GL use in threads. You would think that Mesa/Gallium/RadeonSI (AMDGPU) would be modern enough for Qt to use the threaded renderer by default, but "basic" is still the default on my system. I am going to leave the QSG_RENDER_LOOP=threaded in my session environment, as I experience no problems with it whatsoever. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget with QSG_RENDER_LOOP=basic
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #116 from Matt Whitlock --- (In reply to Ovidiu Chi from comment #114) > Matt, I'm not knowledgeable enough to say which memory leak this is, or the > precise nature of it, but scrolling the list of widgets doesn't do much for > my system as you can see in the first video in my comment #106. When I was > using KDE Neon I could get the memory usage to 1GB in a few seconds by doing > just that. The leak demonstrated by rapidly scrolling the list of available widgets occurs *much* more slowly on my system now than it used to. I too could previously get plasmashell up over 1 GB in under a minute. I tried again just now and was able to bloat it up from just under 200 MB to over 300 MB with about five minutes of scrolling the widgets list. So it's *better* but still not totally solved. The leak demonstrated by the slideshow is fully gone for me. I am running a slideshow of 2560x1600 images every 2 seconds with QSG_RENDER_LOOP=basic as I write this, and both plasmashell's memory usage and the VRAM usage (as reported by radeontop) are remaining in a narrow range. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget with QSG_RENDER_LOOP=basic
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #113 from Matt Whitlock --- (In reply to David Edmundson from comment #112) > @Matt > How can you tell what is leaking from looking at comment #0? There have been at least two distinct memory leaks discussed in this thread. The original report by Antonio Orefice is about a memory leak that occurs when Plasma renders images. Antonio posted a link to a video demonstrating the leak in Comment #59. I am able to reproduce his leak by the same method: force Plasma to paint a lot of images in a short amount of time. It will also leak just the same eventually in normal use, but it takes longer. The leak occurs even without opening the "Add Widget" panel and scrolling the list up and down like mad, but that's one quick way to reproduce it. The other leak was due to the logic error that you described in Comment #86. That leak has been fixed by https://codereview.qt-project.org/#/c/202781/. > and what do you mean by an "in-process leak". All leaks are in-process. Firstly, that's not true; it's entirely possible to leak pixmaps, and those are in the X server's process, not the X client's. But in this case, what I meant was that the leak that was fixed by calling endSync() was a leak of graphics memory, not a leak of system memory, so it wasn't accounted to the plasmashell process. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget with QSG_RENDER_LOOP=basic
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #111 from Matt Whitlock --- (In reply to Ovidiu Chi from comment #110) Plasmashell *does* still have a memory leak, but it's not the one from this bug. Actually, it *is* the one from the original report in Comment #0, but this thread morphed into being about the other leak, which has been fixed. The original, in-process (non-VRAM) memory leak still exists and can be triggered by making plasmashell repaint a lot of images, such as by aggressively scrolling the list of available widgets. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #76 from Matt Whitlock --- (In reply to Nate Graham from comment #74) > So should Qt use the threaded render loop by default, then? Or > should we? Or something else? Presumably the VRAM memory leak in the basic render loop should be found and fixed. I would stop short of suggesting that plasmashell switch to the threaded render loop by default in the meantime, as I do not know whether the threaded render loop has drawbacks. > So perhaps we need a Qt bug to track this. Was > https://bugreports.qt.io/browse/QTBUG-61754 tracking that such that it > should be re-opened, or do we need a new one? I do not know the cause of the in-process memory leak. It may be that QTBUG-61754 is not really fixed, or it may be a fault in plasmashell, or it may be something else. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #73 from Matt Whitlock --- (In reply to Nate Graham from comment #72) > So the consensus is that QSG_RENDER_LOOP=threaded doesn't fix the issue? There are two issues. QSG_RENDER_LOOP=threaded *does* avoid the VRAM memory leak but *does not* avoid the in-process memory leak. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #63 from Matt Whitlock --- (In reply to Alexander Schlarb from comment #62) > the RSS memory leak with the nVidia binary > drivers. Um, I'm using the open-source AMDGPU driver, and I can easily drive up plasmashell's VmRss by doing what Antonio did in his demo video. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #60 from Matt Whitlock --- (In reply to Antonio Orefice from comment #59) > I just made a video showing how plasma can reach about 1GB of ram usage from > 300MB in a bunch of seconds. I too can reproduce a rather serious memory leak just by scrolling the "Add Widget" panel up and down repeatedly, as you demonstrated in your video. This seems to be a separate issue from the scene graph basic render loop texture leak. This one doesn't cause VRAM usage to increase but rather causes the plasmashell process's VmRSS to increase. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #57 from Matt Whitlock --- (In reply to Marco Martin from comment #50) > can this be tried again with a more recent Qt? either the latest 5.9 or 5.10 > making sure both of these patches are in: > > https://codereview.qt-project.org/#/c/200715/ > https://codereview.qt-project.org/#/c/202781/ The second patch set (202781) is a reversion of the first patch set (200715) plus one extra line [sgrc->endSync();]. I confirm that the dev-qt/qtdeclarative-5.9.4 that is built on my Gentoo system does contain that added line. (In reply to Alexander Schlarb from comment #48) > 2. Memory usage of the offending process will be accounted correctly with > running it with `LIBGL_ALWAYS_SOFTWARE=true`, but the leaking issue will > persist I tried this and do confirm that the leak persists and is accounted to the plasmashell process. In this case, radeontop shows unchanging VRAM usage, which is not surprising, given that the rendering is happening all in software. (The transitions between wallpaper images are a lot jerkier, and CPU usage is through the roof.) It's worth noting that triggering this bug is not always so simple as starting up a plasmashell and running a slideshow. For me, it can take many minutes of running an aggressive slideshow before plasmashell starts to leak memory. Maybe this suggests that a race condition is the initial triggering event that leads into the state in which plasmashell leaks textures. Also, I'm not sure if this is a placebo effect, but it may be that mousing over the launcher icons and task manager buttons in the panel (to cause the sliding tooltips effect) may increase the likelihood of starting the memory leak. Once it starts leaking, it's dramatic and fast when you're running a slideshow wallpaper with a 1-second interval. (In reply to gertlink_nospam from comment #51) > QSG_RENDER_LOOP=threaded solves the problem here. After about 10 minutes of trying, I have been unable to trigger the leak when running plasmashell with the threaded render loop. I'll leave the slideshow wallpaper enabled (with a less aggressive, 29-minute interval), using this threaded render loop, and I'll continue to monitor for excessive VRAM usage. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838
--- Comment #55 from Matt Whitlock ---
(In reply to Alexander Schlarb from comment #54)
> `QCG_RENDER_LOOP=basic`.
It's supposed to be QSG_RENDER_LOOP. ("SG" for "scene graph.")
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 387341] Memory leak in plasma shell with 5.10.5
https://bugs.kde.org/show_bug.cgi?id=387341 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #16 from Matt Whitlock --- (In reply to Alexander Schlarb from comment #15) > I see the same symptoms including that fact > that memory seems to go “missing” until you kill plasmashell. @Alexander Schlarb: Have you tried running 'radeontop'? It's the only tool I've found so far that can report on the VRAM usage level. plasmashell definitely leaks VRAM like a sieve when it's running a slideshow. I haven't tried with LIBGL_ALWAYS_SOFTWARE=true yet, but that's a good pointer, so thanks for that. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #43 from Matt Whitlock --- (In reply to Nate Graham from comment #42) > Is there anyone using Qt 5.9.2 or beyond who can reproduce this issue? As I mentioned in comment #36 and comment #38, I am running Qt 5.9.4, and I can still easily exhaust all system memory by running a slideshow wallpaper in plasmashell. I don't know about the application icons thing. I do recall that I used to see the plasmashell process taking hundreds of megabytes of RAM and sometimes even over a gigabyte. I haven't observed that in a while. Nowadays its major memory leak appears to be in VRAM. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #40 from Matt Whitlock --- Sorry your bug report has been "derailed," Antonio, though it's very possible that the symptoms we're each observing may have the same root cause. I just installed radeontop and watched my card's VRAM usage climb rapidly while running the slideshow wallpaper in plasmashell. Stopping the slideshow did not release the VRAM. Killing plasmashell did. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #38 from Matt Whitlock --- (In reply to David Edmundson from comment #37) > Please see my requests on #34 (In reply to David Edmundson from comment #34) > If you're running < Qt5.10 or < 5.9.3 upgrade now so you have them and don't > confuse this report. (Quoting myself from comment #36) > I am running Qt 5.9.4 and Plasma 5.12.1 now > Please also report if you're using the basic or threaded render loop. You > can find out by running QSG_INFO=1 plasmashell and reading the output. qt.scenegraph.general: QSG: basic render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: texture atlas dimensions: 4096x2048 qt.scenegraph.general: R/G/B/A Buffers:8 8 8 8 qt.scenegraph.general: Depth Buffer: 24 qt.scenegraph.general: Stencil Buffer: 8 qt.scenegraph.general: Samples:-1 qt.scenegraph.general: GL_VENDOR: X.Org qt.scenegraph.general: GL_RENDERER:AMD Radeon (TM) R7 300 Series (BONAIRE / DRM 3.23.0 / 4.15.3-gentoo, LLVM 5.0.1) qt.scenegraph.general: GL_VERSION: 3.0 Mesa 17.3.3 qt.scenegraph.general: GL_EXTENSIONS: *(snip)* qt.scenegraph.general: Max Texture Size: 16384 qt.scenegraph.general: Debug context: false > Also please download the sample QML file in > https://bugreports.qt.io/browse/QTBUG-61754 and report on whether that gives > you issues. I observed no issues when I ran the sample QML file in qmlscene, but those sample images are tiny and would take a very long time to fill up VRAM, so it may not be a useful test. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 --- Comment #36 from Matt Whitlock --- Created attachment 110735 --> https://bugs.kde.org/attachment.cgi?id=110735&action=edit time-series chart demonstrating plasmashell memory leak Do we need to open a new bug report for the slideshow wallpaper issue? I am running Qt 5.9.4 and Plasma 5.12.1 now, and it most definitely is still an issue. Please see the attached chart, which visualizes the output of... • free | grep '^Mem:' • grep '^VmRSS:' /proc/"$(pgrep plasmashell)"/status ...with samples taken at 1-second intervals while manipulating plasmashell. Particularly noteworthy is that the actual plasmashell process's VmRSS hardly changed the whole time. The system is evidently not accounting the memory usage to the plasmashell process. Nevertheless, given enough time, plasmashell brings the system to its knees. (I actually had to use AltGr+SysRq+F to manually invoke the OOM killer just so I could terminate plasmashell, as my session had become unresponsive.) I would reasonably expect to see the gradually increasing "Buff/Cache" line and the gradually decreasing "Free" line, as the block cache should be caching the JPEG files as they are loaded from disk. (This is no problem, although frankly plasmashell ought to be calling posix_fadvise(2) with POSIX_FADV_DONTNEED on these files.) What I would NOT expect to see is the "Used" line increasing and the "Available" line decreasing. This suggests that memory is being consumed by something other than the block cache. My best guess is that plasmashell is not properly disposing of its textures. It takes a while for them to fill up VRAM, but then they start spilling into system RAM. I could test this hypothesis if I knew how to view how much VRAM is used/free. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 368838] plasmashell memory leak when slideshow is used for wallpaper/media frame/photo widget
https://bugs.kde.org/show_bug.cgi?id=368838 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #31 from Matt Whitlock --- I am experiencing this bug on a single monitor with the AMDGPU driver, Qt 5.9.3, and Plasma 5.11.4, running on Linux 4.14.13-gentoo. This bug has been affecting me for a few months now, plausibly since I upgraded to the Qt 5.9.x series from 5.7.1 at the end of September 2017. I have the slideshow wallpaper set to change every 29 minutes and 1 second, and I can get 1-2 weeks of use out of my desktop session until I run out of available memory and my system starts thrashing and I have to take steps (see below) to recover and continue. Memory usage seems to grow even while I am away from my computer (i.e., while it's sitting at the KDE Screen Locker with the monitor powered down). Of particular interest on my system: the majority of the memory usage isn't attributed to the plasmashell process, as reported by 'ps' and 'top'. Bizarrely, the memory usage appears to be accountable to *no process*. Because of this, it took me a long time to track it down to Plasma. I even reported a kernel bug[1], as the memory seemed to be inexplicably in use by the kernel itself: adding up the memory counters in /proc/*/status across all running processes yields a total memory usage that does not account for the complete exhaustion of MemAvailable in /proc/meminfo. How I know plasmashell is the culprit: 1. My system started to become sluggish, which happens as the kernel starts evicting pages of executable code from RAM and having to load them back in from disk. (If not immediately addressed, this condition worsens until I have no choice but to invoke the OOM killer using Magic SysRq to reclaim a little bit of memory so I can proceed with the next steps.) 2. I switched to a text-mode VT and ran 'echo 2 > /proc/sys/vm/drop_caches' as root. This elicited a short pause before the prompt reappeared, and then 'free' reported a small amount of additional available memory. 3. I killed (by SIGTERM) my plasmashell process. Some memory was immediately freed (as expected), but about 3 GB was still unaccounted for. That is, 'free' reported much more memory as "used" than the sum of all processes in my system. 4. I ran 'echo 2 > /proc/sys/vm/drop_caches' again. This time the prompt took noticeably longer to reappear. 5. Now 'free' reported a sane number for "used", which was fully attributable to the set of remaining processes running on my system. My usual procedure for recovering from the low-memory scenario is to log out of my KDE session entirely and then do the drop_caches trick to get the kernel to release the apparently unaccounted-for memory. But this time I left my session running and only killed plasmashell. That was enough to unstick the memory, and that's how I found my way to this bug report. I am a low-level C/C++ developer, but I have very little experience with OpenGL and no experience with Qt. My current (only somewhat informed) working theory is that the plasmashell process is allocating wallpapers in video memory but never freeing them and that this memory is not accounted to the process in the usual ways, as it is nominally not system RAM. However, because VRAM is limited, eventually the kernel shifts the disused wallpapers out of VRAM and into system RAM, where they sit, not accounted to any process. I do not understand why killing the plasmashell process does not immediately cause the kernel to free this memory, though. I have to tell the kernel to drop its inode+dentry caches to get the memory back. As I only get into this situation every week or two and have to address the situation immediately when it occurs, it's hard for me to try things and report back quickly, but I would gladly welcome any suggestions and will supply any information requested. Since I run Gentoo, I am able to patch sources and rebuild packages easily. At the moment, I am going to try disabling the slideshow wallpaper and see if plasmashell no longer causes this unaccountable memory usage. I will report back in a few weeks with my findings. __ [1] https://bugzilla.kernel.org/show_bug.cgi?id=197783 - Incidentally, the rogue memory pages are swappable. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 370716] Automatically overwrite closing brackets
https://bugs.kde.org/show_bug.cgi?id=370716 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #9 from Matt Whitlock --- (In reply to Sven Brauch from comment #7) > The other issue with what we're thinking about is that "has a corresponding > opening bracket" is a highly nontrival concept. What does that mean? Within > the same line? In the whole document? Do comments count? Do strings count? See my comments in Bug 368580 for a proposed solution that avoids this issue entirely. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 384404] Kate and KWrite both crash when editing a Javascript or CSS file
https://bugs.kde.org/show_bug.cgi?id=384404 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #3 from Matt Whitlock --- I too am experiencing this bug when editing JavaScript in Kate with KTextEditor 5.38.0. I seem to be able to work around the bug by setting the indentation mode to "Normal" rather than "C Style," though this of course results in a degraded user experience. -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 384476] Ktorrent Crashes on shutdown
https://bugs.kde.org/show_bug.cgi?id=384476 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 384476] Ktorrent Crashes on shutdown
https://bugs.kde.org/show_bug.cgi?id=384476 --- Comment #1 from Matt Whitlock --- Created attachment 107805 --> https://bugs.kde.org/attachment.cgi?id=107805&action=edit New crash information added by DrKonqi ktorrent (5.1.0) using Qt 5.7.1 - What I was doing when the application crashed: I was viewing the Files tree of a completed and stopped torrent when I quit the application via the File menu. This crash seems to be happening every time I quit KTorrent. -- Backtrace (Reduced): #6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #7 0x7f946297abfa in __GI_abort () at abort.c:89 [...] #9 0x7f94629c33de in malloc_printerr (action=3, str=0x7f9462abbebb "corrupted double-linked list", ptr=, ar_ptr=) at malloc.c:5077 #10 0x7f94629c44a6 in _int_free (av=0x7f9462cefae0 , p=0x22b9060, have_lock=0) at malloc.c:4012 #11 0x004bc2ca in QTypedArrayData::deallocate (data=) at /usr/include/qt5/QtCore/qarraydata.h:228 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 380454] New: Akonadi IMAP resource neglects to reconnect failed control socket while IDLE connection remains live
https://bugs.kde.org/show_bug.cgi?id=380454 Bug ID: 380454 Summary: Akonadi IMAP resource neglects to reconnect failed control socket while IDLE connection remains live Product: Akonadi Version: 5.5.1 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: IMAP resource Assignee: chrig...@fastmail.fm Reporter: k...@mattwhitlock.name CC: kdepim-b...@kde.org, vkra...@kde.org Target Milestone: --- Akonadi IMAP typically maintains two socket connections to the IMAP server: one that executes the "IDLE" command and another for all other commands. If the second connection dies while the IDLE connection remains live, then Akonadi is unable to send any commands to the server, including fetching new messages, fetching updated message flags, updating message flags, and expunging messages. This state persists indefinitely until and unless the IDLE connection dies too, at which time Akonadi then initiates a new connection. There should be no need to maintain two simultaneous connections in the first place, as the IDLE command can be aborted. Using a single connection both for idling and for other commands would almost certainly fix this bug "for free." -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #19 from Matt Whitlock --- (In reply to Theresa from comment #18) > Alas my phone (Oneplus One) only has Android 6. FYI, LineageOS 14.1 (Android 7.1) is available for the OnePlus One. LineageOS is the successor to CyanogenOS (which, if I'm not mistaken, is what the OnePlus One runs out of the box). -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 378189] kmail often stuck in "Retrieving Folder Contents"
https://bugs.kde.org/show_bug.cgi?id=378189 --- Comment #14 from Matt Whitlock --- (In reply to Matt Whitlock from comment #13) > I have the Akonadi Console open with the Job Tracker enabled now, to try to > see if any jobs hang in Akonadi. Nope. KMail has gone out to lunch again, but Akonadi Console shows all jobs have "Ended" or "Failed." -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 378189] kmail often stuck in "Retrieving Folder Contents"
https://bugs.kde.org/show_bug.cgi?id=378189 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #13 from Matt Whitlock --- (In reply to Martin Koller from comment #4) > Git commit 63ce354bbee698e3daa5d193e0b8c0e1725af9ab by Martin Koller. > Committed on 19/04/2017 at 05:00. > Pushed by mkoller into branch 'Applications/17.04'. > > On error, still send answer via DBUS, avoiding clients waiting forever This patch didn't solve the problem for me. I'm on Akonadi 17.04.0 (with this patch) and KMail 17.04.0 (5.5.0). Several times a day I find that KMail has stopped retrieving messages from my Gmail IMAP account, and there is an empty progress bar stuck at the bottom of the window. This only started happening fairly recently. (I upgraded from Akonadi 16.12.3 on 21 April, so I may try going back to that version.) I have the Akonadi Console open with the Job Tracker enabled now, to try to see if any jobs hang in Akonadi. Is there anything else I should look for to diagnose this issue? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #17 from Matt Whitlock --- (In reply to Theresa from comment #16) > @Albert/Matt: any idea what's causing my connection drops?! I never did figure it out. Upgrading to Android 7.1 made the problem disappear for me. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 338012] Eclipse crashes in debug mode and using oxygen-gtk
https://bugs.kde.org/show_bug.cgi?id=338012 --- Comment #9 from Matt Whitlock --- (In reply to David Rosenstrauch from comment #8) > IIRC, oxygen-gtk is no longer being supported. (Since the upgrade to gtk3.) GTK3 support in SWT (the GUI toolkit that Eclipse uses) is half-baked (lots of widgets appear unfinished), so I run Eclipse in GTK2 mode, which works perfectly now that I've fixed this bug in Oxygen-GTK2. > So probably best to just bite the bullet and switch to a GTK3 supported > theme, like adwaita. Oxygen is not even an option for GTK3 theme on my system. I use Breeze as my GTK3 theme, but this is irrelevant to Eclipse running in GTK2 mode. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 338012] Eclipse crashes in debug mode and using oxygen-gtk
https://bugs.kde.org/show_bug.cgi?id=338012 --- Comment #7 from Matt Whitlock --- Created attachment 104832 --> https://bugs.kde.org/attachment.cgi?id=104832&action=edit patch that fixes the bug I couldn't find a way to reference count the GtkTreeViewColumn without causing crashes in Gtk, but I did find a way to fix the bug by having Oxygen-Gtk remember the column index rather than a pointer to the column. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 338012] Eclipse crashes in debug mode and using oxygen-gtk
https://bugs.kde.org/show_bug.cgi?id=338012
Matt Whitlock changed:
What|Removed |Added
CC||k...@mattwhitlock.name
--- Comment #6 from Matt Whitlock ---
I have been experiencing this crash for years and am still seeing it in
Oxygen-Gtk2 1.4.6. Here is some more information.
#6
#7 0x7f724774a012 in IA__gtk_tree_view_get_background_area
(tree_view=tree_view@entry=0x7f72b9630b50, path=0x7f72b8a2cdb0,
column=0x7f72b92b5840, rect=rect@entry=0x7f72be2345b0) at
../../gtk+-2.24.31/gtk/gtktreeview.c:13035
#8 0x7f7247434af5 in Oxygen::Gtk::CellInfo::backgroundRect
(this=this@entry=0x7f72b9771320,
treeView=treeView@entry=0x7f72b9630b50) at
../../oxygen-gtk2-1.4.6/src/oxygengtkcellinfo.cpp:206
#9 0x7f7247425fbd in Oxygen::TreeViewStateData::dirtyRect
(this=this@entry=0x7f72b9771278)
at ../../oxygen-gtk2-1.4.6/src/animations/oxygentreeviewstatedata.cpp:129
#10 0x7f7247426130 in Oxygen::TreeViewStateData::delayedUpdate
(pointer=0x7f72b9771278)
at ../../oxygen-gtk2-1.4.6/src/animations/oxygentreeviewstatedata.cpp:176
#11 0x7f7247425c89 in Oxygen::TreeViewStateData::updateState
(this=this@entry=0x7f72b9771278, info=..., state=)
at ../../oxygen-gtk2-1.4.6/src/animations/oxygentreeviewstatedata.cpp:91
#12 0x7f7247403f0e in Oxygen::TreeViewStateEngine::get
(this=0x7f72b83329d0, widget=, info=..., options=...)
at ../../oxygen-gtk2-1.4.6/src/animations/oxygentreeviewstateengine.h:92
#13 0x7f72474ad850 in Oxygen::draw_expander (style=,
window=0x7f72b9d9ba20, state=,
clipRect=0x7f72be234840, widget=0x7f72b9630b50, detail=0x7f72477e0ba6
"treeview", x=6, y=10,
expanderStyle=GTK_EXPANDER_COLLAPSED) at
../../oxygen-gtk2-1.4.6/src/oxygenstylewrapper.cpp:2738
#14 0x7f724773d6fa in gtk_tree_view_draw_arrow
(tree_view=tree_view@entry=0x7f72b9630b50, tree=tree@entry=0x7f72b904d7d0,
node=node@entry=0x7f72b9335120, x=x@entry=0, y=y@entry=7) at
../../gtk+-2.24.31/gtk/gtktreeview.c:9576
#15 0x7f7247743ba0 in do_prelight
(tree_view=tree_view@entry=0x7f72b9630b50, tree=0x7f72b904d7d0,
node=0x7f72b9335120, x=0,
y=7) at ../../gtk+-2.24.31/gtk/gtktreeview.c:3270
#16 0x7f724774b134 in prelight_or_select
(tree_view=tree_view@entry=0x7f72b9630b50, tree=,
node=, x=, y=) at
../../gtk+-2.24.31/gtk/gtktreeview.c:3320
#17 0x7f724774da25 in gtk_tree_view_enter_notify
(widget=widget@entry=0x7f72b9630b50, event=0x7f72b8f0bca0)
at ../../gtk+-2.24.31/gtk/gtktreeview.c:5620
(gdb) frame 9
#9 0x7f7247425fbd in Oxygen::TreeViewStateData::dirtyRect
(this=this@entry=0x7f72b9771278)
at ../../oxygen-gtk2-1.4.6/src/animations/oxygentreeviewstatedata.cpp:129
129 const GdkRectangle previousRect(
_previous._info.backgroundRect( treeView ) );
(gdb) frame 8
#8 0x7f7247434af5 in Oxygen::Gtk::CellInfo::backgroundRect
(this=this@entry=0x7f72b9771320,
treeView=treeView@entry=0x7f72b9630b50) at
../../oxygen-gtk2-1.4.6/src/oxygengtkcellinfo.cpp:206
206 { gtk_tree_view_get_background_area( treeView, _path, _column,
&out ); }
(gdb) frame 7
#7 0x7f724774a012 in IA__gtk_tree_view_get_background_area
(tree_view=tree_view@entry=0x7f72b9630b50, path=0x7f72b8a2cdb0,
column=0x7f72b92b5840, rect=rect@entry=0x7f72be2345b0) at
../../gtk+-2.24.31/gtk/gtktreeview.c:13035
13035 g_return_if_fail (column == NULL || GTK_IS_TREE_VIEW_COLUMN
(column));
(gdb) print *column
$1 = {parent = {parent_instance = {g_type_instance = {g_class =
0x3f003f00}, ref_count = 0, qdata = 0xa}, flags = 0},
tree_view = 0x0, button = 0x0, child = 0x7f72b8ac0180, arrow = 0x1, alignment
= 0x7f72b8f0da30, window = 0x310fe0,
editable_widget = 0xe00, xalign = 0, property_changed_signal = 0, spacing =
-1185748944,
column_type = (GTK_TREE_VIEW_COLUMN_FIXED | unknown: 32624), requested_width
= 28, button_request = 25, resized_width = 96,
width = 0, fixed_width = 28, min_width = 25, max_width = -1184045376, drag_x
= 32626, drag_y = -1180018624, title = 0x0,
cell_list = 0x0, sort_clicked_signal = 3093474752, sort_column_changed_signal
= 32626, sort_column_id = -1188131744,
sort_order = (unknown: 32626), visible = 0, resizable = 0, clickable = 0,
dirty = 0, show_sort_indicator = 0,
maybe_reordered = 0, reorderable = 0, use_resized_width = 0, expand = 0}
As you can see, Oxygen-Gtk is attempting to check that the
Oxygen::Gtk::CellInfo::_column data member points to a valid GtkTreeViewColumn,
but the referent of the pointer has already been freed, leaving a garbage
address in g_class, which causes the G_TYPE_CHECK_INSTANCE_TYPE in
GTK_IS_TREE_VIEW_COLUMN to segfault.
Probably Oxygen::Gtk::CellInfo should not be holding onto a pointer to a
GtkTreeViewColumn instance without incrementing its reference count.
--
You are receiving this mail because:
You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #10 from Matt Whitlock --- KDE Connect has been working flawlessly for me for a while now. I am not sure whether something changed in KDE Connect or if it's due to my upgrading to LineageOS 14.1 (Android 7.1.1). My current versions: KDE Connect (KDE Frameworks 5.32.0) 1.0.3 KDE Connect (LineageOS 14.1, Android 7.1.1) 1.6.1 I can go away from home for days, and KDE Connect works fine upon my return. I can enable Airplane Mode overnight, and KDE Connect works fine when I disable Airplane Mode in the morning. Both of these used to break it. So I am not sure whether this bug still exists, but I am no longer seeing it. -- You are receiving this mail because: You are watching all bug changes.
[kio] [Bug 208625] Temporary files (for previewing files in the trash or remote files) aren't deleted
https://bugs.kde.org/show_bug.cgi?id=208625 --- Comment #38 from Matt Whitlock --- (In reply to David Faure from comment #34) > The only course of action I can suggest is that someone who can reproduce > the bug applies the patch below to their kio build and reports the results. > > http://www.davidfaure.fr/2017/previewjob.cpp.diff Okay, I applied it and reproduced the bug. When I browse to "trash:" and enable thumbnails, I get thousands of these log messages: Using temp file "/tmp/dolphin.c25868" KIO::TransferJob(0x2bb5350) for "/tmp/dolphin.c25868" Deleting temp file "/tmp/dolphin.c25868" After all the log activity subsides, I find that 1.3 GiB are now consumed in two directories inside /tmp. Both of these directory paths are reported in "Deleting temp file" messages (multiple times, presumably because the temp file names are reused). Are you certain that QFile::remove(const QString &) supports recursively removing a non-empty directory? -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 366768] Reply quote header uses UTC timestamp instead of local time zone
https://bugs.kde.org/show_bug.cgi?id=366768 --- Comment #3 from Matt Whitlock --- I have produced a patch, attached to Bug 308444, that fixes the problem of time zone information being discarded when processing these template variables. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 341909] Reply and Print time is in UTC, not in locale
https://bugs.kde.org/show_bug.cgi?id=341909 --- Comment #14 from Matt Whitlock --- I have produced a patch, attached to Bug 308444, that fixes the problem of time zone information being discarded when processing these template variables in a reply. Note: I did not attempt to address the problem when printing. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 355195] date and time are ambiguous when replying to and forwarding messages (no timezone information)
https://bugs.kde.org/show_bug.cgi?id=355195 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #4 from Matt Whitlock --- I have produced a patch, attached to Bug 308444, that fixes the problem of time zone information being discarded when processing these template variables. Note: My patch does not address the reporter's request for the introduction of UTC-forced template variables. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 308444] %OLONGTIME template variable does not yield timezone information
https://bugs.kde.org/show_bug.cgi?id=308444 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #7 from Matt Whitlock --- Created attachment 103342 --> https://bugs.kde.org/attachment.cgi?id=103342&action=edit Patch to messagelib that fixes the problem QDateTime::time() returns a QTime, which conveys no time zone information. QLocale::toString(const QTime &, QLocale::FormatType) then assumes that the passed QTime is a local time. This causes a problem when processing a template in that the time zone information of the Date header in the original message is ignored, and the time part is then reinterpreted as a local time, which is incorrect. Example illustrating the problem: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 1:31:25 PM EST QLocale apparently offers no method to format a QTime with a specific QTimeZone, so the best that can be done is to convert the QDateTime of the original message into a local time by calling QDateTime::toLocalTime(). After applying this fix, the above example becomes: Original message header: Date: Sun, 1 Jan 2017 13:31:25 -0600 %OTIMELONG in reply template expands to: 2:31:25 PM EST -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 341909] Reply and Print time is in UTC, not in locale
https://bugs.kde.org/show_bug.cgi?id=341909 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #13 from Matt Whitlock --- This still a problem in KMail 5.4.0. My local time zone is America/New_York. I received a message with header "Date: Tue, 10 Jan 2017 16:51:49 +". When replying to this message, the template variable %OTIME expands to "4:51 PM", which is arguably okay, but the template variable %OTIMELONG expands to "4:51:49 PM EST", which is just wrong. Evidently the time zone information from the original message's Date header is being discarded, and the unqualified time is being interpreted as a local time. Another example: original message contains "Date: Sun, 1 Jan 2017 13:31:25 -0600", but %OTIMELONG in reply expands to "1:31:25 PM EST", which again is wrong. The time zone information in the original message's Date header has been discarded, and the time has been interpreted as a local time. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 366768] Reply quote header uses UTC timestamp instead of local time zone
https://bugs.kde.org/show_bug.cgi?id=366768 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #2 from Matt Whitlock --- This still a problem in KMail 5.4.0. My local time zone is America/New_York. I received a message with header "Date: Tue, 10 Jan 2017 16:51:49 +". When replying to this message, the template variable %OTIME expands to "4:51 PM", which is arguably okay, but the template variable %OTIMELONG expands to "4:51:49 PM EST", which is just wrong. Evidently the time zone information from the original message's Date header is being discarded, and the unqualified time is being interpreted as a local time. Another example: original message contains "Date: Sun, 1 Jan 2017 13:31:25 -0600", but %OTIMELONG in reply expands to "1:31:25 PM EST", which again is wrong. The time zone information in the original message's Date header has been discarded, and the time has been interpreted as a local time. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 372712] akonadi_imap_resource crashed while I had KMail open in background
https://bugs.kde.org/show_bug.cgi?id=372712 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #2 from Matt Whitlock --- I got the same crash on KMail 16.12.0 with Akonadi 16.12.0. Also occurred while KMail was in the background; I was not interacting with it. [KCrash Handler] #6 std::__atomic_base::load (__m=std::memory_order_relaxed, this=0x18) at /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include/g++-v5/bits/atomic_base.h:396 #7 QAtomicOps::load (_q_value=...) at /usr/include/qt5/QtCore/qatomic_cxx11.h:227 #8 QBasicAtomicInteger::load (this=0x18) at /usr/include/qt5/QtCore/qbasicatomic.h:99 #9 QtPrivate::RefCount::ref (this=0x18) at /usr/include/qt5/QtCore/qrefcount.h:55 #10 0x7fee950bc2d3 in Akonadi::Protocol::Response::errorMessage() const () at ../../../akonadi-16.12.0/src/private/protocol.cpp:488 #11 0x7fee9f9f3831 in Akonadi::SessionPrivate::handleCommand (this=0x1fcd930, tag=, cmd=...) at ../../../akonadi-16.12.0/src/core/session.cpp:107 #12 0x7fee9f9f4538 in Akonadi::Session::qt_static_metacall (_o=, _c=, _id=, _a=0x7fee740050b0) at ./moc_session.cpp:117 #13 0x7feea19b39a9 in QObject::event (this=0x1f63b80, e=) at kernel/qobject.cpp:1263 #14 0x7feea2268cfc in QApplicationPrivate::notify_helper (this=, receiver=0x1f63b80, e=0x7fee741ad1c0) at kernel/qapplication.cpp:3799 #15 0x7feea2270040 in QApplication::notify (this=0x7ffc229d3340, receiver=0x1f63b80, e=0x7fee741ad1c0) at kernel/qapplication.cpp:3556 #16 0x7feea1987ce8 in QCoreApplication::notifyInternal2 (receiver=0x1f63b80, event=event@entry=0x7fee741ad1c0) at kernel/qcoreapplication.cpp:988 #17 0x7feea198a3ab in QCoreApplication::sendEvent (event=0x7fee741ad1c0, receiver=) at kernel/qcoreapplication.h:231 #18 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1c1e7a0) at kernel/qcoreapplication.cpp:1649 #19 0x7feea198a818 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1503 #20 0x7feea19db0d3 in postEventSourceDispatch (s=0x1c79b20) at kernel/qeventdispatcher_glib.cpp:276 #21 0x7fee9de59507 in g_main_dispatch (context=0x7fee880016f0) at ../../glib-2.50.2/glib/gmain.c:3203 #22 g_main_context_dispatch (context=context@entry=0x7fee880016f0) at ../../glib-2.50.2/glib/gmain.c:3856 #23 0x7fee9de59790 in g_main_context_iterate (context=context@entry=0x7fee880016f0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../../glib-2.50.2/glib/gmain.c:3929 #24 0x7fee9de5983c in g_main_context_iteration (context=0x7fee880016f0, may_block=may_block@entry=1) at ../../glib-2.50.2/glib/gmain.c:3990 #25 0x7feea19db4df in QEventDispatcherGlib::processEvents (this=0x1cbf510, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #26 0x7feea1985cda in QEventLoop::exec (this=this@entry=0x7ffc229d2c60, flags=..., flags@entry=...) at kernel/qeventloop.cpp:212 #27 0x7feea198e2ec in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1261 #28 0x7feea1cc0d4c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1633 #29 0x7feea2268c55 in QApplication::exec () at kernel/qapplication.cpp:2975 #30 0x00403ccb in main (argc=1, argv=0x7ffc229d3578) at ../../kmail-16.12.0/src/main.cpp:161 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 331891] Broken references-chain (email header) leads to new Thread
https://bugs.kde.org/show_bug.cgi?id=331891 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name --- Comment #3 from Matt Whitlock --- Still reproducible in KMail 5.4.0 too. Quite annoying, as this breaks the most common threading scenario: Bob emails me, I reply back, Bob replies to my reply. Bob's reply is not threaded under Bob's original message, as the intervening message (my reply) is in my Sent box, not in my Inbox. Threading should consider *all* of the message IDs given in the "References" header if a message identified by the "In-Reply-To" header is not found. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #8 from Matt Whitlock --- (In reply to Albert Vaca from comment #7) > Is there a way I can reproduce it? I'm not sure. KDE Connect is broken for me more often than it works, and I still don't know the exact conditions that cause it to enter the failure mode. I know that rebooting my phone makes it work again for a while. In fact, I did that just now, and now KDE Connect is connected and I can ring my phone from my computer's KDE Connect tray panel. > Does simply adding volatile fixes it for you? I don't have an Android development environment, and I don't know the first thing about developing apps for Android. I'm a Java developer, not an Android developer. > If this was the case, there are probably many more volatile > missing, so I would like to have a way to check the effect of > adding/removing them. Data races are probabilistic and as such are notoriously difficult to reproduce reliably, as they depend on factors outside of the program being tested, such as the global state of the operating system and the specifics of the OS kernel's thread scheduler. Rather than measuring the effects of declaring variables volatile, which sounds a lot like "programming by accident" (https://en.wikipedia.org/wiki/Programming_by_permutation), you should reason about which variables need to be declared volatile. Generally, if you access a variable from more than one thread without any kind of synchronization between the threads, then you must declare the variable volatile. And for what it's worth, Thread.sleep(…) is not a synchronization primitive. In general, there is no upper bound on the amount of time that a thread may be paused between instructions, so you cannot pick any delay time for Thread.sleep(…) that is guaranteed to be long enough. Use proper thread synchronization techniques instead. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #6 from Matt Whitlock --- There is a data-race bug in LanLink.java: https://github.com/albertvaka/kdeconnect-android/blob/master/src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java#L116 Because LanLink.socket is not declared volatile, the load from this field on line 116 can see a stale value that was stored before the call to Thread.sleep(…) on line 115. Declare LanLink.socket volatile to ensure that loads from it are always fresh from RAM and are never speculated out of program order. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #5 from Matt Whitlock --- This failure mode has recurred several times since I last commented. • I can always bring functionality back by rebooting my phone, but obviously I should not need to do this. • Merely stopping the app's "BackgroundService" and then relaunching the app's main activity does not fix the problem. • Force-stopping the app entirely and then relaunching its main activity also does not fix the problem. (Although the app's uptime does reset upon the Force Stop request, the app immediately restarts to start its "NotificationReceiver" service. The "BackgroundService" is not started until the app's main activity is launched.) • Disabling the notifications permission allows the app to be fully stopped. (It disappears from the list of running services upon a Force Stop.) Relaunching the main activity still does not fix the problem. To reiterate, the problem is that the KDE Connect app does not communicate with the computer unless its main activity is in the foreground. The background services continue running, but they do not maintain connectivity with the computer. Rebooting the phone restores background connectivity. The failure mode always seems to begin when the phone is removed from the WLAN for a while. Upon reconnecting to the WLAN, the app's background service does not maintain connectivity with the computer. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 368580] New: Auto Brackets forgets about multiple levels of brackets when overtyping closing bracket
https://bugs.kde.org/show_bug.cgi?id=368580
Bug ID: 368580
Summary: Auto Brackets forgets about multiple levels of
brackets when overtyping closing bracket
Product: frameworks-ktexteditor
Version: unspecified
Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: k...@mattwhitlock.name
This is with ktexteditor 5.26.0.
The Auto Brackets feature appears to remember only one level of bracketing for
purposes of auto-overtyping closing brackets. Only the innermost closing
bracket is automatically overwritten.
Reproducible: Always
Steps to Reproduce:
In a new document in KWrite (or Kate, KDevelop, etc.) with Auto Brackets
enabled, type more than one opening bracket (of any kind). Then type the
corresponding closing brackets (in reverse order).
Actual Results:
Only the first closing bracket gets automatically overwritten. The remaining
closing brackets are inserted instead, leading to excessive closing brackets.
Expected Results:
All closing brackets should be automatically overwritten if they were
automatically inserted and have not yet been automatically overwritten.
This worked in KDE 4, presumably because *all* closing brackets were *always*
automatically overtyped by matching characters. This was an okay solution,
though it confounded the later insertion of additional closing brackets into a
run of closing brackets.
A better solution would be to remember which closing brackets on the current
editing line were automatically inserted and automatically overtype them if and
only if the character being typed matches the existing closing bracket and the
existing closing bracket has not already been automatically overtyped. (The set
of remembered auto-inserted closing brackets can be forgotten when the cursor
moves to another line.)
Some examples (pipe character indicates cursor position)…
Type these five characters: ((a))
Expected result: ((a))|
Actual result: ((a))|)
Type these seven characters: ({[a]})
Expected result: ({[a]})|
Actual result: ({[a]})|})
--
You are receiving this mail because:
You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|UNCONFIRMED |NEEDSINFO --- Comment #4 from Matt Whitlock --- After a reboot of my phone, KDE Connect is remaining connected to my desktop even while running in the background. I will attempt to determine the exact conditions under which KDE Connect enters the failure mode described in this report. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #3 from Matt Whitlock --- Created attachment 101004 --> https://bugs.kde.org/attachment.cgi?id=101004&action=edit KDE Connect memory usage statistics Here's another screen shot. Android reports that the KDE Connect app is "Always running (100%)." -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Matt Whitlock changed: What|Removed |Added Resolution|UPSTREAM|--- Status|RESOLVED|UNCONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 --- Comment #2 from Matt Whitlock --- Created attachment 101003 --> https://bugs.kde.org/attachment.cgi?id=101003&action=edit Running app details Thanks for the reply. You've been too quick to dismiss this, though. In fact, the KDE Connect app is always running. You can see in the attached screen shot that its background services have been running continuously for the past 37+ hours. Android is not killing them. They simply don't work unless one of the app's activities is in the foreground. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 368438] New: KDE Connect does not communicate while running in background on phone
https://bugs.kde.org/show_bug.cgi?id=368438 Bug ID: 368438 Summary: KDE Connect does not communicate while running in background on phone Product: kdeconnect Version: 1.0 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: grave Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: k...@mattwhitlock.name All functionality of KDE Connect works only while the KDE Connect app is in the foreground on the phone. Switching to any other app causes KDE Connect to stop working. It does not receive pings from the desktop, and clipboard sharing is broken. In fact, about 25 seconds after switching away from KDE Connect on the phone, the phone becomes shown as disconnected in the desktop module. Reproducible: Always Steps to Reproduce: 1. Install KDE Connect 1.0 on a phone running Android 6.0.1 (e.g., CyanogenMod 13.0-20160901-NIGHTLY-d2spr). 2. Install KDE Connect 1.0 on desktop running Gentoo Linux, KDE Frameworks 5.25.0, Qt 5.6.1. 3. Pair phone with desktop. 4. Switch away from KDE Connect app on phone (e.g., by pressing Home button). 5. Try to send a ping from the desktop module. (No notification appears on phone.) 6. Switch back to KDE Connect app on phone. 7. Try again to send a ping from the desktop. (Notification appears.) Actual Results: KDE Connect communicates with desktop only while the app is the foreground activity. Expected Results: KDE Connect should continue functioning even while running in the background on the phone. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 96431] Ability to use mouse buttons for shortcuts
https://bugs.kde.org/show_bug.cgi?id=96431 --- Comment #52 from Matt Whitlock --- (In reply to Aloysius from comment #51) > I'm afraid the only way is to use xbindkeys or switch to wayland. Preposterous. If xbindkeys can do it, then KDE's global hotkeys daemon can do the same thing. It's as simple as grabbing all the buttons that have shortcuts assigned to them, isn't it? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 360567] Wrong parameter info displayed for variadic function templates
https://bugs.kde.org/show_bug.cgi?id=360567
Matt Whitlock changed:
What|Removed |Added
CC||k...@mattwhitlock.name
--- Comment #2 from Matt Whitlock ---
(In reply to Alexander Potashev from comment #0)
> In the sample code below, pressing Ctrl+Space shows "void print()". "void
> print()" is just wrong here, these two options should be displayed instead:
> * void print(int a, char b)
> * void print(std::string a, double b)
Your suggestion is wrong. The compiler is in fact free to instantiate the
variadic function template using *any* template parameters whatsoever. It is
true that there will be a compilation error for any but two distinct tuples of
argument types, but this has no bearing on the parameters with which the
template may be instantiated.
What you're asking for is effectively that the contextual assistant should
compute the set containing all tuples of argument types that would not result
in a compilation error, but this may in fact be an infinite set, and in general
there is no way to guess what type tuples might be in the set.
Consider the following addition to your example:
template
std::enable_if_t, void> print_impl(E value) {
std::cout << static_cast>(value);
}
Now what is the contextual assistant supposed to show when you press
Ctrl+Space? Do you expect it to search through every defined type, trying to
instantiate the print_impl(E) function template? Do you expect every defined
enumerated type to appear in the list of suggestions? That would be pretty
impractical.
--
You are receiving this mail because:
You are watching all bug changes.
[kactivitymanagerd] [Bug 348194] kactivitymanager sometimes crashes on logout
https://bugs.kde.org/show_bug.cgi?id=348194 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 348123] Some processes (kuiserver) are left running after exiting KDE
https://bugs.kde.org/show_bug.cgi?id=348123 Matt Whitlock changed: What|Removed |Added CC||k...@mattwhitlock.name -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #5 from Matt Whitlock --- (In reply to Matt Whitlock from comment #4) > (In reply to Hugo Pereira Da Costa from comment #3) > > - and what is the Qt5 version you are using ? > > 5.5.1 Same problem exists when running on Qt 5.6.0. -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #4 from Matt Whitlock --- Created attachment 98534 --> https://bugs.kde.org/attachment.cgi?id=98534&action=edit KCalc (Qt5) running with "-style breeze" (In reply to Hugo Pereira Da Costa from comment #3) > You are running with kwin_x11 (from kf5) as a window manager, right ? Yes, I'm running kwin_x11 5.6.3 on KDE Frameworks 5.21.0. I am logging in using SDDM 0.13.0 as my display manager. > - can you check that shadows are indeed enabled in oxygen settings (either > via systemsettings5, style, oxygen -> configuration, or using > oxygen-settings5) I assume you mean the "Shadows" settings in the "Window Decoration" module of oxygen-settings5. Yes, everything is set to the defaults. > - do you have the same issue when using breeze as a widget theme ? (you > should: both code path are pretty similar) Yes, Breeze also lacks shadows behind menus and tooltips. See the attached screen shot. > - and what is the Qt5 version you are using ? 5.5.1 -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #2 from Matt Whitlock --- Created attachment 98516 --> https://bugs.kde.org/attachment.cgi?id=98516&action=edit Ugly hard black border around menu in Kate (Qt5) -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 362089] tooltips and menus in Qt5 apps are missing shadow
https://bugs.kde.org/show_bug.cgi?id=362089 --- Comment #1 from Matt Whitlock --- Created attachment 98515 --> https://bugs.kde.org/attachment.cgi?id=98515&action=edit Comparison of menus in KMail (Qt4) and KCalc (Qt5) -- You are receiving this mail because: You are watching all bug changes.
