[kwin] [Bug 464950] Implement option to disable 5.27 tiling features
https://bugs.kde.org/show_bug.cgi?id=464950 Grady changed: What|Removed |Added CC||mindinsom...@gmail.com --- Comment #7 from Grady --- Created attachment 157587 --> https://bugs.kde.org/attachment.cgi?id=157587=edit Demostration of UX issue I've attached a GIF that attempts to illustrate why this is a UX issue for some users. In short, the assumption is being made that if two windows are adjacent and sharing a boundary, that it's automatic for resizing one window to automatically resize the other. But that isn't always what users want. See the gif for an example. A solution to this might be to either have an option to disable this assumption, or an option to have this assumption only applied while holding down a hotkey for example (shift/ctrl/etc) while resizing a window. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #14 from Grady --- This might be something to take another look at now given there's been a recent change in how KDE handles multiple monitors that may impact what has been discussed here: Information about the changes here: https://notmart.org/blog/2022/12/multi-screen/ And here: https://pointieststick.com/2022/12/16/this-week-in-kde-wayland-fractional-scaling-oh-and-we-also-fixed-multi-screen/ Quoting pointiestick.com blog post: > Fixing Multi-Screen > > Multi-screen is a complicated beast because it touches so many parts of the > software stack. Ultimately most of our problems arose from the use of > connector IDs to identify screens and map Plasma desktops and panels > (“containments”) to screens. This worked poorly, because connector IDs can > and do change under various circumstances. As a result, things often became a > scrambled mess, with the behavior either being random, or consistently wrong. > > That’s all changed. You can read the details here. In a nutshell, we now use > an index-based system, with index numbers bound very tightly to Plasma > containments, but index numbers themselves being able to move between screens > based on how many screens there are. So for example, when screen 1 with your > Plasma desktop and panel becomes unavailable, a new screen becomes screen 1, > and the Plasma desktop and panel bound move over to it. > > This new system should result in vastly greater stability, reliability, and > predictability with respect to how screens are enabled and disabled, > positioned, and what Plasma desktops and panels they show. It fixes notorious > bugs like Plasma containments being randomly moved around or lost and > desktops sometimes losing their wallpapers, widgets, and icon settings. It > also makes arrangements of screen layouts and Plasma containments stable > across the Plasma X11 and Wayland sessions. Big stuff. And quoting the notmart.org blog post: > We have a new Wayland protocol for screen ordering (as well an X11 > counterpart) for KScreen and KWin to agree to which one is the real logical > ordering of the screens, so Plasmashell will now follow this without > attempting to identify monitors by itself, removing a very big failure point. This sounds like it would fix the issue which was described by Meven of not having a consistent method of identifying which monitor is which. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #13 from Grady --- I attached a mockup of what I'm referring to, this would be a purely GUI thing, would have zero impact on system settings or the actual stored names of the monitors, just an additional text label in the GUI next to each monitor's name, with a number. If you like for visual pleasantness, could make the numbers based on the monitor positions sorted from left to right and top to bottom. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #12 from Grady --- Created attachment 153537 --> https://bugs.kde.org/attachment.cgi?id=153537=edit Mockup of change Mockup of proposed change -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #11 from Grady --- (In reply to Méven from comment #10) > (In reply to Grady from comment #9) > > (In reply to Méven from comment #8) > > > > > > IIRC The problem with X11 is the ordering is not deterministic accross > > > reboots, we simply can't use it. > > > > Thanks for the feedback. > > > > Just a suggestion but is it strictly necessary for the ordering to be > > deterministic across reboots? > > It is mandatory, if not for the UI, it is for the screen settings and plasma > (widgets). Right that's what I mean, this wouldn't be for the screen settings or impact the plasma widgets. I mean just using the numbers purely 100% as just a minor visual adjustment of the GUI of the display settings, just literally adding a number to the names of the monitors in the dropdown UI component and using that name for the displayed monitor name on screen. So that would have no impact on screen settings, shouldn't that be possible? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #9 from Grady --- (In reply to Méven from comment #8) > > IIRC The problem with X11 is the ordering is not deterministic accross > reboots, we simply can't use it. Thanks for the feedback. Just a suggestion but is it strictly necessary for the ordering to be deterministic across reboots? I'm thinking from the perspective of the numbers only being added to the GUI at runtime, not stored or saved with the configuration itself, so the numbers would have no impact on the actual display configuration. So another words it's a purely GUI thing, definitely not stored with the monitor configuration at all so it would have no impact on the order of the monitors for configuration. >From the user's perspective, all the "Identify" button needs to achieve is helping us identify which monitors physically in front of us correspond to the monitors in the dropdown list or laid out in the 2D representation of the screen configuration. So even if the numbers change between reboots, as long as they remain consistent while we're looking at them, that's perfectly fine from my perspective as a user and definitely an improvement. If the choice is between 'no means of telling which monitor is which' and 'having numbers that are not consistent between reboots', I'd say having numbers that are not consistent between reboots would be preferred. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #7 from Grady --- Also, just another idea, another option would be to append the name of the port the monitors are connected to. onto the name of the monitor being displayed. That's what Linux Mint seems to do with it's display settings. So when there are multiple monitors, they also show the port names, 'HDMI-0', 'HDMI-1', 'HDMI-2', etc. That would resolve the issue. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 419494] "Identify" feature does not work properly with identically-named displays
https://bugs.kde.org/show_bug.cgi?id=419494 --- Comment #6 from Grady --- (In reply to David Edmundson from comment #1) > For X this is not fixable, for wayland we may have an option Would it be possible to simply append numbers onto the names of monitors in the order they are gathered from the OS for X? I don't know where you're getting the information from for the monitor names, but I assume there's some kind of query being made, and an array of strings is being returned or objects with string properties, maybe just append the array index value onto the string? With a +1 so it starts at 1 instead of 0. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 461199] New: Got a funny one: Identify monitors feature is unhelpful when all monitors are of an identical brand and model!
https://bugs.kde.org/show_bug.cgi?id=461199 Bug ID: 461199 Summary: Got a funny one: Identify monitors feature is unhelpful when all monitors are of an identical brand and model! Classification: Applications Product: systemsettings Version: 5.25.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_kscreen Assignee: kscreen-bugs-n...@kde.org Reporter: mindinsom...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- Created attachment 153319 --> https://bugs.kde.org/attachment.cgi?id=153319=edit This did not help identify anything lol SUMMARY Right now the Identify button in the Display Configuration settings UI is not very helpful in a situation where a user has monitors that are of identical brand and model. Because the Identify button will display a text box across all monitors displaying the device ID of each monitor... ... which means, when all the monitors are of identical make and model, all monitors will display the same text. Which doesn't help the user much in identifying which monitor in the dropdown list/layout window is which. :D I attached an image of an example, my own three monitor setup, where I have three monitors all of identical make and model and the text that displays on each screen. STEPS TO REPRODUCE 1. Have 2 or more monitors of identical make and model. 2. Click Identify in the Display Configuration UI OBSERVED RESULT On my three monitor setup? Three labels with identical text on each monitor! EXPECTED RESULT Numbers would be nice. SOFTWARE/OS VERSIONS OS: Manjaro Kernel: 5.15.74-4-MANJARO KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION I don't know -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 169405] Save icon size per-directory
https://bugs.kde.org/show_bug.cgi?id=169405 --- Comment #20 from Grady --- Just adding a further comment: Dolphin already has the capacity to save per directory settings for view, for example this is what one .directory file looks like for me: [Dolphin] SortOrder=1 SortRole=modificationtime Timestamp=2021,9,2,11,42,1.22 Version=4 [Settings] HiddenFilesShown=true All that would need to be added is some value like 'Zoom' with the pixel zoom level, eg: Zoom=64 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 169405] Save icon size per-directory
https://bugs.kde.org/show_bug.cgi?id=169405 Grady changed: What|Removed |Added CC||mindinsom...@gmail.com --- Comment #19 from Grady --- I'd like to add myself to the list of folks who would like this. To give an example of a user case. I'm a graphic designer. I have some folders with photos and 3D renders, which I would like very large thumbnail icons for so I can see at a glance what is in them when selecting a file. I have other folders with SVG icons I use for UI design, and I don't need those to have 256x256 resolution thumbnails. I find myself almost constantly changing the zoom level with every folder, and changing it to the same sizes for each folders because the zoom level isn't remembered. At least an option to save zoom level per folder would drastically improve my experience using Dolphin. -- You are receiving this mail because: You are watching all bug changes.
