[plasmashell] [Bug 480356] Panel spacing between applets becomes huge when unchecking "Fill free space on Panel" in the Task Manager settings
https://bugs.kde.org/show_bug.cgi?id=480356 --- Comment #2 from Taro Tanaka --- I'm going to submit a MR for this. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 480356] Panel spacing between applets becomes huge when unchecking "Fill free space on Panel" in the Task Manager settings
https://bugs.kde.org/show_bug.cgi?id=480356 --- Comment #1 from Taro Tanaka --- Created attachment 165236 --> https://bugs.kde.org/attachment.cgi?id=165236=edit Expected result -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 480356] New: Panel spacing between applets becomes huge when unchecking "Fill free space on Panel" in the Task Manager settings
https://bugs.kde.org/show_bug.cgi?id=480356 Bug ID: 480356 Summary: Panel spacing between applets becomes huge when unchecking "Fill free space on Panel" in the Task Manager settings Classification: Plasma Product: plasmashell Version: master Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: mkr...@gmail.com CC: niccolo.venera...@gmail.com Target Milestone: 1.0 Created attachment 165235 --> https://bugs.kde.org/attachment.cgi?id=165235=edit Huge spacing between applets in Panel STEPS TO REPRODUCE 1. Create a Default Panel. 2. Open "Icons-only Task Manager Settings" via the context menu. 3. Make sure "Fill free space on Panel" is already checked. (Otherwise you cannot reproduce this.) 4. Uncheck "Fill free space on Panel". OBSERVED RESULT Panel spacing between applets becomes huge. EXPECTED RESULT Panel has normal spacing between applets and has a big blank space at the end. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon Unstable Edition KDE Plasma Version: 6.0.80 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 472733] Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 --- Comment #15 from Taro Tanaka --- Sorry if my understanding is something wrong, but before submitting a Qt bug report/feature request for it, don't we need a consensus among KDE devs/designers? Or should the design discussion continue in a Qt bug report? Or is this already approved by the KDE side? -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 472733] Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 --- Comment #11 from Taro Tanaka --- So, I found my text-only explanation is probably not very clear and less convincing, I decided to create a comparison table with visual images: https://gist.github.com/eatsu/7db85d564fde71b3a4e3088ead3aae43 Regarding muscle memory of existing users, I'd guess it's not that hard to retrain it (given that it's pretty common today apart from KDE and Windows), but I'm not entirely sure. 路 -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 472733] Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 --- Comment #5 from Taro Tanaka --- Thank you very much for your consideration. Personally I still believe that the "Cancel/OK" button placement is obviously better from the viewpoint of UX and consistency, though. For example this article explains very well why OK buttons work best on the right, with visual images: https://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/ Particularly the three visual fixations mentioned in the article (OK->Cancel->OK) are quite annoying to me, which I don't experience on other platforms. > as long as you're internally consistent--which we are. Personally I always feel that the current button placement is inconsistent with OK-only dialogs, as I argued in my original post. I understand that Plasma may be getting more people migrating from Windows than other platforms, and my proposal may break the expectations of the majority of them. However, on the other hand, I think many people will be using iPhone/Android along with Plasma. I don't know how many people will use Windows along with Plasma, but I'd guess less than the former. Also many websites follow the iPhone/Android convention for a reason. So I'm a bit doubtful if this proposal will really break the expectations of the majority of them, to be honest. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 472733] Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 --- Comment #3 from Taro Tanaka --- (In reply to Tobias Fella from comment #2) > Please do not try to convice us to do something by telling us what ChatGPT > thinks is a good idea. Sorry, I thought the reasons are interesting and might be worth sharing for your reference. I don't intend to tell something like "ChatGPT thinks it's better, so you should do this"... -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 472733] Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 --- Comment #1 from Taro Tanaka --- FWIW, I asked ChatGPT "OK button v.s. Cancel button; which should be on the bottom right corner in dialogs?" and here's the answer: --- START QUOTE --- Traditionally, in dialog boxes or user interfaces, the "OK" button is placed on the bottom right corner, while the "Cancel" button is placed next to it, on the left. This convention has been followed in many operating systems and applications for several reasons: 1. Visual Hierarchy: Placing the primary action (usually "OK" or "Confirm") on the right side draws attention and emphasizes it as the default or preferred choice. 2. Reading Order: In cultures that read from left to right, the natural flow of reading moves from left to right and top to bottom. Placing the "OK" button on the bottom right aligns with this reading pattern. 3. User Expectations: Users have become accustomed to this layout over time, making it a familiar and predictable pattern across various applications. Deviating from this convention might lead to confusion and an inconsistent user experience. 4. Accessibility: It is essential to consider the needs of users with disabilities. Placing the primary action button on the bottom right ensures that users who navigate through the interface using keyboard controls can easily find and activate the main action. However, it's important to note that design conventions can evolve over time, and different user interfaces or platforms may adapt to newer layouts. Always consider the specific context, user base, and platform guidelines when designing dialog boxes or any other user interface components. If you are designing for a specific platform or application, it's a good idea to review their design guidelines and recommendations for button placement to ensure your design aligns with their conventions and provides the best user experience. --- END QUOTE --- -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 472733] New: Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons
https://bugs.kde.org/show_bug.cgi?id=472733 Bug ID: 472733 Summary: Plasma 6 proposal: Swap the placement of the "OK" and "Cancel" buttons Classification: I don't know Product: kde Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: mkr...@gmail.com Target Milestone: --- The OK button can also be "Open", "Select", "Delete", etc, but let's say they are OK buttons. Rationale: - Having an OK button in the window corner makes it easy to see that it is a primary button. - In many dialogs the OK button is highlighted with an accent color. Visually, IMHO it looks better if the highlighted button were in the window corner. - Some dialogs have an OK button but no Cancel button (e.g. KCMs, "About" screen in plasmoid settings windows). Always placing the OK button in the bottom right corner will be consistent with those dialogs. - In dialogs with "Next" and "Back" buttons (e.g. plasma-welcome), the Next button (approximately OK button) is placed on the right and the Back button (approximately Cancel button) is placed on the left. This proposal matches those dialogs as well. (Rightmost buttons are primary.) - GTK, Chromium and Firefox have adopted it. Matching the basic UI layout with those popular third-party apps improves the user experience. - Other systems like Material Design, Android, iOS, macOS and GNOME have adopted it. So it's easier to use for people who are familiar with them. (I'm not sure about Microsoft's Fluent Design though. Looking at their doc, OK buttons may be placed leftmost, rightmost, or neither.) - I'm sorry if this is not the right place to report. I'm unsure if a normal user like me could file this to the plasma-desktop repo directly... -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 469169] New: Allow placing the new tab button on the right side of the tabs
https://bugs.kde.org/show_bug.cgi?id=469169 Bug ID: 469169 Summary: Allow placing the new tab button on the right side of the tabs Classification: Applications Product: konsole Version: 23.04.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: tabbar Assignee: konsole-de...@kde.org Reporter: mkr...@gmail.com Target Milestone: --- Created attachment 158552 --> https://bugs.kde.org/attachment.cgi?id=158552=edit Desired position of the new tab button It would be nice if we could place the new tab button on the right side of the tabs. To me it's much more intuitive, convenient and makes sense to have the new tab button on the right, because new tabs appear on the right, not the left. Also, most applications nowadays (e.g. Firefox, Google Chrome, Windows Terminal, macOS Terminal, etc.) place the new tab button on the right, so it would be familiar to many people. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 468454] New: Allow switching virtual desktops with mouse wheel on Panel Spacer
https://bugs.kde.org/show_bug.cgi?id=468454 Bug ID: 468454 Summary: Allow switching virtual desktops with mouse wheel on Panel Spacer Classification: Plasma Product: plasmashell Version: 5.27.4 Platform: Archlinux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Panel Spacer Assignee: plasma-b...@kde.org Reporter: mkr...@gmail.com Target Milestone: 1.0 SUMMARY On the desktop wallpaper we can switch virtual desktops with mouse wheel. However, if you have maximized/tiled windows open, you need to close, minimize or move them to use the functionality. To quickly and easily switch virtual desktops only with mouse without any additional operation, it would be great to have the same functionality in the Panel Spacer. I know I can achieve this with Pager, but I'd like to avoid using it because: 1. It's visually cluttered and distracting to me. 2. Unlike Spacer, its width is not flexible, so the mouse target can be narrow, requiring more mouse movement. 3. I have vertically aligned virtual desktops, so it makes problem 2 even worse. STEPS TO REPRODUCE Scroll the mouse wheel over an empty space in the panel. OBSERVED RESULT Nothing happens. EXPECTED RESULT Switch virtual desktops. SOFTWARE/OS VERSIONS Linux Version: 6.2.9-arch1-1 (64-bit) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 -- You are receiving this mail because: You are watching all bug changes.
