[kwin] [Bug 486508] On Wayland, some windows goes off the screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 --- Comment #9 from Anya --- KWin 6.0.5 landed in Arch repos and I made a new user to test again, and I can still reproduce the bug. Initially, before changing any settings, it was really tough to reproduce though. I think it's easier after it's happened once. That or after changing the display scaling factor from the default 175% it picked for my system, to the 200% that I prefer. I don't know for sure though. On my existing user the bug is essentially the same as on 6.0.4. In case that helps. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 --- Comment #6 from Anya --- (In reply to Nate Graham from comment #5) > I can confirm the issue, but I'm afraid a certain amount of blurriness is > unavoidable with KDE's current icon rendering technology at low fractional > scale factors and screens with a low to medium pixel density — especially > when using monochrome line-art icons with 1px line widths, as KDE icons are. > > To learn more about the reason why, read > https://community.kde.org/Get_Involved/Design/ > Frequently_Discussed_Topics#Pixel-alignment_for_SVG_icons > > In an ideal world we'd be able to use sub-pixel rendering to avoid > blurriness for thin monochrome icons the way we can for fonts, but this is a > level of technology we unfortunately don't have in KDE, or anywhere else > outside of the font-based icons in macOS and Windows, for that matter. Aw, that's a shame. Thank you for the info though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 --- Comment #4 from Anya --- Created attachment 169660 --> https://bugs.kde.org/attachment.cgi?id=169660=edit Dolphin icons comparison -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 --- Comment #3 from Anya --- Created attachment 169659 --> https://bugs.kde.org/attachment.cgi?id=169659=edit Desktop and dolphin 100% -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 --- Comment #2 from Anya --- Created attachment 169658 --> https://bugs.kde.org/attachment.cgi?id=169658=edit Desktop and dolphin 120% -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 --- Comment #1 from Anya --- Created attachment 169656 --> https://bugs.kde.org/attachment.cgi?id=169656=edit Start menu icon, task manager icons, comparison -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487278] New: Blurry icons in various places using fractional scaling
https://bugs.kde.org/show_bug.cgi?id=487278 Bug ID: 487278 Summary: Blurry icons in various places using fractional scaling Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: anya.vanillagar...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Created attachment 169655 --> https://bugs.kde.org/attachment.cgi?id=169655=edit System tray icons, comparison When scaling factor is set to 120%, desktop icon labels, systray icons, taskbar icons and some dolphin icons become blurry. The clock seems unaffected. There may be blurry icons in other places as well. I made screenshots for comparison between 100% and 120%, but at a quick glance the problems persist with other fractional scaling factors. Icons flicker a little when hovering mouse cursor over them, but this happens at 100% as well. I logged out and back in after changing the scaling factor every time. Tested mainly on a (single) 2560x1440 monitor, Nvidia 550.78. Panel is default but Floating is disabled, System Tray option "Panel icon size" is set to "Scale with Panel height", and I changed the panel height for every screenshot to demonstrate how icons look at different sizes. I confirmed 120% looks blurry on a different machine as well (different resolution and GPU). I hope the screenshots make sense otherwise. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.9.1-arch1-1 (64-bit) Graphics Platform: Wayland Graphics Processor: NVIDIA GeForce RTX 4070 Ti/PCIe/SSE2 I see other bug reports related to taskbar blurriness but they seem to be a different problem, as in my case hovering the mouse doesn't change sharpness, and the problem persists when Floating is disabled. Apologies if an identical bug report already exists though. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486508] Firefox window goes off screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 --- Comment #6 from Anya --- (In reply to Nate Graham from comment #5) > That's so weird, I can't reproduce the issue with any of those apps. Does it > happen with Dolphin or Okular? > > P.S. congratulations on choosing a laptop with a perfect screen resolution! Assuming that's not sarcasm, thanks :) I can't reproduce it with Dolphin or Okular. Couple other things I tried that didn't eliminate the behavior since I don't have a life anyway: - Made a new user, deleted all the hidden folders and files in its home folder, and started a Wayland session - Disabled "Maximize" animation effect - Set scaling factor to 100% and setting it to something else between 100 and 200 - Changed refresh rate from 120hz to 60hz - Changed edge tiling percentage They might be harder to reproduce (not sure about that) but it's definitely non-zero times. Can't reproduce it in an X session. Can't reproduce with Chromium unless it's running in Wayland mode (using the ozone command line arguments). Not sure if it's possible that EndeavourOS applies different KDE settings to fresh users even after wiping the hidden home folder files before logging in? It does apply a different color scheme and wallpaper, as well as a welcome-application that autostarts until you disable it. Would have to try a clean Arch installation or something like that. Something tangentially related, I *am* able to move Dolphin (and other application) below the taskbar where it becomes inaccessible by mouse cursor, but then it can still be maximized and tiled, either through the taskbar right click menu or with keyboard shortcuts. Could be intended behavior though. I took a look at recompiling kwin with the patch applied but it seems impossibly difficult to me. I think that's it for now, hope I didn't forget anything. It's a bit of an annoyance when I want to tile firefox to the right so I can do other stuff on the left side of the screen, but it's obviously not critical. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486508] Firefox window goes off screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 --- Comment #4 from Anya --- (In reply to Anya from comment #3) > Created attachment 169164 [details] > System title bar enabled, more strange behavior > > I noticed that, after I move the window back onto the screen, when I attempt > to resize it (click and hold the window edge, without moving) the window > size instantly completely changes to a weird shape. The window shape before > that (after pulling it back in) seems to correspond to the last tiled shape > but not sure. Sorry, actually click and hold the window edge and move it a tiny bit. The shape doesn't chage if I just click and hold without moving. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486508] Firefox window goes off screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 --- Comment #3 from Anya --- Created attachment 169164 --> https://bugs.kde.org/attachment.cgi?id=169164=edit System title bar enabled, more strange behavior I noticed that, after I move the window back onto the screen, when I attempt to resize it (click and hold the window edge, without moving) the window size instantly completely changes to a weird shape. The window shape before that (after pulling it back in) seems to correspond to the last tiled shape but not sure. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486508] Firefox window goes off screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 --- Comment #2 from Anya --- (In reply to Nate Graham from comment #1) > I wonder if > https://invent.kde.org/plasma/kwin/-/commit/ > 33fe2114710085235d656c04c7d63be3828aefc9 could help. > > Do you have multiple screens, or did you at some point recently before > making this screen recording? > > Does the issue still happen if you enable the system titlebar in Firefox and > then restart it and try to reproduce the issue again? Hi! I'm very not used to applying patches to source code and compiling it, I might try it but it could take a while. There is only the one screen (it's a laptop), never plugged in an external one on this OS. I enabled the system title bars and I can still reproduce the behavior. For clarity, I right-clicked into the empty tab area at the top, clicked "Customize Toolbar...", and then ticked/enabled the "Title Bar" option in the bottom left. Might be worth mentioning I use a 2x scaling factor because my screen is 3200x2000. I also just tried the same thing with three other applications (Chromium, Thunderbird and an Electron app) and can reproduce the behavior with all of them. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 482142] drag in drop files in Google Chrome renders Chrome unusable
https://bugs.kde.org/show_bug.cgi?id=482142 Anya changed: What|Removed |Added CC||anya.vanillagar...@gmail.co ||m --- Comment #21 from Anya --- Can reproduce this with Chromium and Discord when they're running with --enable-features=UseOzonePlatform --ozone-platform=wayland. When attempting to drag and drop a file from Dolphin to Discord or Chromium the mouse cursor changes to the red stop sign thing and the file isn't dropped. It works without the arguments, running in Xwayland. Operating System: EndeavourOS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-1 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 486508] New: Firefox window goes off screen when attempting to tile a certain way
https://bugs.kde.org/show_bug.cgi?id=486508 Bug ID: 486508 Summary: Firefox window goes off screen when attempting to tile a certain way Classification: Plasma Product: kwin Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: anya.vanillagar...@gmail.com Target Milestone: --- Created attachment 169139 --> https://bugs.kde.org/attachment.cgi?id=169139=edit Screen recording of the bug SUMMARY Under certain circumstances, the Firefox window will go off screen and can't be interacted with anymore using the mouse (since you can't move the cursor off screen), tiling shortcuts or maximizing. The "Move" option from the window menu has to be used. This doesn't happen always, but I can consistently reproduce it when I log out and log back in. After attempting to tile Firefox once or twice the behavior goes back to normal/expected. Sometimes it's once, sometimes it continues to happen multiple times in the same session until it eventually goes back to normal. Might not be Wayland-specific. STEPS TO REPRODUCE 1. Open Firefox, maximize it and close it so that it opens as maximized the next time 2. Log out and log back in 4. Start Firefox and attempt to click and drag from the title bar to the right edge of the screen OBSERVED RESULT Window positions itself off screen (to the right I think?) and becomes inaccessible, except when using the "Move" option in the window menu. EXPECTED RESULT Window tiles to the right edge of the screen. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-1 (64-bit) Graphics Platform: Wayland Graphics Processor: Mesa Intel® Graphics ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486245] New: Discord taskbar indicator missing despite libunity being installed
https://bugs.kde.org/show_bug.cgi?id=486245 Bug ID: 486245 Summary: Discord taskbar indicator missing despite libunity being installed Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: unspecified OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: anya.vanillagar...@gmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 SUMMARY Previously there would be a circled number on Discords taskbar button indicating how many new messages or pings there are, if there are any. This is similar to Windows. It seems like with updating to KDE/Plasma 6 this functionality broke. I posted the bug on Discord's bug megathread on Reddit but I don't have high hopes for them to fix it. STEPS TO REPRODUCE 1. Install KDE/Plasma 6 or higher, install Discord 2. Receive a new message or friend request OBSERVED RESULT The taskbar button does not change in appearance at all. EXPECTED RESULT There should be a little circle with a number in it on the taskbar button. SOFTWARE/OS VERSIONS Linux: 6.8.7-arch1-2 (64-bit) (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Wayland session (but I heard this happens on X11 too) Sorry if this might have been posted already somewhere else, but I searched this site and couldn't find any mention of it yet. For clarity, I'm talking about the panels "Task Manager", not the systray. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375420] Auto-hide inactive cursor
https://bugs.kde.org/show_bug.cgi?id=375420 Anya Smith changed: What|Removed |Added CC||anantann...@gmail.com --- Comment #5 from Anya Smith --- Unfortunate that this won't be implemented for Wayland. Other Wayland compositors, such as Sway, have implemented it long ago. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 425152] New: No new brush strokes appear on Paint Layer when a Wet Brush is selected and Alpha Lock is turned on
https://bugs.kde.org/show_bug.cgi?id=425152 Bug ID: 425152 Summary: No new brush strokes appear on Paint Layer when a Wet Brush is selected and Alpha Lock is turned on Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: artistach...@gmail.com Target Milestone: --- Version 4.3.1-alpha (git aa84881) SUMMARY When trying to use wet brushes on a Paint Layer with alpha-lock toggled on, no new strokes appear on top of pre-existing strokes, even if brush is set at 100% opacity. The Undo History shows that a "freehand brush stroke" occurred, but no change is seen on the paint layer. This problem only occurs when Alpha Locked is turned ON. When it is OFF, the Wet Brushes work normally. Other brushes do NOT have this problem from what I can see, only wet brushes (Wet bristles, Wet circle, Wet knife, Wet paint, etc.) STEPS TO REPRODUCE 1. Add a new Paint Layer with Alpha Lock property turned off (Alpha Locked: No). 2. Select one of the wet brushes like "Wet Paint" at 100% opacity, select a first color, then make strokes on the canvas. 3. On the same Paint Layer, turn the Alpha Lock property on (Alpha Locked: Yes) 4. Using the same wet brush and a different color, add new brush strokes on top of existing brush strokes made from Step 2 on the canvas. OBSERVED RESULT Brush strokes made when Alpha Lock is turned ON in the second color from Step 4 do NOT appear on top of strokes that were made with the first color from Step 2 using the same Wet Brush. When the Alpha Lock is turned OFF and you try to draw on the same layer, strokes that you make after turning off the lock can be seen. EXPECTED RESULT New brush strokes using Wet Brushes in the selected second color should appear on top of the brush strokes made with the first color regardless of whether Alpha Lock is toggled on OR off. SOFTWARE/OS VERSIONS Windows: Version 4.3.1-alpha (git aa84881) Qt Version: 5.12.9 Surface Pro 3, Windows 10 -- You are receiving this mail because: You are watching all bug changes.
