[plasmashell] [Bug 373379] Notifications sometimes appear in the middle of the screen after screen geometry change
https://bugs.kde.org/show_bug.cgi?id=373379 --- Comment #2 from Ralf Jung <p...@ralfj.de> --- Created attachment 103613 --> https://bugs.kde.org/attachment.cgi?id=103613=edit A screenshot demonstrating the issue with Plasma 5.8.4 Debian now has 5.8.4, and I am still seeing this issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 375686] New: Black square in top-left corner
https://bugs.kde.org/show_bug.cgi?id=375686 Bug ID: 375686 Summary: Black square in top-left corner Product: plasmashell Version: 5.8.4 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: XembedSNIProxy Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: 1.0 Created attachment 103690 --> https://bugs.kde.org/attachment.cgi?id=103690=edit Screenshot demonstrating the issue When compositing is disabled, I can sometimes see a black square in the top-left corner. I believe this is related to xembed-sni-proxy because clicking the black square behaves like clicking on one of the tray icons that are managed by xembed-sni-proxy -- both for left-click and right-click. The square is not visible when compositing is enabled, but e.g. going to full-screen in mpv disabled compositing and then I have this square on top of the video. Furthermore, *clicking* the area covered by the invisible square still behaves the same when compositing is enabled (naturally, as compositing does not affect input handling). This is not 100% reproducible, I just restarted the application tied to the square (Gajim) and the square did not come back. I will attach a screenshot demonstrating the issue. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 372635] do not follow mousepointer when accessing krunner via keyboard
https://bugs.kde.org/show_bug.cgi?id=372635 --- Comment #2 from Ralf Jung <p...@ralfj.de> --- > I think an easy workaround would to only select an item from krunner by mouse > if the user actually presses the left mouse button. I see no point in the on > hover selection. Sure I could use the mouse and then still hit the enter key, > but what for? Either I use the keyboard or I use the mouse. Alternatively (because the on-hover graphical effect is nice and potentially helpful), pressing the Enter key could entirely ignore th selected item if it was selected with the mouse. (Of course the selection should be honored if it was done with the keyboard.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] Closing windows with sorting "By activity" leads to mixed-up taskbar
https://bugs.kde.org/show_bug.cgi?id=373153 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added Summary|Closing windows in grouped |Closing windows with |task manager entry leads to |sorting "By activity" leads |mixed-up menu |to mixed-up taskbar -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] Closing windows in grouped task manager entry leads to mixed-up menu
https://bugs.kde.org/show_bug.cgi?id=373153 --- Comment #6 from Ralf Jung <p...@ralfj.de> --- *oops* I am sorry I misread what you wrote... I read "setting" instead of "sorting", so I was changing the option "Show only tasks of current activity". Indeed changing the sorting to "Alphabetically" fixes the problem. I have no idea why the sorting option is what it was. I now set it to "By Desktop" and will see how that one behaves. So far, it did not leave things in a bad state; however, the animations when closing a window do look a bit odd -- instead of the closed window being animated to disappear, some other window disappears and then there is a smooth transition if taskbar entires changing their icon and text. That doesn't look right. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] Closing windows in grouped task manager entry leads to mixed-up menu
https://bugs.kde.org/show_bug.cgi?id=373153 --- Comment #3 from Ralf Jung <p...@ralfj.de> --- Created attachment 102657 --> https://bugs.kde.org/attachment.cgi?id=102657=edit Screenshot of my task manager settings These are the settings I use most of the time -- even when there are no groups, I occasionally get screwed-up windows in the taskbar. For the original report (closing a window from a group), the settings were the same except that "Grouping" was set to "By Program Name". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373379] New: Notifications sometimes appear in the middle of the screen after screen geometry change
https://bugs.kde.org/show_bug.cgi?id=373379 Bug ID: 373379 Summary: Notifications sometimes appear in the middle of the screen after screen geometry change Product: plasmashell Version: 5.8.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Notifications Assignee: k...@privat.broulik.de Reporter: p...@ralfj.de CC: mklape...@kde.org Target Milestone: 1.0 Created attachment 102658 --> https://bugs.kde.org/attachment.cgi?id=102658=edit A screenshot demonstrating the issue Sometimes (well, once so far), after the screen geometry changes (I moved from the laptop screen to an external screen), notifications show in the wrong place: they still use the old coordinates based on the screen geometry of the laptop screen. See attached screenshot. Unplugging and replugging the external screen fixed this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] Closing windows in grouped task manager entry leads to mixed-up menu
https://bugs.kde.org/show_bug.cgi?id=373153 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added Status|NEEDSINFO |UNCONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #5 from Ralf Jung <p...@ralfj.de> --- I don't actually use activities, so this is probably something I changed years ago... However, after disabling this (and enabling the grouping again), I was able to still reproduce the issue on the first try. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373865] plasmashell crashes on usb disconnect
https://bugs.kde.org/show_bug.cgi?id=373865 --- Comment #16 from Ralf Jung <p...@ralfj.de> --- As was brought up in the Qt bug, the cause is likely even more upstream, in libxi: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849026> A libxi package with the fix is in Debian unstable and should migrate to testing tomorrow. I have my fingers crossed that this fixes the problem. No crash in the one suspend-disconnect I did so far, but that's a rather small sample size ;) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] New: Closing windows in grouped task manager entry leads to mixed-up menu
https://bugs.kde.org/show_bug.cgi?id=373153 Bug ID: 373153 Summary: Closing windows in grouped task manager entry leads to mixed-up menu Product: plasmashell Version: 5.8.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Task Manager Assignee: h...@kde.org Reporter: p...@ralfj.de CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 102563 --> https://bugs.kde.org/attachment.cgi?id=102563=edit A screenshot demonstrating the issue Steps to reproduce: * Have at least 3 windows in a group. * Left-click that group * Right-click a window in that group and select "Close" Expected behavior: * The window closed and disappears from the group, and nothing else happens Actual behavior: * Another window can start showing up in the group -- even windows that are not usually shown, e.g. "plasma". I will attach a screenshot demonstrating this. This is not entirely reproducible because it seems to depend on the exact state of the task manager, i.e. how many groups of which size are presented in which order. Still, it happens frequently for me. Having more windows grouped increases the likelihood of seeing this. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 373154] New: In a keyboard-only interaction, krunner will frequently pick the item that appears below the cursor
https://bugs.kde.org/show_bug.cgi?id=373154 Bug ID: 373154 Summary: In a keyboard-only interaction, krunner will frequently pick the item that appears below the cursor Product: krunner Version: 5.8.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: k...@privat.broulik.de Reporter: p...@ralfj.de Target Milestone: --- Steps to reproduce: * Have your mouse cursor roughly in the center of your screen, in the area where the krunner dialog will expand to when it finds sufficiently many hits. * Trigger krunner via the keyboard and enter a term. (For me, this happens e.g. with "kwallet" and "firefox") Expected behavior: As long as I don't move the mouse, I expect krunner to entire ignore the cursor. I like to start e.g. the KWalletManager by typing "WIN-r k w a l ENTER" without any noticeable pauses. I *know* kwalletmanager is the first thing to appear on the query "kwal" (and Win-R is my shortcut for KRunner), to this should always work. Actual behavior: Sometimes, the item under the mouse is selected even though the mouse did not move. This seems to depend on how quickly the contents are loaded. Typing another key usually fixes this, but when I quickly enter a query and hit ENTER, it's already too late -- some random document has already been opened. This is pretty frustrating. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 373164] New: Keyboard layout not applied on reboot
https://bugs.kde.org/show_bug.cgi?id=373164 Bug ID: 373164 Summary: Keyboard layout not applied on reboot Product: systemsettings Version: 5.8.2 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_keyboard_layout Assignee: ary...@gmail.com Reporter: p...@ralfj.de Target Milestone: --- I have configured (in systemsettings) may keybaord to use the layout "German (no dead keys)". However, when I reboot my system, the wrong keybaord layout is used: It uses the default German keyboard layout, enabling dead keys. I can "fix" this for the USB keybaord by unplugging and replugging it, but then the internal keyboard of the laptop will keep using the wrong layout. Alternatively, I can switch the layout back and forth with the keyboard layout status indicator; that will fix things for all keyboards. But of course, the correct layout should already be applied on login. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373153] Closing windows in grouped task manager entry leads to mixed-up menu
https://bugs.kde.org/show_bug.cgi?id=373153 --- Comment #1 from Ralf Jung <p...@ralfj.de> --- Actually I now frequently get a slightly messed-up task manager even when no windows are grouped. For example, I just used right-click "Close" to close one of two qgit windows I had open (grouping was disabled). Then *both* vanished from the taskbar, and some icons of other windows got swapped. Switching the active window repaired the taskbar, i.e., the missing qgit window came back and the icons all got fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373423] Plasma crashes when disconnecting laptop from dockingstation
https://bugs.kde.org/show_bug.cgi?id=373423 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added CC||p...@ralfj.de --- Comment #3 from Ralf Jung <p...@ralfj.de> --- My guess would be that the crash is not entirely reproducible, which is why you don't see it... I think this is a duplicate of https://bugs.kde.org/show_bug.cgi?id=373865 which I am seeing with Qt 5.7.1. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 373865] plasmashell crashes on usb disconnect
https://bugs.kde.org/show_bug.cgi?id=373865 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added CC||p...@ralfj.de --- Comment #12 from Ralf Jung <p...@ralfj.de> --- I am having the same issue and reported it upstream with Qt at <https://bugreports.qt.io/browse/QTBUG-57897>. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 --- Comment #4 from Ralf Jung <p...@ralfj.de> --- Created attachment 106539 --> https://bugs.kde.org/attachment.cgi?id=106539=edit xprop of Firefox Nightly -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 --- Comment #5 from Ralf Jung <p...@ralfj.de> --- Created attachment 106540 --> https://bugs.kde.org/attachment.cgi?id=106540=edit xprop of Firefox Stable -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added Resolution|FIXED |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #3 from Ralf Jung <p...@ralfj.de> --- There is no icon for this in /usr/share/applications; I installed Nightly by downloading the tarball and extracting it somewhere. Sure icons should work for all applications, not just those installed by root? Same for Firefox, is is also just installed in $HOME. I will attach xprop output for nightly and stable. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from Ralf Jung <p...@ralfj.de> --- > If you install an application in your $HOME you're responsible for putting a > .desktop file specifying the icon in $HOME/.local/share/applications and also > deploying the icon. Are you serious? Most of the time, I don't even bother to create a menu entry for an application. The Alt+F2 menu works just fine for applications symlinked from ~/bin. KWin demonstrates that showing the icon for such applications is perfectly possible. So, to be frank, I think it is quite ridiculous to not support this. It is quite surprising as well. People observing this behavior will see a bug in KDE, there is no way to *know* that .desktop files are suddenly considered mandatory by some software. But, okay, in the interest of making progress let me play my your rules -- it's your software after all. I added a menu entry for nightly using KMenuEditor. This is what the .desktop file looks like: $ cat ~/.local/share/applications/firefox-2.desktop [Desktop Entry] Comment=Browse the World Wide Web Encoding=UTF-8 Exec=/home/r/bin/firefox-nightly GenericName=Web Browser Icon=/home/r/bin/firefox.nightly.d/browser/icons/mozicon128.png MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;x-scheme-handler/http;x-scheme-handler/https; Name=Firefox Nightly NoDisplay=false Path[$e]= StartupNotify=true StartupWMClass=Firefox Terminal=0 TerminalOptions= Type=Application X-GNOME-FullName=Firefox Web Browser X-KDE-SubstituteUID=false X-KDE-Username= X-MultipleArgs=false The issue remains the same: I started Firefox Nightly from the KDE menu, and still, the taskbar panel shows the wrong icon. Reopening because the reason given dos not apply any more. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] New: Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 Bug ID: 382142 Summary: Panel icon wrong: Does not match window icon Product: plasmashell Version: 5.8.7 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: 1.0 Created attachment 106513 --> https://bugs.kde.org/attachment.cgi?id=106513=edit Screenshot demonstrating the issue. Notice how the icon in the window does not match the icon in the panel. Plasma sometimes displays the wrong panel icon for Firefox Nightly. The icon shown in the top-left corner of the window is correct, so I assume that the application is properly setting its window properties -- but Plasma, for some reason, decides to use the "normal" Firefox icon rather than the Firefox Nightly icon for these windows. I've already seen this happen some days ago, but then it was fixed by restarting Firefox Nightly. Now the bug has come back, and this time, restarts do not help. Unfortunately, I have no idea how Plasma picks the icon, so I don't know where to start debugging. This is with Debian testing amd64. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 379930] kcm_keyboard kills ibus daemon, entirely breaking the keyboard
https://bugs.kde.org/show_bug.cgi?id=379930 --- Comment #9 from Ralf Jung <p...@ralfj.de> --- Thank you for taking this on. :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 379930] kcm_keyboard kills ibus daemon, entirely breaking the keyboard
https://bugs.kde.org/show_bug.cgi?id=379930 --- Comment #1 from Ralf Jung <p...@ralfj.de> --- I verified that changing XkbHelper::preInitialize to not do anything fixes the ibus-daemon trouble, at least as far as automatically starting it on launch is concerned. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 339270] KDE doesn't automatically launch the input method framework(e.g. ibus-daemon)
https://bugs.kde.org/show_bug.cgi?id=339270 Ralf Jung <p...@ralfj.de> changed: What|Removed |Added CC||p...@ralfj.de --- Comment #3 from Ralf Jung <p...@ralfj.de> --- Not sure how this is supposed to work on Fedora; in Debian, ibus installs a script in /etc/X11/Xsession.d/ which injects "im-launch" into the session launch process. I did not yet find out how or where im-launch starts ibus-daemon, but well. However, ibus still doesn't work in KDE -- not because it is not started, but because it is killed immediately. .xsession-errors: org.kde.kcm_keyboard: ibus successfully stopped I reported this as bug 379930. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 379930] New: kcm_keyboard kills ibus daemon, entirely breaking the keyboard
https://bugs.kde.org/show_bug.cgi?id=379930 Bug ID: 379930 Summary: kcm_keyboard kills ibus daemon, entirely breaking the keyboard Product: systemsettings Version: 5.8.6 Platform: Other OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: kcm_keyboard Assignee: unassigned-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- I was having some trouble setting up ibus, which I first attributed to bugs in ibus itself: ibus would not start automatically (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862721) and would sometimes quit on suspend-resume (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862717). However, since then, I have noticed that the following line appears in .xsession-errors every time ibus breaks: org.kde.kcm_keyboard: ibus successfully stopped The result of this is that keyboard input does not work -- effectively making the machine unusable. I assume there is/was a good reason for kcm_keyboard to kill the ibus daemon, but right now, the net effect of this behavior is rather catastrophic. As far as I can tell, the only possible "fix" for me is to uninstall ibus :/ -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 379930] kcm_keyboard kills ibus daemon, entirely breaking the keyboard
https://bugs.kde.org/show_bug.cgi?id=379930 --- Comment #2 from Ralf Jung <p...@ralfj.de> --- Created attachment 105624 --> https://bugs.kde.org/attachment.cgi?id=105624=edit A patch fixing the issue Just for reference, I attached the patch I used to fix the issue. -- You are receiving this mail because: You are watching all bug changes.
[ksshaskpass] [Bug 384738] New: Focus is not on password field
https://bugs.kde.org/show_bug.cgi?id=384738 Bug ID: 384738 Summary: Focus is not on password field Product: ksshaskpass Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: jpwhit...@kde.org Reporter: p...@ralfj.de Target Milestone: --- Since somewhat recently, the password field of the ksshaskpass dialog no longer is focused per default. I now have to press Tab once before I can type my password, which is rather annoying. I am not entirely sure how this started happening; there was no ksshaskpass update. Still, I would not know where else to report this either. I am using Debian testing and upgraded the KDE packages to unstable, which means I have (most of) KDE 5.10.5. In particular, Kwin and Plasma are on that version. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384935] New: Focus stealing prevention keeps KWallet window in background
https://bugs.kde.org/show_bug.cgi?id=384935 Bug ID: 384935 Summary: Focus stealing prevention keeps KWallet window in background Product: kwin Version: 5.10.5 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- ## Steps to reproduce I have kwin's focus stealing prevention is enabled and set to "Low". When I type "git push" in Konsole and access to the repository needs an SSH key, ksshaskpass fires up to get my SSH key unlocked. ksshaskpass first opens the wallet to see if my password is stored there. ## Actual behavior The KWallet window asking for my wallet password is opened in the background. ## Expected behavior The window should open in the foreground. This is problematic enough that I end up disabling focus stealing prevention, even though in many other cases I would actually love to have it enabled. I am going to try and work around this using window-specific rules, but something like this seems like it should work out-of-the-box. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 353313] Gwenview is broken under cinnamon: Title bar is often missing, switching to full-screen freezes for 30sec
https://bugs.kde.org/show_bug.cgi?id=353313 --- Comment #10 from Ralf Jung <p...@ralfj.de> --- I am no longer using Cinnamon, so I cannot tell. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 382142] Panel icon wrong: Does not match window icon
https://bugs.kde.org/show_bug.cgi?id=382142 --- Comment #9 from Ralf Jung <p...@ralfj.de> --- Thanks for that, this is interesting information. I guess I should try to somehow create a service file for both versions of Firefox, and see if that helps. Also, my version of KDE is so outdated at this point that I can perfectly understand that you don't want to support it any more. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 397343] New: Search state lost when switching from one file to another
https://bugs.kde.org/show_bug.cgi?id=397343 Bug ID: 397343 Summary: Search state lost when switching from one file to another Product: kate Version: 18.04.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: search Assignee: kwrite-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- Often, I want to search one string first in one file and then in another, or replace A by B in two or three files. Unfortunately, in Kate, when I go from one file to another, not only does it close the search bar; also when I hope it, it emptied all the fields in there. That makes it much harder than necessary to work on projects that span multiple files. I think when I switch from one file to another, the search/replace bar at the bottom should stay open, and it should keep its state. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 397343] Search state lost when switching from one file to another
https://bugs.kde.org/show_bug.cgi?id=397343 --- Comment #3 from Ralf Jung --- There is a big problem with this solution: Now Ctrl-F is entirely broken in KWrite, because I changed the key bindings in Kate. Is there a way to keep using the normal search in KWrite? -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 397343] Search state lost when switching from one file to another
https://bugs.kde.org/show_bug.cgi?id=397343 --- Comment #2 from Ralf Jung --- That looks promising, thanks. I don't understand why the default search bar behaves so strange now. (I think with old kate -- around Kate 4 -- the search bar still was properly synced between multiple open files.) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 398900] New: "Quick open" got much (100x) slower with 18.08 [regression]
https://bugs.kde.org/show_bug.cgi?id=398900 Bug ID: 398900 Summary: "Quick open" got much (100x) slower with 18.08 [regression] Product: kate Version: 18.08.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- With Kate 18.04, I first discovered the "quick open" feature (Ctrl-Alt-O), and started to get used to it. Unfortunately, with Kate 18.08, it got so slow it is useless. To reproduce, clone the Rust compiler (git clone https://github.com/rust-lang/rust/), ideally onto an SSD, and make sure to initialize all submodules (git submodule update --init --recursive). This will take a bit. Then open some files under src, and also open src/README.md. Then do Ctrl-Alt-O. This used to be instantaneous with previous versions of kate, now it takes around 10 seconds (so it is at least 100x slower). Also, it is now listing every file twice when I start searching, once as `/home/r/src/rust/rustc//src/...` and once as `file://home/r/src/rust/rustc/src/...` (one has a duplicate slash, and one has a `file://` prefix). I do not this this was the case before the update. I am on Debian testing. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 407930] Something spams the notification area with hundreds of "Additional multimedia codec required"
https://bugs.kde.org/show_bug.cgi?id=407930 --- Comment #1 from Ralf Jung --- I have found this in my ".xsession-errors": qt.qpa.xcb: QXcbConnection: XCB error: 2 (BadValue), sequence: 59768, resource id: 90177543, major code: 142 (Unknown), minor code: 3 qt.qpa.xcb: QXcbConnection: XCB error: 2 (BadValue), sequence: 60242, resource id: 35651590, major code: 142 (Unknown), minor code: 3 ** Message: 09:11:25.639: PackageKit: xid = 90177543 ** Message: 09:11:25.639: PackageKit: desktop_id = (null) ** Message: 09:11:25.639: PackageKit: Codec nice name: Vorbis decoder ** Message: 09:11:25.639: PackageKit: structure: gstreamer1(decoder-audio/x-vorbis)()(64bit) Unfortunately there is no indication *why* it requests that codec from PackageKit. Also this lets me count how often I got that notification... $ fgrep decoder-audio/x-vorbis .xsession-errors -c 8926 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 407930] Something spams the notification area with hundreds of "Additional multimedia codec required"
https://bugs.kde.org/show_bug.cgi?id=407930 --- Comment #2 from Ralf Jung --- Another report of the same issue for opensuse: https://lists.opensuse.org/opensuse-gnome/2016-06/msg1.html -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 407930] New: Something spams the notification area with hundreds of "Additional multimedia codec required"
https://bugs.kde.org/show_bug.cgi?id=407930 Bug ID: 407930 Summary: Something spams the notification area with hundreds of "Additional multimedia codec required" Product: frameworks-knotifications Version: 5.54.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: p...@ralfj.de CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY Sometimes (around every two days), Plasma goes crazy showing notifications that say "Additional multimedia codec required". Closing one just makes the next appear, and opening the notification list shows hundreds of these notifications (I can scroll down for a long while in that list and still see just more duplicates of the same notification). CPU load goes to 100%. Clicking the "Install" button in one of these notifications opens some GNOME application saying "internet access was required but wasn't available". The window title says "Vorbis decoder", so it seems like something thinks I don't have a vorbis decoder? ".ogg" files play just fine though. This stops when I close Konsole. In this state, closing individual tabs in Konsole does not work any more (they just stay open even when I hit Ctrl-D), but closing the entire window works. However, I have (very rarely) also seen Kate do this. Just Konsole does it much more often. STEPS TO REPRODUCE 1. Open Konsole. 2. Use it for a day or two. OBSERVED RESULT Something spams the system with notifications saying I need an extra audio codec. This stops when I close Konsole. EXPECTED RESULT There should be no notification spam. Also audio is working fine so the message seems wrong in the first place. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit ADDITIONAL INFORMATION My guess is that this is caused by the notification system or so? It wants to play an ".ogg" file, something goes wrong, then it concludes the codec is missing and somehow retries that in a loop? But notifications in Konsole generally work fine. Still, clearly this bug is not in Konsole-the-applocation but somewhere in KDE's library stack. The same symptoms have been described at https://bugzilla.redhat.com/show_bug.cgi?id=1551152, so this is not a Debian thing. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408029] Scrolling in evince when window does not have focus does not work (Xinput2-related)
https://bugs.kde.org/show_bug.cgi?id=408029 --- Comment #2 from Ralf Jung --- How do I figure that out? I think I left most everything at the default value. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408029] New: Scrolling in evince when window does not have focus does not work (Xinput2-related)
https://bugs.kde.org/show_bug.cgi?id=408029 Bug ID: 408029 Summary: Scrolling in evince when window does not have focus does not work (Xinput2-related) Product: kwin Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY When scrolling in an evince window that does not have focus, nothing happens. STEPS TO REPRODUCE 1. Open evince, make it cover half the screen. 2. Put some other window on the other half and give it focus. 3. Hover the mouse over the evince window without clicking, and turn the scroll wheel. OBSERVED RESULT Nothing happens. EXPECTED RESULT It should scroll. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit ADDITIONAL INFORMATION First reported against evince/GTK at https://gitlab.gnome.org/GNOME/gtk/issues/949. However, after discovering that setting GDK_CORE_DEVICE_EVENTS=1 in the environment works around the issue, they concluded that this has something to do with KWin not supporting Xinput2 (?). Curiously, when I use two-finger scrolling on my touchpad to scroll, evince *does* scroll properly. It's only mouse wheel scrolling that gets "lost", and only when the evince window does not have focus. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408029] Scrolling in evince when window does not have focus does not work (Xinput2-related)
https://bugs.kde.org/show_bug.cgi?id=408029 --- Comment #4 from Ralf Jung --- Looks like it is: libinput-bin/testing,unstable,now 1.12.6-2 amd64 [installed,automatic] libinput10/testing,unstable,now 1.12.6-2 amd64 [installed,automatic] xserver-xorg-input-libinput/testing,unstable,now 0.28.2-2 amd64 [installed,automatic] -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 407930] Something spams the notification area with hundreds of "Additional multimedia codec required"
https://bugs.kde.org/show_bug.cgi?id=407930 --- Comment #7 from Ralf Jung --- A few days ago I have uninstalled "gstreamer1.0-packagekit" and have not had the issue any more since then (but I am going to wait some more days to be sure). And indeed that package contains "pk-gstreamer-install". Phonon is using the GStreamer backend, so maybe that's how such things could be caused by a KDE application? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 407930] Something spams the notification area with hundreds of "Additional multimedia codec required"
https://bugs.kde.org/show_bug.cgi?id=407930 --- Comment #4 from Ralf Jung --- Do you have any suggestion for how one could determine which application is responsible? I am not even sure if I had any GNOME app running when the issue occurred. So far the spamming always stopped when I quit Kate/Konsole -- so looks more like a KDE issue to me. My guess is that a GNOME app open when I click the notification because somehow GNOME's software center is the default, but that's not the main problem here. -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 407892] Kwallet does not get unlocked when I unlock my screen
https://bugs.kde.org/show_bug.cgi?id=407892 --- Comment #3 from Ralf Jung --- I'm a bit disappointed that I do not even get an answer for suggesting what I think is a rather reasonable use-case. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407821] Terminal bell does not trigger system (visual) bell
https://bugs.kde.org/show_bug.cgi?id=407821 --- Comment #2 from Ralf Jung --- I have seen that, yes. There is no option "trigger system bell" there that I can see. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407821] Terminal bell does not trigger system (visual) bell
https://bugs.kde.org/show_bug.cgi?id=407821 --- Comment #4 from Ralf Jung --- Yes I know how to configure what happens when the system bell gets triggered. It flashes the window, inverting it 100ms. But Konsole does not trigger that bell. I have described the steps to reproduce and the observed and expected result in my original report. Which part is not clear? -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 408960] New: Option to show "max core load"
https://bugs.kde.org/show_bug.cgi?id=408960 Bug ID: 408960 Summary: Option to show "max core load" Product: kdeplasma-addons Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: systemloadviewer Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- I have 8 CPU cores, so even when some process goes wild and uses one of my cores for 100%, the bar in the system load viewer widget barely moves up (to 12.5%, to be more precise). That makes the widget less helpful than it could be to detect the situation when there is a runaway process somewhere in the background. The number of CPU cores we have installed in our systems is only going to grow, so this problem is only going to get worse. One way to improve the situation here would be to offer, next to the "total CPU usage", also the option to show the CPU usage of the most-used core. Then one could immediately see that *something* is using up a full core. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 408959] New: System load viewer: grayed-out box "CPUs separately" without indication why it is disabled
https://bugs.kde.org/show_bug.cgi?id=408959 Bug ID: 408959 Summary: System load viewer: grayed-out box "CPUs separately" without indication why it is disabled Product: kdeplasma-addons Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: systemloadviewer Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY The "CPUs separately" box in the system load viewer widget configuration is grayed out. There is no indication what I could/should do to be allowed to enable that checkbox. That's at best confusing and at worst frustrating UI design. Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 15,5 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 408959] System load viewer: grayed-out box "CPUs separately" without indication why it is disabled
https://bugs.kde.org/show_bug.cgi?id=408959 --- Comment #2 from Ralf Jung --- Ah, that does it, thanks a lot! I tried various things but not that combination, it seems. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 397343] Search state lost when switching from one file to another
https://bugs.kde.org/show_bug.cgi?id=397343 --- Comment #5 from Ralf Jung --- I described above why this is not a great solution: after setting up Ctrl-F to trigger the search plugin, KWrite has no functioning search any more. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 409074] New: System load viewer sometimes sees no load while there is some
https://bugs.kde.org/show_bug.cgi?id=409074 Bug ID: 409074 Summary: System load viewer sometimes sees no load while there is some Product: kdeplasma-addons Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: systemloadviewer Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- Created attachment 121093 --> https://bugs.kde.org/attachment.cgi?id=121093=edit A screenshot demonstrating the issue SUMMARY When switching the system load viewer to show per-CPU load, during a long compilation session (where there's always load on at least one core), the laod seems to regularly drop to 0 according to the load viewer. Watching htop at the same time shows that there is always load, though. STEPS TO REPRODUCE 0. Configure system load viewer to show per-CPU load and a high update frequency (e.g. 0.5s). The issue also happens with 2s, but is easier to observe with higher frequencies. 1. Start a long build. 2. Start htop. 3. Watch htop and the load viewer. OBSERVED RESULT They should show roughly the same thing. EXPECTED RESULT The load viewer frequently claims no load when there actually is plenty. I attached a screenshot. The system load viewer widget is marked in the bottom-left corner. You can't see it because it shows 0 load. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 15,5 GiB of RAM ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 409074] System load viewer sometimes sees no load while there is some
https://bugs.kde.org/show_bug.cgi?id=409074 --- Comment #1 from Ralf Jung --- Interestingly, I have never seen this happen when showing just one bar for the entire CPU load. So this seems to be something about the per-CPU-load measurement. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 397343] Search state lost when switching from one file to another
https://bugs.kde.org/show_bug.cgi?id=397343 --- Comment #7 from Ralf Jung --- But this means it is impossible to have both Kate remember the search state of Ctrl-F across files, and Ctrl-F work in KWrite. So either I have to use a non-standard shortcut in Kate (which is a mess, as Ctrl-F is used *everywhere*), or KWrite search is broken. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407821] New: Terminal bell does not trigger system (visual) bell
https://bugs.kde.org/show_bug.cgi?id=407821 Bug ID: 407821 Summary: Terminal bell does not trigger system (visual) bell Product: konsole Version: 18.04.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY I have configured my system to enable a "visual bell" (in the KDE system settings), because I often work with the sound turned off so I wouldn't otherwise notice these bells. This works fine e.g. in emacs or gnome-terminal. However, Konsole seems to never trigger this bell. STEPS TO REPRODUCE 1. Enable "visual bell" in KDE system settings. 2. Open a terminal. 3. Hit "delete" without having typed anything into the prompt. OBSERVED RESULT Nothing happens (I guess a sound is played but I have the system muted). EXPECTED RESULT A visual bell should be triggered. This happens when I do the exact same thing in gnome-terminal (in a KDE session). SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 407891] New: KRunner crashed when searching
https://bugs.kde.org/show_bug.cgi?id=407891 Bug ID: 407891 Summary: KRunner crashed when searching Product: krunner Version: 5.14.5 Platform: Debian stable OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@privat.broulik.de Reporter: p...@ralfj.de Target Milestone: --- Application: krunner (5.14.5) Qt Version: 5.11.3 Frameworks Version: 5.54.0 Operating System: Linux 4.19.0-5-amd64 x86_64 Distribution: Debian GNU/Linux 10 (buster) -- Information about the crash: - What I was doing when the application crashed: I triggered krunner and entered "susp" to see if it would find a "suspend" action. Nothing came up so I started to delete what I typed. Then KRunner crashed. -- Backtrace: Application: krunner (krunner), signal: Aborted Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63 [Current thread is 1 (Thread 0x7fd62a0e5cc0 (LWP 2111))] Thread 23 (Thread 0x7fd5d5ffb700 (LWP 2055)): #0 0x7fd62ea4f00c in futex_wait_cancelable (private=0, expected=0, futex_word=0x564bcd2b13e0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x7fd62ea4f00c in __pthread_cond_wait_common (abstime=0x0, mutex=0x564bcd2b1390, cond=0x564bcd2b13b8) at pthread_cond_wait.c:502 #2 0x7fd62ea4f00c in __pthread_cond_wait (cond=0x564bcd2b13b8, mutex=0x564bcd2b1390) at pthread_cond_wait.c:655 #3 0x7fd62faa125b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fd613be4d30 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #5 0x7fd613be8ae8 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #6 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #7 0x7fd613be6bb9 in ThreadWeaver::Thread::run() () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #8 0x7fd62faa0aa7 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7fd62ea48fa3 in start_thread (arg=) at pthread_create.c:486 #10 0x7fd62f7904cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 22 (Thread 0x7fd5d67fc700 (LWP 2054)): #0 0x7fd62ea4f00c in futex_wait_cancelable (private=0, expected=0, futex_word=0x564bcd2b13e0) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x7fd62ea4f00c in __pthread_cond_wait_common (abstime=0x0, mutex=0x564bcd2b1390, cond=0x564bcd2b13b8) at pthread_cond_wait.c:502 #2 0x7fd62ea4f00c in __pthread_cond_wait (cond=0x564bcd2b13b8, mutex=0x564bcd2b1390) at pthread_cond_wait.c:655 #3 0x7fd62faa125b in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fd613be4d30 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #5 0x7fd613be8ae8 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #6 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #7 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #8 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #9 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #10 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #11 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #12 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #13 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #14 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #15 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #16 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #17 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #18 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #19 0x7fd613be8b42 in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #20 0x7fd613be3e3d in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*,
[kwallet-pam] [Bug 407892] New: Kwallet does not get unlocked when I unlock my screen
https://bugs.kde.org/show_bug.cgi?id=407892 Bug ID: 407892 Summary: Kwallet does not get unlocked when I unlock my screen Product: kwallet-pam Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY When I unlock my screen, I always immediately get a KWallet password prompt. So I effectively have to enter my password twice. I expected the PAM module to take care of that. STEPS TO REPRODUCE 1. Lock your screen. 2. Unlock it. OBSERVED RESULT There's a KWallet prompt asking for my password (saying "kded5" needs it, which is not very informative). EXPECTED RESULT The PAM module should take care of this. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 10 KDE Plasma Version: 5.14.5 Qt Version: 5.11.3 KDE Frameworks Version: 5.54.0 Kernel Version: 4.19.0-5-amd64 OS Type: 64-bit ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwallet-pam] [Bug 407892] Kwallet does not get unlocked when I unlock my screen
https://bugs.kde.org/show_bug.cgi?id=407892 --- Comment #2 from Ralf Jung --- > Given kwallet's only job is to protect a system that's at rest. I struggle to > see a use case for closing it when you lock the screen in combination with > auto unlock that would provide any security. Assuming the attacker grabs my laptop while the screen is locked, it would be nice to know that the wallet is closed and hence nothing can be extracted from RAM. So, disabling auto-close-on-lock would severely degrade security. Auto-open-wallet-on-screen-unlock OTOH does not degrade security as both the screen lock and the walltet are protected by the same password. So, I think there is quite an obvious use-case for this and it would significantly increase security, in particular when the laptop is hardly ever turned off so all the time "at rest" is spent in suspend. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407748] New: Left edge of screen is not "part" of maximized window
https://bugs.kde.org/show_bug.cgi?id=407748 Bug ID: 407748 Summary: Left edge of screen is not "part" of maximized window Product: kwin Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY When I move the cursor to the left edge of the screen and e.g. turn the scroll wheel, nothing happens. When I click and there are controls on the left edge of the window, nothing happens. It's as if the window manager would not consider this "one pixel column" on the left to be part of the window. I can also see that the cursor changes, which is likely related to a different bug: all KWin context menus (when I e.g. right-click a title bar) have a bigger cursor than everything else (meaning the cursor gets bigger when it is above one of these menus), and the same bigger cursor also shows when I move it all the way to the left edge of the screen. STEPS TO REPRODUCE 1. Log in, start e.g. a web browser. 2. Maximize the web browser, and surf to some website that gets a scroll bar. 3. Move the cursor to the left edge of the screen and turn the scroll wheel OBSERVED RESULT Nothing happens. EXPECTED RESULT The website should be scrolled. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION My internal laptop screen is 4K, but I am using it with a resolution of 1920x1080. The issue occurs both with that screen and with an external screen connected via HDMI. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 387775] KWin touch screen edge creates a 1 pixel dead zone on that edge that doesn't accept mouse clicks outside of full-screen mode
https://bugs.kde.org/show_bug.cgi?id=387775 --- Comment #18 from Ralf Jung --- > I hit this before in Bug 386735. The issue is a KWin left screen edge action > or top hot corner; they create the one-pixel dead zone. Turning them off will > work around the issue. Thanks a lot, I can confirm that this works. However, KWin has to be restarted after turning off the edge action. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407749] New: KWin menus use a too big cursor
https://bugs.kde.org/show_bug.cgi?id=407749 Bug ID: 407749 Summary: KWin menus use a too big cursor Product: kwin Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY The cursor changes whenever it hovers a KWin control (including title bar context menus, the menus that appear when left-clicking a window icon, and moving the cursor over the alt-tab menu): it approximately doubles in size. Looks like somehow KWin thinks it needs a high-dpi cursor theme when it does not? STEPS TO REPRODUCE 1. Right-click a title bar, and hover the menu that appears. OBSERVED RESULT The cursor doubles in size. EXPECTED RESULT The cursor should stay the same as it is for the rest of the system. SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.54.0 Qt Version: 5.11.3 ADDITIONAL INFORMATION My internal laptop screen has a resolution of 4K, but I am using it with 1920x1080 (I change between internal and external screens a lot, and with KDE seemingly not supporting dynamic zoom factor changes, that's my only option). Also, my laptop is one of these weird "reverse prime" machines where the external HDMI port is connected to the NVidia chip, but the internal screen is connected to the Intel chip. I am using SDDM, and added the following to /usr/share/sddm/scripts/Xsetup : xrandr --setprovideroutputsource 1 0 xrandr --auto So SDDM starts on my 4K internal screen, then the external screen gets added (which SDDM does not handle very well, but that's SDDM's problem), then I log in and whenever KDE applies the stored screen configuration the resolution changes from 4K to 1080p. In the midst of this, it seems like KWin gets confused about the cursor theme. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407749] KWin menus use a too big cursor
https://bugs.kde.org/show_bug.cgi?id=407749 Ralf Jung changed: What|Removed |Added Attachment #120197|0 |1 is obsolete|| --- Comment #4 from Ralf Jung --- Created attachment 120198 --> https://bugs.kde.org/attachment.cgi?id=120198=edit Screenshot with small cursor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407749] KWin menus use a too big cursor
https://bugs.kde.org/show_bug.cgi?id=407749 --- Comment #2 from Ralf Jung --- Created attachment 120196 --> https://bugs.kde.org/attachment.cgi?id=120196=edit Screenshot with big cursor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407749] KWin menus use a too big cursor
https://bugs.kde.org/show_bug.cgi?id=407749 --- Comment #3 from Ralf Jung --- Created attachment 120197 --> https://bugs.kde.org/attachment.cgi?id=120197=edit Screenshot with small cursor -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 407749] KWin menus use a too big cursor
https://bugs.kde.org/show_bug.cgi?id=407749 --- Comment #5 from Ralf Jung --- > Hmm, if you use resolution dependent cursor size, then I would expect the > cursor to decrease in its size when you hover window decorations, etc. Unless > you force some specific cursor size, e.g. 48. "Size" is set to "resolution dependent". But thanks for pointing to that setting, that should make a good work-around. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 408677] Screen sometimes comes up black from suspend when suspending with external screen connected
https://bugs.kde.org/show_bug.cgi?id=408677 Ralf Jung changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #3 from Ralf Jung --- This happened again and I captured the output of "DISPLAY=:0 xrandr -q": Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP-1 connected (normal left inverted right x axis y axis) 3840x2160 60.00 + 59.9859.97 3200x1800 59.9659.94 2880x1620 59.9659.97 2560x1600 59.9959.97 2560x1440 59.9959.9959.9659.95 2048x1536 60.00 1920x1440 60.00 1856x1392 60.01 1792x1344 60.01 2048x1152 59.9959.9859.9059.91 1920x1200 59.8859.95 1920x1080 60.0159.9759.9659.93 1600x1200 60.00 1680x1050 59.9559.88 1600x1024 60.17 1400x1050 59.98 1600x900 59.9959.9459.9559.82 1280x1024 60.02 1440x900 59.89 1400x900 59.9659.88 1280x960 60.00 1440x810 60.0059.97 1368x768 59.8859.85 1360x768 59.8059.96 1280x800 59.9959.9759.8159.91 1152x864 60.00 1280x720 60.0059.9959.8659.74 1024x768 60.0460.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.9559.9659.9059.82 960x600 59.9360.00 960x540 59.9659.9959.6359.82 800x600 60.0060.3256.25 840x525 60.0159.88 864x486 59.9259.57 800x512 60.17 700x525 59.98 800x450 59.9559.82 640x512 60.02 720x450 59.89 700x450 59.9659.88 640x480 60.0059.94 720x405 59.5158.99 684x384 59.8859.85 680x384 59.8059.96 640x400 59.8859.98 576x432 60.06 640x360 59.8659.8359.8459.32 512x384 60.00 512x288 60.0059.92 480x270 59.6359.82 400x300 60.3256.34 432x243 59.9259.57 320x240 60.05 360x202 59.5159.13 320x180 59.8459.32 DP-1-1 disconnected (normal left inverted right x axis y axis) DP-1-2 disconnected (normal left inverted right x axis y axis) DP-1-3 disconnected (normal left inverted right x axis y axis) I also, for the first time, managed to get the machine out of this state without restart my session, by blindly typing "xrandr --auto" on a terminal. (Doing "DISPLAY=:0 xrandr --auto" on another terminal did not work.) -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 408677] Screen sometimes comes up black from suspend when suspending with external screen connected
https://bugs.kde.org/show_bug.cgi?id=408677 --- Comment #2 from Ralf Jung --- > Do you have a cursor on the black screen? No, if I recall correctly the screen is black as if it was just turned off. (Which is why I tried "xbacklight", I remember that helping in a similar situation several years ago on another machine. Seems like I need to figure out which command I have to use for that nowadays.) > Please do this and then run I will try that next time it happens. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 408677] New: Screen sometimes comes up black from suspend when suspending with external screen connected
https://bugs.kde.org/show_bug.cgi?id=408677
Bug ID: 408677
Summary: Screen sometimes comes up black from suspend when
suspending with external screen connected
Product: kwin
Version: 5.14.5
Platform: Other
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: p...@ralfj.de
Target Milestone: ---
SUMMARY
Sometimes, when I (in quick succession) unplug the external screen and suspend
my laptop by closing the lid, when I resume the laptop, the internal screen is
just black.
This is a critical bug that leads to data loss because I have to hard-kill the
KDE session.
STEPS TO REPRODUCE
1. Have an external screen connected and but the desktop exclusively there (so
the internal screen is disabled).
2. Unplug the screen and suspend the machine in quick succession. Unfortunately
I have not found a way to reproduce this.
3. Resume the machine.
OBSERVED RESULT
The internal screen comes back black.
EXPECTED RESULT
The internal screen should be enabled properly when coming back from suspend.
SOFTWARE/OS VERSIONS
Operating System: Debian GNU/Linux 10
KDE Plasma Version: 5.14.5
Qt Version: 5.11.3
KDE Frameworks Version: 5.54.0
Kernel Version: 4.19.0-5-amd64
OS Type: 64-bit
ADDITIONAL INFORMATION
Connecting an external screen to HDMI shows that the image is still on that
port. But of course when I am traveling at that point, I don't usually have an
external screen in my luggage...
Ctrl-Alt-Fn still switches to a normal terminal session, but switching back to
X11 does not fix the issue. I can blindly unlock the screen, open a terminal
and type "touch xx" to see (in the terminal) that this actually happens. But I
found no way to enable the screen so far. I tried "xrandr -q". ("xbacklight"
does not work at all on my laptop so I couldn't try that.)
I have used Gnome on this laptop for a year and this has not happened a single
time. Hence I think that this is an issue in KDE, not in the drivers.
--
You are receiving this mail because:
You are watching all bug changes.
[drkonqi] [Bug 415062] Fails to submit crash report when backtrace is too big
https://bugs.kde.org/show_bug.cgi?id=415062 --- Comment #2 from Ralf Jung --- I can, once it lands in my distro... Though also I wouldn't know how to trigger this error on purpose. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 415062] New: Fails to submit crash report when backtrace is too big
https://bugs.kde.org/show_bug.cgi?id=415062 Bug ID: 415062 Summary: Fails to submit crash report when backtrace is too big Product: drkonqi Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: p...@ralfj.de Target Milestone: --- Created attachment 124436 --> https://bugs.kde.org/attachment.cgi?id=124436=edit the message DrKonqi failed to submit SUMMARY DrKonqi fails to submit a bug report when the backtrace is too long. STEPS TO REPRODUCE 1. Make a KDE application crash with a big backtrace (and lots of threads) 2. Try to submit the crash report through DrKonqi OBSERVED RESULT It says "Error sending crash report", "Error message was: Comments cannot be bigger than 65535 characters". EXPECTED RESULT DrKonqi shouldn't fail to submit a bugreport. Maybe make the backtrace an attachment instead? SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.14.5 Qt Version: 5.12.5 KDE Frameworks Version: 5.62.0 Kernel Version: 5.3.0-2-amd64 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 15,6 GiB of RAM ADDITIONAL INFORMATION I attached the message DrKonqi tried to submit. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419980] Cannot change relative position of multiple screens
https://bugs.kde.org/show_bug.cgi?id=419980 --- Comment #1 from Ralf Jung --- Setting "Windows' drag mode" in the Breeze widget style settings to "titlebar, menubar and toolbar" instead of "all empty areas" works around the problem. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419980] New: Cannot change relative position of multiple screens
https://bugs.kde.org/show_bug.cgi?id=419980 Bug ID: 419980 Summary: Cannot change relative position of multiple screens Product: systemsettings Version: 5.17.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_kscreen Assignee: kscreen-bugs-n...@kde.org Reporter: p...@ralfj.de CC: plasma-b...@kde.org Target Milestone: --- SUMMARY When I have multiple screens connected, I cannot change their relative position in the Display settings. I expect to be able to drag the screens around, but drag'n'drop moves the configuration window itself, instead of its content. STEPS TO REPRODUCE 1. Have more than 1 screen connected. 2. In the display settings, try to drag'n'drop one of the screens to change their relative position. OBSERVED RESULT The entire window starts moving around, as if I had drag'n'droped the title bar. EXPECTED RESULT The screen in the configuration should be moved around. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.5 Kernel Version: 5.4.19 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 15,5 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407821] Terminal bell does not trigger system (visual) bell
https://bugs.kde.org/show_bug.cgi?id=407821 --- Comment #11 from Ralf Jung --- What is missing from that list is "call XkbBell", which seems to be the standard way of triggering the system bell in X11. (I tried SystemBeepBell, but it doesn't seem to do that.) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 407821] Terminal bell does not trigger system (visual) bell
https://bugs.kde.org/show_bug.cgi?id=407821 --- Comment #9 from Ralf Jung --- > BellMode=2 Interesting option, thanks! This still does not trigger a system bell, but it means that Konsole manually replicates the behavior of the system bell (if that is set to flash, too). Of course, it would be much better if Konsole could just respect my global configuration. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 425823] New: Lock wallet when machine goes to suspend
https://bugs.kde.org/show_bug.cgi?id=425823 Bug ID: 425823 Summary: Lock wallet when machine goes to suspend Product: frameworks-kwallet Version: 5.70.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: va...@kde.org Reporter: p...@ralfj.de CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY The wallet should get locked when the machine goes to suspend, to protect secrets against memory-readout attacks. (It might even be a good idea to do this any time the screen is locked.) STEPS TO REPRODUCE 1. Open and unlock the wallet. 2. Suspend machine. 3. Resume machine. OBSERVED RESULT The wallet is still unlocked. EXPECTED RESULT The wallet should be locked. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.70.0 Qt Version: 5.14.2 Kernel Version: 5.6.13 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 15,5 GiB of RAM ADDITIONAL INFORMATION See https://blog.freesources.org//posts/2020/08/cryptsetup-suspend/ for some more discussion of security around system suspend. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 438823] New: "kded5 has requested to open the wallet": no information, no way to reject
https://bugs.kde.org/show_bug.cgi?id=438823 Bug ID: 438823 Summary: "kded5 has requested to open the wallet": no information, no way to reject Product: frameworks-kwallet Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: va...@kde.org Reporter: p...@ralfj.de CC: kdelibs-b...@kde.org Target Milestone: --- Every now and then, when I start an application (Steam seems to often trigger this), I then get a pop from KWallet saying that kded5 requested to open the wallet, could I please enter my password. This popup contains very little useful information, since kded5 is doing many different things. So all I know is *something* wants to access all my passwords. What are my options? - I can hit "cancel". In that case, the password prompt will just open again. I have hit "escape" for more than a minute to see if it ever gives up; it looks like the computer has more patience than I do. - Or I can enter my password, and just hope that this request is legitimate. This is not a great user experience for two reasons: - There is not enough information presented to make a meaningful choice. - There is no way to even make a choice, since when I want to say "no", KDE simply ignores that and just asks again until I give in and say "yes". Operating System: Debian GNU/Linux 11 KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-6-amd64 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 438823] "kded5 has requested to open the wallet": no information, no way to reject
https://bugs.kde.org/show_bug.cgi?id=438823 --- Comment #3 from Ralf Jung --- Another situation where such a "kded5" wallet prompt appears is when I shut down a VM in virt-manager. So I suspect it has something to do with network devices changing? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kwallet] [Bug 438823] "kded5 has requested to open the wallet": no information, no way to reject
https://bugs.kde.org/show_bug.cgi?id=438823 --- Comment #2 from Ralf Jung --- So is Steam able to access the KDE wallet? I wasn't able to find information about this, and I'd prefer it it did not access my wallet... Usually when an application accesses the wallet, it shows the application name and I can say "deny forever". So the fact that kded5 is listed here makes me wonder if this is truly Steam doing this, or if launching steam triggers... something... that triggers kded5 into doing something. -- You are receiving this mail because: You are watching all bug changes.
[kgpg] [Bug 354338] with tray icon shown, kgpg cannot be opened from launcher or CLI
https://bugs.kde.org/show_bug.cgi?id=354338 Ralf Jung changed: What|Removed |Added CC||p...@ralfj.de --- Comment #6 from Ralf Jung --- I agree that this is a serious bug. I thought kgpg was entirely broken because when I started it from the launcher or from the CLI, exactly nothing happened. Only after searching for these symptoms did I find some (old) forum post telling me to use "kgpg -k". The bug title says "with tray icon shown", but the bug in fact also happens when the tray icon is not shown yet: either way, running "kgpg" (which is what the launcher does) does not open any KGPG UI. When I click "kgpg" in the launcher, a KGPG window should open, no matter whether there already is some (potentially hidden) icon in the systray or not. Everything else is a bug that will frequently make people entirely unable to use this software at all. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432788] New: kwin freezes when sharing a minimized window
https://bugs.kde.org/show_bug.cgi?id=432788 Bug ID: 432788 Summary: kwin freezes when sharing a minimized window Product: kwin Version: 5.20.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY When I "share my screen" in Firefox and select a minimized window, the screen freezes. STEPS TO REPRODUCE 1. Join a Jitsi video conference (meet.jit.si) in Firefox. 2. Click "Share my screen", then select a window that is minimized. OBSERVED RESULT The screen freezes, but I can still talk to the other people in the conference. I can also move the cursor, but other than that interaction with the graphical session becomes impossible. I have to hard-reboot the system. EXPECTED RESULT Nothing I do in Firefox should lead to the entire session freezing like that. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-1-amd64 OS Type: 64-bit Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 ADDITIONAL INFORMATION I am using X11. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 Ralf Jung changed: What|Removed |Added CC||p...@ralfj.de --- Comment #3 from Ralf Jung --- I am having the same problem: after boot, when I connect my phone, I can access files just fine. When I unplug and replug, I can no longer connect. I am doing a lot of unplugging and replugging since I am migrating from an old to a new phone. I basically have to reboot my entire system each time since KDE refuses to ever let go of that MTP connection. I hope killing kiod5 does not have too adverse side-effects. I can recommend "android-file-transfer" -- as long as KDE stays out of the way, it is a very reliably tool to access MTP devices. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 391083] Allow user to 'press' keys that aren't on Android keyboard
https://bugs.kde.org/show_bug.cgi?id=391083 Ralf Jung changed: What|Removed |Added CC||p...@ralfj.de --- Comment #4 from Ralf Jung --- Yes I think it would be great if KDEconnect had better support for this. I have installed Hacker's Keyboard (thanks for the recommendation), but for regular use I prefer the default Android keyboard -- so now I need to swap keyboards each time I need the advanced keys in KDEconnect. Also, even with Hacker's Keyboard I am unable to send things like "Ctrl-+", or at least it does not lead to applications actually zooming in. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 444952] Glitch in panel after restarting kwin
https://bugs.kde.org/show_bug.cgi?id=444952 Ralf Jung changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Ralf Jung --- > You said you can reproduce this just by restarting KWin? Yes. KWin is sadly crashing fairly regularly since the update (fix is supposed to be in 5.23.1) and the glitches do appear each time that happens. > does it get fixed by restarting plasmashell (`plasmashell --replace`)? Yes, though my restart script looks slightly different: killall plasmashell sleep 0.2 plasmashell & -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 444949] When connecting external primary screen on the left, maximized windows do not move over [regression]
https://bugs.kde.org/show_bug.cgi?id=444949 --- Comment #2 from Ralf Jung --- I'm a bit wary of doing such experiments on my main production system. ;) Is there a live system one could use to test this? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 444907] New: Add option to always show date below time
https://bugs.kde.org/show_bug.cgi?id=444907 Bug ID: 444907 Summary: Add option to always show date below time Product: plasmashell Version: 5.23.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Digital Clock Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: 1.0 SUMMARY Until Plasma 5.19 (I think), the digital clock would show the date in small font below the time. However, since the update to Plasma 5.20 (or maybe 5.21), it now shows the date next to the time, wasting a ton of horizontal space. It would be great to get back the option of having the date below the time, even if the font needs to be tiny to make them bit. My panel is set to be 30px high. With Plasma 5.23, there is the option to force the date next to the time; what I am hoping for is to also have the option to force the date *below* the time. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.0-2-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 444907] Add option to always show date below time
https://bugs.kde.org/show_bug.cgi?id=444907 --- Comment #2 from Ralf Jung --- That is great, thanks. :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 444949] New: When connecting external primary screen on the left, maximized windows do not move over [regression]
https://bugs.kde.org/show_bug.cgi?id=444949 Bug ID: 444949 Summary: When connecting external primary screen on the left, maximized windows do not move over [regression] Product: kwin Version: 5.23.0 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY With my laptop, I switch from single-screen to dual-screen setup and back at least daily. When the external screen is connected, I want all windows to be moved to that screen, since it is used as the main screen. (The laptop screen is turned on only for the rare case where I need some extra screen space, and to work around https://gitlab.freedesktop.org/xorg/xserver/-/issues/948.) That used to work fine up until Plasma 5.21, but with Plasma 5.23 is stopped working, meaning I now spend a bunch of time each day to move windows back and forth, which is quite annoying. STEPS TO REPRODUCE 1. Connect the external screen and configure it to be on the left of the internal screen, and make the external screen primary. 2. Disconnect the external screen. Have some windows open on the internal screen; some maximized, some not. 3. Connect the external screen. OBSERVED RESULT The non-maximized windows move over to the external screen (presumably because they remain at screen coordinate [0,0], and since the external screen is on the left, that coordinate is on the external screen). However, all the maximized windows remain on the internal screen (meaning their screen coordinate changes since the internal screen is 1920px to the right). EXPECTED RESULT All windows should move to the external screen. This is what happened in earlier versions of Plasma/kwin (up until 5.21, I did not test 5.22). SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.0-2-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 444952] New: Glitch in panel after restarting kwin
https://bugs.kde.org/show_bug.cgi?id=444952 Bug ID: 444952 Summary: Glitch in panel after restarting kwin Product: plasmashell Version: 5.23.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de Target Milestone: 1.0 Created attachment 143203 --> https://bugs.kde.org/attachment.cgi?id=143203=edit Screenshot of the panel with the extra horizontal artifact SUMMARY When kwin is restarted while Plasma already runs, the panel starts showing a strange horizontal line near the top. It disappears when restarting Plasma. STEPS TO REPRODUCE 1. In a running X11 session, restart kwin. OBSERVED RESULT A new horizontal artifact appears spanning the entire panel. See attached screenshot. EXPECTED RESULT The panel should look as before. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.23.0 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.0-2-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 444952] Glitch in panel after restarting kwin
https://bugs.kde.org/show_bug.cgi?id=444952 Ralf Jung changed: What|Removed |Added Platform|Other |Debian testing -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 353038] Drawing is stuttering
https://bugs.kde.org/show_bug.cgi?id=353038 --- Comment #13 from Ralf Jung --- I have not noticed issues with video playback in a while. Using my test application, I did get a rather stuttering 20fps -- but then after restarting KWin, it is up to 60fps. So it seems like in principle KWin can handle this properly, but sometimes it might get into a degraded state? Not sure how to reproduce this though. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 412257] kiod5 doesn't release usb device when it is not in use
https://bugs.kde.org/show_bug.cgi?id=412257 --- Comment #9 from Ralf Jung --- In my case, kio seems to even lock itself out -- after unplugging and re-plugging my phone, kio-based applications are unable to access it. Also, kio will lock the MTP device even without me using any kio app -- if I want to use another app, I always have to kill the KIO daemon, even if I did not open the phone in Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451811] New: After screen unplug, notifications show in wrong place
https://bugs.kde.org/show_bug.cgi?id=451811 Bug ID: 451811 Summary: After screen unplug, notifications show in wrong place Product: plasmashell Version: 5.24.3 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Multi-screen support Assignee: plasma-b...@kde.org Reporter: p...@ralfj.de CC: aleix...@kde.org, notm...@gmail.com Target Milestone: 1.0 Created attachment 147679 --> https://bugs.kde.org/attachment.cgi?id=147679=edit A screenshot demonstrating the wrong position of the notification SUMMARY After a screen got unplugged while the machine is suspended, Plasma shows notifications in the wrong spot. STEPS TO REPRODUCE 1. Have an external screen connected, with the internal screen being set up "to the right of" the external one 2. Put machine to sleep, unplug external screen, resume machine 3. Make a notification happen OBSERVED RESULT The notification shows in the wrong spot, it partially clips outside of the visible area and overlaps with the toolbar. (See attached screenshot.) EXPECTED RESULT The notification should show where it usually does: in the bottom right corner, *above* the toolbar. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.0-4-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 ADDITIONAL INFORMATION This seems to be a zombie bug that came back: https://bugs.kde.org/show_bug.cgi?id=373379. This is a regression, the same sequence of actions worked with before the latest KDE/Plasma update (previous I was on 5.22 or 5.23). It's not just notifications, other things like KRunner also show in the wrong spot. Connecting and disconnecting another external screen while the machine runs fixes the problem. So it seems like a bug was introduced recently where Plasma fails to notice screen geometry changes in some situations related to system suspend/resume. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451898] Notifications randomly switch to the left
https://bugs.kde.org/show_bug.cgi?id=451898 --- Comment #2 from Ralf Jung --- https://bugs.kde.org/show_bug.cgi?id=451811 has been marked as a duplicate, but I will note that I have seen wrong notification positions *only* after screen geometry changes, which seems different from the problem reported here. (But of course there could be a common cause.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451612] Kwin crashes in KWin::WindowThumbnailItem::updateOffscreenTexture() when switching applications
https://bugs.kde.org/show_bug.cgi?id=451612 Ralf Jung changed: What|Removed |Added CC||p...@ralfj.de --- Comment #3 from Ralf Jung --- I am also seeing this with the Debian packages: Operating System: Debian GNU/Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.0-4-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 Application: KWin (kwin_x11), signal: Aborted [KCrash Handler] #4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #5 0x7fec33251546 in __GI_abort () at abort.c:79 #6 0x7fec2660331c in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #7 0x7fec27270f79 in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #8 0x7fec267e38a9 in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #9 0x7fec35f0fa34 in KWin::WindowThumbnailItem::updateOffscreenTexture() (this=0x563bfc044c80) at ./src/scripting/thumbnailitem.cpp:432 #10 0x7fec343ea1b3 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffcb2a4da30, r=0x563bfc044c80, this=0x563bfc17f070) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #11 doActivate(QObject*, int, void**) (sender=0x563bfb0bd960, signal_index=3, argv=0x7ffcb2a4da30) at kernel/qobject.cpp:3886 #12 0x7fec343e367f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=sender@entry=0x563bfb0bd960, m=m@entry=0x7fec360c0d20 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x0) at kernel/qobject.cpp:3946 #13 0x7fec35de1800 in KWin::Scene::frameRendered() (this=this@entry=0x563bfb0bd960) at ./obj-x86_64-linux-gnu/src/kwin_autogen/EWIEGA46WW/moc_scene.cpp:155 #14 0x7fec35ee10fb in KWin::Scene::paintScreen(QRegion const&, QRegion const&, QRegion*, QRegion*, KWin::RenderLoop*, QMatrix4x4 const&) (this=this@entry=0x563bfb0bd960, damage=..., repaint=..., updateRegion=updateRegion@entry=0x7ffcb2a4dbd0, validRegion=validRegion@entry=0x7ffcb2a4dbd8, renderLoop=renderLoop@entry=0x563bfacef090, projection=...) at ./src/scene.cpp:282 #15 0x7fec35fb902e in KWin::SceneOpenGL::paint(KWin::AbstractOutput*, QRegion const&, QList const&, KWin::RenderLoop*) (this=0x563bfb0bd960, output=0x0, damage=..., toplevels=, renderLoop=0x563bfacef090) at ./src/scenes/opengl/scene_opengl.cpp:259 #16 0x7fec35e32e0e in KWin::Compositor::composite(KWin::RenderLoop*) (this=0x563bfaa40f60, renderLoop=0x563bfacef090) at ./src/composite.cpp:633 #17 0x7fec35e334ab in KWin::X11Compositor::composite(KWin::RenderLoop*) (this=0x563bfaa40f60, renderLoop=0x563bfacef090) at ./src/composite.cpp:844 #18 0x7fec343ea1b3 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffcb2a4dec0, r=0x563bfaa40f60, this=0x563bfaf15260) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #19 doActivate(QObject*, int, void**) (sender=0x563bfacef090, signal_index=5, argv=0x7ffcb2a4dec0) at kernel/qobject.cpp:3886 #20 0x7fec343e367f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7fec360c0da0 , local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x7ffcb2a4dec0) at kernel/qobject.cpp:3946 #21 0x7fec35de6372 in KWin::RenderLoop::frameRequested(KWin::RenderLoop*) (this=, _t1=) at ./obj-x86_64-linux-gnu/src/kwin_autogen/EWIEGA46WW/moc_renderloop.cpp:206 #22 0x7fec35ecf5a3 in KWin::RenderLoopPrivate::dispatch() (this=0x563bface4e10) at ./src/renderloop.cpp:150 #23 0x7fec343ea1b3 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffcb2a4dfe0, r=0x563bfacef090, this=0x563bfacf69b0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #24 doActivate(QObject*, int, void**) (sender=0x563bface4e28, signal_index=3, argv=0x7ffcb2a4dfe0) at kernel/qobject.cpp:3886 #25 0x7fec343e367f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7fec3464d2e0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffcb2a4dfe0) at kernel/qobject.cpp:3946 #26 0x7fec343ee05a in QTimer::timeout(QTimer::QPrivateSignal) (this=, _t1=...) at .moc/moc_qtimer.cpp:205 #27 0x7fec343e007f in QObject::event(QEvent*) (this=0x563bface4e28, e=0x7ffcb2a4e160) at kernel/qobject.cpp:1336 #28 0x7fec3398b71f in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x563bface4e28, e=0x7ffcb2a4e160) at kernel/qapplication.cpp:3632 #29 0x7fec343b3b4a in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x563bface4e28, event=0x7ffcb2a4e160) at kernel/qcoreapplication.cpp:1063 #30 0x7fec3440a52b in QTimerInfoList::activateTimers() (this=this@entry=0x563bfaa74ea8) at kernel/qtimerinfo_unix.cpp:643 #3
[kwin] [Bug 444949] When connecting external primary screen on the left, maximized windows do not move over [regression]
https://bugs.kde.org/show_bug.cgi?id=444949 --- Comment #4 from Ralf Jung --- I am now on plasma-desktop 4:5.24.3-1, kwin-x11 4:5.24.3-1 (Debian packages), and when I just plugged in my external screen the Windows still stayed on the laptop screen. So the bug still seems to be present in that version. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 415948] Session creation in Kate causes invalid desktop file to be placed in ~/.local/share/applications
https://bugs.kde.org/show_bug.cgi?id=415948 Ralf Jung changed: What|Removed |Added CC||p...@ralfj.de -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 415948] Session creation in Kate causes invalid desktop file to be placed in ~/.local/share/applications
https://bugs.kde.org/show_bug.cgi?id=415948 --- Comment #20 from Ralf Jung --- This is still a problem in Kate 22.12.3. It makes Kate very hard to use on non-KDE desktop environments that expect desktop files to match the spec. One doesn't even need to create a session. Just starting Kate when a session exists, and closing it again, will create the faulty desktop file. I would probably have to delete all my sessions to work around this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 465377] Sometimes, drag'n'drop of entries in the task bar stops working
https://bugs.kde.org/show_bug.cgi?id=465377 --- Comment #6 from Ralf Jung --- I think in my case it was probably the stuck modifier key issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451612] Kwin crashes in KWin::WindowThumbnailItem::updateOffscreenTexture() when switching applications
https://bugs.kde.org/show_bug.cgi?id=451612 --- Comment #27 from Ralf Jung --- I have just observed the crash with 5.24.5 (Debian testing): Application: KWin (kwin_x11), signal: Aborted [KCrash Handler] #4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #5 0x7fda6223a546 in __GI_abort () at abort.c:79 #6 0x7fda55f1831c in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #7 0x7fda56b861d9 in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #8 0x7fda560f88a9 in () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so #9 0x7fda64f03a04 in KWin::WindowThumbnailItem::updateOffscreenTexture() (this=0x56391648aaf0) at ./src/scripting/thumbnailitem.cpp:432 #10 0x7fda633d7133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffc2d9820c0, r=0x56391648aaf0, this=0x563916374c80) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #11 doActivate(QObject*, int, void**) (sender=0x563915478b70, signal_index=3, argv=0x7ffc2d9820c0) at kernel/qobject.cpp:3886 #12 0x7fda633d05ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=sender@entry=0x563915478b70, m=m@entry=0x7fda650b4c80 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x0) at kernel/qobject.cpp:3946 #13 0x7fda64dd5810 in KWin::Scene::frameRendered() (this=this@entry=0x563915478b70) at ./obj-x86_64-linux-gnu/src/kwin_autogen/EWIEGA46WW/moc_scene.cpp:155 #14 0x7fda64ed50cb in KWin::Scene::paintScreen(QRegion const&, QRegion const&, QRegion*, QRegion*, KWin::RenderLoop*, QMatrix4x4 const&) (this=this@entry=0x563915478b70, damage=..., repaint=..., updateRegion=updateRegion@entry=0x7ffc2d982260, validRegion=validRegion@entry=0x7ffc2d982268, renderLoop=renderLoop@entry=0x7fda58003230, projection=...) at ./src/scene.cpp:282 #15 0x7fda64fad6de in KWin::SceneOpenGL::paint(KWin::AbstractOutput*, QRegion const&, QList const&, KWin::RenderLoop*) (this=0x563915478b70, output=0x0, damage=..., toplevels=, renderLoop=0x7fda58003230) at ./src/scenes/opengl/scene_opengl.cpp:259 #16 0x7fda64e26e1e in KWin::Compositor::composite(KWin::RenderLoop*) (this=0x5639151df820, renderLoop=0x7fda58003230) at ./src/composite.cpp:633 #17 0x7fda64e274bb in KWin::X11Compositor::composite(KWin::RenderLoop*) (this=0x5639151df820, renderLoop=0x7fda58003230) at ./src/composite.cpp:844 #18 0x7fda633d7133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffc2d982550, r=0x5639151df820, this=0x563915650580) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #19 doActivate(QObject*, int, void**) (sender=0x7fda58003230, signal_index=5, argv=0x7ffc2d982550) at kernel/qobject.cpp:3886 #20 0x7fda633d05ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7fda650b4d00 , local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x7ffc2d982550) at kernel/qobject.cpp:3946 #21 0x7fda64dda382 in KWin::RenderLoop::frameRequested(KWin::RenderLoop*) (this=, _t1=) at ./obj-x86_64-linux-gnu/src/kwin_autogen/EWIEGA46WW/moc_renderloop.cpp:206 #22 0x7fda64ec3573 in KWin::RenderLoopPrivate::dispatch() (this=0x563915281860) at ./src/renderloop.cpp:150 #23 0x7fda633d7133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffc2d982670, r=0x7fda58003230, this=0x563915287d90) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #24 doActivate(QObject*, int, void**) (sender=0x563915281878, signal_index=3, argv=0x7ffc2d982670) at kernel/qobject.cpp:3886 #25 0x7fda633d05ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7fda6363a2e0 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffc2d982670) at kernel/qobject.cpp:3946 #26 0x7fda633dafda in QTimer::timeout(QTimer::QPrivateSignal) (this=, _t1=...) at .moc/moc_qtimer.cpp:205 #27 0x7fda633ccfff in QObject::event(QEvent*) (this=0x563915281878, e=0x7ffc2d9827f0) at kernel/qobject.cpp:1336 #28 0x7fda629776bf in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=, receiver=0x563915281878, e=0x7ffc2d9827f0) at kernel/qapplication.cpp:3632 #29 0x7fda633a0aca in QCoreApplication::notifyInternal2(QObject*, QEvent*) (receiver=0x563915281878, event=0x7ffc2d9827f0) at kernel/qcoreapplication.cpp:1063 #30 0x7fda633f74ab in QTimerInfoList::activateTimers() (this=this@entry=0x563915010ce8) at kernel/qtimerinfo_unix.cpp:643 #31 0x7fda633f4c6c in QEventDispatcherUNIXPrivate::activateTimers() (this=this@entry=0x563915010c60) at kernel/qeventdispatcher_unix.cpp:249 #32 0x7fda633f59b7 in QEventDispatcherUNIX::processEvents(QFlags) (this=, flags=...) at kernel/qeventdispatcher_unix.cpp:516 #33 0x7fda5cd5e91e in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #34 0x7fda6339f4db in QEventLoop::exec(QFlags) (this=this@entry=0x7ffc2d982990, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/gl
[konsole] [Bug 456253] New: "http://127.0.0.1:4000/" no longer recognized as a single link (including the port)
https://bugs.kde.org/show_bug.cgi?id=456253 Bug ID: 456253 Summary: "http://127.0.0.1:4000/; no longer recognized as a single link (including the port) Product: konsole Version: 22.04.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: p...@ralfj.de Target Milestone: --- SUMMARY The string "http://127.0.0.1:4000/; no longer becomes a single clickable link in Konsole. Instead it thinks the link is for "http://127.0.0.1;. STEPS TO REPRODUCE 1. "echo http://127.0.0.1:4000/; 2. Right-click on the link, "Open Link" OBSERVED RESULT It opens "http://127.0.0.1; EXPECTED RESULT It should open "http://127.0.0.1:4000/;. This used to work a few months ago, so I think this is some recent regression. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.18.0-2-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Xeon® CPU E3-1505M v5 @ 2.80GHz Memory: 31,2 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics P530 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453562] Plasma freezes when saving an edited image
https://bugs.kde.org/show_bug.cgi?id=453562 --- Comment #7 from Ralf Jung --- Here's a main thread backtrace with some more debug symbols installed: (gdb) bt #0 0x7f0e019ef0fa in __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x5565f3675134, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7ffeb44b54e0, private=private@entry=0, cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74 #1 0x7f0e019ef15b in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5565f3675134, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7ffeb44b54e0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123 #2 0x7f0e019e8f44 in __pthread_cond_wait_common (abstime=0x7ffeb44b54e0, clockid=1, mutex=0x5565f36750e0, cond=0x5565f3675108) at pthread_cond_wait.c:504 #3 __pthread_cond_timedwait (cond=0x5565f3675108, mutex=0x5565f36750e0, abstime=0x7ffeb44b54e0) at pthread_cond_wait.c:637 #4 0x7f0e020657a8 in QWaitConditionPrivate::wait_relative(QDeadlineTimer) (deadline=..., this=0x5565f36750e0) at thread/qwaitcondition_unix.cpp:136 #5 QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x5565f36750e0) at thread/qwaitcondition_unix.cpp:144 #6 QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=, mutex=0x5565f3658928, deadline=...) at thread/qwaitcondition_unix.cpp:225 #7 0x7f0e020658a7 in QWaitCondition::wait(QMutex*, unsigned long) (this=0x5565f3658930, mutex=0x5565f3658928, time=) at thread/qwaitcondition_unix.cpp:209 #8 0x7f0dfcf7e673 in QXcbEventQueue::waitForNewEvents(unsigned long) (this=this@entry=0x5565f36588c0, time=163) at ./src/plugins/platforms/xcb/qxcbeventqueue.cpp:360 #9 0x7f0dfcf53a60 in QXcbClipboard::waitForClipboardEvent(unsigned int, int, bool) (this=this@entry=0x5565f36fc3b0, window=window@entry=41943085, type=type@entry=31, checkManager=checkManager@entry=false) at ./src/plugins/platforms/xcb/qxcbclipboard.cpp:809 #10 0x7f0dfcf54149 in QXcbClipboard::getSelection(unsigned int, unsigned int, unsigned int, unsigned int) (this=0x5565f36fc3b0, selection=1, target=380, property=385, time=286955112, time@entry=0) at ./src/plugins/platforms/xcb/qxcbclipboard.cpp:900 #11 0x7f0dfcf55b68 in QXcbClipboard::getDataInFormat(unsigned int, unsigned int) (fmtAtom=, modeAtom=, this=) at ./qxcbatom.h:249 #12 QXcbClipboardMime::formats_sys() const (this=0x5565f5cfd060) at ./src/plugins/platforms/xcb/qxcbclipboard.cpp:100 #13 0x7f0e0263f6bf in QInternalMimeData::formats() const (this=) at kernel/qinternalmimedata.cpp:98 #14 0x7f0d836505fd in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_clipboard.so #15 0x7f0e0227a133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffeb44b5900, r=0x5565f5b8e490, this=0x7f0df8006f20) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #16 doActivate(QObject*, int, void**) (sender=0x7f0df8008750, signal_index=3, argv=0x7ffeb44b5900) at kernel/qobject.cpp:3886 #17 0x7f0e013157ee in KSystemClipboard::changed(QClipboard::Mode) () at /usr/lib/x86_64-linux-gnu/libKF5GuiAddons.so.5 #18 0x7f0e0227a133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffeb44b5a10, r=0x7f0df8008750, this=0x5565f5ba3fa0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #19 doActivate(QObject*, int, void**) (sender=0x5565f3ea9ad0, signal_index=3, argv=0x7ffeb44b5a10) at kernel/qobject.cpp:3886 #20 0x7f0e022735ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (sender=, m=m@entry=0x7f0e02ba1c20 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffeb44b5a10) at kernel/qobject.cpp:3946 #21 0x7f0e02a8face in QClipboard::changed(QClipboard::Mode) (this=, _t1=) at .moc/moc_qclipboard.cpp:168 #22 0x7f0e0263016b in QClipboard::emitChanged(QClipboard::Mode) (this=, mode=) at kernel/qclipboard.cpp:608 #23 0x7f0e026121e3 in QPlatformClipboard::emitChanged(QClipboard::Mode) (this=, mode=) at kernel/qplatformclipboard.cpp:125 #24 0x7f0dfcf543a6 in QXcbClipboard::handleXFixesSelectionRequest(xcb_xfixes_selection_notify_event_t*) (this=, event=event@entry=0x7f0df801a460) at ./src/plugins/platforms/xcb/qxcbclipboard.cpp:679 #25 0x7f0dfcf57c74 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) (this=this@entry=0x5565f365c420, event=event@entry=0x7f0df801a460) at ./src/plugins/platforms/xcb/qxcbconnection.cpp:685 #26 0x7f0dfcf59186 in QXcbConnection::processXcbEvents(QFlags) (this=0x5565f365c420, flags=...) at ./src/plugins/platforms/xcb/qxcbconnection.cpp:1003 #27 0x7f0dfcf7f573 in xcbSourceDispatch(GSource*, GSourceFunc, gpointer) (source=) at ./src/plugins/platforms/xcb/qxcbeventdispatcher.cpp:103 #28 0x7f0e001eff8b in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x7f0e001f0238 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0
[plasmashell] [Bug 453562] Plasma freezes when saving an edited image
https://bugs.kde.org/show_bug.cgi?id=453562 --- Comment #6 from Ralf Jung --- Created attachment 149516 --> https://bugs.kde.org/attachment.cgi?id=149516=edit 'thread apply all bt' when the freeze happens -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 453562] Plasma freezes when saving an edited image
https://bugs.kde.org/show_bug.cgi?id=453562 Ralf Jung changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|BACKTRACE |--- --- Comment #5 from Ralf Jung --- Okay I think I got a setup that reproduces the problem, and I *think* I captured the right backtrace -- I will add the 'thread apply all bt' as an attachment, but here's the main thread: Thread 1 (Thread 0x7f0dfd3f29c0 (LWP 814183) "plasmashell"): #0 0x7f0e019ef0fa in __futex_abstimed_wait_common64 (futex_word=futex_word@entry=0x5565f3675130, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7ffeb44b54e0, private=private@entry=0, cancel=cancel@entry=true) at ../sysdeps/nptl/futex-internal.c:74 #1 0x7f0e019ef15b in __GI___futex_abstimed_wait_cancelable64 (futex_word=futex_word@entry=0x5565f3675130, expected=expected@entry=0, clockid=clockid@entry=1, abstime=abstime@entry=0x7ffeb44b54e0, private=private@entry=0) at ../sysdeps/nptl/futex-internal.c:123 #2 0x7f0e019e8f44 in __pthread_cond_wait_common (abstime=0x7ffeb44b54e0, clockid=1, mutex=0x5565f36750e0, cond=0x5565f3675108) at pthread_cond_wait.c:504 #3 __pthread_cond_timedwait (cond=0x5565f3675108, mutex=0x5565f36750e0, abstime=0x7ffeb44b54e0) at pthread_cond_wait.c:637 #4 0x7f0e020657a8 in QWaitConditionPrivate::wait_relative(QDeadlineTimer) (deadline=..., this=0x5565f36750e0) at thread/qwaitcondition_unix.cpp:136 --Type for more, q to quit, c to continue without paging-- #5 QWaitConditionPrivate::wait(QDeadlineTimer) (deadline=..., deadline=..., this=0x5565f36750e0) at thread/qwaitcondition_unix.cpp:144 #6 QWaitCondition::wait(QMutex*, QDeadlineTimer) (this=, mutex=0x5565f3658928, deadline=...) at thread/qwaitcondition_unix.cpp:225 #7 0x7f0e020658a7 in QWaitCondition::wait(QMutex*, unsigned long) (this=0x5565f3658930, mutex=0x5565f3658928, time=) at thread/qwaitcondition_unix.cpp:209 #8 0x7f0dfcf7e673 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #9 0x7f0dfcf53a60 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #10 0x7f0dfcf54149 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #11 0x7f0dfcf55b68 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #12 0x7f0e0263f6bf in QInternalMimeData::formats() const () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #13 0x7f0d8365040b in () at /usr/lib/x86_64-linux-gnu/qt5/plugins/plasma/dataengine/plasma_engine_clipboard.so #14 0x7f0e0227a133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffeb44b5900, r=0x5565f5b8e490, this=0x7f0df8006f20) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #15 doActivate(QObject*, int, void**) (sender=0x7f0df8008750, signal_index=3, argv=0x7ffeb44b5900) at kernel/qobject.cpp:3886 #16 0x7f0e013157ee in KSystemClipboard::changed(QClipboard::Mode) () at /usr/lib/x86_64-linux-gnu/libKF5GuiAddons.so.5 #17 0x7f0e0227a133 in QtPrivate::QSlotObjectBase::call(QObject*, void**) (a=0x7ffeb44b5a10, r=0x7f0df8008750, this=0x5565f5ba3fa0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #18 doActivate(QObject*, int, void**) (sender=0x5565f3ea9ad0, signal_index=3, argv=0x7ffeb44b5a10) at kernel/qobject.cpp:3886 #19 0x7f0e02a8face in QClipboard::changed(QClipboard::Mode) () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 #20 0x7f0dfcf57c74 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #21 0x7f0dfcf59186 in QXcbConnection::processXcbEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #22 0x7f0dfcf7f573 in () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #23 0x7f0e001eff8b in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7f0e001f0238 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #25 0x7f0e001f02ef in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #26 0x7f0e0229b104 in QEventDispatcherGlib::processEvents(QFlags) (this=0x5565f3723830, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #27 0x7f0e022424db in QEventLoop::exec(QFlags) (this=this@entry=0x7ffeb44b5cd0, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #28 0x7f0e0224a7b0 in QCoreApplication::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #29 0x5565f1ffa76a in () #30 0x7f0e01bc37fd in __libc_start_main (main=0x5565f1ff9910, argc=1, argv=0x7ffeb44b5f68, init=, fini=, rtld_fini=, stack_end=0x7ffeb44b5f58) at ../csu/libc-start.c:332 #31 0x5565f1ffa88a in () I am not surprised to see the clipboard show up there, the clipboard has caused freezes in Plasma for me for at least the last 10 years across four different laptops. -- You are receiving this mail because: You are watchi
