[frameworks-qqc2-desktop-style] [Bug 491185] Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item
https://bugs.kde.org/show_bug.cgi?id=491185 --- Comment #5 from Eamonn Rea --- Thank you for this, and for the KDE folks as acknowledging this as an issue at least worth looking into at some point! I was quite afraid this would get shot down and interpreted as being *far* too nitpicky and would simply be disregarded or worse have repercussions of some kind (the Bugzilla equivalent of a suspension, if such a thing exists). I understand this is a deeper issue and I'll keep an eye on Bug 487563. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491185] Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item
https://bugs.kde.org/show_bug.cgi?id=491185 --- Comment #3 from Eamonn Rea --- Created attachment 172226 --> https://bugs.kde.org/attachment.cgi?id=172226=edit Digital Clock Settings - 6 Pixels Edited screenshot to use 6 pixels of padding instead of 2. This is an increase in 4 pixels from the existing padding. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491185] Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item
https://bugs.kde.org/show_bug.cgi?id=491185 --- Comment #2 from Eamonn Rea --- Created attachment 172225 --> https://bugs.kde.org/attachment.cgi?id=172225=edit Digital Clock Settings - 5 Pixels Edited screenshot to use 5 pixels of padding instead of 2. This is an increase in 3 pixels from the existing padding. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491185] Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item
https://bugs.kde.org/show_bug.cgi?id=491185 --- Comment #1 from Eamonn Rea --- Created attachment 172224 --> https://bugs.kde.org/attachment.cgi?id=172224=edit Digital Clock Settings - 4 Pixels Edited screenshot to use 4 pixels of padding instead of 2. This is an increase in 2 pixels from the existing padding. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491185] New: Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item
https://bugs.kde.org/show_bug.cgi?id=491185 Bug ID: 491185 Summary: Not Enough Top-Padding of Settings Menu's Top-Most Sidebar Item Classification: Plasma Product: plasmashell Version: 6.1.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Created attachment 172223 --> https://bugs.kde.org/attachment.cgi?id=172223=edit Digital Clock Settings - Existing Padding (2 Pixels) SUMMARY The padding at the top of Settings Menus which use the rounded "floating" highlight (such as the Digital Clock Settings page) does not have enough padding, so the selection and icon on the item itself look too close to the titlebar. This does not apply to Settings pages which use the "filled" styling such as Gwenview's Settings page. On the "floating" highlight panels, there is a padding of 4 pixels on the left and the right of the highlighted / hovered item in the sidebar. Between each element, the spacing between the selected item in the sidebar and the hover selection is 6 pixels (this gives good visual separation so that's fine imo). However at the top of the menu, there is only 2 pixels of a gap. To me, this stands out a lot and looks as though something is "cut off". It results in slightly poor visual polish because the spacing at the top is too little so it's too close to the titlebar. Even when not highlighted or hovered, the icon looks too close to the titlebar itself. The amount that the padding spacing should be adjusted by is subjective I think, but in my own messings-around, I think adjusting it so that there are 4-5 pixels of padding from the top of the titlebar to the selection highlight is the sweet spot. - 3 pixels seems like too little - 6 pixels seems like way too much, then the problem becomes that there is noticeably *too much* spacing! - 4 pixels makes this even with the padding on the left and right, which makes me favour it, but it doesn't look like enough still. However it could be chosen because it is symmetrical with the sides. - 5 pixels, although fully inconsistent with everything else, just "looks right" to my tastes. I have attached a screenshot of how the Digital Clock Settings page looks right now, and I will attach follow-up screenshots of the padding size increased to be 4 pixels (consistent with the left/right padding), 5 pixels (totally inconsistent, but the one that looks best to my tastes), and 6 pixels (consistent with the padding between the spacing of selected/hovered items, but inconsistent with the left/right padding). The value chosen at the end of the day is going to be heavily subjective, but I think the fact that the current padding is noticeably thin is a bit less-subjective. STEPS TO REPRODUCE 1. Open a settings menu with a sidebar equivalent to that of the Digital Clock Settings page. 2. The top-most sidebar item does not have enough padding so it appears too close to the titlebar. OBSERVED RESULT Settings menu with a sidebar equivalent to that of the Digital Clock Settings page has noticeably reduced top-most padding so it is too close to the titlebar. The padding is only 2 pixels and increasing it would improve visual polish. EXPECTED RESULT There should be more of a gap between the top-most item in the sidebar and the titlebar. Approximately 2-3 pixels of an increase, bringing the padding up to 4-5 pixels from the titlebar to the highlighted selection, is what my untrained eye personally prefers. It is subjective what improvement is best, but I feel it can be agreed that, if nothing else, the current 2-pixel padding is noticeable without pixel-peeping. Maybe there is disagreement that it doesn't look good, maybe this is fully intended, it just seems visually-off to me. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX ADDITIONAL INFORMATION * This doesn't affect all Settings pages, only the ones as described. It is also not exclusive to the one described, this is just the one I was in most recently. It affects all pages I have seen with this style of sidebar. * I don't want this to come off as a troll report or looking for problems, this catches my eye each time I see a settings page like this. While obviously there are *far* more pressing items to deal with and this would be at the bottom of even the "wishlist" issues, Plasma 6 has made major strides in improving visual polish and consistency. I feel like this could be another step in the right direction - improving the UI
[gwenview] [Bug 491184] New: Gwenview very slow to load on first launch
https://bugs.kde.org/show_bug.cgi?id=491184 Bug ID: 491184 Summary: Gwenview very slow to load on first launch Classification: Applications Product: gwenview Version: 24.05.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY When launching Gwenview for the first time in a session, it takes a very long time to load images, particularly if the drive is not the boot drive. This happens regardless of which drive or folder I open, but after the first launch of Gwenview things are significantly faster. There is still a 5-ish second loading process. The loading process causes Gwenview to be very unresponsive, so there is a lot of delay when zooming into images initiating actions such as a crop, etc. I was in the process of making another report and was using Gwenview to open some screenshots for comparison, and it took several minutes before everything fully loaded and I could get into using Gwenview. Once the number at the bottom of the screen actually represented the number of images in that folder and so had fully loaded it, things were smooth. This happens across SATA SSDs and m.2 NVMe SSDs, and also happened when I had an internal HDD which is no longer connected. After this period, while it still takes Gwenview some 5-ish seconds, it's much faster than several minutes on the first boot. I have been able to reproduce similar behaviour on a separate device, although it is much faster (less than a minute) it still takes time for Gwenview to "warm up" on a first boot. Perhaps Gwenview is trying to parse all images across drives or something? Since this happens regardless of which folder I open. There are a significant amount of images and videos across my devices, almost 70,000 on one drive on my PC. These are primarily large, uncompressed Steam Screenshots (thousands of these are 15-17mb). Maybe the volume and size of the files is causing Gwenview to take a long time to "load"? Ideally, Gwenview would be as close to instantaneous when opening an image as possible, assuming adequate hardware and drive speed. STEPS TO REPRODUCE 1. Perhaps a prerequisite is to have a significant amount of high resolution, large image files. 2. Open Gwenview for the first time on a boot. 3. It is significantly slower than you'd expect, taking at minimum about 30-45 seconds but upwards of several minutes before it can become usable. 4. Close Gwenview and re-open the image 5. It loads up much faster (the number at the bottom-middle of the display parses all images in the folder much more quickly. OBSERVED RESULT Gwenview is quite slow on a first load, but is faster on subsequent loads (although it could still be faster). Until it has fully loaded, it is too slow to interact with. As an example if you take a screenshot and want to crop it, it can take a very long time if you haven't opened Gwenview in that session. Even if you have, it is still slower than what it ideally should be. EXPECTED RESULT Gwenview should not necessarily load images faster, but become responsive faster, to increase workflow speed. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX ADDITIONAL INFORMATION * This isn't new behaviour, it has been this way for many years, I just never got around to reporting it before :-) * I had a look around in the settings and didn't fine anything. Looking online it seems like people have complained about this before, but every issue I saw explicitly mentioned high CPU usage while loading. My CPU usage does not increase significantly overtime when waiting on Gwenview (there is a spike up to around 50% when opening but it dies down quickly). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490992] Images on Clipboard in the "Clipboard Items" Popup Are Too Small To Be Meaningful
https://bugs.kde.org/show_bug.cgi?id=490992 --- Comment #3 from Eamonn Rea --- Woohoo! That was quite a coincidence! I would've preferred to keep the old UI in-tact but I don't know how it would be solved in that case, and if it shares the layout files from the panel that only makes sense. Any improvements to the panel UI would carry over now too, helps with consistency! -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 486039] [wayland] Some Applications Render Fonts with Artifacting at Certain Window/Element Widths at Fractional Scale Factors
https://bugs.kde.org/show_bug.cgi?id=486039 --- Comment #6 from Eamonn Rea --- Thanks for resolving! I will keep an eye on the linked issue. To my understanding, the workaround of `QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor` disables fractional scaling which might not be viable for my setup. I may still try it if the situation worsens, but good to know the cause is at least being looked into and that this is known! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490991] On Scaled Displays, Clipboard Contents text is misaligned, gets blurry and jumps around when moused over
https://bugs.kde.org/show_bug.cgi?id=490991 --- Comment #5 from Eamonn Rea --- Created attachment 172131 --> https://bugs.kde.org/attachment.cgi?id=172131=edit Blurry Hovered Clipboard Text -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490991] On Scaled Displays, Clipboard Contents text is misaligned, gets blurry and jumps around when moused over
https://bugs.kde.org/show_bug.cgi?id=490991 --- Comment #4 from Eamonn Rea --- I think this is the same bug as Bug 478165 overall, with the font-y weirdness being Bug 479891 as mentioned. I can still provide a screenshot just in case, and this can be re-opened if it is indeed a separate bug. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 490990] Add an "All My Bugs" Saved Search to Display All Reported Bugs Regardless of Status
https://bugs.kde.org/show_bug.cgi?id=490990 --- Comment #4 from Eamonn Rea --- This is awesome, thank you so much! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490992] New: Images on Clipboard in the "Clipboard Items" Popup Are Too Small To Be Meaningful
https://bugs.kde.org/show_bug.cgi?id=490992 Bug ID: 490992 Summary: Images on Clipboard in the "Clipboard Items" Popup Are Too Small To Be Meaningful Classification: Plasma Product: plasmashell Version: 6.1.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: 1.0 SUMMARY The "Clipboard Items" popup (which appears when pressing i.e. Meta+V) can display images from the clipboard history. This is a good feature! However the images are very tiny, far too tiny to really know what they are, and so they aren't very meaningful. The Clipboard Contents tray menu doesn't have this issue as it has the luxury of more space, so it can display the images at a larger size. The images in the popup are also misaligned from text on the list. While text has a nice indentation, images don't have this, so they appear misaligned compared to text on the clipboard (or vice versa, if you have more screenshots on your clipboard history than text!). I understand why the images are as small as they are, this is a list in a pop-up where space is at a premium, so the images are displayed at the same size as the text (which is truncated if it is long, probably for the same space-is-at-a-premium reason). And if the images were displayed at full size it wouldn't look nearly as sleek as having the even popup list we have now. But the overall issue still remains that images in the popup are really tiny and don't convey anything meaningful just by looking at them in the list. I don't really know what the solution is, so I put off reporting this since reporting issues like this without a vision on how to fix them can come across as lazy. I believe this clipboard popup feature is only present in KDE Plasma as I have yet to see this anywhere else (the concept of clipboard history like this in general is pretty much exclusive to the Linux Desktop). So I don't think there's the possibility to reference what other projects are doing. Short of re-designing the popup UI entirely, maybe there could be a way to enlarge the image on mouseover? It could animatedly scale up, or an additional "tooltip" could appear and also list its resolution. But I have no idea if this is possible to implement without a massively significant refactor. I'm sure this issue has been noticed and the reason it is the way it is is because there is no easy fix. I didn't find another issue mentioning this so I wanted to bring it up in case there is any discussion to be had around this. STEPS TO REPRODUCE 1. Copy an image to the clipboard. 2. Open the Clipboard Popup (I believe the default binding is Meta+V). 3. The image on the clipboard is too tiny to convey anything meaningful. OBSERVED RESULT Images on the Clipboard Items popup are too small to know what they represent. EXPECTED RESULT There should be a way to more easily see what the image on the Clipboard Items popup represent. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.10.2 Linux Zen KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490991] New: On Scaled Displays, Clipboard Contents text is misaligned, gets blurry and jumps around when moused over
https://bugs.kde.org/show_bug.cgi?id=490991 Bug ID: 490991 Summary: On Scaled Displays, Clipboard Contents text is misaligned, gets blurry and jumps around when moused over Classification: Plasma Product: plasmashell Version: 6.1.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: 1.0 SUMMARY Some text in the Clipboard Contents widget is misaligned. Letters have inconsistent spacing and some letters appear higher or lower. Also, when mousing over the items in the list, the text becomes blurry, and the text jumps around. This jumping around actually makes the misaligned letters and text become aligned. The text also exhibits the same artifacting problem described in Bug 486039. STEPS TO REPRODUCE 1. Open the Clipboard Contents tray widget. 2. The items in the dropdown have misaligned items and inconsistent spacing. 3. Hovering over the items causes them to become blurry. OBSERVED RESULT Text in the Clipboard Contents widget has issues with inconsistent spacing, letters at inconsistent heights, and the text becomes blurry when moused over. EXPECTED RESULT Text in the Clipboard Contents widget should display no visual oddities. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.10.2 Linux Zen KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION - None of these issues are present on the "Clipboard Items" Klipper menu that can be accessed by default with Meta+V. - Maybe these are symptoms of fractional-scale-v1 that, like several other fractional scaling oddities, will be resolved with fractional-scale-v2? -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 490990] New: Add an "All My Bugs" Saved Search to Display All Reported Bugs Regardless of Status
https://bugs.kde.org/show_bug.cgi?id=490990 Bug ID: 490990 Summary: Add an "All My Bugs" Saved Search to Display All Reported Bugs Regardless of Status Classification: Websites Product: bugs.kde.org Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: templates Assignee: sysad...@kde.org Reporter: eamonn...@protonmail.com CC: she...@kde.org Target Milestone: --- SUMMARY At present, the default links to view reported bugs only display a small subset of a user's reported bugs. This reduces visibility into a user's reported bugs, which can be somewhat frustrating for users that want to keep tabs on what versions their reported bugs are fixed in, or update existing bug reports. There should be an "All My Bugs" Saved Search that a user can access from the homepage to display a list of all the bugs they have reported regardless of status. If possible, this should be sorted by "Changed" time, so that bugs which require the user's attention can be seen towards the top of the list. By default, a user can view their bug reports from the "Open Bugs Reported By Me" link on the homepage, or from the "My Bugs" link. However this only lists bugs in some statuses, like "Reported", "Confirmed", "Assigned" (and possibly some others). When a bug is marked as any other status such as "Resolved" (upstream/downstream), the bug disappears from the list, and a user has no visibility into the status of their bug. There are emails, and a bug may often be in a user's history, but it is difficult to access a full list and see the status of the bugs. But more problematic is that if a bug is marked as a status that needs the user to respond (ideally promptly) like "NEEDSINFO", the bug still disappears from the user's "My Bugs" list and it can be easy to lose track of it. If you report a lot of bugs it can be difficult to keep track of them and some can slip through when they disappear. Whether this new feature should be a link, or a bigger more prominent button, or something else entirely, is not something I am sure of. But something to make it easier for users to view all of their reported bugs ever regardless of status would be very useful imo :-) STEPS TO REPRODUCE 1. Go to https://bugs.kde.org/ 2. There is no easy way to view all reported bugs, just a subset. OBSERVED RESULT There is no easy way to view all reported bugs, just a subset. A user has to manually create this as a Saved Search, and a user may not know how to do that if they are new to Bugzilla (or even the theming flavour used here). EXPECTED RESULT There should be a default way to view all reported bugs regardless of their status. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.10.2 Linux Zen KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION I'd like to clarify that I'm not advocating to remove or update any *existing* links. For sure, the current links to only view the bugs in a handful of statuses are useful for a more "focused" view, but I feel like a wider overview by default would be helpful for visibility without creating a snowball problem of creating lots of saved searches by defaut; one new saved search only for *everything* would complement the existing list without opening the door to go more granular I think. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 483159] [wayland] On a scaled display, icons jump very slightly to the side when being focused/unfocused with the mouse if the mouse moves over them during the focusing/unfocusing
https://bugs.kde.org/show_bug.cgi?id=483159 --- Comment #1 from Eamonn Rea --- This is still present in Plasma 6.1.3. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 486039] [wayland] Some Applications Render Fonts with Artifacting at Certain Window/Element Widths at Fractional Scale Factors
https://bugs.kde.org/show_bug.cgi?id=486039 --- Comment #4 from Eamonn Rea --- I noticed recently that this affects Elisa particularly badly, and it can even be seen on a screenshot for this week's "This Week in KDE", although it is not quite as bad as it is on my system, it may help confirm that this is not a bug specific to my system. This is the screenshot in question where this is visible, along the lefthand side text like the highlighted "Artists" section can show this issue: https://pointieststick.com/wp-content/uploads/2024/07/screenshot_20240719_104718.jpeg In my case, however, this is more apparent. But that may be a case of varying scale factors/window sizes. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489008] Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"
https://bugs.kde.org/show_bug.cgi?id=489008 Eamonn Rea changed: What|Removed |Added Resolution|--- |UPSTREAM Status|REPORTED|RESOLVED --- Comment #4 from Eamonn Rea --- Confirmed across two machines that this was fixed with a recent systemd update. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490527] New: Default-enabled gdb symbols when submitting crash reports eats RAM and causes a system lockup
https://bugs.kde.org/show_bug.cgi?id=490527 Bug ID: 490527 Summary: Default-enabled gdb symbols when submitting crash reports eats RAM and causes a system lockup Classification: Plasma Product: plasmashell Version: 6.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic-crash Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: 1.0 SUMMARY When waking my computer from sleep, Plasma consistently shows the crash reporter. When I try to report the crash, the GDB checkbox is already enabled, and the crash reporter tries to report the bug. Presumably it is waiting on getting the symbols from GDB to submit as part of the crash report. However in doing this, the GDB process will keep eating ram until my system locks up. Disabling the GDB checkbox doesn't resolve the problem, the process continues and will eat RAM until a system lockup. This can take a while as the memory consumption increases gradually. I'm not sure quite how long it takes, maybe approximately 10 minutes, but the first time I encountered this was when I had woken my computer from sleep, tried to submit the crash report, and then realised a bit too late that my system had a *lot* of memory used with a widget I have in one of my panels. The next time it happened I noticed it was GDB eating the memory, and in the Crash Reporter I saw that there was a checkbox for the debug symbols. But disabling this didn't appear to do anything. I understand the requirement for symbols and why they're enabled by default, but unfortunately in some cases it can exhaust all system RAM. I'm not sure what Plasma could do about this. This could be entirely wrong, but perhaps this crash is a large core component of Plasma crashing, and fetching the symbols just requires a *lot* of memory. Maybe symbols should be disabled by default if Plasma can detect certain components have crashed, or on systems with lower memory? I have 32GB RAM on my Desktop and PC, and although this is more-or-less standard for modern hardware, users with older hardware (even moreso hardware that cannot be upgraded) may not have the luxury of more than 16GB RAM. And some users may not even check the system monitor to see that GDB is the culprit eating RAM overtime, their system may just lock up suddenly. Or if they're watching the Crash Reporter they may not realise why it is taking so long. STEPS TO REPRODUCE 1. Produce a crash and get the Crash Reporter, in my case, waking my Desktop PC from sleep will always show this, but my laptop does not show this. Perhaps it needs to be something like the Plasma session crashing entirely? 2. Report the crash, including debug symbols should be enabled by default. 3. GDB will gradually keep consuming memory until the system locks up. OBSERVED RESULT Crash Reporter's option to include debug symbols can cause the system to exhaust all available memory and lock up. EXPECTED RESULT That's a tricky one to answer without simply saying "memory shouldn't be exhausted" but this is a direct product of GDB, and I would imagine including those symbols is pretty much required for tracking down nasty bugs without fumbling in the dark (or I believe so anyway, I'm not super familiar with C++). SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.9 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION To clarify, this is not a report for the crash when waking from sleep, this is a bug report for the Crash Reporter firing GDB by default (again, understandably!) but in this case it will eat RAM until the system halts. Waking from sleep is just the crash that happens to trigger GDB eating a ton of memory. -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 490239] New: Info Center Sometimes Cannot Display Battery Change Percentage Graph
https://bugs.kde.org/show_bug.cgi?id=490239 Bug ID: 490239 Summary: Info Center Sometimes Cannot Display Battery Change Percentage Graph Classification: Applications Product: kinfocenter Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: sit...@kde.org Target Milestone: --- SUMMARY Sometimes the "Energy" information's Change Percentage tab for my laptop cannot display its graph. There is a bubble that says "This type of history is currently not available for this device". Swapping between the "Change Percentage" and "Energy Consumption" info will eventually get the graph to display. This issue usually happens after taking my laptop from sleep, even just putting it to sleep briefly (less than a minute). Waking from sleep doesn't seem to fix the issue. When running from the commandline in my case, I was able to see these errors. The first one was printed when I opened the "Energy" tab, so that was from a "first load" of the page. The other two were after I switched to the "Energy Consumption" tab and then back to the "Change Percentage" tab (they are buttons but act like tabs, sorry if I used the wrong phrasing, unsure how to describe them). ``` qrc:/kcm/kcm_energyinfo/Graph.qml:56: TypeError: Cannot read property 'x' of undefined qrc:/kcm/kcm_energyinfo/Graph.qml:118: TypeError: Cannot read property 'x' of undefined qrc:/kcm/kcm_energyinfo/Graph.qml:118: TypeError: Cannot read property 'x' of undefined ``` STEPS TO REPRODUCE 1. Open Info Center after a device with a battery has been put to sleep 2. Open the Energy pane 3. Sometimes the "Change Percentage" graph cannot be loaded. 4. Swap between "Energy Consumption" and "Change Percentage" 5. Eventually, the graph should load, it can take a long time though. OBSERVED RESULT Energy Consumption can sometimes not be displayed after taking a device with a battery from sleep. EXPECTED RESULT The information should be available. Maybe this as straightforward as passing some data differently to the graph. Otherwise, Plasma could either try to fetch it and show some kind of loading placeholder for the graph with a spinner. Reading the error again, "not currently available" does seem to have an implication that the data may be available in future. So perhaps this error was placed with the intent to convey that the data should be present, but Plasma couldn't get it right now. In that case, maybe adding a "please try again later" or something to this effect would be good, to indicate that Plasma does know it should display this information for this device, but that it cannot right now. I am not sure if Plasma displays the same warning on a Desktop PC without a battery connected, but if it does, ideally the two warnings should be distinct; something indicating that in this case, the battery is known to be present, but that Plasma just cannot get the requested information for the graph right now. But again, if it is possible to fix this outright, that should be preferred :-) SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.8 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Looking at master, I guess this is `plot` that is undefined: https://invent.kde.org/plasma/kinfocenter/-/blob/be18d5e78711dfa5ddc5a85f90c59fa197ac083d/kcms/energy/ui/Graph.qml#L56 >From skimming the code maybe it isn't able to load some data, which is causing the graph to not display? Maybe there is a deeper firmware issue or something causing this behaviour, I am unsure (although powertop can display battery information fine so I am unsure). Or maybe it takes a while to fetch some of this information / it has to be re-prompted to fetch it, which might be why switching between the two pages with the two graphs eventually gets the information to display? That would mean it isn't necessarily switching the pages that fixes the problem, but that switching them means that effectively the data the Change Percentage page needs has finally loaded and so going back to the page acts like a "refresh" action. I am unsure, I'm not super familiar with the technology here :-) If there are any files I can provide, such as cache files like for a prior issue with QML errors, let me know what to provide and the next time I can reproduce this problem I will attach the necessary files. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 490119] New: With fractional scaling, grabbing to resize a panel element's dropdown menu causes it to jump when grabbed and jump slightly when it is resized
https://bugs.kde.org/show_bug.cgi?id=490119 Bug ID: 490119 Summary: With fractional scaling, grabbing to resize a panel element's dropdown menu causes it to jump when grabbed and jump slightly when it is resized Classification: Plasma Product: plasmashell Version: 6.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 SUMMARY With at least some fractional scale factors (such as 145%), when you click on a panel element (such as network settings, etc) to show its dropdown menu, grabbing to resize the panel will cause it to jump very slightly. In my case with a panel at the top of the screen, with a panel element to the right of the panel, the dropdown menu jumps slightly to the left. When moving on to resize the panel, it will jump a very small amount as well. This is differeent to what is experienced when resizing quickly and having the *contents* jump around while it adjusts to the new size, this is about the dropdown itself jumping around a pixel or two. I mention fractional scaling because I am aware there have been, I believe, some rounding issues that cause this sort of behaviour (such as Bug 489016). STEPS TO REPRODUCE 1. Have a fractional scale factor (unsure at time of writing if it is required for reproducing the problem) 2. Open a panel element's dropdown menu (such as network settings) 3. Click to begin resizing the dropdown 4. When "grabbed" after being clicked, the dropdown itself will shift very slightly in some direction; for me, it is to the left, but this could vary depending on panel location and the location of the panel element. OBSERVED RESULT Panel element jumps very slightly when being grabbed. It continues to jump around after being resized. EXPECTED RESULT Panel content location should not jump like this. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.8 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Extremely minor issue but could help iron out any fractional scaling rounding issues. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489802] Overview effect doesn't support blur below app windows
https://bugs.kde.org/show_bug.cgi?id=489802 --- Comment #2 from Eamonn Rea --- Thanks. Interestingly this doesn't occur with the new "Edit Mode" effect. The panel is present for this effect but it actually tweens its opacity properly. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 489839] New: Changing "Desktop and Wallpaper" settings and then going back to the defaults will not count as unchanged settings
https://bugs.kde.org/show_bug.cgi?id=489839 Bug ID: 489839 Summary: Changing "Desktop and Wallpaper" settings and then going back to the defaults will not count as unchanged settings Classification: Plasma Product: plasmashell Version: 6.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY If you open the Desktop & Wallpapers setting for a given desktop and change a setting, such as the current Wallpaper or Right Click action for the Desktop (any setting reproduces the behaviour, these are just examples), going back to the defaults will not register as having unchanged settings. This is inconsistent with the rest of Plasma, where changing a setting but going back to the existing settings before the settings were changed will correctly register that no settings were changed (the "Apply" button will be disabled, and closing the window won't give warnings about unchanged settings). As a simple and possibly common example, select a new wallpaper, and then click on the previously selected wallpaper (i.e. the current one), this does not count as an unchanged setting. The "Apply" button is still active, and attempting to close the window will give you a warning that unchanged settings will not be applied. I note this as a common example as I originally thought this only applied to Wallpapers until I was writing this bug report and tried other settings, and discovered it applies to all settings under "Desktop and Wallpaper" STEPS TO REPRODUCE 1. Open "Desktop and Wallpaper" settings. 2. Change a setting, such as the current Wallpaper, but any setting will do (including Mouse Actions settings). 3. This marks the settings as changed, so the "Apply" button will be enabled and attempting to close the window will warn that there are unsaved settings. This is normal so far and not a bug. 3. Change the setting back to what it was when you opened the window, i.e. if you changed the wallpaper, go back to the previous Wallpaper 4. The "Apply" button is still enabled although the settings have been reverted back manually, and attempting to close the window will warn that there are unsaved settings. OBSERVED RESULT Changing "Desktop and Wallpaper" settings and then changing them back while the window is open does not register that settings are unchanged. Attempting to close the window will result in an incorrect warning that settings will not be saved, although there are no changed settings to apply. This is inconsistent with the rest of the Plasma Desktop which will correctly understand that going back to the current settings means there are no unapplied settings. EXPECTED RESULT The "Desktop and Wallpaper" settings should understand that going back to the existing settings without applying them means that there are no unchanged settings. This should hopefully be feasible as other parts of Plasma are able to do this. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.7 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION I don't know when this began happening, it could have happened in Plasma 5 as well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489838] New: [wayland] If panel opacity changes when switching virtual desktops, the panel glitches while the opacity changes
https://bugs.kde.org/show_bug.cgi?id=489838 Bug ID: 489838 Summary: [wayland] If panel opacity changes when switching virtual desktops, the panel glitches while the opacity changes Classification: Plasma Product: kwin Version: 6.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY If panel opacity changes when switching virtual desktops, such as going from a virtual desktop with a window maximised to an empty virtual desktop with with no windows, the panel will glitch while the opacity adjusts. This happens when switching virtual desktops using a keyboard shortcut, but seems to be more prevalent when switching using a touchpad gesture. This is probably because the speed can vary. Depending on how you perform the gesture sometimes it is not visible, but performing the gesture very fast makes the glitching very noticeable. The effect is still noticeable when switching with a keyboard shortcut but it happens earlier. It *seems* like the opacity smoothly transitions if you perform the touchpad gesture to move around halfway between the virtual desktops and let go, then the opacity smoothly transitions and does not glitch. It is somewhat precise, as too much / too little still causes the glitching. I don't have a touchpad on my PC to test there. I have my panel at the top of the screen, but this also occurs with panels at the bottom of the screen. I did not test if this happens with panels to the left / right of the screen. This happens on my Desktop PC and my laptop, using the open source Mesa drivers. There is potential it could be a GPU driver bug but if so it would be specific to AMD / Mesa. I do not have any Intel or Nvidia hardware to test on. I don't believe bug was present in Plasma 5, but it is new to Plasma 6, and I am unsure when it started happening in Plasma 6. STEPS TO REPRODUCE 1. Have a panel with adaptive opacity, and at least two virtual desktops 2. Maximise a window on one of the virtual desktops 3. Switch virtual desktops with a keyboard shortcut OR a very fast / very slow touchpad gesture (sliding with three fingers). 4. Observe that the panel glitches briefly while it settles into the correct opacity. OBSERVED RESULT Panel opacity glitches if it changes while switching virtual desktops. EXPECTED RESULT Panel opacity should not glitch and should smoothly transition. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.7 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #23 from Eamonn Rea --- Oops replied to the wrong issue, sorry... -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489008] Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"
https://bugs.kde.org/show_bug.cgi?id=489008 --- Comment #3 from Eamonn Rea --- Should be fixed in systemd 256.2 with this cherry-picked commit: https://github.com/systemd/systemd/commit/52371fe5263eb2916dcef69d93515f8d2a8e6043 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #22 from Eamonn Rea --- Should be fixed in systemd v256.2 with this cherrypicked commit: https://github.com/systemd/systemd/commit/52371fe5263eb2916dcef69d93515f8d2a8e6043 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 483155] [wayland] Spectacle Rectangle Select has Inaccurate Sizing on Multi-Screen Multi-Scale Configurations
https://bugs.kde.org/show_bug.cgi?id=483155 --- Comment #8 from Eamonn Rea --- This is still not fixed in Spectacle 24.05.2 despite being marked as fixed in 24.05. It was never fixed for me, the displayed resolution is always incorrect so long as there is a scaled display anywhere in the setup, even just a single scaled display on a laptop. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #21 from Eamonn Rea --- After further testing on my PC, my findings are: - Both scaled and non-scaled displays still have the incorrect resolution. - This issue appears fixed on my laptop which has a single display, but my laptop is using a 145% scale factor and a single display, whereas my PC has a 150% display and several 1080p displays with no scaling applied. - Turning off the other displays on my PC will fix the issue and create correct region screenshots the same way my laptop does. - My assumption then is that when I connect my laptop to another display, it will reproduce the bug. - I am taking region screenshots on a multi-screen setup but the region screenshots themselves are confined to a single display. - Despite the resolution being correct on single-display setups (with and without scaling, the invalid scaling is not exclusive to multi-screen setups), the resolution preview box still displays the incorrect resolution. This displayed resolution is correct on multi-scale setups, i.e. a resolution of 3000x2000 on a 1080p display is actually what the screenshot would save as on a multi-screen setup with at least one scaled display, but on a setup with a single scaled display, the displayed resolution is wrong. - Although I note they are exclusive to multi-scale setups, I don't know what would happen if all displays had the same scale factor. Perhaps the issue would be fixed? - The Resolution Preview box bug is probably Bug 483155. I hope this clarifies the state of the bug a little more. Definitely important progress, now Spectacle region screenshots work great on my laptop! -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #20 from Eamonn Rea --- Nevermind, the bug is fixed on my laptop it seems but not on my multi-screen Desktop PC. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489802] New: [wayland] Activating Overview Effect / All Desktops effect disables panel blur while active
https://bugs.kde.org/show_bug.cgi?id=489802 Bug ID: 489802 Summary: [wayland] Activating Overview Effect / All Desktops effect disables panel blur while active Classification: Plasma Product: kwin Version: 6.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY When activating the Overview Effect or the All Desktops effect (unsure what it is called, when you slide down with four-fingers on a touchpad), panel blur is disabled temporarily. This is most noticeable with a touchpad and sliding up or down with four fingers to activate the Overview effect or All Desktops effect, but it is visible albiet briefly however these effects are activated (using a touchpad just allows you to activate the effects gradually). Using a background that provides a significant blur colour makes this even more noticeable, for example using the Plasma "Reef" wallpaper. This was not present in 6.1.1 to my knowledge. This may affect other, er, effects that perform similar actions, but the Overview Effect and All Desktops effect are the only ones I am aware of. STEPS TO REPRODUCE 1. Have a panel that has transparency and blur. 2. Activate the Overview Effect or All Desktops effect. a. This can be more noticeable when using a touchpad gesture that allows you to gradually animate the effects, and also most noticeable with a wallpaper that provides significant blur. 3. While the effects are active, there panel blur will be disabled. OBSERVED RESULT These effects temporarily disable panel blur. EXPECTED RESULT These effects should not disable panel blur. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.7 Linux Zen KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION May affect other effects, and so would be a more general bug than being specific to these effects. But as I can only reproduce it with these effects, I reported it under these. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #19 from Eamonn Rea --- This appears to be fixed for single-display region screenshots with Spectacle 24.05.2, however I have only tested on a single-scale display. I did some pixel-peeping and the results look virtually identical to my eyes. - I don't have the most fancy colour-measuring equipment or anything but colours also look identical, and I don't see any ringing artifacts. - Everything right down to the number of pixels in the close button for a window is identical in terms of sizing, opacity, colours (measured with KColorChooser) looks identical to me. - File sizes of region screenshots and cropped window screenshots are also pretty much identical. I don't think I mentioned it in this issue but the only remaining problem is that after taking a screenshot, depending on how long it takes the screenshot to save, the enlarged screenshot is briefly overlayed on top of the screen in what can either be a quick flash for a fraction of a second, or a larger length of time if saving a very high resolution image to a slower external drive. I haven't confirmed yet if the issue is fixed on setups with a variety of scale factors but I intend to test that later today when I am on my PC and not my laptop. But overall apart from the above mentioned issue (which I could open a separate ticket about) this issue is entirely resolved for me and I am very pleased. Region screenshots on my laptop at least look, for my purposes and tastes, perfect. My assumption is that region screenshots across displays and so also all-display screenshots will still have the upscaling (so wrong resolution) and ringing artifacts. On my single-display laptop, Entire Desktop screenshots look identical to Current Monitor screenshots and Region Screenshots of the same area. But as far as the exacts of this issue so, I think this is fixed, pending further testing on my desktop with all my displays! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489016] [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time
https://bugs.kde.org/show_bug.cgi?id=489016 --- Comment #7 from Eamonn Rea --- Super cool, thank you for fixing it so quickly! -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426627] Ability re-arrange existing virtual desktops
https://bugs.kde.org/show_bug.cgi?id=426627 --- Comment #17 from Eamonn Rea --- Came to express support for this. On my PC I never really understood the need for this, but on my laptop this is something I keep instinctively trying to do and cannot. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426627] Ability re-arrange existing virtual desktops
https://bugs.kde.org/show_bug.cgi?id=426627 Eamonn Rea changed: What|Removed |Added CC||eamonn...@protonmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489012] [wayland] Adaptive Sync option sometimes disappears when waking from sleep
https://bugs.kde.org/show_bug.cgi?id=489012 --- Comment #3 from Eamonn Rea --- This happened again today, although not when waking from sleep but on bootup after updating to Plasma 6.1.1. I have not rebooted since but I suspect rebooting will get the option to appear again. I installed `drm_info` from the AUR, and 9 connectors were returned. The first one, connector 0, does list VRR as being supported. The other ones, 1-8, list this as not being supported. Connector 0: - "vrr_capable" (immutable): range [0, 1] = 1 Connector 1-8: - "vrr_capable" (immutable): range [0, 1] = 0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489016] [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time
https://bugs.kde.org/show_bug.cgi?id=489016 --- Comment #4 from Eamonn Rea --- This is the geometry of the Dolphin window under X11 windows, with Dolphin being run with `QT_QPA_PLATFORM=xcb dolphin`. bufferGeometry: 895.333,1329.33 1376x919.333 clientGeometry: 895.333,1329.33 1376x919.333 frameGeometry: 894,1296 1379.33x954.667 At first I manually entered these, as I didn't realise double-clicking on the entry in the KWin Debug Console would copy them over. As for window decoration settings, I use standard Breeze Dark decorations, with Button Size set to Large. I don't believe I have any other esoteric settings, at least nothing that has changed in the last few years. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488936] Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling
https://bugs.kde.org/show_bug.cgi?id=488936 --- Comment #8 from Eamonn Rea --- > Do you have keyboard brightness exposed in the widget? If so, try scrolling > there too; I'm guessing it has the same problem. I can not, keyboard brightness is not exposed for any of my keyboards or devices (none of my laptops or external keyboards have their brightness show up in any software), it can only be controlled on the keyboards themselves. But I appreciate the insight, I'm guessing other sliders either have a different snapMode or no snapMode. Took a look around plasma-desktop out of interest and didn't see a snapMode defined for what looked like volume-related slider QML :-) Interesting either way. And yup, a duplicate of the bug mentioned. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488936] Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling
https://bugs.kde.org/show_bug.cgi?id=488936 --- Comment #6 from Eamonn Rea --- Yup, good catch! Turning the scroll speed back to default (as per Bug 470746, the 5th tick from the left on the slider) and the scroll events trigger properly. It is worth noting that from what I have observed, all other scroll behaviour is fine, including those on other widgets such as the Volume widget. Scrolling on that changes the volume as expected, this seems to only impact Power Management. That doesn't mean it *isn't* Bug 470746 but it is an inconsistency in that this only appears to affect Power Management, at least in my case. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488936] Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling
https://bugs.kde.org/show_bug.cgi?id=488936 --- Comment #4 from Eamonn Rea --- I have changed the scroll speed, yes.I have it at the lowest setting (which is still a bit fast for my tastes). I have not tried a new user account, but this one is pretty fresh (just over a week old). If I do a "fling" gesture (not sure how to word it, sorry) where I swipe vertically with two fingers really fast it will pretty consistently actually change. But gradually scrolling like I would do for, say, volume, requires quite a lot of scrolling (usually two full scrolls). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489012] [wayland] Adaptive Sync option sometimes disappears when waking from sleep
https://bugs.kde.org/show_bug.cgi?id=489012 --- Comment #2 from Eamonn Rea --- Thanks, next time this occurs I will check for this. drm_info seems like exactly what i was looking for to check if this was a visual thing or if KWin is reflecting that the information has disappeared. I'm guessing that, if this is reproducible again and drm_info shows that VRR is not available, that this is a bug with DRM / some other part of the graphics stack and not KWin? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488935] Adjusting Power Profile Affects Display Colours
https://bugs.kde.org/show_bug.cgi?id=488935 --- Comment #2 from Eamonn Rea --- Alright then, thanks! I'll take this up with Framework. The only thing that changes with the screen are the colours. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488936] Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling
https://bugs.kde.org/show_bug.cgi?id=488936 --- Comment #2 from Eamonn Rea --- > sometimes when you change the profile, it immediately changes back, and the > UI is simply reflecting this bug. Very annoying for sure. Even if the text on the tooltip itself never changes, but does change and stays correct if I keep scrolling? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489139] New: [wayland] Grabbing a window and switching virtual desktops with window transparency enabled removes the window transparency effect
https://bugs.kde.org/show_bug.cgi?id=489139 Bug ID: 489139 Summary: [wayland] Grabbing a window and switching virtual desktops with window transparency enabled removes the window transparency effect Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-window-management Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY When the window transparency effect is enabled for grabbed windows, grabbing a window (which makes it transparent) and switching to another virtual desktop with a keyboard shortcut will cause the window transparency effect on that window to disappear while it is grabbed. Re-grabbing the window correctly re-enables the effect. This is a regression since Plasma 6.0.5, which did correctly preserve the window transparency effect. STEPS TO REPRODUCE 1. Enable transparency for grabbed windows. 2. Grab a window 3. Move to another virtual desktop while holding the window by using a keyboard shortcut 4. The window transparency effect disappears. OBSERVED RESULT The window transparency effect disappears for grabbed windows when switching to another virtual desktop while holding the window. EXPECTED RESULT Window transparency should be preserved like in Plasma 6.0.5 and below. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.6 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489008] Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"
https://bugs.kde.org/show_bug.cgi?id=489008 --- Comment #2 from Eamonn Rea --- Might be a duplicate of Bug 488177. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489016] [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time
https://bugs.kde.org/show_bug.cgi?id=489016 --- Comment #1 from Eamonn Rea --- I cannot reproduce this on my laptop with just a single screen connected, so perhaps this is specific to display configurations with one scaled display and at least one regular display? My Desktop always has multiple monitors connected so it is most easily reproducible there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489017] [wayland] Moving the mouse cursor across the corners of a display causes it to get stuck
https://bugs.kde.org/show_bug.cgi?id=489017 --- Comment #2 from Eamonn Rea --- Perfect, nice and smooth again, thank you! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489017] New: [wayland] Moving the mouse cursor across the corners of a display causes it to get stuck
https://bugs.kde.org/show_bug.cgi?id=489017 Bug ID: 489017 Summary: [wayland] Moving the mouse cursor across the corners of a display causes it to get stuck Classification: Plasma Product: kwin Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multi-screen Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY This bug is not the same as Bug 488829, which is related to a new feature in Plasma 6.1.0 If you have two displays arranged horizontally or vertically, if you attempt to move the mouse while hugging one of the connected edges, the cursor will get stuck in the corner that connects the displays. They do not even have to be perfectly aligned to see this. For example, if you have two displays arranged vertically, hug the left or right edge and attempt to move the cursor down. It will get stuck as it tries to go beyond the display. This is not the same as the Edge Barriers feature because this only applies to the screen corners, and no amount of pulling will get the cursor to move down, and it also occurs if you have Edge Barriers disabled. You have to move the cursor away from the edge and then it can move down. If you have displays arranged horizontally, the same thing happens when hugging the top or bottom edge. It also happens if your displays are not perfectly aligned, for example a displays arranged horizontally but slightly offset from each other. Attempting to move into the display when hugging a corner only will cause the cursor to get stuck. STEPS TO REPRODUCE 1. Arrange some displays 2. Attempt to move the mouse between displays while hugging one of the edges 3. At the corner where the displays connect, the mouse will get stuck, and this only happens in the corners. OBSERVED RESULT Cursor can get stuck when moving between displays if hugging the edge. EXPECTED RESULT Cursor should not get stuck. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489016] New: [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time
https://bugs.kde.org/show_bug.cgi?id=489016 Bug ID: 489016 Summary: [wayland] Showing and hiding titlebar and frames on a scaled display will cause XWayland windows to move diagonally by about 1px every time Classification: Plasma Product: kwin Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY Toggling the window titlebar and frames of an XWayland application on a scaled display (I am using 150% scaling on my PC and 140% scaling on my laptop), such as by using a shortcut that you can hold down to repeat. will cause the window to shift diagonally by about 1px each time. In my testing this has cause the window to either move diagonally up and to the left, or diagonally down and to the right, but other combinations may exist as well. I am not sure what influences the direction that the windows move, perhaps however the coordinates are being rounded. This *only* affects XWayland applications and only if they are windowed and not maximised. A maximised XWayland application (such as Steam) or a fullscreen XWayland application (such as a game) is not impacted by this. Holding down the shortcut is not required for this, but it is the fastest way to toggle the window decorations and to see visually the movement. It is worth noting that I only found one XWayland application that was unaffected, and that was the Steam Client. I thought that maybe this only affected Qt-based XWayland windows then, but games running via Wine also exhibit this behaviour (games are my most common XWayland use-case which is the only reason I mention them). I could be wrong but perhaps this is related to some fractional scaling weirdness and the rounding of pixels (which should be fixed with fractional-scale-v2)? Possibly related in that case: Bug 459373. STEPS TO REPRODUCE 1. Have an XWayland that has a traditional titlebar and frame, such as the Dolphin File Manager running with XWayland using `QT_QPA_PLATFORM=xcb dolphin` a. You can verify when a program is using XWayland with xeyes 2. Have a keyboard shortcut bound to toggle the Window Titlebar and Frame (can be set under Shortcuts -> KWin -> "Toggle Window Titlebar and Frame") 3. Put the window onto a scaled display. 4. Hide the titlebar and frame, the shortcut will cause the window to drift OBSERVED RESULT Many XWayland windows will drift by about 1px each time if you toggle their window decorations. There is at least one exception, the Steam Client, but every other tested XWayland window did exhibit this behaviour (including some KDE apps like Dolphin forced to run with XWayland) EXPECTED RESULT XWayland windows should not drift and should behave the same as Wayland windows. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Did not test X11 to see if this is just a bug with X11 in general and not spe -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489010] Copying error messages from Dolphin with Ctrl+C will copy selected files instead of text
https://bugs.kde.org/show_bug.cgi?id=489010 --- Comment #1 from Eamonn Rea --- I found out this applies outside of Dolphin. In Kate if you open a file and it updates while the file is open, it prompts you to ask if you want to reload the file, enable auto-reload, etc. This bubble is very similar to the one in Dolphin, and if you select the text in this prompt, the same thing happens; selected text will be copied (there is no selected text focus colour changes in Kate even if the window is unfocused so that doesn't apply here) and the text from the prompt will not be copied. Similarly right-clicking on it will allow you to copy it but it won't show "Ctrl+C" in the context menu. Maybe this is a problem generally related to this UI component, if it's re-used? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489008] Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"
https://bugs.kde.org/show_bug.cgi?id=489008 --- Comment #1 from Eamonn Rea --- Attempted to use `xdg-open` to open this file and it does not work either, it gives the following error: ``` kf.kio.gui: Failed to launch process as service: "app-org.kde.kate@c6423623b2c042cdb697e96a24758e21.service" "org.freedesktop.DBus.Error.InvalidArgs" "WorkingDirectory= may not be below /proc/, /sys/ or /dev/" WorkingDirectory= may not be below /proc/, /sys/ or /dev/ ``` Perhaps this is an upstream issue with systemd? https://github.com/systemd/systemd/issues/33361 - Although that would suggest the changes came with systemd, but this just started happening to me since Plasma 6.1. Maybe it was just coincidental timing? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 489012] New: [wayland] Adaptive Sync option sometimes disappears when waking from sleep
https://bugs.kde.org/show_bug.cgi?id=489012 Bug ID: 489012 Summary: [wayland] Adaptive Sync option sometimes disappears when waking from sleep Classification: Applications Product: systemsettings Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_kscreen Assignee: kscreen-bugs-n...@kde.org Reporter: eamonn...@protonmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Occasionally when walking my laptop from sleep, the "Adaptive Sync" option will disappear from the System Settings' Display Configuration menu. I have not noticed this happen on Plasma 6.0.5 or below with the brief period I used it on this laptop, or on my PC which has been running Plasma for a long time and which I wake from sleep quite regularly. I have not yet seen the Adaptive Sync options disappear on Plasma 6.1.0 on my PC, but it is happening on my laptop. I am not sure if this means Adaptive Sync is disabled or not. But I have noticed that when the setting disappears, my battery life significantly tanks (the display is 165hz). if there is a way that I could check the status of Adaptive Sync from the commandline please let me know, I would be interested to check if it is actually being disabled when the setting disappears! STEPS TO REPRODUCE 1. Put a device to sleep and wake it up. 2. Occasionally the Adaptive Sync option will disappear and won't come back until a reboot. OBSERVED RESULT Adaptive Sync option occasionally disappears when waking device from sleep. EXPECTED RESULT Adaptive Sync option should not disappear when waking from sleep. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Perhaps this is a driver issue when waking a laptop from sleep that is reporting to KDE that Adaptive Sync is unavailable? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489010] New: Copying error messages from Dolphin with Ctrl+C will copy selected files instead of text
https://bugs.kde.org/show_bug.cgi?id=489010 Bug ID: 489010 Summary: Copying error messages from Dolphin with Ctrl+C will copy selected files instead of text Classification: Applications Product: dolphin Version: 24.05.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY If Dolphin displays an error, such as "WorkingDirectory= may not be below /proc/, /sys/ or /dev/", it will not copy the text but instead will copy nothing, or the selected file. I noticed this when reporting Bug 489008 when I tried to copy the error message shown there, and couldn't paste it into the issue title. I checked my clipboard contents and saw that the selected file was being copied. This problem may apply generally to any time Dolphin shows these kinds of bubbles. Right-clicking on this text after selecting it will show the "Copy" option, which works, but there is no "Ctrl+C" shortcut description beside it, so perhaps this is intentional or a missing feature. Clicking on this message box will correctly "unfocus" the selected item in the files pane, dimming the accent colour, so I imagine the pane is losing focus. Perhaps these bubbles just need to be wired up to enable Ctrl+C? If it is not intended for this message to work with Ctrl+C, then the text should not be selectable, and pressing Ctrl+C should still probably not copy the files as the selection colour is dimmed implying it is not focused. But it would be nice if these errors could be copied, in case a user needs to talk about them online or anything :-) STEPS TO REPRODUCE 1. Trigger Dolphin to display an in-window warning, such as by trying to open a file in /dev on Plasma 6.1.0. 2. Select the text in this warning and attempt to copy it with Ctrl+C 3. The text will not be copied, you have to right click on the selection and choose "Copy" OBSERVED RESULT Messages in warning/error sections in Dolphin cannot be copied with Ctrl+C, and it will instead copy any selected files instead of the error contents. EXPECTED RESULT Messages should be able to be copied with Ctrl+C because they can be copied by right clicking and choosing "Copy". If it is intentional that these messages cannot be copied with Ctrl+C, then at least, nothing should be copied including any selected files, as the pane with the selection is dimmed visually implying that the selection is not focused and so won't be copied. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I have only tested with one warning message, that is the one from Bug 489008, but I can test others if you can direct me on how to trigger some of them. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 489008] New: Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"
https://bugs.kde.org/show_bug.cgi?id=489008 Bug ID: 489008 Summary: Cannot open files in /dev with error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/" Classification: Applications Product: dolphin Version: 24.05.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When trying to open a file in "/dev", such as log files in "/dev/shm/", Dolphin is unable to open them and displays the error "WorkingDirectory= may not be below /proc/, /sys/ or /dev/" when trying to open them using any application such as Kate. However the applications themselves can open these files. You can run `kate /dev/shm/myfile.log` and open it just fine. Likewise you can open these files just fine, for example opening files in this directory with Kate using its file picker works just fine. It is only Dolphin which does not let you open files in this directory. This is a regression in 6.1.0, and was not present in 6.0.5 and below - I regularly open files from /dev/shm, which is how I noticed this, but this bug is specific to any files in /dev. STEPS TO REPRODUCE 1. Navigate to /dev in Dolphin. 2. Attempt to open a file in this directory. 3. Dolphin will display the message "WorkingDirectory= may not be below /proc/, /sys/ or /dev/" a. When trying to double-click the file, it will show it in a red box inside the Dolphin window b. When trying to open the file by right clicking -> Open With -> Application, the error is displayed in a dialog box. OBSERVED RESULT Dolphin cannot open files in /dev, whereas applications themselves (such as Kate) can open files in this directory. EXPECTED RESULT Dolphin should be able to open files in /dev, in particular /dev/shm as some applications will put logging information there. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I confirmed this issue across two separate machines, so I do not think it is an isolated problem. If this is intentional, this is going to be quite problematic for applications that put logging information in /dev/shm, and should perhaps be reconsidered? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488936] New: Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling
https://bugs.kde.org/show_bug.cgi?id=488936 Bug ID: 488936 Summary: Scrolling to Change Power Profile on Power Management Icon Takes a Lot of Scrolling Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Battery Monitor Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@privat.broulik.de, m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: 1.0 SUMMARY I initially wrote this issue to report that the scrolling on the Power Management widget didn't work. However after messing for a few minutes I did actually discover that it works, it just takes a lot of scrolling to do so. When hovering over the Power Management widget, you can scroll to change the power profile. However, this takes a lot of scrolling to do so. On my trackpad (which fwiw has scroll speed set to the slowest value) I have to do two full vertical scrolls to change the power profile; it is faster to open the widget and click the profile at that speed. I did not try if a mouse scroll wheel requires as much scrolling. Other Plasma widgets which allow you to scroll to interact with them, such as Volume, do not take nearly as much scrolling. STEPS TO REPRODUCE 1. Hover over the Power Management widget 2. Scroll on it 3. it takes a lot of scrolling to change OBSERVED RESULT Power Management widget takes a lot of scrolling (two or more scrolls for me) to change the power profile, more than other Plasma widgets. EXPECTED RESULT Power Management should require the same amount of scrolling as other Plasma widgets. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Used a built-in laptop trackpad, did not try a mouse. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488935] New: Adjusting Power Profile Affects Display Colours
https://bugs.kde.org/show_bug.cgi?id=488935 Bug ID: 488935 Summary: Adjusting Power Profile Affects Display Colours Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Battery Monitor Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@privat.broulik.de, m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: 1.0 SUMMARY I couldn't find much information on this so I assume it is a specific bug and perhaps not intended, but if it is intended and I am being silly, feel free to close! When changing the CPU power profile in the Power Management widget, the display colours change. They will become much more washed out at Powersave, but look normal at Balanced and Performance (the display seems brighter at Performance, but that's it). I am aware that some systems allow you to toggle a display power profile and a CPU power profile, but I have not seen them grouped together. I also don't recall this happening on an old laptop I had where I changed the CPU performance governor manually. It also does not happen on my Desktop PC, or if it does, it is not noticeable. But this may be specific to a laptop power profile - or this laptop's power profile, as I could not see information online about this behaviour. The closest I could think of is that the power profile affects how much power the screen could be getting? But even on other devices where you can set a TDP limit, such as the Steam Deck, the screen colours are never affected in this way. I am using a Framework 16 laptop. This could very well be intended behaviour, but I couldn't find information about changing the Power Profile affecting display colours. This problem could also be an OS configuration issue and not something on the KDE side. I noticed this because I was keeping my laptop in Power Save, and when I opened some YouTube videos, the video quality was noticeably poor (like poor exposure or something). STEPS TO REPRODUCE 1. Adjust Performance Profile from a higher value to a lower value (naming and options may be different depending on the CPU) 2. Display colours will become washed out. 3. Turn the Performance Profile back up. 4. The colours will look normal. OBSERVED RESULT Display colours become washed out when turning the Power Profile down. EXPECTED RESULT Power profile should not impact the screen, or if it is intended, there should be an option to tweak this (perhaps a separate option under Displays for this?) SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I did not notice if this happened on Plasma 6.0.5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487904] Stuff using Kirigami InlineMessage and PlaceholderMessage fail to load with error `Cannot assign object of type \"Action\" to property of type \"Action_QMLTYPE_72*\" as the
https://bugs.kde.org/show_bug.cgi?id=487904 --- Comment #26 from Eamonn Rea --- I still have the backup of my entire `~/.cache` folder and will keep it around, let me know if there is any more information I can help provide! The bug is not critically affecting me, but it may be critically affecting others, and I am happy to help. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487904] Stuff using Kirigami InlineMessage and PlaceholderMessage fail to load with error `Cannot assign object of type \"Action\" to property of type \"Action_QMLTYPE_72*\" as the
https://bugs.kde.org/show_bug.cgi?id=487904 --- Comment #25 from Eamonn Rea --- Created attachment 170780 --> https://bugs.kde.org/attachment.cgi?id=170780=edit Archive containing qmlconfg files Archive of ~/.cache/plasmashell/qmlconfig from when the issue was occurring -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487904] Stuff using Kirigami InlineMessage and PlaceholderMessage fail to load with error `Cannot assign object of type \"Action\" to property of type \"Action_QMLTYPE_72*\" as the
https://bugs.kde.org/show_bug.cgi?id=487904 --- Comment #24 from Eamonn Rea --- I encountered this problem over at Bug 488907, and was directed to upload a backup of my `~/.cache/plasmashell/qmlcache` that was producing the error. I will do so after posting this comment (unsure if I can do it alongside a comment). So to be clear, the qmlcache archive I am uploading contains the backed up `~/.cache` folder from the time when the issue was occurring. I backed up the folder and then removed the original `~/.cache`. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488907] Weather Report in System Tray Displays a QML-related error
https://bugs.kde.org/show_bug.cgi?id=488907 --- Comment #4 from Eamonn Rea --- No problem, I'll attach only an archive of the specified path `~/.cache/plasmashell/qmlcache/` (where `~/.cache` is the backed up cache folder) to the mentioned Bug Report. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488849] [wayland] Klipper menu will appear on next display to mouse in some circumstances
https://bugs.kde.org/show_bug.cgi?id=488849 --- Comment #1 from Eamonn Rea --- May be relevant to note that, with a single display, the Klipper menu works fine. So this is specific to multi-screen setups. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488907] Weather Report in System Tray Displays a QML-related error
https://bugs.kde.org/show_bug.cgi?id=488907 --- Comment #2 from Eamonn Rea --- I have made a backup of the `.cache` folder and will happlly share it, is it fine to upload it here or could it contain some information that should be provided directly to KDE devs instead somehow? I also tried removing the `.cache` folder afterwards and the widget is still not working. I have not tried rebooting yet, although I suspect that would fix the issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488907] New: Weather Report in System Tray Displays a QML-related error
https://bugs.kde.org/show_bug.cgi?id=488907 Bug ID: 488907 Summary: Weather Report in System Tray Displays a QML-related error Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: System Tray Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: mate...@gmail.com Target Milestone: 1.0 SUMMARY When configuring the Weather Report option in System Tray to be always visible, and then right-clicking on it to configure it, the configure option is greyed out. When clicking on it, I see "Sorry! There was an error loading Weather Report" and the error logs below. ``` file:///usr/share/plasma/plasmoids/org.kde.plasma.weather/contents/ui/main.qml:438:25: Type FullRepresentation unavailable file:///usr/share/plasma/plasmoids/org.kde.plasma.weather/contents/ui/FullRepresentation.qml:38:24: Cannot assign object of type "QQC2.Action" to property of type "Action_QMLTYPE_134*" as the former is neither the same as the latter nor a sub-class of it. ``` A restart may fix this, but in case it does not, I am reporting it (it may also be a bug nonetheless that may need resolved, that I just happened to encounter). I have a Weather Report widget configured from a long time back on my Desktop PC prior to Plasma 6, and it does not have this issue. STEPS TO REPRODUCE 1. Enable Weather Report from System Tray 2. Click on the icon that appears in the System Tray 3. The error message may be displayed. OBSERVED RESULT Weather Report displays an error and prevents configuration. EXPECTED RESULT Weather Report should be configurable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Unsure if this affects X11 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 464654] KDE Connect should be able to send RCS messages
https://bugs.kde.org/show_bug.cgi?id=464654 Eamonn Rea changed: What|Removed |Added CC||eamonn...@protonmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 488845] Attempting to search for files using "From Here (folder)" errors with "kf.baloo: Failed to add exclude folder config entry for /home/username"
https://bugs.kde.org/show_bug.cgi?id=488845 Eamonn Rea changed: What|Removed |Added Version|unspecified |24.05.1 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488902] Searching for "Shake Cursor" in System Settings does not bring up Accessibility option
https://bugs.kde.org/show_bug.cgi?id=488902 Eamonn Rea changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488841 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488841] Shake Cursor Effect is Too Hidden
https://bugs.kde.org/show_bug.cgi?id=488841 Eamonn Rea changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488902 --- Comment #6 from Eamonn Rea --- Thanks, I reported this in a separate issue: Bug 488902. > That "Shake Cursor" does not show up directly is a technical limitation of > how things are implemented. No problem, I am aware of this part :-) But the "Accessibility" option not showing up when searching for "Shake Cursor" in System Settings sounds like a bug. Interestingly, as noted in that bug report, "Accessibility" does appear when searching in KRunner or the Application Launcher, so this bug is only for System Settings. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488841] Shake Cursor Effect is Too Hidden
https://bugs.kde.org/show_bug.cgi?id=488841 --- Comment #5 from Eamonn Rea --- Thanks, I reported this in a separate issue: Bug 488902. > That "Shake Cursor" does not show up directly is a technical limitation of > how things are implemented. No problem, I am aware of this part :-) But the "Accessibility" option not showing up when searching for "Shake Cursor" in System Settings sounds like a bug. Interestingly, as noted in that bug report, "Accessibility" does appear when searching in KRunner or the Application Launcher, so this bug is only for System Settings. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488903] New: Power Management Widget missing Battery Percentage in Panel if Power Profile is "Power Save"
https://bugs.kde.org/show_bug.cgi?id=488903 Bug ID: 488903 Summary: Power Management Widget missing Battery Percentage in Panel if Power Profile is "Power Save" Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Battery Monitor Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@privat.broulik.de, m...@ratijas.tk, natalie_clar...@yahoo.de Target Milestone: 1.0 SUMMARY When setting the Power Profile to "Power Save", the Power Management widget in a panel will display the "Power Save" icon (default is a leaf icon) but in doing so the Battery Percentage is not displayed. Changing the Power Profile back to any other setting will display the Battery Percentage again. I believe in Plasma 6.0.5, the Battery Percentage was still shown, as I just noticed this after upgrading to Plasma 6.1.0 (although I only used Plasma 6.0.5 on this device for a few days before upgrading). STEPS TO REPRODUCE 1. Add a "Power Management" widget to a Panel 2. Enable the Battery Percentage display option 3. Change CPU Power Profile to "Power Save" 4. Battery Percentage is hidden (but the option is still enabled if you right click on the widget) 5. Turn the Power Profile back up to another value 6. The percentage will display again, it is only missing when the power profile is "Power Save" OBSERVED RESULT The Power Management widget will not display the Battery Percentage if the Power Profile is set to "Power Save". EXPECTED RESULT The Power Management widget should display the Battery Percentage. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I have only tested the Wayland Session, I did not test X11. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488902] New: Searching for "Shake Cursor" in System Settings does not bring up Accessibility option
https://bugs.kde.org/show_bug.cgi?id=488902
Bug ID: 488902
Summary: Searching for "Shake Cursor" in System Settings does
not bring up Accessibility option
Classification: Applications
Product: systemsettings
Version: 6.1.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: kcm_accessibility
Assignee: plasma-b...@kde.org
Reporter: eamonn...@protonmail.com
Target Milestone: ---
SUMMARY
I originally filed Bug 488841 because I thought the Shake Cursor effect was
only togglable from Desktop Effects. I was then directed that the option is
under Accessibility, and that I can search for "shake" in System Settings to
bring up the Accessibility setting.
However, searching for "Shake" or "Shake Cursor" or incomplete variations
thereof does not bring up the Accessibility option. Searching for "Shake" or
anything after does not bring up accessibility. It simply shows "No items
matching your search."
This happens on a laptop that was installed with Plasma 6.0.5 and upgraded to
Plasma 6.1.0, so it is a very fresh (matter of days) old installation. And the
issue also happens on my long-term Plasma installation on my PC, also running
Plasma 6.1.0. In other words, this problem happens across two different
installations of varying ages.
When typing the letters one at a time, ("s, sh, sha, shak, shake" etc) the
Accessibility option does not appear at all. So while searching and the entries
in the sidebar get filtered, Accessibility is never shown.
It is worth noting that searching for "Shake" in KRunner and the Application
Launcher *will* bring up the Accessibility option, but *not* when searching in
System Settings. However it is equally worth nothing that users can disable
System Settings showing up in KRunner (I have this off on my Desktop, but I am
still tweaking my laptop settings and this was not disabled yet) and if the
user has disabled this, the user would have no way currently to search for
Shake Cursor.
STEPS TO REPRODUCE
1. Open System Settings
2. Search for "Shake"
3. The "Accessibility" menu which contains the "Shake Cursor" effect does not
show up, it displays "No items matching your search"
4. Searching for "Shake" in KRunner or the Application Launcher
OBSERVED RESULT
Searching for "Shake" in System Settings does not show the "Accessibility"
option on the sidebar, which contains this setting.
EXPECTED RESULT
Searching for "Shake" in System Settings should show the "Accessibility" option
on the sidebar.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.9.5 Linux Zen
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
ADDITIONAL INFORMATION
- In case locale is potentially an issue, I am using the en_GB.UTF-8 locale.
But I am not sure how this is implemented, so perhaps this is not relevant.
- I'm also aware that "Shake Cursor" will not show up in the System Settings
side pane when searching for it, that is totally fine, I am reporting that the
category which *contains* "Shake Cursor" - that is, the "Accessibility" option
- does not show up.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 488849] New: [wayland] Klipper menu will appear on next display to mouse in some circumstances
https://bugs.kde.org/show_bug.cgi?id=488849 Bug ID: 488849 Summary: [wayland] Klipper menu will appear on next display to mouse in some circumstances Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: 1.0 SUMMARY Activating the Klipper menu will cause the menu to appear on the display to the side, or above/below, the mouse cursor, in some circumstances. If you have two displays arranged horizontally, and on the left-most display you move the mouse cursor so that it is close to the right edge of the display, then the Klipper menu will appear on the right-most display. Specifically, I believe this happens when the remaining space between the mouse and the next display is less than half of the width of the Klipper menu. It is certainly not the full width, but it looks like half-width could be possible based on some testing. The menu will be aligned correctly on the Y axis but not on the X axis, appearing at the left edge of the right-most display. The same behaviour happens when displays are arranged vertically, except here I think it is when the space between the mouse and the top/bottom edge of the display is less than half of the *height* instead of width. I believe this is to do with the width/height is because if you are more than this approximate halfway marker, the dialog will draw on the correct display, but the mouse will be moved slightly over the top of the dialog, as you would expect (the dialog appears at the nearest position on the current display even if that means it cannot draw at the exact position of the mouse). But once you go more than halfway and there is less space available, instead of drawing on the same display as the mouse and having the menu hug the edge while the mouse is slightly offset along the top (or side, if vertical), the menu will just draw on the next display. Alternatively drawing the Klipper menu between displays could work, but I don't think this happens anywhere else in Plasma, and doesn't match existing Klipper behaviour. I think keeping the current behaviour but fixing the dialog drawing on the wrong display is the most intuitive approach. This offset bug is *specific* to when the cursor is close to the edge of another display. The position of the Klipper menu is correct in Plasma 6.1.0 in all other instances that I have seen. In other words this is distinct from Bug 482076 and Bug 485703. Note: I was not able to reproduce a case where this happened and the menu was not accessible. It is always possible to use the menu, but it is offset occasionally. Note 2: Scaled displays don't seem to have an effect here. It happens with and without a scaled display, even on display arrangements where the displays are identical in resolution. STEPS TO REPRODUCE 1. Move the mouse cursor close to the edge between it and another display 2. Activate Klipper menu, such as with Meta+V 3. The menu is offset onto the other display, hugging the edge closely 4. Move the mouse away from the edge of it and the other display 5. Once you are far enough away, the Klipper menu will display correctly under the mouse. OBSERVED RESULT Klipper menu appears on next display if the distance between the mouse cursor and the current screen edge is *less than half* the width/height of the Klipper menu (width when horizontally adjacent displays, height when vertically adjacent). EXPECTED RESULT Klipper menu should display on the same display as the mouse cursor. It handles this properly if the space between the cursor and the edge of the screen is more than halfway, the mouse cursor appears further along the top of the dialog. So this should apply even when the cursor is even closer to the screen edge. The Klipper menu should only appear on the next display once the mouse cursor goes onto that display. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I believe this bug is specific to Plasma 6.1.0, but I was unable to find this until Plasma 6.1.0 because of Bug 485703 (fixed in Plasma 6.1.0). -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485703] [wayland] Klipper popup menu position offset unless on top display.
https://bugs.kde.org/show_bug.cgi?id=485703 Eamonn Rea changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Eamonn Rea --- This is fixed in Plasma 6.1.0. I confirmed before upgrading that it was not fixed in Plasma 6.0.5. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 485871] Various Products Reference Plasma 5 / Frameworks 5 specifically
https://bugs.kde.org/show_bug.cgi?id=485871 --- Comment #1 from Eamonn Rea --- This has been partially fixed, "Plasmashell" no longer specifies the Plasma version. Some places still do though, such as "Plasma Workspace Wallpapers". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488841] Shake Cursor Effect is Too Hidden
https://bugs.kde.org/show_bug.cgi?id=488841 --- Comment #3 from Eamonn Rea --- Ah, thank you! Unfortunately the "Shake Cursor" effect does not come up when searching for "Shake" in System Settings, which is why I thought it was not visible. It simply displays "No items matching your search". This should be reported separately I think? -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 488847] New: It should be possible to unlock with fingerprint on lock screen without using the keyboard/mouse to activate the login UI
https://bugs.kde.org/show_bug.cgi?id=488847 Bug ID: 488847 Summary: It should be possible to unlock with fingerprint on lock screen without using the keyboard/mouse to activate the login UI Classification: Plasma Product: kscreenlocker Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY When waking up a device from sleep, it will show the time and wallpaper. You can use the mouse or the keyboard to "focus" and begin logging in. This by itself is fine, but in order to unlock the device with a fingerprint, this action has to be taken first. This means you cannot simply open a laptop lid and use your fingerprint to unlock. In my case (and from what I have observed in general, for others too) the fingerprint that my device uses is on the opposite hand to the one I use the trackpad with. This case would also allow for opening, say, a laptop lid and pressing the power button, but keeping your finger on the power button and having it unlock the device (perhaps after a (configurable?) delay). This is how it works on macOS for example. STEPS TO REPRODUCE 1. Setup fingerprint on a device 2. Put device to sleep (i.e. on a laptop, close the lid) 3. Wake device 4. Try to unlock device with fingerprint. 5. Nothing will happen. 6. The lock screen has to be "focused" (unsure of the correct word) to show the username and password field, and only then can the fingerprint scanner be used (and works without issue). OBSERVED RESULT The fingerprint reader cannot be used until the lock screen is "focused" and the login user and password field are displayed. EXPECTED RESULT The fingerprint reader can be used as soon as the screen comes on and the screen locker is displayed. There is a message under the passwordtelling you that you can use your fignerprint, but it should be possiible to use your fignerprint earlier than this as well. It works this way on macOS for example (unsure of other operating systems). SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION - I am aware that you cannot use the fingerprint on first boot, this issue is for after a screen is locked / system it put to sleep, not on bootup. - Unsure if this is a regression, but it has been the behaviour since at least Plasma 6.0.5, as that is the first time I used a computer other than a Mac with a fingerprint reader. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 488845] New: Attempting to search for files using "From Here (folder)" errors with "kf.baloo: Failed to add exclude folder config entry for /home/username"
https://bugs.kde.org/show_bug.cgi?id=488845 Bug ID: 488845 Summary: Attempting to search for files using "From Here (folder)" errors with "kf.baloo: Failed to add exclude folder config entry for /home/username" Classification: Applications Product: dolphin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When pressing Ctrl+F to activate the search functionality in Dolphin, running via shell shows that when trying to search using the "From Here (folder)" option (where "folder" is the current folder), it shows an error with "kf.baloo: Failed to add exclude folder config entry for /home/username". Using the "Your files" option can find the files no problem, although it takes a long time. I checked the File Indexer which I believe uses Baloo, and I can see my home folder listed there twice: One as "indexed" and the other as "not indexed". It's the exact same path, "/home/username". The trash icon to delete the entry is greyed out. Perhaps this conflict of enabled and disabled indexing is causing the problem? This functionality works fine on a brand new laptop, but not on my PC which has had this Arch installation for a number of years. As far as I can remember, it never worked on my PC, but I am only getting around to reporting it now when I happened to notice by accident that it works on my laptop. Note: KFind works without issue, and it's how I've been working around this problem for the last while, before I got the laptop and noticed Dolphin's Find works fine there. STEPS TO REPRODUCE 1. Open Dolphin 2. Press Ctrl+F to open the Find toolbar 3. Select the "From Here" tab 4. Search for a file 5. Perhaps specific to my PC, the results won't show up. OBSERVED RESULT "From Here" does not show files any files on my PC and fails immediately. EXPECTED RESULT "From Here" should work as it does on at least one other installation of Plasma 6.1.0 SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488841] Shake Cursor Effect is Too Hidden
https://bugs.kde.org/show_bug.cgi?id=488841 --- Comment #1 from Eamonn Rea --- This may be a good candidate for the "Quick Settings" pane for System Settings. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488841] New: Shake Cursor Effect is Too Hidden
https://bugs.kde.org/show_bug.cgi?id=488841 Bug ID: 488841 Summary: Shake Cursor Effect is Too Hidden Classification: Plasma Product: kwin Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY I understand Plasma 6.1.0 has enabled the "Shake Cursor" effect by default, I am not here to voice my disagreement with that :-) However in Plasma 6.0 when I tried it out it was available in the general list of Desktop Effects. In Plasma 6.1 it was enabled and I tried to disable it. It took me a while to figure out this option was considered an "Internal Effect" and hidden under the filter, which excluded these effects by default. I don't think "Shake Cursor" should be considered Internal in this way, it is new functionality on by default that is easy to activate with the shaking of a cursor (often accidentally), so a way to more easily disable it would be useful. KDE Plasma is not macOS and rightly so, however it is the only comparison I have, and I believe you can turn off this cursor effect for macOS more easily under the mouse settings. Whether this setting could be moved to have more visibility there is perhaps an alternative approach. Even if this feature were not enabled by default, keeping it under "Internal" effects would make it difficult for users who want to configure it. Further still, if a user disables it but later wants to enable it (say months later), the filter option for Desktop Effects is not preserved, so the effect becomes hidden again by default. STEPS TO REPRODUCE 1. Open Desktop Effects 2. "Shake Cursor" effect is hidden by default 3. Disable the "Exclude internal effects" option 4. Shake Cursor appears, but is not shown by default like it was in Plasma 6.0.5 OBSERVED RESULT "Shake Cursor" effect is too hidden under "Internal effects" and not shown by default. EXPECTED RESULT "Shake Cursor" should be visible as it is an easily-activatable effect newly enabled by default that users may want to disable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488833] Many Click-Enabled Shortcuts Changed to use Meta Key instead of Alt with No Configuration Option
https://bugs.kde.org/show_bug.cgi?id=488833 --- Comment #2 from Eamonn Rea --- Thanks! I wonder why this suddenly changed for me. I recently did a fresh install of endeavourOS with Plasma 6.0.5 on a laptop and I think the default was set to Alt, and when updating to Plasma 6.1.0 it was changed to Meta as well... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488839] New: Zooming into a desktop will cause screens with colour profiles to appear with distorted colours when they spill over onto other displays
https://bugs.kde.org/show_bug.cgi?id=488839 Bug ID: 488839 Summary: Zooming into a desktop will cause screens with colour profiles to appear with distorted colours when they spill over onto other displays Classification: Plasma Product: kwin Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multi-screen Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY The title of this issue is awful, I am sorry I could not phrase it better... When you have multiple displays and zoom in with "Meta+=" (Meta key and Equals key without shift held down) to, say, a window centered on one of them. Parts of other displays' content will spill onto other displays, because you're zooming in. That part is not a bug. However on a screen that has an ICC colour profile set up, the screen itself looks fine, but the contents of that screen that expand and spill onto other displays when you zoom in, are very visually distorted. Disabling the colour profile fixes this issue. Similarly, if content from displays that do not have an ICC colour profile spill onto the display with the ICC profile, they will use incorrect colours as well (in my case, too dark). STEPS TO REPRODUCE 1. Have multiple displays, with at least one having an iCC colour profile set up. 2. Zoom into your displays. 3. When you zoom in and parts of the display with an ICC profile spill onto other displays, the contents will have distorted colours. The content on the display with the ICC profile itself looks fine, it's when the contents goes onto other displays that it looks wrong. 4. Disable ICC profile for that display. 5. The bug goes away. OBSERVED RESULT Zooming in when one display has a colour profile, the colours on the content that spills onto other displays will look wrong. EXPECTED RESULT Colours should look correct when zoomed display contents overlaps between displays that do and don't have ICC profiles SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION - I believe this issue is exclusive to Wayland, as only the Wayland session offers setting an ICC profile? If there is a way to do this on X11 I have not tried and don't know if it replicates this bug. - I have not tested what happens when two displays have two colour profiles, however I could test that if required (I can plug a laptop which has a profile into one of my PC displays). - I did not know this zoom effect existed until earlier today, so I am unsure when this began. It might have been a problem since ICC profile selection was introduced in Plasma 6. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488832] Add a button/option that will show the logout screen with all options
https://bugs.kde.org/show_bug.cgi?id=488832 --- Comment #2 from Eamonn Rea --- Yes, that is what it boils down to; in the context of this issue, ideally also preserving the icon would be useful as well (some users may have "Restart" as their default, although I personally have "Poweroff"). That might be excessive and very specific customisation though. Maybe in general being able to set a custom icon rather than customising it based on the selected option is the way to go, like how we can change the icon for the Application Dashboard/Launcher/Menu. I'm not sure if it's feasible, or should be a separate report, but just some thoughts :-) The icon is certainly lower priority though, as to me this is more of a muscle-memory thing than a visual thing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488829] [wayland] Cursor gets stuck for a brief period between displays
https://bugs.kde.org/show_bug.cgi?id=488829 --- Comment #2 from Eamonn Rea --- Thanks! It appears to be under "Edge barrier", if anyone is reading this in future and also wants to turn it off. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488834] New: Adaptive Panel Effect No Longer Works for Maximised Windows
https://bugs.kde.org/show_bug.cgi?id=488834 Bug ID: 488834 Summary: Adaptive Panel Effect No Longer Works for Maximised Windows Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 SUMMARY The "Adaptive" panel effect no longer works for maximised windows. It works if a window is moved under a panel, but not when it is maximised. This is mot noticeable with bright wallpapers. I understand this effect will sometimes break, but I have tried many restarts and could not fix it. If this behaviour is intentional, a new option to adapt panel transparency on window maximise and not just on windows going under panels would be much appreciated. STEPS TO REPRODUCE 1. Create a panel with the "Adaptive" transparency setting. 2. Maximise a window. 3. The panel's transparency does not change. OBSERVED RESULT Panels with "Adaptive" transparency do not update when windows are maximised, only when they are under the panel. EXPECTED RESULT Panels with "Adaptive" transparency should at least have the option to change transparency when a window is maximised. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I have only confirmed this on AMD hardware; one is a laptop with a "AMD Radeon 780M" iGPU and the other is a Desktop with a 7900XTX (both running latest Mesa 24.1 drivers). Unsure if this is perhaps a GPU bug, but it worked fine on both machines on Plasma 6.0.5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488833] New: Many Click-Enabled Shortcuts Changed to use Meta Key instead of Alt with No Configuration Option
https://bugs.kde.org/show_bug.cgi?id=488833 Bug ID: 488833 Summary: Many Click-Enabled Shortcuts Changed to use Meta Key instead of Alt with No Configuration Option Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY Some shortcuts that previously used Alt+Mouse Click, such as Alt+Left Mouse to drag a window, or Alt+Right Mouse to resize, have now switched to Meta+Mouse Click. I think before there was a way to configure this modifier key, as I believe Meta became the default recently, but with Plasma 6.1.0 I cannot find a way to configure this, so I am (possibly incorrectly ;-)) assuming the configuration option for this has been taken out. In Plasma 6.0.5 and below, I was able to use the Alt key for this functionality, and have done so for many years. STEPS TO REPRODUCE 1. Move Window shortcut is now enforced as Meta+Left Click 2. Resize Window shortcut is now enforced as Meta+Right Click 3. Previously these shortcuts were either by default or configurable to use "Alt" as the modifier, but now the default has been set to Meta with seemingly no way to change this. OBSERVED RESULT Move Window shortcut is now enforced as Meta+Left Click. Resize Window shortcut is now enforced as Meta+Right Click EXPECTED RESULT Plasma should have respected the user defaults, and should allow the option to change this modifier key if the functionality has indeed been removed (or if it was never there to begin with and my memory is just not good :-)) SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Using the Wayland Session, I did not check X11. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488832] New: Clicking on Lock/Logout Widget with Only Shutdown Present will Only Display "Power Off" Option
https://bugs.kde.org/show_bug.cgi?id=488832 Bug ID: 488832 Summary: Clicking on Lock/Logout Widget with Only Shutdown Present will Only Display "Power Off" Option Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Session Management Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: natalie_clar...@yahoo.de Target Milestone: 1.0 SUMMARY If you have a Lock/Logout widget and configure it to only show that button, clicking on it will only show "Shut Down Now" and "Cancel". There is no way to, for example, restart, unless you configure this widget to display, in that case, "Restart" *and* click that button. You are locked to only be able to "Perform Action Now", where that Action is the button you pressed. For Lock/Logout, the user might only have one button configured so as to not pollute the panel, and to simply have this as a "catch all" to display session options. The action can be selected from KRunner by searching for, say, "Restart", but the "Desktop Sessions" category may not be the first result or the options could have jumped around and changed by the time a user presses enter. This may be intentional, as if you do this from something like the Application Dashboard where the buttons are bigger, and the action is less generic than it is with the Lock/Logout widget. Although I still think in that case it should be customisable what options display on that screen, to restore the previous behaviour. Alternatively, a widget that can act as a button to show any number of options as a replacement would also work. STEPS TO REPRODUCE 1. Add Lock/Logout Widget 2. Configure it to only display "Power Off" 3. Click on the Widget 4. It does not display the other session management options, it acts like the button on the Application Dashboard/Launcher/Menu, or the option from KRunner. This is unexpected behaviour from previous Plasma versions where you would see a list of session management options, and I believe there was an option for this setting to take effect immediately. OBSERVED RESULT Session management screen only displays the option to perform the action you pressed immediately or to cancel. There is no way to show all session management options (Restart, Poweroff, etc). This is a significant change in behaviour from Plasma 6.0.5 and below, where you could see all management options, so when using the Lock/Logout widget you could press the "Poweroff" looking button and then choose whether you wanted to logout, restart, poweroff, etc, without having to do so from any other screen. EXPECTED RESULT The options in the Application Dashboard/Launcher/Menu could, by default, have this behaviour, but Lock/Logout should at least have an option to configure it to display all session management options with a single button press. I assume Lock/Logout is using the same pattern as the Application Dashboard/Launcher/Menu. There is an option in Power Management to "Show logout screen" on actions such as when the Power Button is pressed. There should be a way to enable this for whenever a session management button is pressed, both from Lock/Logout and if the logic is indeed shared then also in the Application Dashboard/Launcher/Menu. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION I am using the Wayland session, but I don't think this is specific to X11 or Wayland. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488829] New: [wayland] Cursor gets stuck for a brief period between displays
https://bugs.kde.org/show_bug.cgi?id=488829 Bug ID: 488829 Summary: [wayland] Cursor gets stuck for a brief period between displays Classification: Plasma Product: plasmashell Version: 6.1.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY When moving a cursor between displays, they will get stuck briefly. If you slowly move a cursor it will stick at very close to the screen edge and there will be resistance when trying to move it beyond. This makes it difficult for a cursor to glide slowly across many displays at once, such as from one display across to a fourth display horizontally (although this effect also happens for displays that are stacked vertically, and for arrangements with displays arranged horizontally and vertically). If the cursor is moving very fast, the resistence is less noticeable, but can still be felt. This felt like a Desktop Effect or some kind of intentional behaviour, because it can make splitting windows slightly easier, but it impacts the default mouse behaviour. If the intent was to make tiling easier then this should ideally only apply if a window is being tiled, not for regular desktop usage. Even so, I would also say it should be optional behaviour, on by default, sure, but it should also be togglable as it is a significant change in behaviour from previous Plasma versions and other DEs/operating systems (unless something has changed significantly). I could not find any setting to turn this off, so I am filing it as an issue in case this is some kind of optional functionality. I don't know if this is intended to be a default, as this is not behaviour I have seen before on any Desktop Environment / Wayland Compositor (GNOME 3 way back, Xfce, Hyprland, Sway) or operating system with multiple monitors (Windows 10 a long time ago, macOS for work). I could reproduce this on my desktop, and on a laptop running Plasma 6.1.0 with an external display connected. It did not happen on any previous Plasma version. If this is intended to be the always-on default behaviour with no way to disable it, please consider making this optional. For cases where you might need to slowly move your mouse from the top right corner of one display to the top right of the adjacent display, this becomes a chore. STEPS TO REPRODUCE 1. Have multiple displays arranged next to each other. 2. Move the mouse across displays. 3. The mouse will "stick" to the edge of the display and take resistence to move. OBSERVED RESULT Cursor cannot slowly move between screens and gets "stuck" until "pushed" harder across the display. EXPECTED RESULT Cursor should not get stuck when crossing a screen border, or should be togglable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Did not test X11 session. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488822] New: [wayland] Broken UI for Digital Clock Text Display "Choose Style"
https://bugs.kde.org/show_bug.cgi?id=488822 Bug ID: 488822 Summary: [wayland] Broken UI for Digital Clock Text Display "Choose Style" Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Digital Clock Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: 1.0 Created attachment 170703 --> https://bugs.kde.org/attachment.cgi?id=170703=edit Screenshot of the Digitla Clock "Choose Style" dialog SUMMARY When configuring the Plasma Digital Clock widget, the UI that appears when selecting the "Choose Style" for a manual Text Display (this dialog should allow you to set and configure a font) is entirely visually broken. The UI still functions, but it is very difficult to navigate, and regardless does not look correct. This happens on Plasma 6.1.0 but also happens on Plasma 6.0.5. I am not sure if it happens on versions older than 6.0.5. STEPS TO REPRODUCE 1. Add the Digital Clock widget somewhere 2. Right click and choose "Configure Digital Clock" 3. Under "Text Display", click on the "Manual" radio button and then click on the "Choose Style..." button. OBSERVED RESULT The interface for "Choose Style" is visually broken, but it does function. EXPECTED RESULT The interface for "Choose Style" should use similar UI theming to other Plasma versions (it should probably be its own dialog?) SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.4 Linux Zen KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Unsure if this affects the Wayland session, but I confirmed this bug on two different machines running Plasma 6.0.5 and then after updating them to Plasma 6.1.0 (and rebooting). -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 464374] Ctrl+f focuses the search on the current page, but typing doesn't work
https://bugs.kde.org/show_bug.cgi?id=464374 --- Comment #13 from Eamonn Rea --- If you press Ctrl+F the searchbar will focus but no text will be entered. *However* if you click somewhere inside of the submenu, even right-click, then you will be able to enter text. If you tab into an item on the submenu, and then Ctrl+F to search, it will work correctly. But if you then right click somewhere on the left pane, and Ctrl+F, then no text will be entered. Perhaps this is an issue to do with the pane that displays the submenu contents not being focused correctly? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 488646] New: [wayland] Pressing Ctrl+F will focus search bars in System Settings, but they cannot receive text input until clicked
https://bugs.kde.org/show_bug.cgi?id=488646 Bug ID: 488646 Summary: [wayland] Pressing Ctrl+F will focus search bars in System Settings, but they cannot receive text input until clicked Classification: Applications Product: systemsettings Version: 6.0.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY Pressing Ctrl+F to focus a search bar in System Settings will visually focus that searchbar, but it cannot receive text input. The text field has to be clicked before any text can be entered. This does not visually update the field in any way, as Ctrl+F will visually focus the field but it does not accept text until clicked. STEPS TO REPRODUCE 1. Open a System Settings page with a search bar, such as Shortcuts or Desktop Effects. 2. Press Ctrl+F to focus the search bar. 3. The search bar will receive visual focus. 4. Attempt to enter text with the keyboard. 5. No text will be entered in the search bar. 6. Click on the search bar and attempt to enter some text. 7. The search field will now be able to receive text. OBSERVED RESULT Pressing Ctrl+F will visually focus the search field but it cannot receive text and so it cannot be searched. EXPECTED RESULT Pressing Ctrl+F should visually and practically focus the search field. SOFTWARE/OS VERSIONS These are the specifications of my current machine, but I have another machine with nearly identical Plasma version (both running Arch, one is just slightly further behind with the kernel but same KDE software versions) that has the same problem. Linux/KDE Plasma: 6.9.5 Linux Zen KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Unsure if this affects the X11 session. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 483155] [wayland] Spectacle Rectangle Select has Inaccurate Sizing on Multi-Screen Multi-Scale Configurations
https://bugs.kde.org/show_bug.cgi?id=483155 --- Comment #7 from Eamonn Rea --- This issue is not fixed in Spectacle 24.05.1, the resolution displayed in the box is still incorrect. This also affects another device I have running Plasma 6.0.5 and Spectacle 24.05.1. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488473] [wayland] For Native Wayland Applications, Overview Effect with Screen Edge Preserves Focus but Overview Effect with Keyboard Shortcut Partially Does Not
https://bugs.kde.org/show_bug.cgi?id=488473 --- Comment #4 from Eamonn Rea --- I noted this at the bottom of the OP but there's a lot of text so perhaps it was missed :-) > As far as I can tell, this doesn't really impact anything. This is not > something that is affecting me in any way, but I noticed it all the same. > Maybe it has implications for window behaviours/pausing (i.e. games) when > focus is lost? I have not been able to test any native Wayland games to see > which might have this sort of behaviour and if they are impacted. It is a behavioral inconsistency though that is specific to Wayland applications. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488473] [wayland] For Native Wayland Applications, Overview Effect with Screen Edge Preserves Focus but Overview Effect with Keyboard Shortcut Partially Does Not
https://bugs.kde.org/show_bug.cgi?id=488473 --- Comment #2 from Eamonn Rea --- There is some strange focusing behaviour with windows in the Overview Effect and the Application Dashboard/Launcher/Menu. This behaviour is noted on Bug 488546. I will copy and paste it here for transparency. If you focus an element of window: - Activating the Overview Effect with a Screen Edge preserves the focus (i.e. a focused YouTube search bar). - Activating the Dashboard/Launcher/Menu will un-focus the search bar on the spread windows (i.e. on YouTube, the search bar highlight will disappear and the suggested searches list will close as though you clicked off of the search bar). - Deactivating the Dashboard/Launcher/Menu (i.e. by pressing the Meta key again) will resume the focus. - Activating the Overview Effect with a Keyboard Shortcut partially unfocuses the window (i.e. on YouTube, a focused search bar will lose its focus if the Overview Effect is activated with a keyboard shortcut). - Activating the Dashboard/Launcher/Menu will at first have no effect, because the focus is lost when the effect is activated with a keyboard shortcut - Deactivating the Dashboard/Launcher/Menu (i.e. by pressing the Meta key again) will give the visual focus back, which it originally had when the effect was activated but which it *does not visually have* when the effect is activated with a keyboard shortcut -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488546] New: [wayland] Application Dashboard/Launcher/Menu can be activated with a Keyboard Shortcut while the Overview Effect is active
https://bugs.kde.org/show_bug.cgi?id=488546 Bug ID: 488546 Summary: [wayland] Application Dashboard/Launcher/Menu can be activated with a Keyboard Shortcut while the Overview Effect is active Classification: Plasma Product: kwin Version: 6.0.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-overview Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY When the Overview Effect is active, the Application Dashboard, Application Launcher, and Application Menu, can all be activated with a keyboard shortcut (in this case, the Meta key). Pressing it can open and close the Dashboard/Launcher/Menu. You can see the Dashboard/Launcher/Menu in the Virtual Desktops preview at the top of the Effect. Notably, it is **not** displayed on the window spread, just the small Virtual Desktop preview along the top (and imo this is correct behaviour, the Application Dashboard being present in the windows in the Overview Effect would be bad). Pressing Escape to cancel the effect will open the Dashboard/Launcher/Menu. For example if you were to activate the Overview Effect, press the Meta key by mistake (or whatever key you bound it to), and then press Escape to cancel the Effect, the Dashboard/Launcher/Menu would be activated. It is also worth noting that even though the Application Dashboard/Launcher/Menu doesn't appear in the spread windows, it can effect the focus behaviour of these windows (See also Bug 488473). If you focus an element of window: - Activating the Overview Effect with a Screen Edge preserves the focus (i.e. a focused YouTube search bar). - Activating the Dashboard/Launcher/Menu will un-focus the search bar on the spread windows (i.e. on YouTube, the search bar highlight will disappear and the suggested searches list will close as though you clicked off of the search bar). - Deactivating the Dashboard/Launcher/Menu (i.e. by pressing the Meta key again) will resume the focus. - Activating the Overview Effect with a Keyboard Shortcut partially unfocuses the window (i.e. on YouTube, a focused search bar will lose its focus if the Overview Effect is activated with a keyboard shortcut). - Activating the Dashboard/Launcher/Menu will at first have no effect, because the focus is lost when the effect is activated with a keyboard shortcut - Deactivating the Dashboard/Launcher/Menu (i.e. by pressing the Meta key again) will give the visual focus back, which it originally had when the effect was activated but which it *does not visually have* when the effect is activated with a keyboard shortcut STEPS TO REPRODUCE 1. Have an Application Dashboard/Launcher/Menu entry and have it bound to a keyboard shortcut 2. Activate the Overview Effect 3. Use your Application Dashboard/Launcher/Menu shortcut to activate it 4. The Application Dashboard/Launcher/Menu can be seen visually at the top of the effect in the Virtual Desktops preview row 5. Cancelling the Overview Effect with Escape will display the Application Dashboard/Launcher/Menu, just as if it were activated before the Overview Effect (but this time it is activated *during* the Overview Effect, which is undesired behaviour). OBSERVED RESULT The Application Dashboard/Launcher/Menu can be activated while the Overview Effect is active. EXPECTED RESULT It should not be possible to activate the Application Dashboard/Launcher/Menu while the Overview Effect is active. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.4 Linux Zen KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Unsure if this is specific to the Wayland session. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488473] [wayland] For Native Wayland Applications, Overview Effect with Screen Edge Preserves Focus but Overview Effect with Keyboard Shortcut Partially Does Not
https://bugs.kde.org/show_bug.cgi?id=488473 --- Comment #1 from Eamonn Rea --- I discovered today that if you activate the Overview Effect with a Screen Edge, which preserves the focus, and then type something in the Overview Effect Search bar (which hides the windows) and then remove that term (which brings the windows back), the focus behaviour will be the same as if the Overview Effect was activated with a keyboard shortcut - i.e. window has partially(?) lost focus, but deactivating the Overview Effect restores focus correctly. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 488473] New: [wayland] For Native Wayland Applications, Overview Effect with Screen Edge Preserves Focus but Overview Effect with Keyboard Shortcut Partially Does Not
https://bugs.kde.org/show_bug.cgi?id=488473 Bug ID: 488473 Summary: [wayland] For Native Wayland Applications, Overview Effect with Screen Edge Preserves Focus but Overview Effect with Keyboard Shortcut Partially Does Not Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-overview Assignee: kwin-bugs-n...@kde.org Reporter: eamonn...@protonmail.com Target Milestone: --- SUMMARY If you activate the Overview Effect using a Screen Edge, such as Top Left, the currently focused window will keep its focused state. If the Overview Effect is activated using a keyboard shortcut, such as Ctrl+W, all windows will partially lose focus. This only applies to native Wayland applications. This can be observed in different ways depending on the application. With a standard KDE application like Dolphin running with Wayland, activating the Overview Effect with a Screen Edge won't change the titlebar / windowing focus colour shade. However if activating the Overview Effect with a keyboard shortcut (like Ctrl+W), the window decoration area will keep its focused colour, but the rest of the top part of the window will change to its unfocused colour. When the Overview Effect is cancelled (such as with Ctrl+W again or Escape) then the window comes back into focus again and behaves as normal. Running Dolphin with `QT_QPA_PLATFORM=xcb dolphin` (and verifying that it is using X11 with `xeyes`) and activating the Overview effect with either a Screen Edge or a keyboard shortcut will preserve the window focus, at least visually. I state that it "partially" loses focus because I am not sure internally if focus is being given/lost, this is based on visuals. I also say partially because Firefox, which dims the text in tabs when a window is unfocused, does not dim the tab text in either Overview Effect case, but web pages will act as though focus is lost - For example the Discord website version, which pauses gifs when focus is lost, and gifs are paused when the Overview Effect is activated with a keyboard shortcut but are NOT paused when the Overview Effect is activated with a Screen Edge. Other Wayland GTK applications behave randomly. GTK applications seem to retain their titlebar focus colour, but window content (such as buttons with a tab highlight) will lose focus when the Overview Effect is activated with a keyboard shortcut but NOT when activated with a Screen Edge. Perhaps this is why Firefox window content behaves unfocused, but the tab text retains its focus, as other GTK applications retain the titlebar focus shade, and I believe Firefox is GTK-based. I am unsure if this behaviour is a regression, but it is a minor inconsistency in behaviour. STEPS TO REPRODUCE Most Wayland Applications 1. Open a Wayland native application, such as KDE Dolphin and make sure it is focused 2. Activate the Overview Effect with a Screen Edge 3. Dolphin retains its "focused" visuals 4. Close Overview Effect (i.e. with Escape) 5. Activate the Overview Effect again but this time with a keyboard shortcut 6. Dolphin's window decorations retain the focused shade, but the other parts of the window (such as the toolbar just below the window decorations) gain their unfocused shade. X11 Qt Applications 1. Open an X11 Qt application, such as KDE Dolphin but with `QT_QPA_PLATFORM=xcb dolphin` from the Terminal a. Optional: Verify that Dolphin is running under XWayland by using `xeyes` and hovering over the Dolphin window; the eyes will follow the cursor when it is over the X11 window, but not for the Wayland window. 2. Activate the Overview Effect with a Screen Edge 3. Dolphin retains its "focused" visuals 4. Close Overview Effect (i.e. with Escape) 5. Activate the Overview Effect again but this time with a keyboard shortcut 6. Dolphin still retains its "focused" visuals unlike when running with Wayland native Wayland GTK Applications 1. Open a Wayland native GTK application, such as Firefox 2. Activate the Overview Effect with a Screen Edge 3. Application retains its "focused" visuals entirely (any highlighted sections remain highlighted, titlebar does not change focus colour) 4. Close Overview Effect (i.e. with Escape) 5. Activate the Overview Effect again but this time with a keyboard shortcut 6. The window titlebar will still retain its "focused" visuals, but the window content will behave as thought is unfocused a. On Firefox for example, highlights around text areas (such as on this issue tracker) will disappear in this instance, but will remain highlighted when the Overview Effect is activated with a Screen Edge OBSERVED RESULT Wayland window focus behaviour appears to differ, at least visually, depending on whether the Overview Effect is activated using a
[Spectacle] [Bug 488234] [wayland] Single-Window Recordings Have Incorrect Resolution on Scaled Displays
https://bugs.kde.org/show_bug.cgi?id=488234 Eamonn Rea changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488233 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 488233] [wayland] Rectangle Region Recordings Have Incorrect Resolution on Scaled Displays
https://bugs.kde.org/show_bug.cgi?id=488233 Eamonn Rea changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488234 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 488234] New: [wayland] Single-Window Recordings Have Incorrect Resolution on Scaled Displays
https://bugs.kde.org/show_bug.cgi?id=488234 Bug ID: 488234 Summary: [wayland] Single-Window Recordings Have Incorrect Resolution on Scaled Displays Classification: Applications Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: eamonn...@protonmail.com CC: k...@david-redondo.de Target Milestone: --- SUMMARY Single-Window Recordings in Spectacle have an incorrect resolution. On a 3840x2160 display @ 150% scaling, a recording of a maximised window will have a resolution of roughly 2560x1440. The width will be 2560, but the height will be slightly less, probably because of the height of the panel offsetting this. This does not affect single-window recordings on non-scaled displays, only on scaled displays. The Spectacle compression means this isn't a huge issue, but it is probably not ideal behaviour. STEPS TO REPRODUCE 1. Maximise a window on a scaled display 2. Take a single-window recording 3. The resolution will be close to the scaled resolution of that display (3840 -> 2560, 2160 -> 1440). OBSERVED RESULT Single-window recordings are at the scaled resolution of the display and not the unscaled resolution. EXPECTED RESULT Single-window recordings should represent the true resolution of the window. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.9.3 Linux Zen KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION See also: Bug 488233 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 488233] New: [wayland] Rectangle Region Recordings Have Incorrect Resolution on Scaled Displays
https://bugs.kde.org/show_bug.cgi?id=488233
Bug ID: 488233
Summary: [wayland] Rectangle Region Recordings Have Incorrect
Resolution on Scaled Displays
Classification: Applications
Product: Spectacle
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: General
Assignee: noaha...@gmail.com
Reporter: eamonn...@protonmail.com
CC: k...@david-redondo.de
Target Milestone: ---
SUMMARY
Rectangle Region Recordings have incorrect resolution on scaled displays.
A region taking up most of a 3840x2160 display @ 150% scaling will have a
resolution of approximately 5,000 across by 2,800 pixels down.
Region screenshots have a very similar problem, except that affects scaled and
unscaled displays. In the case of screen recordings, the resolution is correct
for recordings on non-scaled displays.
The compression used (or default compression settings if it's configurable?)
means that the filesize and video quality are not particularly adversely
affected here, so it is not as much of an issue.
There is a similar issue with Single-Window recordings, but I will report that
separately as the resolution problem is different.
It is worth noting that single screen recordings ("Record Screen") work
correctly and use the correct resolution.
STEPS TO REPRODUCE
1. Record a Region Screenshot on a scaled display.
2. Save it.
3. The resolution will be incorrect.
OBSERVED RESULT
The resolution for Rectangle Region Recordings is incorrect.
EXPECTED RESULT
The resolution for Rectangle Region Recordings should be the same resolution as
though the Screen recording resolution were cropped down.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.9.3 Linux Zen
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1
ADDITIONAL INFORMATION
I took a look at the codebase out of curiosity. C++ is outside of my
wheelhouse, doubly so for anything specific to Qt/Wayland (although I am hoping
to learn more overtime as it is a fascination of mine!). I'm not saying I found
anything here that should be fixed, more that for my own understanding of what
the problem is I wanted to point to a few areas in the code :-)
- For Screen recordings (which call Screencasting::createOutputStream), it
looks like the native wl_output is used, which I guess returns the raw
3840x2160
(https://invent.kde.org/graphics/spectacle/-/blob/3f6c5b6c7207959221d225ea0c6d0b03c82fa16f/src/Platforms/screencasting.cpp#L101).
I guess this is why single-screen recordings work?
- For Region recordings (which calls Screencasting::createRegionStream) it
seems to use the QScreen(?) geometry which is then increased by the scaling.
However I think QScreen geometry might be returning 2560x1440 for the
width/height (which is the 150% scaled value of my 3840x2160 display), which is
then multiplied by a scale factor of 2 (instead of 1.5, possibly intentionally,
given the use of std::max
(https://invent.kde.org/graphics/spectacle/-/blob/3f6c5b6c7207959221d225ea0c6d0b03c82fa16f/src/Platforms/VideoPlatformWayland.cpp#L192)),
which would give 5120 and that would line up with my approximate 5,000x2,800
resolution (allowing for the fact that my region didn't encompass the entire
screen and had some margin on all sides).
- I guess a sub-question here if the scale factor is rounded up is, why?
Something specific to rounding pixels with fractional-scale-v1? If so, once
implemented in Qt and Plasma, could fractional-scale-v2 also fix this the same
way it can fix other issues with fractional scales? As many Wayland devs
evangelise, "screens don't have fractional pixels" so perhaps that's the
reasoning of the rounding here? I'm not saying it's wrong, you and the KDE
folks know better than me for sure, just wondering!
- For Window recordings, I'm not sure, I couldn't find how that part works (I
got as far as here:
https://invent.kde.org/graphics/spectacle/-/blob/3f6c5b6c7207959221d225ea0c6d0b03c82fa16f/src/Platforms/screencasting.cpp#L121).
Although my guess would be that it uses QScreen geometry without any scaling,
which is why a window maximised on my scaled display would give 2560x1440,
since unscaled QScreen geometry may be returning that value?
--
You are receiving this mail because:
You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Larger Resolution and Ringing Artifacts
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #18 from Eamonn Rea --- It might end up being a lot of work (as based on your description of how it currently works, it may need to be re-implemented), and should probably be a separate issue, but maybe there could be an option to only allow region screenshots on one screen at a time? This could be useful if you want to capture specifics of one screen without the risk of bleeding a few pixels into another screen. I believe macOS limits you to taking a region screenshot on one screen, but macOS also doesn't let you take a screenshot of menus and doesn't pause the display content like Spectacle does. While not pausing the window content could be one solution, having an option to locking region select to one display could be more advantageous. Primarily though, I am thinking it could help to solve our problem here of a region screenshot being a cropped "all screens" screenshot. If we could have an option to limit the region screenshot to one screen (and thus the "dimming" effect would only appear on one screen), we could avoid all of the scaling issues here if my understanding is correct, and thus avoid all of the scaling up and back down. We could capture the display with the "Current Monitor" screenshot and crop that, as that option works perfectly fine in terms of quality and resolution. Again, it's something I'd be happy to file in a separate issue, but I am asking here in case it would be a non-starter. I think the option to restrict region screenshots to a single display is not only a good way to work around this issue and give a better out-of-box behaviour, but has actual tangible benefits for making it easier to take screenshots. Having a way to limit the region screenshot to just one screen would be helpful for increasing precision especially at higher mouse sensitivities. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 487997] [wayland] Spectacle Rectangular Region Screenshots Saving Wrong Resolution and Poor Quality
https://bugs.kde.org/show_bug.cgi?id=487997 --- Comment #12 from Eamonn Rea --- I have provided four screenshots of two different scenarios to illustrate the bad quality. I recommend saving the images and zooming in using a tool such as Gwenview which doesn't filter the images. Viewing them in Firefox, at least for me, softens the images and if you zoom in they don't become pixelated. The Region Screenshots were taken on a 3840x2160 display scaled to 150%. The Current Monitor screenshots are cropped down to be close to the Region Screenshot. This is my current workaround; Current Monitor / Single Window screenshots that I crop down to a specific region. The Region Screenshot image screenshots have incorrect resolutions as well. The Current Monitor cropped screenshots have the correct resolution. - Scenario 1: YouTube Feed - Region Screenshot: Poor Quality (look around text, there is some sharpening/artifacting) - Current Monitor Screenshot: Good quality (text looks normal, image quality is either not dampened at all or it is virtually unnoticeable) - Scenario 2: Area of Panel - Region Screenshot: Poor Quality - Current Monitor Screenshot: Good quality (compare the quality of the icons in the taskbar, they have a noticeably worse quality in the Region Screenshot). -- You are receiving this mail because: You are watching all bug changes.
