[plasmashell] [Bug 487402] New: Plasma widgets (panel, krunner, volume...) have a significantly darker background in Breeze Light with compositing disabled
https://bugs.kde.org/show_bug.cgi?id=487402 Bug ID: 487402 Summary: Plasma widgets (panel, krunner, volume...) have a significantly darker background in Breeze Light with compositing disabled Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Theme - Breeze Assignee: plasma-b...@kde.org Reporter: eevee.kdeb...@veekun.com CC: visual-des...@kde.org Target Milestone: 1.0 Created attachment 169728 --> https://bugs.kde.org/attachment.cgi?id=169728=edit panel with compositing enabled (top) vs disabled (bottom) See attached screenshot. I can't figure out where the darker background could be coming from, and it makes the taskbar significantly harder to read at a glance. I don't see any difference between compositing on/off with Breeze Dark, though, so I'm tentatively blaming Breeze Light. Arch Linux x64, last updated yesterday. Using X11. KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481985] Feature request: bring back "Walk through desktops" shortcut
https://bugs.kde.org/show_bug.cgi?id=481985 Eevee changed: What|Removed |Added CC||eevee.kdeb...@veekun.com --- Comment #9 from Eevee --- in the same boat as evn. i did use "walk through desktops" exactly the same way as alt-tab: most frequently to cycle between two desktops, but occasionally to go further. i have such strong muscle memory for it that i keep hitting the shortcut habitually, even knowing it doesn't do anything any more. but reproducing that requires some gui — probably about what was removed from tabbox. i can't even figure out why this was removed. the merge request says the tabbox code was "effectively unused" because you had to get into "kwin internals" to make use of it, but it was a readily-accessible shortcut in system settings, so that doesn't make any sense. i STILL see it in system settings — along with at least half a dozen other bindings that no longer seem to work — which does not make its removal seem very intentional. other than the wayland session that instantly crashed, this is the main obvious change in kde 6, which is kind of a bummer. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 479195] Displays should be able to suspend if the session is manually locked, even when inhibited
https://bugs.kde.org/show_bug.cgi?id=479195 --- Comment #4 from Eevee --- Same procedure but with dbus-monitor running, and the only mentions of org.freedesktop.ScreenSaver are: # starting love method call time=1710791833.031274 sender=:1.9319 -> destination=org.freedesktop.ScreenSaver serial=6 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit string "My SDL application" string "Playing a game" method call time=1710791833.031619 sender=:1.12 -> destination=org.kde.Solid.PowerManagement.PolicyAgent serial=366224 path=/org/kde/Solid/PowerManagement/PolicyAgent; interface=org.kde.Solid.PowerManagement.PolicyAgent; member=AddInhibition uint32 4 string "My SDL application" string "Playing a game" ... # locking signal time=1710791840.483870 sender=:1.14 -> destination=(null destination) serial=39716 path=/component/ksmserver; interface=org.kde.kglobalaccel.Component; member=globalShortcutPressed string "ksmserver" string "Lock Session" int64 243112269 signal time=1710791840.484068 sender=:1.12 -> destination=(null destination) serial=366228 path=/ScreenSaver; interface=org.kde.screensaver; member=AboutToLock signal time=1710791840.484073 sender=:1.12 -> destination=(null destination) serial=366229 path=/org/freedesktop/ScreenSaver; interface=org.kde.screensaver; member=AboutToLock signal time=1710791840.573955 sender=:1.14 -> destination=(null destination) serial=39717 path=/component/ksmserver; interface=org.kde.kglobalaccel.Component; member=globalShortcutReleased string "ksmserver" string "Lock Session" int64 243112269 ... # locking finished...? signal time=1710791842.146249 sender=:1.12 -> destination=(null destination) serial=366230 path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged boolean true signal time=1710791842.146273 sender=:1.12 -> destination=(null destination) serial=366231 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged boolean true method call time=1710791842.146277 sender=:1.12 -> destination=org.kde.kglobalaccel serial=366232 path=/kglobalaccel; interface=org.kde.KGlobalAccel; member=allComponents signal time=1710791842.146536 sender=:1.24 -> destination=(null destination) serial=468463 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true signal time=1710791842.146545 sender=:1.24 -> destination=(null destination) serial=468464 path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true ... # ??? signal time=1710791870.577083 sender=:1.12 -> destination=(null destination) serial=366245 path=/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged boolean false signal time=1710791870.577304 sender=:1.12 -> destination=(null destination) serial=366246 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=ActiveChanged boolean false signal time=1710791870.578015 sender=:1.24 -> destination=(null destination) serial=468465 path=/org/freedesktop/PowerManagement/Inhibit; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true signal time=1710791870.578030 sender=:1.24 -> destination=(null destination) serial=468466 path=/org/freedesktop/PowerManagement; interface=org.freedesktop.PowerManagement.Inhibit; member=HasInhibitChanged boolean true as well as a couple calls to org.freedesktop.DBus that look like uninteresting interface inspection. Still seems like SDL is doing the right thing. Not sure what the last block of stuff is about, a conspicuous 30 seconds after my last input (pressing super+L). And the same steps without running `love` do leave my monitors asleep. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 479195] Displays should be able to suspend if the session is manually locked, even when inhibited
https://bugs.kde.org/show_bug.cgi?id=479195 Eevee changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Eevee --- That's, uh, odd. I tried the following: - run `xinput test 9` in one terminal - run `love` in another terminal (no game loaded, just an SDL window, so, about as small a test as I can get without building something) - run `sleep 10; xset dpms force suspend` in a third terminal - quickly lock the screen and sit back My screen reliably turns off, then back on. I don't see anything that looks like spurious keyboard input. Poring over source code, LÖVE simply calls SDL_DisableScreenSaver(), which is implemented here for X: https://github.com/libsdl-org/SDL/blob/12245e4c756eb964ecdf4a528c36aab6f971baf5/src/video/x11/SDL_x11events.c#L2023 If built with dbus support, which seems to be the default, then it appears to use the freedesktop interface: https://github.com/libsdl-org/SDL/blob/main/src/core/linux/SDL_dbus.c#L428 Otherwise it falls back to XScreenSaverSuspend, which looks like it's supposed to be called on a timer. VLC also has two implementations: one that shells out to `xdg-screensaver reset`: https://github.com/videolan/vlc/blob/f7bb59d9f51cc10b25ff86d34a3eff744e60c46e/modules/misc/inhibit/xdg.c#L33 And one using dbus, which at a glance is at least somewhat similar to the SDL implementation: https://github.com/videolan/vlc/blob/f7bb59d9f51cc10b25ff86d34a3eff744e60c46e/modules/misc/inhibit/dbus.c#L239 So I have no idea what's going on here. Both applications seem to do the correct thing: try DBus, and if that doesn't work, fall back to an X interface. If KDE's power management works as you describe then I'd expect both approaches to have the same results? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 479195] New: Displays should be able to suspend if the session is manually locked, even when inhibited
https://bugs.kde.org/show_bug.cgi?id=479195 Bug ID: 479195 Summary: Displays should be able to suspend if the session is manually locked, even when inhibited Classification: Plasma Product: Powerdevil Version: 5.27.8 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eevee.kdeb...@veekun.com CC: m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: --- On multiple occasions I've locked my desktop for the night, gone to bed, and awoken in the morning to find that my monitors have been awake the entire time. Even `xset dpms force suspend` doesn't actually work; my displays will suspend, but then come back on moments later. (I prefer not to turn them completely off because that has historically confused kwin and scattered all of my windows to the four winds.) This has always turned out to be due to some software (that I left running and forgot about) having a surprise feature of, as the frequent culprit SDL calls it, inhibiting the screen saver. Which is very frustrating if you aren't aware that that's a freedesktop capability, let me tell you. :) Anyway, it seems to me that if I /manually/ lock my session, there's no reason to also prevent my displays from sleeping -- whatever might be on the screen, I can't see it anyway! SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.11 Using X. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386370] kwin randomly crashes when switching desktops
https://bugs.kde.org/show_bug.cgi?id=386370 --- Comment #9 from Eevee <eevee.kdeb...@veekun.com> --- I'm pretty sure I'd notice if X were crashing. See also bug 388127, which has a workaround. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386370] kwin randomly crashes when switching desktops
https://bugs.kde.org/show_bug.cgi?id=386370 --- Comment #7 from Eevee <eevee.kdeb...@veekun.com> --- This is definitely still happening with 5.11.4 and the latest nvidia blob. Again, there is no backtrace; kwin is exiting cleanly. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 386370] kwin randomly crashes when switching desktops
https://bugs.kde.org/show_bug.cgi?id=386370 Eevee <eevee.kdeb...@veekun.com> changed: What|Removed |Added CC||eevee.kdeb...@veekun.com --- Comment #6 from Eevee <eevee.kdeb...@veekun.com> --- I'm having the same problem — quite frequently! — and I don't think kwin is crashing at all. It seems to be cleanly exiting, hence the lack of a backtrace or error dialog or automatic restarting. At the moment I'm running it in a shell loop, which is... not ideal. I'm also on Arch with the nvidia blob, using 5.11.3, and had no problems before upgrading from 5.10.5. The Arch forum thread suggests it's fixed in 5.11.4, but doesn't clarify further. I don't see any recent commits that /sound/ relevant, but I only know so much about WM internals. :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 378942] Add a brush size docker
https://bugs.kde.org/show_bug.cgi?id=378942 --- Comment #10 from Eevee <eevee.kdeb...@veekun.com> --- Neat, thank you! Eager to try it out. This is probably a good reference for doing slightly unobvious things with the Python API, too. :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 378942] Add a brush size docker
https://bugs.kde.org/show_bug.cgi?id=378942 --- Comment #7 from Eevee <eevee.kdeb...@veekun.com> --- Thank you :) Though for what it's worth, I've never used SAI or any other painter with a brush size palette, and I still want it. (I did a quick Twitter poll a few days ago, and it seems a decent number of people feel fairly strongly about it: https://twitter.com/eevee/status/854996101056708610) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 378942] Add a brush size docker
https://bugs.kde.org/show_bug.cgi?id=378942 --- Comment #4 from Eevee <eevee.kdeb...@veekun.com> --- I think you're misunderstanding. It's not a set of presets; it changes only the brush size, for ANY brush. The icons are round just to show a rough idea of the size, not because they make the brush tip round. So the equivalent would be to make a bunch of duplicate presets in various sizes, for /every single brush you have/. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 378942] Add a brush size docker
https://bugs.kde.org/show_bug.cgi?id=378942 --- Comment #2 from Eevee <eevee.kdeb...@veekun.com> --- Yes, the grid of round brush icons. I don't have SAI myself so I can't take a clearer screenshot, sorry. Using presets is technically possible but also defeats the whole point, which is that a brush size palette is quick and easy to use. Replicating the effect with presets would involve making dozens of duplicates, cluttering the brush list, editing all their icons so they can be distinguished at a glance, etc. Kind of a hard sell. I know artists who are /instantly/ disappointed in Krita solely for lacking this feature, and it seems like a fairly minor addition. If there can be six different dockers for picking colors, surely there's room for this. :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 378942] New: Add a brush size docker
https://bugs.kde.org/show_bug.cgi?id=378942 Bug ID: 378942 Summary: Add a brush size docker Product: krita Version: 3.1.2 Platform: Archlinux Packages OS: All Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: eevee.kdeb...@veekun.com Target Milestone: --- It would just be a grid of predefined brush sizes. You can see it fairly conspicuously in the lower-right of the Paint Tool SAI screenshot on this page: https://www.systemax.jp/en/sai/ Clip Studio Paint and Manga Studio have a similar feature. It would be very handy for changing between several consistent brush sizes with a tablet; the toolbar slider and shift-drag are both a bit fiddly and imprecise. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 375878] Eraser will not switch back to brush after turning Wacom pen back around
https://bugs.kde.org/show_bug.cgi?id=375878 Eevee <eevee.kdeb...@veekun.com> changed: What|Removed |Added CC||eevee.kdeb...@veekun.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364850] (Qt 5.7) If any docker is in focus e.g. layer docker , canvas zoom function with mouse scrollwheel is gone. The contents of the dockers is scrolled instead of canvas zoom
https://bugs.kde.org/show_bug.cgi?id=364850 --- Comment #15 from Eevee <eevee.kdeb...@veekun.com> --- This also happens with the scrollable list in the "recover documents" dialog: if I scroll it with the mouse wheel, the mouse wheel no longer works anywhere else, even after closing the dialog. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 365336] New: Instant Preview moves wrong layer with "move layer with content"
https://bugs.kde.org/show_bug.cgi?id=365336 Bug ID: 365336 Summary: Instant Preview moves wrong layer with "move layer with content" Product: krita Version: 3.0 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Instant Preview Assignee: krita-bugs-n...@kde.org Reporter: eevee.kdeb...@veekun.com Using the move tool in "move layer with content" mode with Instant Preview on will sometimes appear to move the currently-selected layer, rather than the layer being clicked on. The real image will change correctly, so the preview and real image will get severely out of sync. Switching layers manually fixes the preview. This doesn't always happen, and I'm not sure what exactly triggers it, but it reproduces fairly easily. Create a large image and make several layers with a large brush stroke on each, then try to move them around. Clicking on nearly-transparent areas seems more likely to choose the wrong layer. Reproducible: Sometimes -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364850] If a layer in layer docker is clicked and the docker has a scrollbar , canvas zoom with scrollwheel is gone
https://bugs.kde.org/show_bug.cgi?id=364850 --- Comment #4 from Eevee <eevee.kdeb...@veekun.com> --- Aha, actually, I don't think the problem is clicking. If you use the mouse wheel to scroll the layers docker (or the brush presets docker, or probably others), any further use of the mouse wheel /anywhere/ will go to that same docker. No clicking is necessary. This probably isn't as noticeable on Windows because (iirc) Windows interprets the mouse wheel as scrolling whatever has focus, whereas Linux scrolls whatever's under the cursor. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 364850] If a layer in layer docker is clicked and the docker has a scrollbar , canvas zoom with scrollwheel is gone
https://bugs.kde.org/show_bug.cgi?id=364850 Eevee <eevee.kdeb...@veekun.com> changed: What|Removed |Added CC||eevee.kdeb...@veekun.com --- Comment #3 from Eevee <eevee.kdeb...@veekun.com> --- The mouse wheel no longer works for scrolling any other docker, either. Even if the layers docker isn't visible. Even if you close the image with many layers and switch to an image with only one layer! I can't find any way to fix this once it's happened, either, other than closing and reopening Krita. Also on Linux. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 343661] stops drawing window content after some time, likely SyncObject related
https://bugs.kde.org/show_bug.cgi?id=343661 Eevee <eevee.kdeb...@veekun.com> changed: What|Removed |Added CC||eevee.kdeb...@veekun.com --- Comment #63 from Eevee <eevee.kdeb...@veekun.com> --- This has been driving me up the wall since I "upgraded" to Plasma 5 over a year ago. Never happened on KDE 4. I've seen it affect at least Chromium, VLC, Krita, GZDoom, pico-8, and /very rarely/ Firefox or LilyTerm. (Firefox is my primary browser; Chromium I basically just use for YouTube.) It only seems to affect windows using OpenGL — once when it was particularly bad, I turned off OpenGL in Krita for a while, and Krita became immune. It's definitely per-window. Moving a busted window will cause it to repaint during the move (because it's translucent, I imagine), then refreeze. The taskbar's live thumbnails show the correct window contents, but the window itself does not. It seems to happen more often when my machine's been on for a while, and/or when more apps are trying to use OpenGL, and/or when there are a lot of repaints happening. Sometimes I go hours or (if I'm lucky) days without seeing it; sometimes it happens every few /minutes/. It seems to happen more often after a "trigger" like alt-tabbing or closing a Chromium tab, but it also happens spontaneously in the middle of using a single app. I don't know if it's related, but after enough rounds of toggling the compositor off and back on, the un-composited panel ALSO freezes, and nothing short of restarting kwin will fix it. It turns a very dark gray when frozen, versus Breeze's usual medium-light gray. Ha. Firefox just "froze", right now, while typing this. No video playing, nothing onscreen but a browser window with a textbox and an idle terminal. I have Chromium, pico-8, and Krita running, but they're all idle and minimized. Arch, nvidia blob driver, two monitors. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 360640] New: Ark's new extract-to dialog silently ignores a directory path entered in the name field
https://bugs.kde.org/show_bug.cgi?id=360640 Bug ID: 360640 Summary: Ark's new extract-to dialog silently ignores a directory path entered in the name field Product: ark Version: 15.12.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: elvis.angelac...@kdemail.net Reporter: eevee.kdeb...@veekun.com CC: rak...@freebsd.org, rthoms...@gmail.com The new extract-to dialog has several parts in the middle column, including: the location of the current directory, the contents of that directory, and a filename to extract to. The default directory is my desktop. I type a directory path in the filename field, and it even helps me do so, with tab completion and a list of suggestions. Nice. Then I press Enter, and the files are immediately extracted to... my desktop. This is the exact opposite behavior of every other file browse dialog on the planet, which would usually notice that I typed a directory path and browse to that directory. Instead, Ark seems to think my Enter keypress was to activate the Extract button, and ignores the path I typed entirely. I can type the path in the location field at the top, press Enter, and all works fine. But I sure do have some strong muscle memory for this. :) I'm fairly certain this started after I upgraded to Plasma 5 (and with it, the Ark 15.x series). Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 337135] Assigning ctrl (Color Picker) to pen sideswitch not working
https://bugs.kde.org/show_bug.cgi?id=337135 --- Comment #10 from Eevee <eevee.kdeb...@veekun.com> --- Oh, I've also tried binding a single key (like `) to colorpick rather than needing to click at all, and that just doesn't work at all, even from the keyboard. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 337135] Assigning ctrl (Color Picker) to pen sideswitch not working
https://bugs.kde.org/show_bug.cgi?id=337135 Eevee <eevee.kdeb...@veekun.com> changed: What|Removed |Added CC||eevee.kdeb...@veekun.com --- Comment #9 from Eevee <eevee.kdeb...@veekun.com> --- I have the same problem on Arch Linux, I believe since 2.9.7. I have a pen side button bound (via xsetwacom) to "key +ctrl button 1 key -ctrl", and pressing it makes the brush cursor slightly smaller but does nothing else. The workaround I've been using is to bind it only to "key +ctrl", then hold it and tap to pick a color. Perhaps a related problem that started at the same time: I have another button bound to ctrl-z (as "key +ctrl z -ctrl"). Sometimes I'll press that button and immediately try to draw a new stroke, but Krita will colorpick instead, as if there's a slight delay before it realizes the ctrl key has been released. -- You are receiving this mail because: You are watching all bug changes.
