[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.
[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.
[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.
[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.
[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.
[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.
[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.
[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=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.
[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.
[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=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] 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=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.
[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=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.
[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.
[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.
[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] 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.
[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.
[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.
[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.
[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 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=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.
[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.
[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.
[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.
[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.
[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.
[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=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.
[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.
[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.
[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 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=edit screenshot -- 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] 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=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 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=edit screen recording of the problem SUMMARY When trying to drag-and-drop (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 animation is wrong (the file goes back to where it was, as if d was failed), so I cannot instantly know if 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 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.
[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.
[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.
[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=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.
[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=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.
[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 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.
