[Kalk] [Bug 487763] New: Ability to customise text colours/weight.
https://bugs.kde.org/show_bug.cgi?id=487763 Bug ID: 487763 Summary: Ability to customise text colours/weight. Classification: Applications Product: Kalk Version: 24.05.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: hanyo...@protonmail.com Reporter: typing...@gmail.com CC: espi...@gmail.com Target Milestone: --- SUMMARY It seems that currently, the user input is using the text hint colour (normally a dim colour) and the output is using the default text colour. But this, in my opinion, makes it difficult to see the input whilst typing numbers. Wouldn't it make more sense just use the same text colour or the input and maybe use bold font for the output? Also, the operators (+, -, C, etc) are dim. At first I thought they were disabled. I don't know why they are dim. Maybe other people have different opinions what are the best colours, so maybe the best way is just allowing users to customise the colour and font weight of the following texts: 1. Input 2. Output 3. Operators SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch, Wayland, 6.9.2-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 -- You are receiving this mail because: You are watching all bug changes.
[Arianna] [Bug 488128] New: Font setting is not saved.
https://bugs.kde.org/show_bug.cgi?id=488128 Bug ID: 488128 Summary: Font setting is not saved. Classification: Applications Product: Arianna Version: 24.05.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: c...@carlschwan.eu Reporter: typing...@gmail.com Target Milestone: --- SUMMARY Font setting is not stored. STEPS TO REPRODUCE 1. Click Settings 2. Click change default font 3. Change font settings 4. Click OK. 5. Close Settings. 6. Click Settings 7. Click change default font OBSERVED RESULT It shows the initial font before user's change. EXPECTED RESULT User's changed font settings are preserved. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.9.3-arch1-1 ( (available in About System) KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485771] Desktop icons disappear after icon update (including the trash icon)
https://bugs.kde.org/show_bug.cgi?id=485771 --- Comment #18 from Sin Jeong-hun --- Version fixed in "6.4"? Is that correct? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 485529] New: Support a shortcut for toggling the legacy applications scaling mode
https://bugs.kde.org/show_bug.cgi?id=485529 Bug ID: 485529 Summary: Support a shortcut for toggling the legacy applications scaling mode Classification: Applications Product: systemsettings Version: 6.0.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_kscreen Assignee: kscreen-bugs-n...@kde.org Reporter: typing...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- I need both "Apply scaling themselves" and "Scaled by the system", depending on the X11 app I am using. Some more recent X11 apps, such as Android Studio or VS Code, support scaling themselves, but a lot of older X11 apps, such as Qt5-based ones, do not support self-scaling. I have tried `export QT_SCALE_FACTOR`, but the mouse pointer pointed wrong items when trying to click a submenu of their main menu, and the window content was not painted correctly (they were blank until I resized or moved mouse over them), so QT scaling was not very useable. It's inconvenient and time-consuming to repeatedly open the Display Configuration and change it every time. I wish that toggling this setting was possible with a system-wide shortcut (Input & Output -> Keyboard -> Shortcuts -> System Settings). -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 485753] New: Brightness up/down keys' steps could be smaller in low value range
https://bugs.kde.org/show_bug.cgi?id=485753 Bug ID: 485753 Summary: Brightness up/down keys' steps could be smaller in low value range Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- In Plasma Desktop 6.0, pressing the brightness key changes the brightness level by 5% each. The problem is that in a dark environment, when the monitor's brightness is very low, 5% is too big of a step. In the low brightness range, even 1% change makes a noticeable difference. That is, something like 0% is too dark but 5% is a bit too bright. I can use the mouse, click the brightness icon on the system notification, and drag the slider to set values like 3%, but pressing the keys is more convenient. So, I wonder what if pressing the brightness keys changes the value by 1%, if the current monitor brightness is below 5% or 1-digit. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485986] New: Resizing a drag-detached-from-maximised GTK window acts weirdly.
https://bugs.kde.org/show_bug.cgi?id=485986 Bug ID: 485986 Summary: Resizing a drag-detached-from-maximised GTK window acts weirdly. Classification: Plasma Product: kwin Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: typing...@gmail.com Target Milestone: --- SUMMARY If a GTK window (happens with FireFox or Gnome Web) started maximised mode, and I drag down the title bar to make the window unmaximised, release the mouse,and then try to resize the window at the top-left/top-right corners, it seems that the window's x,y positions get inverted. STEPS TO REPRODUCE 1. Start Firefox or Gnome Web. Maximise its window, then close it. 2. Start the app again. The app starts with the window maximised. 3. Click the title bar (the thick empty area on the top of the window) and drag it down until it becomes an unmaximised window. Release the mouse button. 4. Try to resize the window on the top-left/top-right corners. OBSERVED RESULT Window jumps to up/left side. EXPECTED RESULT Window stays where it is and the size gets resized. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.7-arch1-1 (64-bit), Wayland (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 485986] Resizing a drag-detached-from-maximised GTK window acts weirdly.
https://bugs.kde.org/show_bug.cgi?id=485986 --- Comment #1 from Sin Jeong-hun --- Created attachment 168823 --> https://bugs.kde.org/attachment.cgi?id=168823&action=edit screen recording I thought it was GTK window thing, but it happens with QT6 apps, too, like KWrite. See the screen recording. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 486047] New: ".desktop" shorts randomly disappear from the desktop
https://bugs.kde.org/show_bug.cgi?id=486047 Bug ID: 486047 Summary: ".desktop" shorts randomly disappear from the desktop Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- SUMMARY Especially the trash.desktop keeps disappearing, but I have seen another .desktop entry that I manually created disappearing from the desktop. The .desktop files are there, but just don't show up on the Desktop. Deleting the file using Dolphin and undoing it (ctrl + Z) makes it reappear on the desktop. STEPS TO REPRODUCE 1. Create trash.desktop ( like in ADDITIONAL INFORMATION below) 2. Use your computer for a while 3. OBSERVED RESULT Randomly trash.desktop disappears from the desktop. EXPECTED RESULT No such thing. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.7-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION The content of "trash.desktop" [Desktop Entry] Name=Trash Comment=Contains removed files Icon=user-trash-full EmptyIcon=user-trash Type=Link URL=trash:/ OnlyShowIn=KDE; -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485811] The Trash disappears from the desktop after being emptied and until plasmashell restart
https://bugs.kde.org/show_bug.cgi?id=485811 Sin Jeong-hun changed: What|Removed |Added CC||typing...@gmail.com --- Comment #5 from Sin Jeong-hun --- I reported this https://bugs.kde.org/show_bug.cgi?id=486047 and it may be a duplicate of this issue, but in my case, I saw other .desktop shortcut that I created with a text editor and placed on the desktop disappearing just like the trash.desktop. Does this happen to you. In any case of disappeared .desktop, I could make it reappear by opening a file manager, go to ~/desktop, delete the .desktop files, and undo the deletion. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486319] New: Keep above other windows, only when in it's a normal window
https://bugs.kde.org/show_bug.cgi?id=486319 Bug ID: 486319 Summary: Keep above other windows, only when in it's a normal window Classification: Applications Product: systemsettings Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_kwinrules Assignee: kwin-bugs-n...@kde.org Reporter: typing...@gmail.com CC: isma...@gmail.com, plasma-b...@kde.org Target Milestone: --- SUMMARY There currently is the "keep above other windows" property, it's useful for cases like you want to watch a video in a small window whilst doing other things. The problem is that if you set "keep above other windows" on an app, it remains always-on-top, even if you maximise the window or enter full-screen mode. When the app's window is maximised or full-screen, the always-on-top property is no longer useful and causes more inconveniences (e.g., can't temporarily see another window without minimising the always-on-top window). So, it would be helpful if there is another property "keep above other windows in window mode". This property keeps the window always-on-top, when the window is a normal (not maximised, not full-screen) window. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 429067] Dolphin does not return the path of the locally mounted network drive through kio-fuse during drag and drop
https://bugs.kde.org/show_bug.cgi?id=429067 Sin Jeong-hun changed: What|Removed |Added CC||typing...@gmail.com --- Comment #3 from Sin Jeong-hun --- Is this a bug or an enhancement? Because, I think the fix would be simple, and yet it's 4-years old. If I open an SMB shared directory and double-click a video file, MPV plays it fine, because Dolphin passes a converted local address to MPV. But if I drag-and-drop the same file to the same MPV, MPV crashes, because Dolphin passes the raw "smb://" address. Then, can't this be solved by passing the same converted local address for drag-and-drop, too? Why pass different addresses depending on double-click or drag-and-dropping? If for some historical backward-compatibility reason, drag-and-drop needs to remain raw network address, how about having an option in the Dolphin's configuration? It could allow users to choose whether to use converted local address or the raw network address for drag-and-drop. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486363] New: Applying a view mode to future subdirectories
https://bugs.kde.org/show_bug.cgi?id=486363 Bug ID: 486363 Summary: Applying a view mode to future subdirectories Classification: Applications Product: dolphin Version: 24.02.2 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: typing...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY I want to use the Details View mode by default, but use different view modes for some special directories. For this, I have set Configure -> View -> Remember display style for each folder. If I want to set a different view mode to directory and all its descendant directories, I can check View -> Adjust View Display Style -> Apply to -> Current folder and sub-folders. The problem is that this only applies to currently-existing descendant directories. If I create a new subdirectory, it uses the default view mode. I thought checking "Use as default view settings" would apply to only the descendants to the current directory, but it applied to all directories, so that was not it. This is inconvenient. For example, suppose that you set the Icon view mode to the Pictures directory. Whenever you create a new sub-directory to hold a group of pictures, you have to change the view mode again and again. On Microsoft Windows, if I set Properties -> Customise -> Optimise this folder for -> Also apply the template to all subfolders, it automatically gets applied to any newly-created descendant directory. I wish there was a way to apply a view mode to all its current and future descendant directories. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486376] New: When system shortcuts are linked files, copy the source shortcuts, not the link files.
https://bugs.kde.org/show_bug.cgi?id=486376 Bug ID: 486376 Summary: When system shortcuts are linked files, copy the source shortcuts, not the link files. Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 Created attachment 169057 --> https://bugs.kde.org/attachment.cgi?id=169057&action=edit libre system shortcuts SUMMARY I tried to modify LibreOffice Writer shortcut (adding environment), but it showed permission error. "Could not save properties due to insufficient access to: /home/me/.local/share/applications/libre...desktop". That was weird, because it is under my home directory. I wend to that directory, and found that the .desktop file's owner is "root". It seems that LibreOffice shortcuts in "/usr/share/applications/" are, unlike others, linked files to "/usr/lib/libreoffice/share/xdg/desktop", and Kickoff copies the link file to user's directory, not the source file of the file, which means that the copied link file in the user's directory points to the shortcut in the system directory that is owned by "root". It should copy the original ".desktop" file to the user's directory, not the link. STEPS TO REPRODUCE 1. Arch Linux, install libreoffice-fresh from the "extra" repository. 2. In the menu, right click Writer, and try to change it and save it. 3. OBSERVED RESULT Could not save properties due to insufficient access EXPECTED RESULT Save a copy in the local "applications" directory. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.8 (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 486047] ".desktop" shorts randomly disappear from the desktop
https://bugs.kde.org/show_bug.cgi?id=486047 Sin Jeong-hun changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Sin Jeong-hun --- *** This bug has been marked as a duplicate of bug 485811 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485811] The Trash disappears from the desktop after being emptied and until plasmashell restart
https://bugs.kde.org/show_bug.cgi?id=485811 --- Comment #8 from Sin Jeong-hun --- *** Bug 486047 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485811] The Trash disappears from the desktop after being emptied and until plasmashell restart
https://bugs.kde.org/show_bug.cgi?id=485811 --- Comment #9 from Sin Jeong-hun --- I thought it was random but it seems that, in my case, whenever I delete a file by drag-and-dropping a file into the Trash icon, whether the Trash was empty or not. I have also trying setting the same icon for both full/empty, but that made no difference. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485811] The Trash disappears from the desktop after being emptied and until plasmashell restart
https://bugs.kde.org/show_bug.cgi?id=485811 --- Comment #10 from Sin Jeong-hun --- In Bug 486047, I said other ".desktop"'s also disappearing, and I think now I can reproduce it 100%. It seems that whenever a ".desktop" file is modified, it disappears. For example, if I copy Dolphin's ".desktop" from "/usr/share/applications/" to the desktop, right-click and click "Properties", in the "Applications" tab, in the empty "Comment" field, if I type "1" and click "OK", Dolphin's icon disappears from the desktop. The Trash icon disappear when deleting a file, probably because that internally changes the ".desktop" files property somehow. Also, another workaround to get it back, other than deleting & undoing, is just renaming the ".desktop" file in Dolphin. The desktop uses the name in the properties, not the file name, so it doesn't matter what the file name is. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486606] New: Option to disable renaming by clicking selected file's name
https://bugs.kde.org/show_bug.cgi?id=486606 Bug ID: 486606 Summary: Option to disable renaming by clicking selected file's name Classification: Applications Product: dolphin Version: 24.02.2 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: view-engine: details mode Assignee: dolphin-bugs-n...@kde.org Reporter: typing...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY I wish there is an option to disable by clicking selected file's name. I don't need to edit file names that often, and it is too often executed by a mistake. I can rename files using the easy shortcut F2, so I do not need this renaming by clicking the name, but I could not find any option to disable it. STEPS TO REPRODUCE 1. In details view mode 2. Select a file by clicking the file name once. 3. Click the file name once again. OBSERVED RESULT Renaming starts. EXPECTED RESULT I wish I could disable this. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486647] New: Can't turn on/off Night Light with shortcut when Night Light is "Always Off".
https://bugs.kde.org/show_bug.cgi?id=486647 Bug ID: 486647 Summary: Can't turn on/off Night Light with shortcut when Night Light is "Always Off". Classification: Applications Product: systemsettings Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_keys Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: k...@david-redondo.de Target Milestone: --- SUMMARY Time-based NL activation is useless to me, because I do not need it based on time. So, I only want manual control. That is manually turning NL on/off as I need. There are 5 options in the NL settings, but other than "Always Off", all other options turn NL on automatically. But if I have chosen "Always Off", pressing the shortcut in System Settings -> KWin -> Toggle NL only shows "NL on/off" message and doesn't actually enable/disable NL. I wish I could turn NL on/off manually using the shortcut. STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 484952] New: "Window Background" value lower than 24 makes the background of list brighter
https://bugs.kde.org/show_bug.cgi?id=484952 Bug ID: 484952 Summary: "Window Background" value lower than 24 makes the background of list brighter Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 168076 --> https://bugs.kde.org/attachment.cgi?id=168076&action=edit screenshot SUMMARY When the "Window Background" colour is lower than 25 (each of RGB), list item's background gets brighter, making it almost impossible to read the text. STEPS TO REPRODUCE 1. Go to System Settings -> Colours. Create a copy of "Breeze Dark". Click the edit button and change the Window Background value to 24 (#191919) 2. Open Discover -> Settings. 3. OBSERVED RESULT For values higher than 25, the background colour is darker than the text. But for values lower than 25, the background colour gets brighter. EXPECTED RESULT The background of list get darker, not brighter. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch (available in About System) KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 485095] New: Feature Request: A way to close all when tasks are not grouped.
https://bugs.kde.org/show_bug.cgi?id=485095 Bug ID: 485095 Summary: Feature Request: A way to close all when tasks are not grouped. Classification: Plasma Product: plasmashell Version: 6.0.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: qydwhotm...@gmail.com Target Milestone: 1.0 When the tasks are grouped, due to lack of space, I can right-click and choose "Close All". But if there is enough space, and there are multiple windows of the same app, I have to close them one by one. I wish there is a way to close them all even when not grouped. For example, if there are ungrouped 4 Dolphin tasks on the task bar, clicking "Close" on the context menu with the middle-mouse button, not with the left-button, could close all 4 Dolphin windows at once. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 485114] New: Feature Request: Ability to set source precedence
https://bugs.kde.org/show_bug.cgi?id=485114 Bug ID: 485114 Summary: Feature Request: Ability to set source precedence Classification: Applications Product: Discover Version: 6.0.3 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: aleix...@kde.org Target Milestone: --- I have multiple Flatpak sources, because I added "Flatpak beta" to use a certain application. But other than that, I prefer the main "Flatpak". In Discover's Settings, I placed "Flatpak" higher than "Flatpak beta", but Discover shows "Flatpak beta" by default when the app is available in both "Flatpak" and "Flatpak beta", for example, Development Tools -> Godot. It shows a warning that "A more stable version is available. " and I have to switch the source to "Flatpak" at the top-right corner. Shouldn't the user be able to set the precedence of sources? I think most users would want "Flatpak" the default instead of "Flatpak beta". -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 485115] New: Finicky to drag-and-drop to Trash (Waste bin) on the Desktop.
https://bugs.kde.org/show_bug.cgi?id=485115 Bug ID: 485115 Summary: Finicky to drag-and-drop to Trash (Waste bin) on the Desktop. Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 168206 --> https://bugs.kde.org/attachment.cgi?id=168206&action=edit screen recording of the problem SUMMARY When trying to drag-and-drop (d&d) a file onto the Trash, an arrow quickly flashes on the top-left. If the drop-location is not exact, it just moves the file. If that arrow means "You're trashing the file, not moving it near the Trash", then the feedback should be more obvious (e.g., on XFCE, the whole Trash icon gets illuminated) and stable. Even when trashing succeeds, the d&d animation is wrong (the file goes back to where it was, as if d&d was failed), so I cannot instantly know if d&d failed or not; I have to wait and see if the file icon disappears after it returned to the original position. STEPS TO REPRODUCE 1. Create a desktop entry for Trash by using [Desktop Entry] to URL=trash:/. 2. Try d&d a file. 3. OBSERVED RESULT As described in summary. EXPECTED RESULT Should work like the Trash of Windows or XFCE. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch (available in About System) KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 ADDITIONAL INFORMATION Please see the attached screen recording -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 485292] New: Battery widget on the task bar: Option for text-only.
https://bugs.kde.org/show_bug.cgi?id=485292 Bug ID: 485292 Summary: Battery widget on the task bar: Option for text-only. Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 168315 --> https://bugs.kde.org/attachment.cgi?id=168315&action=edit screenshot **The problem** Gnome and Android have the option to show the battery percentage on the status bar, but they are displayed alongside the battery icon. The in-built battery widget on Plasma, however, shows the percentage ON the battery icon. The problem is that that number is almost illegible, if I set the task bar thin (see the attached screenshot) to save the screen space of the small laptop display. Battery is mostly only present on laptops, and laptops usually have small displays, so probably a lot of people use thinner task bar on laptops. **Possible solutions** (1) Option for text-only: I don't need the icon; I mostly only need to see the percentage. The battery icon is not reliable because it varies by the theme. The practical functionality of the battery icon does can be easily substituted with the colour of the percentage text. For example, the text could be white normally, but red when the battery is low, and yellow when the battery is being charged. (2) Just display the percentage number alongside the battery icon ,like Gnome or Android do. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 485292] Battery widget on the task bar: Option for text-only.
https://bugs.kde.org/show_bug.cgi?id=485292 Sin Jeong-hun changed: What|Removed |Added Attachment #168315|0 |1 is obsolete|| --- Comment #1 from Sin Jeong-hun --- Comment on attachment 168315 --> https://bugs.kde.org/attachment.cgi?id=168315 screenshot wrong file. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 485292] Battery widget on the task bar: Option for text-only.
https://bugs.kde.org/show_bug.cgi?id=485292 --- Comment #2 from Sin Jeong-hun --- Created attachment 168316 --> https://bugs.kde.org/attachment.cgi?id=168316&action=edit screenshot -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486647] Can't turn on/off Night Light with shortcut when Night Light is "Always Off".
https://bugs.kde.org/show_bug.cgi?id=486647 --- Comment #2 from Sin Jeong-hun --- (In reply to Nate Graham from comment #1) > "Always Off" in fact means the feature is disabled entirely. The way to > achieve your desired usage mode is to turn it on and then you can use the > shortcuts to disable or enable it as needed. > > Did I get that right, Natalie? Actually, I had tried that but even when I "turned it off" NL with the shortcut, every time I rebooted, NL was turned on by default. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 486647] No way to turn off and on night light manually persistent across reboots
https://bugs.kde.org/show_bug.cgi?id=486647 --- Comment #7 from Sin Jeong-hun --- I need NL depending on the ambient light and the content I am seeing, not on the time of the day. That is, at the same 10 PM, if the room is bright and I am watching a video, I don't need NL. But if the room is dark and I am reading text, then NL is useful because it reduces the perceived brightness lower than the lowest screen brightness (i.e., many screens lowest brightness is not low enough). In my opinion, the current NL option seems unnecessarily confusing. On Android, I could set "Schedule" to "None", and use the "Use NL" toggle or a Quick Settings toggle to turn it on/off arbitrarily, and if I turn it on/off, it stays in that state even I reboot the phone. Of course, a phone doesn't reboot often, unlike a rolling Linux like Arch. I don't remember exactly, but I think Windows 10 probably also worked like this. Simple on/off without automatic scheduling. The thing I did was setting Plasma's NL to "Always on" (because with "Always off", the shortcut did not work) and used the shortcut to turn it off/on, but the state was not remembered and when I rebooted the PC in a bright room, NL got automatically turned on at the next login. Of course, all I had to do was pressing the shortcut to turn it off, but I thought it was annoying. So, what I think is, any of the following change could be helpful to people who want only manual control, without automatic anything. (1) When NL is set to "Always off", pressing the NL shortcut change it to "Always on", and when it is set to "Always off", the shortcut changes it to "Always off". (2) NL "Switching times" can have a new entry "Manual". The shortcut turns it on/off, and it persists after reboot. (3) When NL is set to "Always on", and the user pressed the NL shortcut to turn it off, the off state persists after reboot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 482185] Context menu (when right-clicking on the desktop) appears in a separate window after external monitor restart
https://bugs.kde.org/show_bug.cgi?id=482185
Sin Jeong-hun changed:
What|Removed |Added
CC||typing...@gmail.com
--- Comment #16 from Sin Jeong-hun ---
This problem is not because of external/dual monitors. This happens when the
context menu has no parent and you right click the widget when its parent
window is not focused. I know this because I recently wrote a simple PySide6
myself and had this exact same problem, and after spending a lot of time, I
discovered the reason.
So, this problem can be reproduced in the say way in Plasma desktop. Open any
window (not maximised) and click to focus that window. Then, directly
right-click the desktop. Since the desktop (desktop context menu's parent) is
not focused, it's opened as a pop-up. This also happens with the Up arrow in
the notification area that shows hidden items.
Below is a simple code to demonstrate this problem. Right-click both text boxes
when the window is NOT focused (i.e. click some other window).
from PySide6.QtGui import QAction, QIcon, Qt
from PySide6.QtWidgets import QApplication, QMainWindow, QWidget,
QVBoxLayout, QTextEdit, QMenu
class MainWindow(QMainWindow):
def __init__(self):
super().__init__()
self.resize(600, 400)
self.context_menu1 = QMenu()
menu_item1 = QAction(QIcon.fromTheme("edit-copy"), "I have no
parent", self)
self.context_menu1.addAction(menu_item1)
self.context_menu2 = QMenu(self)
menu_item2 = QAction(QIcon.fromTheme("edit-copy"), "I have a
parent", self)
self.context_menu2.addAction(menu_item2)
self.widget1 = QTextEdit()
self.widget1.setText("Context menu NO parent")
self.widget1.setContextMenuPolicy(Qt.CustomContextMenu)
self.widget1.customContextMenuRequested.connect(self.show_custom_context_menu1)
self.widget2 = QTextEdit()
self.widget2.setText("Context menu WITH parent")
self.widget2.setContextMenuPolicy(Qt.CustomContextMenu)
self.widget2.customContextMenuRequested.connect(self.show_custom_context_menu2)
layout = QVBoxLayout()
layout.addWidget(self.widget1)
layout.addWidget(self.widget2)
self.central_widget = QWidget()
self.central_widget.setLayout(layout)
self.setCentralWidget(self.central_widget)
def show_custom_context_menu1(self, point):
self.context_menu1.popup(self.widget1.viewport().mapToGlobal(point))
def show_custom_context_menu2(self, point):
self.context_menu2.popup(self.widget2.viewport().mapToGlobal(point))
app = QApplication([])
win = MainWindow()
win.show()
app.exec()
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 482185] Context menu (when right-clicking on the desktop) appears in a separate window after external monitor restart
https://bugs.kde.org/show_bug.cgi?id=482185 --- Comment #17 from Sin Jeong-hun --- Created attachment 169483 --> https://bugs.kde.org/attachment.cgi?id=169483&action=edit Demo screen recording for my code in comment 16. When the window is not focused, I right-clicked on the two text boxes. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 487051] New: Desktop icons' positions change after waking up from sleep when a secondary monitor is disabled.
https://bugs.kde.org/show_bug.cgi?id=487051 Bug ID: 487051 Summary: Desktop icons' positions change after waking up from sleep when a secondary monitor is disabled. Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 169500 --> https://bugs.kde.org/attachment.cgi?id=169500&action=edit Shows the problem in a drawing. SUMMARY When using dual monitors and one monitor is disabled, sleep/wake up (no password) changes the desktop icons location. Very often vertically-aligned icons become horizontally-aligned, or sometimes they were kept vertical, but some of them moved randomly. When no monitors are disabled, it did not seem to happen. Please see the attachment for illustration. STEPS TO REPRODUCE 1. Disable a secondary monitor. 2. Arrange icons vertically at the left side, like Window's default desktop icons. 3. Sleep 4. Wake it up (no password when waking up) OBSERVED RESULT Icons positions change EXPECTED RESULT Icons remain where they were before sleep. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 487051] Desktop icons' positions change after waking up from sleep when a secondary monitor is disabled.
https://bugs.kde.org/show_bug.cgi?id=487051 Sin Jeong-hun changed: What|Removed |Added Attachment #169500|0 |1 is obsolete|| --- Comment #1 from Sin Jeong-hun --- Created attachment 169501 --> https://bugs.kde.org/attachment.cgi?id=169501&action=edit Illustration of the problem Previous image was .SVG with transparent background which made the white text (LibreOffice's default text colour in dark theme) illegible, so I created a new image with black background. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 487051] Desktop icons' positions change after waking up from sleep when a secondary monitor is disabled.
https://bugs.kde.org/show_bug.cgi?id=487051 --- Comment #2 from Sin Jeong-hun --- I have tried "context menu -> Icons -> Locked", but the icons still got rearranged horizontally anyway. KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-2 (64-bit) Graphics Platform: Wayland Graphics Processor: Mesa Intel® Arc The sizes/scaling values of the two monitors are different; and the main monitor's scaling is 160%. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 487081] New: Dark theme, Print Preview shows empty, prints white text on white background.
https://bugs.kde.org/show_bug.cgi?id=487081 Bug ID: 487081 Summary: Dark theme, Print Preview shows empty, prints white text on white background. Classification: Applications Product: kate Version: 24.02.2 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kwrite Assignee: kwrite-bugs-n...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 169521 --> https://bugs.kde.org/attachment.cgi?id=169521&action=edit Wrote "Hello" and printed it to a PDF file. SUMMARY When Plasma is using dark theme, selecting File -> Print/Export -> Print Preview seems to change the theme of the editor view to "Printing". The editor shows black text on white background, but the preview dialogue itself is using white text on white background; I see nothing. I clicked the print button and chose PDF. The PDF looked empty. When I tried text selection tool, it seemed that I could select something. I copied it and pasted it into a text editor, and the text was there. So, the PDF is using white text on white background. Isn't it a bug that invoking the print preview changes the editor's theme? I have to change it back, which is cumbersome. The preview is showing in a separate pop-up window, so I am not sure if it is necessary to change the editor's theme. At least shouldn't KWrite change editor's theme back when the preview window is closed? Also it seems that on a monitor with fractional scaling, the window size of print preview is very small and I have to resize it every time. Both Kate/KWrite seem to do exactly the same thing. STEPS TO REPRODUCE 1. Set dark mode for Plasma, and a dark theme for the editor 2. Print Preview 3. Print to PDF OBSERVED RESULT White text on paper EXPECTED RESULT Black text on paper SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch Linux, Wayland (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION Attaching the printed PDF page. It has "Hello" on it. -- You are receiving this mail because: You are watching all bug changes.
[policykit-kde-agent-1] [Bug 485407] polkit-kde-agent crashes with nullptr in PolicyKitListener::finishObtainPrivilege() when run in Hyprland
https://bugs.kde.org/show_bug.cgi?id=485407 Sin Jeong-hun changed: What|Removed |Added CC||typing...@gmail.com --- Comment #20 from Sin Jeong-hun --- I think "Hyperland" is not related. I am using Plasma X11 (version 6.0.4), and it happens, too. Took me hours to find out this is a bug, because I thought it was a problem of polkit rules and tried modifying rules. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487454] New: Search clear button opens an app in the Favourites
https://bugs.kde.org/show_bug.cgi?id=487454 Bug ID: 487454 Summary: Search clear button opens an app in the Favourites Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 SUMMARY After searching, if you click the clear button right away, it clears the text as expected. But after searching if you move the mouse over one of the result and then click the clear button, it opens an app in the Favourites. STEPS TO REPRODUCE 1. Type some existing app's name (e.g., firefox) 2. Hover the mouse over the app in the search result (e.g., fireFox) 3. Now, click the clear button OBSERVED RESULT Some app in the top row of the Favourites gets launched EXPECTED RESULT Clear the search field and nothing more. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Arch (available in About System) KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.0 ADDITIONAL INFORMATION I swear God, I searched the existing with multiple text. If this is also a duplicate, please improve the search feature... -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 377357] configurable timer setting to turn off the keyboard's backlight
https://bugs.kde.org/show_bug.cgi?id=377357 Sin Jeong-hun changed: What|Removed |Added CC||typing...@gmail.com --- Comment #11 from Sin Jeong-hun --- Maybe the inactivity should not include mouse/trackpad. In many cases, I only use mouse (e.g., browsing the web) so if the keyboard light keeps getting turned on/off each time I use the mouse, it would be distracting. I think I only need keyboard inactivity (turns off 15s after no keyboard input). I don't remember exactly, but I think Samsung's keyboard backlight setting worked this way. ( https://r1.community.samsung.com/t5/image/serverpage/image-id/2822470iF59997A91BCBC17F ) So, maybe the automatic turn-off should provide two options: (1)no user input (this includes mouse/trackpad) (2)no keyboard input Anyway, is this feature being developed? It is an essential feature for laptops, in my opinion. Windows has it, macOS has it. ( https://i.sstatic.net/xeg1g.png ) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 487612] New: Public's tooltip is the same as Video
https://bugs.kde.org/show_bug.cgi?id=487612 Bug ID: 487612 Summary: Public's tooltip is the same as Video Classification: Applications Product: systemsettings Version: 6.0.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_desktoppath Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- SUMMARY Says "Public" is a place to save movies. STEPS TO REPRODUCE 1. Place the mouse over the Public input box 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 402857] Touchpad gestures should be configurable
https://bugs.kde.org/show_bug.cgi?id=402857 Sin Jeong-hun changed: What|Removed |Added CC||typing...@gmail.com --- Comment #18 from Sin Jeong-hun --- Even Windows natively allows customising gestures. Under Windows, I used to use "three-finger left/right swipe" for "go backward/forward", basically the same as the mouse back/forward buttons. In my opinion, this was really helpful, because I could easily/quickly browser the web, file manager, and even programming IDE's. Gnome does not provide gesture customisation either, but at least there was an extension that allowed me to map "three-finger left/right" to "go forward/backward". Currently, on Plasma, both three and four-finger swipes do the same thing: switching desktop, and I have to move the mouse pointer to click the back icon on the top-left of the app. Really inconvenient and hurting my wrist. If not full customisation, I wish at least there was some sort of checkbox to use three-finger swipes for "go forward/backward". -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492264] New: Notification icon area tooltip reappears on mouse hover
https://bugs.kde.org/show_bug.cgi?id=492264 Bug ID: 492264 Summary: Notification icon area tooltip reappears on mouse hover Classification: I don't know Product: kde Version: unspecified Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: typing...@gmail.com Target Milestone: --- Created attachment 173000 --> https://bugs.kde.org/attachment.cgi?id=173000&action=edit screen recording of the problem SUMMARY Tooltip first appears, then disappears, and then reappear, making it annoying to see the tooltips like battery information. It doesn't always happen, and I don't know what the condition that causes this is, but in my experience, this happens multiple times a day. STEPS TO REPRODUCE 1. Hover the mouse over an icon in the notification area 2. 3. OBSERVED RESULT Tooltip reappears or shows random sliding animation (like moving from the left). EXPECTED RESULT Stable tooltip shows up. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Arch KDE Plasma Version: 6.1.4 KDE Frameworks Version: 6.5.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION It is probably easier to watch the screen recording to understand the problem. If this is a malfunction of animation, let us disable the animation for the notification area tooltip. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492264] Notification icon area tooltip reappears on mouse hover
https://bugs.kde.org/show_bug.cgi?id=492264 --- Comment #2 from Sin Jeong-hun --- (In reply to Nate Graham from comment #1) > If you disable the "Morphing Popups" effect in System Settings > Window > Management > Desktop Effects, does the issue stop happening? Sorry for the late reply; somehow the notification of Gmail on my phone has not been working. I just disabled that effect, and I immediately liked this better, because the animation had been annoying. But, as the reappearing is sporadic and I don't know the exact condition, I think I need to keep using the desktop for a while to make sure that it never happens again. I will report in a few days. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492264] Notification icon area tooltip reappears on mouse hover
https://bugs.kde.org/show_bug.cgi?id=492264 --- Comment #3 from Sin Jeong-hun --- It still happens with that effect disabled. It happens on my laptop, and the screen recording that I had attached was a virtual machine that I basically just installed a new OS with barely any configuration modification. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491334] New: Search result is empty for some two letters
https://bugs.kde.org/show_bug.cgi?id=491334 Bug ID: 491334 Summary: Search result is empty for some two letters Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 SUMMARY Not all, but for some two letters, the search result is empty. That is, `A` shows something, `AB` shows nothing, and `ABC` shows something. For example, type "wri". "wr" shows nothing. This is not limited to "wr". Another example is "jap" (assuming that you have an item "japan"). STEPS TO REPRODUCE 1. Type wri 2. 3. OBSERVED RESULT Two letters shows nothing. EXPECTED RESULT Two letters shows a match(s). SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.9.10-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 490972] Communicate better to the user why two character searches sometimes return no results
https://bugs.kde.org/show_bug.cgi?id=490972 --- Comment #6 from Sin Jeong-hun --- (In reply to cwo from comment #1) > I'm pretty sure this is intentional - many of the search categories only > apply from the third letter (and sometimes even more) on, to avoid > completely irrelevant matches. I don't get it. If it shows nothing for 2 letters because the search result is not good, why does it show result for 1 letter, which is even shorter? Also, I don't agree that 2-letter result is mostly useless. In my opinion, the better option is just order the results by the frequency. That is, if I had typed `wr` and choose "writer" often, then "writer" should be at the top when I typed `wr` next time. Doesn't Windows start menu search work that way? -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 490972] Communicate better to the user why two character searches sometimes return no results
https://bugs.kde.org/show_bug.cgi?id=490972 --- Comment #8 from Sin Jeong-hun --- (In reply to cwo from comment #7) So, you mean, it works for "Ka" because "Kate" starts with it, but not for "Wr" because "LibreOffice Writer" does not start with it? It would make sense not to include descriptions or other metadata, but in case of "LibreOffice Writer", I think that effectively its name is "Writer", because I don't think anyone would call it "LibreOffice Writer" under normal situations. I just call it "Writer". So, shouldn't the 2-letter search match the start of any word in the name? And about having too many results, maybe that is only the case when file search is enabled. I always disable it, because I kind of think it's dumb to search the file system in the start menu search. So, in my case, "wr" would only match a few items. In this case, can't the two-letter search not work for file search results, but work for application name search? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401581] New: Win+P still assumes the monitors position wrongly, ignoring the Display Configuration.
https://bugs.kde.org/show_bug.cgi?id=401581 Bug ID: 401581 Summary: Win+P still assumes the monitors position wrongly, ignoring the Display Configuration. Product: kwin Version: 5.14.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: typing...@gmail.com Target Milestone: --- SUMMARY MonitorL is on the left, MonitorR is on the right. However, the graphics card arbitarily assigns Display1 to the right monitor, and Display2 on the left monitor, and this cannot be changed. I can switch the positions and set MonitorL (which is Display2) as the primary monitor in Display Configuration, yet Win+P still thinks that MonitorR is on the left, MonitorL is on the right, and shows "Extend to left/right" wrongly. Moreover, when the primary display has been set to MonitorL (Display2), if I disable MonitorR by selecting "Switch to external screen" and then re-enable it by selecting "Extend to left", the primary monitor is changed to MonitorR (Display1). STEPS TO REPRODUCE 1. Connect two monitors to your computer. 2. Purposely position the monitor that the graphics card think the first monitor on the right. 3. Change monitor positions in Display Settings, and set the physical left monitor as the primary monitor. 4. Press Win+P to disable the right monitor and re-enable it. OBSERVED RESULT Win+P assumes the positions wrongly. Disable/re-enabling Diplay1 moves the primary monitor from Display2 to Display1. EXPECTED RESULT Win+P should respect the actual positions that is set in Display Settings. The primary monitor should be remembered (Windows does, for the same situation). SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: Manjaro (Kernel 4.19.4.1) but also happens in Ubuntu 18.10 KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401680] New: Wobbly Windows, dual monitor, dragging a maximised windows shows weird animation
https://bugs.kde.org/show_bug.cgi?id=401680 Bug ID: 401680 Summary: Wobbly Windows, dual monitor, dragging a maximised windows shows weird animation Product: kwin Version: 5.14.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: typing...@gmail.com Target Milestone: --- SUMMARY When I drag a maximised windows so that that window can be a smaller size, a large ghost-like big image of the window flickers on the other monitor. This is especially apparent when the wobbliness is big. This is not a serious problem, but hey, people use wobbliness to look good, not for practical reasons. So, looking good is all that matters, and this makes it look less good. STEPS TO REPRODUCE 1. Increase wobbliness 2. Maximise a window 3. Drag down the title bar of that window OBSERVED RESULT On the other monitor, a large ghost of the window flickers. EXPECTED RESULT I do not think the effect should be shown beyond the current monitor, when resizing a maximised window. Maybe it is better to confine the animation within the monitor, not expanding it to the other monitor. SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: Manjaro (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 401680] Wobbly Windows, dual monitor, dragging a maximised windows shows weird animation
https://bugs.kde.org/show_bug.cgi?id=401680 --- Comment #6 from Sin Jeong-hun --- Created attachment 116643 --> https://bugs.kde.org/attachment.cgi?id=116643&action=edit When it happened. I had tested Wobbly in a slightly older KDE last week, and the visual artefact was a lot worse (the artefact did not even disappear after the animation). This time, it was not that bad, just a minor annoyance. The "Maximise" seems to have been enabled by default. When I turned it off, it no longer happened. Maybe you could add a warning about this in the description, like "Not to be used along with the Maximise effect"? I had captured the "weird animation" before seeing the comment about "Maximise effect", so I will attach it. You can see a large version of the window flashes at the right corner of the left monitor. I forgot the Wobbly parameters, but with certain parameters, the flashing large window was a lot bigger. Anyways, I think you can close this issue, as this can be solved by simply disabling "Maximise". Thank you for your help. I am not sure if I could say this here but if you do not mind, there are really minor two additional things... (1) While wobbling, I can see some sort of seam between the title bar and the client area, as if the title bar and the client are not one piece. (2) Maybe apply anti-aliasing to the wobbling edges? It looks a little bit jaggy. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 494649] New: Ways to prevent accidental clicks on the "Add New Page..." on the left panel
https://bugs.kde.org/show_bug.cgi?id=494649 Bug ID: 494649 Summary: Ways to prevent accidental clicks on the "Add New Page..." on the left panel Classification: Applications Product: plasma-systemmonitor Version: git-stable-Plasma/6.2 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: typing...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- There is "Add New Page..." at the bottom of the list on the left panel, and it's very annoying for me that I often misclick it. Does this button even need to be there? I mean, who that often adds new pages in the system monitor in the first place? If I click it by a mistake, it opens a pop-up, so I have to move the mouse to close it and then return to the list. I have thought of a few ways to prevent this. 1. Move into the "Add New Page..." into the hamburger menu above. 2. Dock "Add New Page..." at the bottom of the panel, sort of like the settings button of Visual Studio Code's left panel. 3. Option to make the list big icons, like Visual Studio Code. The current list items are too narrow vertically, so it's easy to misclick them. It only has 5 items by default, so there is a lot of wasted vertical space. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 495163] New: Feature request: Clock/battery overlay at the corner
https://bugs.kde.org/show_bug.cgi?id=495163 Bug ID: 495163 Summary: Feature request: Clock/battery overlay at the corner Classification: Applications Product: systemsettings Version: 6.2.1 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_kwineffects Assignee: kwin-bugs-n...@kde.org Reporter: typing...@gmail.com CC: plasma-b...@kde.org Target Milestone: --- When watching full screen videos or doing a full-screen task on a laptop, I often find that I need to check the clock and battery. To do so, currently, I have to exit the full-screen, and place the mouse over the battery icon in the system tray. I think it would be very convenient if there is an effect that shows the clock/battery at the top corer of the screen (like Japanese morning TV programmes), and I could toggle it on/off with a shortcut. I don't think it's too hard to implement, so I tried to create an effect myself, but I could not find enough resources to get started, so I could not even make a "hello world" effect. I am continue to search for ways, but in the meanwhile, if someone who knows effect programming well could do it, that would be better. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 492264] Notification icon area tooltip reappears on mouse hover
https://bugs.kde.org/show_bug.cgi?id=492264 Sin Jeong-hun changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from Sin Jeong-hun --- (In reply to Bug Janitor Service from comment #4) > 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 > days. Please provide the requested information, then set the bug status to > REPORTED. If there is no change for at least 30 days, it will be > automatically closed as RESOLVED WORKSFORME. > > For more information about our bug triaging procedures, please read > https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. > > Thank you for helping us make KDE software even better for everyone! I think I have provided the information. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 492264] Tray icon tooltips disappear then reappear while hovering
https://bugs.kde.org/show_bug.cgi?id=492264 --- Comment #9 from Sin Jeong-hun --- Created attachment 173909 --> https://bugs.kde.org/attachment.cgi?id=173909&action=edit Reproduced in a VM of KDE Neon's live mode. In Vmware Workstation, I create a new VM with "neon-user-20240822-0718.iso". The CPU setting was the default, RAM was 3.7GB, HDD was 20GB, no network. I booted to the live desktop, and this recording starts from there. I closed the installer. I switched the resolution to 1080p. (My laptop, on which the problem happens, is 1080p, and my desktop, where this did not happen is 4K. But on my desktop, when I lowered the resolution to 1080p, it happened.) Then, I resized the taskbar height from 44 to 32. (My desktop's task bar height is 36, so it probably doesn't have to be exactly 32.) Then I tried hovering the mouse pointer on the tray icons. Since this problem happens randomly, I tried it multiple times. The problem was reproduced at 1:00 of the video. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 492264] Tray icon tooltips disappear then reappear while hovering
https://bugs.kde.org/show_bug.cgi?id=492264 --- Comment #8 from Sin Jeong-hun --- Created attachment 173855 --> https://bugs.kde.org/attachment.cgi?id=173855&action=edit more screen recording It seems that it happens with the bell icon, too. But this is random. Even for the same icon, it sometimes happens, sometimes doesn't happen. I used Spectacle to record the screen, but for some reason, the recorded file kept prematurely ended then I stopped recording (bug?), so it was hard to record the time this flickering happened. The recording is my laptop, and the same thing problem happened in a virtual machine, too. I guess I am going to install a new Plasma in VM (I forgot to create a snapshot for the old one), and try to reproduce this with minimal system change. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 492264] Tray icon tooltips disappear then reappear while hovering
https://bugs.kde.org/show_bug.cgi?id=492264 --- Comment #7 from Sin Jeong-hun --- (In reply to cwo from comment #6) > Thank you for the bug report! > > Just to make sure, is this limited to the system tray, or does it also > happen with other tooltips on the panel (such as for the application > launcher or clock), and is it restricted to some tray icons or can it happen > for all of them? I can't seem to reproduce the issue myself. It seems that it only happens with some of the icons in the system tray, not with the application icons or the click. For example, it does not seem to happen with the bell icon (notifications, I guess), but with the clipboard, battery, or network icons. Please see the I am going to attach. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 402857] Touchpad and touchscreen gestures should be configurable
https://bugs.kde.org/show_bug.cgi?id=402857 --- Comment #36 from Sin Jeong-hun --- I have tried https://github.com/taj-ny/kwin-gestures . Well, it's better than nothing, because now I can finally use gestures to go back/forward in browsers and file managers, instead of painfully clicking the back button, but I think it has the same fundamental problem as the old Fusuma thing: it calls the action after the gesture is done. So, it cannot give the feedback. For example, the native Exposé gesture shows windows moving as I start to swipe four fingers, but with this plugin, Exposé starts instantly after I have done swiping. Also, in Gnome's gesture extension ( https://github.com/harshadgavali/gnome-gesture-improvements ), left/right arrows start to appear when I start swiping left/right with three fingers, so I can cancel it. With this plugin, going back/forward is done instantly without notice. The configuration I used for going back with 3 finger right swiping: gestures: - type: swipe direction: right fingers: 3 actions: - keyboard: +BACK -BACK -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 497482] New: Export shortcuts as printable "cheat sheet" page
https://bugs.kde.org/show_bug.cgi?id=497482 Bug ID: 497482 Summary: Export shortcuts as printable "cheat sheet" page Classification: Applications Product: systemsettings Version: 6.2.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_keys Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com CC: duha.b...@gmail.com, fanzhuyi...@gmail.com, k...@david-redondo.de Target Milestone: --- SUMMARY It's not easy to remember all the shortcuts, even the ones I had set after some time. There already is an "Export" button, but it only exports the shortcuts in a machine-friendly format for import purposes. It includes all the empty shortcuts. How about adding "cheat sheet pdf" to the existing type "Shortcut Scheme"? If the user chooses this, it will save the shortcuts as a PDF file like this: https://code.visualstudio.com/shortcuts/keyboard-shortcuts-linux.pdf -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486606] Option to disable renaming by clicking selected file's name
https://bugs.kde.org/show_bug.cgi?id=486606 --- Comment #3 from Sin Jeong-hun --- (In reply to TraceyC from comment #1) > I believe the feature you want is already present. If you go to > Settings - Configure Dolphin - View > On the General tab, uncheck "Rename single items inline" > > Does this do what you want? Whilst it does disable rename by accidental clicks, it shows a separate pop-up dialogue box, instead of the inline editing, when I actually want to rename the file by pressing F2, which is not what I want. But, I think the convenience of not getting accidental renaming weighs more than the inconvenience of using a pop-up dialogue for renaming, so I think I can use this. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 499112] New: Ctrl+A does not work in the list
https://bugs.kde.org/show_bug.cgi?id=499112 Bug ID: 499112 Summary: Ctrl+A does not work in the list Classification: Applications Product: plasma-systemmonitor Version: git-stable-Plasma/6.2 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: typing...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY In the lists (Applications/Processes), Ctrl + A has no effect. I don't think it makes sense, because I can select multiple (even all) items by shift/ctrl click anyway. STEPS TO REPRODUCE 1. Press Ctrl + A 2. 3. OBSERVED RESULT No effect. EXPECTED RESULT All items selected. SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.1 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] New: Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 Bug ID: 500878 Summary: Sleep with keyboard shortcut triggers sleep again on the next waking up Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Power management & brightness Assignee: plasma-b...@kde.org Reporter: typing...@gmail.com Target Milestone: 1.0 SUMMARY I have set a shortcut for sleep (Meta + S), and if I put the PC to sleep using this shortcut, when I wake the PC up with a key press (any key), the computer goes back to sleep right away. This happens on my desktop with two different different USB keyboards (both connected to the same USB hub). My guess is that somehow the shortcut key press before the sleep is sent to the PC again when it wakes up, so Plasma thinks I pressed the sleep shortcut again and puts the PC to sleep. I am not sure on how many PC's this happens, but if it can be fixed without too much efforts, I wish it gets fixed. For example, it could have some sort of guard period where the sleep shortcut is ignored, when the PC is waking up from sleep, like 1 second. STEPS TO REPRODUCE 1. Set a shortcut for sleep 2. Put the PC to sleep using the shortcut 3. Press any key to wake the PC up. OBSERVED RESULT The computer goes back to sleep right away. EXPECTED RESULT The computer wakes up. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.4-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: Intel® Arc ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 --- Comment #8 from Sin Jeong-hun --- (In reply to Nate Graham from comment #7) > Thanks, I thought it sounded familiar. > > *** This bug has been marked as a duplicate of bug 493974 *** It does not look like the same problem to me. The computer is a desktop PC with two DP monitors. There is no lid. It does not happen if I put the PC to sleep using the sleep button on the KickOff menu. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 --- Comment #4 from Sin Jeong-hun --- Created attachment 179109 --> https://bugs.kde.org/attachment.cgi?id=179109&action=edit system log text (In reply to cwo from comment #3) > Hm, I can't reproduce this - the computer goes to sleep on Meta+S, and > immediately wakes up on any key press (even the sleep shortcut itself) > without going back to sleep. Since it just happened again, I asked A.I. for a command to get the system log of the last 10 minutes, for which it gave "journalctl --since "10 minutes ago" > last_10_minutes.log". I will attach the file. Maybe you can see why it happened. If the command is not correct, let me know the correct command to know what causes the immediate re-sleep. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 Sin Jeong-hun changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|DOWNSTREAM |--- --- Comment #2 from Sin Jeong-hun --- I don't know why it was set to 6.0.4. Probably some kind of mistake with the mouse wheel. I'm using 6.3.2, as shown above, so I am re-opening it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 Sin Jeong-hun changed: What|Removed |Added Version|6.0.4 |6.3.2 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500878] Sleep with keyboard shortcut triggers sleep again on the next waking up
https://bugs.kde.org/show_bug.cgi?id=500878 --- Comment #6 from Sin Jeong-hun --- (In reply to Nate Graham from comment #5) > I also can't reproduce the issue. > > Do you by any chance have multiple screens on this system? Yes, I have two monitors, using per-monitor DPI on Wayland. -- You are receiving this mail because: You are watching all bug changes.
