[kwin] [Bug 467999] Focus stealing prevention is not working properly.
https://bugs.kde.org/show_bug.cgi?id=467999 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #11 from Yevhen --- (In reply to Nate Graham from comment #9) > Dolphin does, but `xdg-open` doesn't. Both the sending and receiving apps > need to support it. I have a similar issue on Wayland (Fedora Kinoite Nightly). "FocusStealingPreventionLevel" is set for KWin and I have a Kate window opened. When I'm opening some text file from Dolphin, Kate window is not raised automatically. Task manager doesn't even notify me that Kate window requires attention. If Kate is closed and I open some file associated with Kate, focus appropriately migrates to the Kate window. Not sure if this issue is on the KWin/Wayland or Kate side. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #2 from Yevhen --- (In reply to Vlad Zahorodnii from comment #1) > I cannot reproduce it in Plasma 6 when using Ukrainian keyboard layout. > Shift+2 produces " too in UA layout. I have a similar Wayland-specific issue on both Plasma 5 and Plasma 6. STEPS TO REPRODUCE: 1. Switch to the Ukrainian layout 2. Open multiple windows of some program 3. Press Alt+"Above_Tab" shortcut to trigger "Walk Through Windows of Current Application" Task Switcher action OBSERVED RESULT: KWin Wayland presumably expects specifically Alt+~ combination (and not Alt+ʼ which is produced with input using Ukrainian keyboard layout). As a workaround I can set Alt+ʼ as an alternative shortcut. On the X11 Session there wan't need in this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467999] Focus stealing prevention is not working properly.
https://bugs.kde.org/show_bug.cgi?id=467999 --- Comment #13 from Yevhen --- (In reply to Yevhen from comment #11) > (In reply to Nate Graham from comment #9) > > Dolphin does, but `xdg-open` doesn't. Both the sending and receiving apps > > need to support it. > > I have a similar issue on Wayland (Fedora Kinoite Nightly). > "FocusStealingPreventionLevel" is set for KWin and I have a Kate window > opened. When I'm opening some text file from Dolphin, Kate window is not > raised automatically. Task manager doesn't even notify me that Kate window > requires attention. > If Kate is closed and I open some file associated with Kate, focus > appropriately migrates to the Kate window. > Not sure if this issue is on the KWin/Wayland or Kate side. It could be a temporary distribution packaging/migration issue on Fedora 40 Rawhide. Flatpak version of Kate doesn't always "steal focus" on Plasma 6 but informs when its window requires attention. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477625] Weird icon placement of apps that do not have window in Dekstop Overview
https://bugs.kde.org/show_bug.cgi?id=477625 --- Comment #8 from Yevhen --- (In reply to David Redondo from comment #7) > KWin bug then? It should skip windows with skip switcher here maybe? It's possible. With Plasma 5 I still have XWaylandVideoBridge icon on Overview or Desktop Grid. On Plasma 6 it didn't show up lately. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 413134] Night color conflicts with color correction
https://bugs.kde.org/show_bug.cgi?id=413134 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #22 from Yevhen --- This issue has migrated to KDE Plasma 6 Wayland. STEPS TO REPRODUCE: 1. In "System Settings" go to "Input & Output" > "Display & Monitor" > "Display Configuration" 2. In the field "Color Profile" specify the path to the ICC color profile file (.e.g., /usr/share/color/icc/colord/Rec709.icc) 3. In "System Settings" go to "Appearance & Style" > "Colors & Themes" > "Night Light". Set "Switching times" to "Always on night light" OBSERVED RESULT: "Night Light" does not work until the user disables "Color Profile" and re-applies "Night Light" -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482547] New: Improve parsing of distro custom fontconfig (Sub-pixel RGB on Fedora KDE)
https://bugs.kde.org/show_bug.cgi?id=482547 Bug ID: 482547 Summary: Improve parsing of distro custom fontconfig (Sub-pixel RGB on Fedora KDE) Classification: Applications Product: systemsettings Version: 5.27.11 Platform: Other OS: Linux Status: REPORTED Keywords: reproducible Severity: normal Priority: NOR Component: kcm_fonts Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- SUMMARY Fedora by default has Sub-pixel RGB disabled by default (no symlink to /usr/share/fontconfig/conf.avail/10-sub-pixel-rgb.conf in /etc/fonts/conf.d/) . Instead, Fedora KDE spin ships special fontconfig which enables it (https://pagure.io/fedora-kde/kde-settings/blob/f39/f/etc/fonts/conf.d/10-sub-pixel-rgb-for-kde.conf) KDE rgb I can confirm that it works not only visually but also using the command below: fc-match --verbose | grep 'rgba\|desktop' However, on System Settings "Sub-pixel rendering" value shows as unset/"None" by default. STEPS TO REPRODUCE 1. Delete original /etc/fonts/conf.d/10-sub-pixel-rgb.conf and create Fedora's config (link above) 2. Create new user and login with its account 3. Check "System Settings" > "Appearance & Style" > "Text & Fonts" > "Fonts" > "Sub-pixel rendering" OBSERVED RESULT Value for "Sub-pixel rendering" is "None" EXPECTED RESULT Value for "Sub-pixel rendering" is "RGB" SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 40 Kinoite KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION It looks like kcm_fonts targets specifically original "10-sub-pixel-rgb.conf". I wasn't able to tweak Fedora's fontconfig so that kcm_fonts returns the correct value. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 482547] Improve parsing of distro custom fontconfig (Sub-pixel RGB on Fedora KDE)
https://bugs.kde.org/show_bug.cgi?id=482547 Yevhen changed: What|Removed |Added Version|5.27.11 |6.0.0 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 482800] New: Kate freezes if an open file with Linux device information has been modified externally
https://bugs.kde.org/show_bug.cgi?id=482800 Bug ID: 482800 Summary: Kate freezes if an open file with Linux device information has been modified externally Classification: Applications Product: kate Version: 24.02.0 Platform: Other OS: Linux Status: REPORTED Keywords: qt6, reproducible, usability Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- SUMMARY Application freezes if user has opened file from the /sys directory, and this file was changed externally. For example, user disables CPU core , changes I/O Disk scheduler or tweaks some device parameter Freezing also occurs if the file contents are overwritten with the same value. STEPS TO REPRODUCE 1. Open /sys/devices/system/cpu/cpu1/online using KWrite or Kate 2. Open terminal (either Kate built-in or external application) 3. Execute the command below to overwrite the file value echo 1 | sudo tee /sys/devices/system/cpu/cpu1/online OBSERVED RESULT KWrite/Kate window freezes EXPECTED RESULT KWrite/Kate window shouldn't freeze SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION If I modify file within Kate/KWrite, it can't be saved (even though I provide a correct password for administrator authentication). The error says that "The document could no be saved, as it was no possible to write to ...". That's also the case with files inside /proc directory (e.g. /proc/sys/vm/page-cluster), though Kate doesn't freeze if those files are changed externally. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 482838] New: Ask for confirmation when closing Kate windows with a terminal panel running a program
https://bugs.kde.org/show_bug.cgi?id=482838
Bug ID: 482838
Summary: Ask for confirmation when closing Kate windows with a
terminal panel running a program
Classification: Applications
Product: kate
Version: 24.02.0
Platform: Other
OS: Linux
Status: REPORTED
Keywords: qt6, usability
Severity: normal
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: xalt7x.serv...@gmail.com
Target Milestone: ---
SUMMARY
When user has something running in Kate built-in terminal panel, and closes
Kate, there's no warning that process running in shell will terminate. It
would be nice to have such feature, especially for users that hide terminal
panel with F4 (keyboard shortcut that toggles "Show Terminal Panel").
STEPS TO REPRODUCE
1. Open Terminal Panel
2. Run `watch ls`
3. Close Kate window which was a terminal panel with the running process
OBSERVED RESULT
No warning that the program 'watch' will terminate if user closes the window
EXPECTED RESULT
Warning dialog like in KDE Dolphin ("The program 'watch' is still running in
the Terminal panel. Are you sure you want to quit?")
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 40 Kinoite
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
ADDITIONAL INFORMATION
Similar feature was implemented for KDE Dolphin
(https://bugs.kde.org/show_bug.cgi?id=304816)
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 304816] Dolphin should warn the user before closing if there's a process (program, script) running in built-in shell
https://bugs.kde.org/show_bug.cgi?id=304816 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=482838 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #6 from Yevhen --- (In reply to Oded Arbel from comment #5) > (In reply to Andrey from comment #4) > > This bug is about non-Latin symbols, both "/" and "Q" are Latin. > > I'm not sure I follow - so "/" is a Latin symbol, but "@" and double quotes > are not? I guess, Andrey is referring to the issue that was described at https://bugs.kde.org/show_bug.cgi?id=375518#c47 I'll copy it here: > (In reply to Andrey from comment #46) > > Essentially, if a key produces different Latin symbol on other layout, the > > shortcut won't work (but it will if the symbol is not Latin). > > So basically: > - if my keyboard has non-Latin (e.g. Cyrillic) symbol on the same place as > the Latin symbol - shortcut will work > - If my keyboard has some other Latin symbol - shortcut won't work and I > will need to create another shortcut using different keyboard keyboard > > For me "Walk Through Windows of Current Application" is broken by default > since Ukrainian keyboard layout has another Latin symbol (apostrophe) on the > same place as QuoteLeft/Grave symbol. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428272] Unmaximize does not restore window size/position correctly if KWin's Quicktile shortcuts were used before
https://bugs.kde.org/show_bug.cgi?id=428272 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428272] Unmaximize does not restore window size/position correctly if KWin's Quicktile shortcuts were used before
https://bugs.kde.org/show_bug.cgi?id=428272
--- Comment #9 from Yevhen ---
Created attachment 165806
--> https://bugs.kde.org/attachment.cgi?id=165806&action=edit
Video of "resize" workaround
For now I'm using "Resize Window" shortcut/action as a workaround.
Caveats:
- Tested on KDE Plasma 6.0 RC2 and 1920x1080 display resolution
- It works mostly for bigger tiles (e.g. 2 windows tiled vertically in half)
- This trick breaks simultaneous resizing of tiled windows (that was introduced
in Plasma 5.27)
How to (also see attached screencast):
1. Assign some shortcut (e.g. Meta+Ctrl+s) for "Resize Window". it can be set
at "System Settings" > "Keyboard" > "Shortcuts" > "KWin")
You can also assign something like Meta+Ctrl+w for "Move Window" action
2. Tile windows and adjust their sizes
3. Use keyboard only (don't use mouse or touchpad) for the next steps
4. After switching to the tiled window, press "Resize Window" shortcut (if it
wasn't set, press Alt+F3 to activate window menu, and use keyboard arrows to
find and activate "Resize" window action).
5. The cursor will move automatically to the lower right corner of the window,
ready for resize
6. Don't resize window, just "Enter" or "Space" to confirm.
7. Use "Move"/"Move Window" window action or shortcut for a test. After "Move
window" activation, window will either move temporally to different location
or stay in place. Either way, you can restore previous ("tiled") window
location by pressing "Esc" key. If window temporally changes location during
"Move Window" activation, then this "resize" workaround wouldn't help, and
after "Maximize"/"Unmaximize" window will be moved to the inappropriate
location.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 432536] Move Mouse To Focus doesn't work as expected on Wayland
https://bugs.kde.org/show_bug.cgi?id=432536 --- Comment #6 from Yevhen --- Created attachment 165807 --> https://bugs.kde.org/attachment.cgi?id=165807&action=edit Demo of the "move window" workaround >From https://invent.kde.org/plasma/kwin/-/merge_requests/4721 I've learned that at least for now "Move Mouse to Focus" might work for some applications under X11 session. For now, users can try to use "Move Window" shortcut as a more universal workaround. 1. Assign some keyboard shortcut (e.g. Meta+Ctrl+w) for the "Move Window" action. it can be set at "System Settings" > "Keyboard" > "Shortcuts" > "KWin" 2. Use keyboard only (don't use mouse or touchpad) while performing further steps 3. With Alt+Tab or Meta+Number switch to the window where you want to place cursor 4. Press "Move Window" shortcut 5. Cursor will move to the center of the active window 6. Press "Esc" key to cancel "Move window" action. Cursor will stay in the center of the active window. I'm attaching screencast that shows this workaround in action. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 481322] New: When switching tasks, "Hightlight Window" effect causes flickering of maximized windows
https://bugs.kde.org/show_bug.cgi?id=481322 Bug ID: 481322 Summary: When switching tasks, "Hightlight Window" effect causes flickering of maximized windows Classification: Plasma Product: kwin Version: 5.93.0 Platform: Other OS: Linux Status: REPORTED Keywords: reproducible Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- Created attachment 165819 --> https://bugs.kde.org/attachment.cgi?id=165819&action=edit Screencast demonstrating flickering with the Hightlight Window effect SUMMARY "Highlight Window" effect makes possible to hightlight windows while hovering over taskbar entries. When user selects some window (by hover over taskbar window entry or by switching with tasks with Alt+Tab), other windows temporally hide, so user can focus on a particular window. "Highlight Window" doesn't hide other elements (e.g. desktop, panel, widgets), and this effect works really well when user has a only floating windows. However, when user switches between maximized window, there's always a distracting side effect. For a very short time highlighted window becomes semi-transparent so user sees desktop, then window becomes opaque again. STEPS TO REPRODUCE (please also see screencast in attachment) 1. Open and maximize several windows 2. Press and hold "Alt" key 3. While holding "Alt", slowly press "Tab" several times to switch between windows OBSERVED RESULT After temporal switch to the Task Switcher task, there's a brief flickering (highlighted window becomes semi-transparrent showing desktop) EXPECTED RESULT I don't need to briefly see desktop when I switch to the maximized window. I also think that option to not hide other window might improve experience with tiled windows for some users. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite Rawhide (40) KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION It's not Plasma 6 or Wayland regression. I have the same issue on Plasma 5.27 Also, as you can see from the screencast, highlight of the taskbar entries can be smoother sometimes. There's still some unwanted flickering but transition goes from the window below, not from desktop (as in the case with the Task Switcher). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 481385] New: Activate specific tab number with shortcut (Alt + [1-9])
https://bugs.kde.org/show_bug.cgi?id=481385 Bug ID: 481385 Summary: Activate specific tab number with shortcut (Alt + [1-9]) Classification: Applications Product: kate Version: 24.01.95 Platform: Other OS: Linux Status: REPORTED Keywords: usability Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- SUMMARY Nowadays many applications with tab support has an option to activate specific tab with shortcut. There, "Alt" + Number key activates tab by its order number on the panel. For example, Alt+1 activates 1st tab, Alt+5 activates 5th tab etc. Some application use their last Alt+Number shortcut to activate the last tab (for browsers it's Alt+9, for KDE Dolphin it's Alt+0, Konsole also has such action but shortcut is not set by default). STEPS TO REPRODUCE 1. Open several tabs 2. Use Alt+2 to activate the 2nd tab OBSERVED RESULT Nothing happens EXPECTED RESULT Alt+2 activates the 2nd tab SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION AFAIK, Alt+[2-9] shortcuts are currently not used but Alt+1 is already set for "Search" in the "kateproject". I hope that can be changed by default. -- You are receiving this mail because: You are watching all bug changes.
[colord-kde] [Bug 432073] colord-kde does not display translations
https://bugs.kde.org/show_bug.cgi?id=432073 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #1 from Yevhen --- I have this as well. https://invent.kde.org/graphics/colord-kde/-/merge_requests/20 deals with extraction of strings from .qml files. But unfortunately even with a more complete locale file, for me kcm_colord UI is still untranslated. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 375518] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts
https://bugs.kde.org/show_bug.cgi?id=375518 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #47 from Yevhen --- (In reply to Andrey from comment #46) > (In reply to George Melikov from comment #38) > > Global hotkey Shift+Win+2 is still broken for me on layout switch to > > non-English with other Shift+2 symbol (english has @ there, my layout has ") > > in Wayland , it worked on X11. Wayland just tries to insert ". > Right, this case is still broken but has a separate report: > bug 453661 > > Essentially, if a key produces different Latin symbol on other layout, the > shortcut won't work (but it will if the symbol is not Latin). So basically: - if my keyboard has non-Latin (e.g. Cyrillic) symbol on the same place as the Latin symbol - shortcut will work - If my keyboard has some other Latin symbol - shortcut won't work and I will need to create another shortcut using different keyboard keyboard For me "Walk Through Windows of Current Application" is broken by default since Ukrainian keyboard layout has another Latin symbol (apostrophe) on the same place as QuoteLeft/Grave symbol. Is there any hope to workaround it on the KDE side? I also wonder, why do we need a separate issue (https://bugs.kde.org/show_bug.cgi?id=453661) for this case. This issue is also about Wayland session but it's more noticeable and has more useful information. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 440534] On Wayland, dragging items over windows immediately makes those windows focused
https://bugs.kde.org/show_bug.cgi?id=440534 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #7 from Yevhen --- Created attachment 165263 --> https://bugs.kde.org/attachment.cgi?id=165263&action=edit Demo of the window raising issue during drag-n-drop on Wayland > STEPS TO REPRODUCE > 1. Open a window (for example, Firefox) in fullscreen. > 2. Open two Dolphin windows, and move them to the top left and top right > corners of the screen, leaving a gap between them. > 3. Attempt to drag a file or folder from one Dolphin window to the other. I still have it on a Wayland session. With the steps above, it's easily reproducible on different KDE Plasma versions (6.0 RC1, 5.27 and even 5.24). Please see my video that shows difference in drag-and-drop behavior on X11 and Wayland sessions. It's available in attachment and also on https://youtu.be/jMoGk-C8L_Q -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480511] New: On Wayland, during Drag'n'Drop, if the cursor hovers over a non-target window, it quickly receives focus and rises above the others
https://bugs.kde.org/show_bug.cgi?id=480511 Bug ID: 480511 Summary: On Wayland, during Drag'n'Drop, if the cursor hovers over a non-target window, it quickly receives focus and rises above the others Classification: Plasma Product: kwin Version: 5.92.0 Platform: Other OS: Linux Status: REPORTED Keywords: usability, wayland Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- Flags: Wayland+ Created attachment 165330 --> https://bugs.kde.org/attachment.cgi?id=165330&action=edit Demo of the window raising issue during drag-n-drop on Wayland SUMMARY Currently, on Wayland session drag-n-drop should be performed without delays, otherwise there is a risk, that some other window will receive focus and raise above the target window (so user will need to use Task Switcher or Task Manager to re-activate required window). When cursor with an item stops movement and holds/hovers over any window, it quickly receives focus and raises. Such unexpected focus change doesn't happen on X11 session. STEPS TO REPRODUCE 1. Launch some application (e.g. Firefox) and maximize its window 2. Launch 2 instances of Dolphin File Manager. Resize and place their windows at some distance from each other (for example, near opposite edges of the screen). Both windows should be visible (raise/float over Firefox window but without activated "Keep Above Others" option) 3. Select file from one Dolphin window and start dragging it to another Dolphin window 4. On a midway, hold cursor over Firefox window OBSERVED RESULT Firefox window receives focus and raises above second/target Dolphin window EXPECTED RESULT Firefox window doesn't "steal" focus when cursor hovers over it SCREENCAST Please see file in attachment or https://youtu.be/jMoGk-C8L_Q SOFTWARE/OS VERSIONS Linux: Fedora Kinoite 40 (Rawhide) KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION It's reproducible on older KDE Plasma releases as well (tested 5.24.7 and 5.27.10). Initially, it was reported at https://bugs.kde.org/show_bug.cgi?id=440534 but since this issue has a slight difference (it happens specifically when user holds cursor over window), Nate suggested to create a new bug report. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 440534] On Wayland, dragging items over windows immediately makes those windows focused
https://bugs.kde.org/show_bug.cgi?id=440534 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=480511 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480511] On Wayland, during Drag'n'Drop, if the cursor hovers over a non-target window, it quickly receives focus and rises above the others
https://bugs.kde.org/show_bug.cgi?id=480511 --- Comment #4 from Yevhen --- (In reply to Vlad Zahorodnii from comment #2) > > Firefox window doesn't "steal" focus when cursor hovers over it > > This is the intentional behavior. If the drag pointer hovers over a window, > the user likely wants to drop there. I can't agree with that. Most current KDE Plasma users are not robots/machines to perform Drag'n'Drop action with determined speed and accuracy. Especially, we can't expect that from older people, non-experienced users or users with disabilities. I can think of at least 3 cases where the current focus behavior is harmful to usability: 1. Drag'n'Drop file from file manager window to some other application to transfer file (web browser, chat app etc) 2. Drag'n'Drop browser tab to attach it to another browser window 3. Drag'n'Drop item from file manager to the terminal (to quickly get file/folder path) In a perfect world, I would like to avoid "drag-n-drop focus changes" for both maximized and floated windows (like Windows does - https://www.reddit.com/r/kde/comments/fz6as1/a_feature_that_i_really_missed_from_windows_is_it/). This would allow KWin users to perform simple Drag'n'Drop operations without much hassle (e.g. enable/disable "Always on Top"/"Keep above others", tile windows, drag file to the panel, activate Task Switcher etc.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 480511] On Wayland, during Drag'n'Drop, if the cursor hovers over a non-target window, it quickly receives focus and rises above the others
https://bugs.kde.org/show_bug.cgi?id=480511 --- Comment #9 from Yevhen --- (In reply to Vlad Zahorodnii from comment #8) > The EXPECTED RESULT talks about no raising window, i.e. matching the > behavior on X11 as demonstrated in the linked video. As I understood it, > that was about removing/adding option rather than tweaking the timeout. > Since the current behavior on Wayland is intentional, I closed the bug > report with RESOLVED INTENTIONAL. Yes, you're right, the expected result is to match X11 behavior as it provides arguably better usability. As a regular user, I may not be familiar with the codebase (e.g., timer values), what's in charge of input, how X11 clients grab the focus and other technical details of the KWin/X11/Wayland internals. All I know exactly is that Drag-n-Drop in the above-mentioned cases work better on KWin X11 and Mutter Wayland than on KWin Wayland. Surely, increase of the timeout is the welcome change that hopefully will make this issue less noticeable for the majority of users. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470257] The alternative shortcut for layout switching should support modifier-only shortcuts
https://bugs.kde.org/show_bug.cgi?id=470257 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=453506 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453506] Need to kick hotkeys on release, not press
https://bugs.kde.org/show_bug.cgi?id=453506 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=470257 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=470256 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470256] Multi-modifier Modifier-only shortcuts
https://bugs.kde.org/show_bug.cgi?id=470256 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=420493 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=470257 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 470257] The alternative shortcut for layout switching should support modifier-only shortcuts
https://bugs.kde.org/show_bug.cgi?id=470257 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com See Also||https://bugs.kde.org/show_b ||ug.cgi?id=420493 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464805] Modifier only shortcuts on X11 trigger on "press" action instead of "release"
https://bugs.kde.org/show_bug.cgi?id=464805 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=470256 CC||xalt7x.serv...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470256] Multi-modifier Modifier-only shortcuts
https://bugs.kde.org/show_bug.cgi?id=470256 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=464805 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464805] Modifier only shortcuts on X11 trigger on "press" action instead of "release"
https://bugs.kde.org/show_bug.cgi?id=464805 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=420493 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=464805 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=453661 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 453661] Global shortcuts are not working across multiple keyboard layouts (US and CZ for me)
https://bugs.kde.org/show_bug.cgi?id=453661 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=462274 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 423796] Alt+tilde/Alt+backtick shortcuts don't take into account that tilde and backtick characters may not be on the same physical key together
https://bugs.kde.org/show_bug.cgi?id=423796 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=453661 CC||xalt7x.serv...@gmail.com --- Comment #1 from Yevhen --- Very similar to https://bugs.kde.org/show_bug.cgi?id=453661 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 453661] Global shortcuts are not working across multiple keyboard layouts (US and CZ for me)
https://bugs.kde.org/show_bug.cgi?id=453661 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=423796 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 423796] Alt+tilde/Alt+backtick shortcuts don't take into account that tilde and backtick characters may not be on the same physical key together
https://bugs.kde.org/show_bug.cgi?id=423796 --- Comment #2 from Yevhen --- Sounds similar to https://bugs.kde.org/show_bug.cgi?id=453661 -- You are receiving this mail because: You are watching all bug changes.
[colord-kde] [Bug 480938] New: Display devices do not appear in the list (Plasma 6 Wayland session)
https://bugs.kde.org/show_bug.cgi?id=480938 Bug ID: 480938 Summary: Display devices do not appear in the list (Plasma 6 Wayland session) Classification: Plasma Product: colord-kde Version: 24.01.95 Platform: Other OS: Linux Status: REPORTED Keywords: regression, reproducible, wayland Severity: normal Priority: NOR Component: Systems Settings Module (KCM) Assignee: dantt...@gmail.com Reporter: xalt7x.serv...@gmail.com Target Milestone: --- Created attachment 165594 --> https://bugs.kde.org/attachment.cgi?id=165594&action=edit Plasma 6 Wayland with colord-kde v24.01.95 SUMMARY kcm_colord KDE Plasma 6 Wayland doesn't show any display device. On KDE Plasma 5 Wayland and KDE Plasma 6 X11 display device is listed STEPS TO REPRODUCE 1. Open "System Settings" > "Connected Devices" > "Color Management" or launch "kcmshell6 kcm_colord" 2. On the Devices tab search for Display device on the list OBSERVED RESULT No Display devices EXPECTED RESULT Even on VM there should be display device SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 (Rawhide) KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION 1. Both KDE Neon User (Plasma 5) and Testing (Plasma 6) editions provide colord-kde v23.08.4, and there I see the same issue. So I don't think that it's a regression with QT6 port (version 24.01.90+), distro packaging issue etc. 2. ICC profile assignment with "System Settings" > "Input & Output" > "Display & Monitor" > "Display Configuration" works properly on KDE Plasma 6 Wayland. 3. On KDE Plasma 6 Wayland, printer appear in the list. -- You are receiving this mail because: You are watching all bug changes.
[colord-kde] [Bug 480938] Display devices do not appear in the list (Plasma 6 Wayland session)
https://bugs.kde.org/show_bug.cgi?id=480938 --- Comment #1 from Yevhen --- Created attachment 165596 --> https://bugs.kde.org/attachment.cgi?id=165596&action=edit Plasma 5 Wayland with colord-kde v23.08.4 -- You are receiving this mail because: You are watching all bug changes.
[colord-kde] [Bug 480938] Display devices do not appear in the list (Plasma 6 Wayland session)
https://bugs.kde.org/show_bug.cgi?id=480938 --- Comment #2 from Yevhen --- Created attachment 165597 --> https://bugs.kde.org/attachment.cgi?id=165597&action=edit Plasma 6 Wayland with colord-kde v23.08.4 Plasma 6 Wayland with colord-kde v23.08.4 (KDE Neon Testing VM) -- You are receiving this mail because: You are watching all bug changes.
[colord-kde] [Bug 480938] Display devices do not appear in the list (Plasma 6 Wayland session)
https://bugs.kde.org/show_bug.cgi?id=480938 --- Comment #3 from Yevhen --- Created attachment 165598 --> https://bugs.kde.org/attachment.cgi?id=165598&action=edit Plasma 6 X11 with colord-kde v23.08.4 (KDE Neon Testing VM) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 481082] New: Incorrect KWin rule export dialog on KDE Plasma 6
https://bugs.kde.org/show_bug.cgi?id=481082 Bug ID: 481082 Summary: Incorrect KWin rule export dialog on KDE Plasma 6 Classification: Applications Product: systemsettings Version: 5.93.0 Platform: Other OS: Linux Status: REPORTED Keywords: regression, reproducible, usability Severity: normal Priority: NOR Component: kcm_kwinrules Assignee: kwin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com CC: isma...@gmail.com, plasma-b...@kde.org, vlad.zahorod...@kde.org Target Milestone: --- Created attachment 165680 --> https://bugs.kde.org/attachment.cgi?id=165680&action=edit Screencast demonstrating the issue SUMMARY KWin on KDE Plasma 6 has a weird UX regression with rule export. On KDE Plasma 5 in the "Export" dialog it was possible to save rule(s) to the new file that will be created automatically when user input name and press "Save". On KDE Plasma 6 in the "Export" dialog I need to overwrite existing file, otherwise there is an error. STEPS TO REPRODUCE (there is also screencast in the attachment) 1. Go to "System Settings" > "Apps & Windows" > "Window Management" > "Window Rules" (alternatively, execute command "kcmshell6 kcm_kwinrules") 2. Create and "Apply"/Save some window rule 3. Navigate back to the "Window Rules" window 4. Press "Export" button, select rule that you would like to export 5. Press "Save Rules" button 6. In the Export dialog enter name of the saved .kwinrule file (e.g., "nice") 7. Press "Open" (the button name here is "Open", not "Save") OBSERVED RESULT Error dialog appears with title: "Cannot open file — System Settings" and description "The file "/home/user/nice" could not be found" EXPECTED RESULT a new "nice.kwinrule" file is created SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION I assume that kcm_kwinrules selects "FileDialog.OpenFile" even for the "Export" dialog. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 478964] New: Files from external apps always open in the first Kate instance
https://bugs.kde.org/show_bug.cgi?id=478964 Bug ID: 478964 Summary: Files from external apps always open in the first Kate instance Classification: Applications Product: kate Version: 23.08.3 Platform: Other OS: Linux Status: REPORTED Keywords: reproducible, usability Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- SUMMARY Kate prefers to open files in tabs. However, it's also possible to launch a separate instances. Unfortunately, regardless of which Kate window was used last, new files opened from external programs (e.g. file manager) are always added to the initial Kate window. Other applications (e.g. Firefox) open files in the last used/viewed window. That's more preferable behaviour for multi-tasking. STEPS TO REPRODUCE 1. Launch Kate and open some file 2. Launch a new Kate instance (FIle - New Window) and open another file 3. Move second Kate instance to second virtual desktop 3. On the second virtual desktop launch file manager and there try to open text file with Kate OBSERVED RESULT Opened file is added on the initial Kate window so user have to switch back to another virtual desktop to see it EXPECTED RESULT Opened file is added to the last used Kate window SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 39 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 (built against 5.15.10) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432536] Move Mouse To Focus doesn't work as expected on Wayland
https://bugs.kde.org/show_bug.cgi?id=432536 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #1 from Yevhen --- I see a similar behaviour on X11 as well so it doesn't look like a Wayland regression. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432536] Move Mouse To Focus doesn't work as expected on Wayland
https://bugs.kde.org/show_bug.cgi?id=432536 --- Comment #2 from Yevhen --- I did some research on this 1. "Move Mouse to Focus", as well as "Move Mouse To Center", are still a part of the Zoom effect. So "Move Mouse To Center" doesn't work with the "Zoom" effect disabled. However, the former KWin maintainer previously announced the intention to move both actions to the KWin core (https://invent.kde.org/plasma/kwin/-/commit/80bd289e065634cd034e69325c0cc15bf5b5e7de , "Better names for global shortcuts in Zoom Effect"), 2. "Move Mouse to Focus" somehow depends on the "focusPoint" which calculation was changed a few years ago (https://invent.kde.org/plasma/kwin/-/commit/c1ea0412a45a64d99c120eedfa80ef376c7e6610 , "[effects/zoom] Implement focus tracking with QAccessibilityClient"). 3. I've also tried Kubuntu 14.04.5 live USB (with KDE SC 4.13) but unfortunately haven't figured out how to get the "Move Mouse to Focus" action to work. --- Conclusions: 1. "Move Mouse To Center" action still works well on both X11 and Wayland and doesn't seem to have a direct connection to the Zoom effect, so probably can be moved to the KWin core. 2. "Move Mouse to Focus" action seems broken even on the KDE SC 4.13, and if someone is going to fix or re-implement it, please make it independent of the "Zoom" effect's "Focus Tracking". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462448] Switching Virtual Desktops with Ctrl+Alt+MouseWheel seems inverted
https://bugs.kde.org/show_bug.cgi?id=462448 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #1 from Yevhen --- Until this issue is resolved, I'm attaching proposed patch from the relevant merge request (https://invent.kde.org/plasma/kwin/-/merge_requests/4602). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462448] Switching Virtual Desktops with Ctrl+Alt+MouseWheel seems inverted
https://bugs.kde.org/show_bug.cgi?id=462448 --- Comment #2 from Yevhen --- Created attachment 163520 --> https://bugs.kde.org/attachment.cgi?id=163520&action=edit Patch for KWin 5.27.x -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462448] Switching Virtual Desktops with Ctrl+Alt+MouseWheel seems inverted
https://bugs.kde.org/show_bug.cgi?id=462448 --- Comment #3 from Yevhen --- Created attachment 163521 --> https://bugs.kde.org/attachment.cgi?id=163521&action=edit Patch for KWin 5.27.80 (Plasma 6 Alpha) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462448] Switching Virtual Desktops with Ctrl+Alt+MouseWheel seems inverted
https://bugs.kde.org/show_bug.cgi?id=462448 Yevhen changed: What|Removed |Added Attachment #163520|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462448] Switching Virtual Desktops with Ctrl+Alt+MouseWheel seems inverted
https://bugs.kde.org/show_bug.cgi?id=462448 --- Comment #4 from Yevhen --- Created attachment 163522 --> https://bugs.kde.org/attachment.cgi?id=163522&action=edit Patch for KWin 5.27.9 (Plasma 5 Stable) (In reply to Yevhen from comment #2) > Created attachment 163520 [details] > Patch for KWin 5.27.x This one depends on another patch. Here's a correct one for Plasma 5.27.9 -- You are receiving this mail because: You are watching all bug changes.
[XWaylandVideoBridge] [Bug 477595] New: Invisible window on KDE Plasma Task Switcher and Pager
https://bugs.kde.org/show_bug.cgi?id=477595 Bug ID: 477595 Summary: Invisible window on KDE Plasma Task Switcher and Pager Classification: Applications Product: XWaylandVideoBridge Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com CC: aleix...@kde.org, k...@davidedmundson.co.uk Target Milestone: --- Created attachment 163525 --> https://bugs.kde.org/attachment.cgi?id=163525&action=edit Screenshot of the XWaylandVideoBridge item on Switcher and Pager SUMMARY Invisible window of the XWaylandVideoBridge is available for selection in Task Switcher. Icon is also visible on Pager/Overview. STEPS TO REPRODUCE 1. Make sure that XWaylandVideoBridge is running (it's generally visible in System Tray) 2. Press Alt+Tab to trigger Task Switcher 3. See selectable "Wayland to X Recording bridge" — Xwayland Video Bridge" item OBSERVED RESULT XWaylandVideoBridge window is invisible EXPECTED RESULT As user can't interact with content of the XWaylandVideoBridge window, it should not appear on Switcher and Pager SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite 40 Nightly (Plasma 6 Alpha image) KDE Plasma Version: 5.80 KDE Frameworks Version: 5.245.0 Qt Version: 6.6.0 -- You are receiving this mail because: You are watching all bug changes.
[XWaylandVideoBridge] [Bug 477595] Invisible window on KDE Plasma Task Switcher and Pager
https://bugs.kde.org/show_bug.cgi?id=477595 --- Comment #1 from Yevhen --- Created attachment 163526 --> https://bugs.kde.org/attachment.cgi?id=163526&action=edit KWin Rule to skip XWaylandVideoBridge on Switcher and Pager Simple workaround is to create the KWin Window Rule: Window class (application): xwaylandvideobridge Skip pager: Force Skip switcher: Force -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432536] Move Mouse To Focus doesn't work as expected on Wayland
https://bugs.kde.org/show_bug.cgi?id=432536 --- Comment #4 from Yevhen --- Created attachment 163558 --> https://bugs.kde.org/attachment.cgi?id=163558&action=edit Unofficial patch for KWin 5.27 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 432536] Move Mouse To Focus doesn't work as expected on Wayland
https://bugs.kde.org/show_bug.cgi?id=432536 --- Comment #5 from Yevhen --- Created attachment 163559 --> https://bugs.kde.org/attachment.cgi?id=163559&action=edit Unofficial patch for KWin 5.80 (Plasma 6 Alpha) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477625] Weird icon placement of apps that do not have window in Dekstop Overview
https://bugs.kde.org/show_bug.cgi?id=477625 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #6 from Yevhen --- Created attachment 163605 --> https://bugs.kde.org/attachment.cgi?id=163605&action=edit After commit 9ee3d7a2 XWayland Video Bridge is still visible in Overview (In reply to Jakub from comment #4) > (In reply to David Redondo from comment #2) > > > > *** This bug has been marked as a duplicate of bug 477025 *** > > Can still reproduce. I do not have Wayland to X11 Video Bridge in the task > switcher, but I do have it in the Dekstop Overview. This is no a duplicate > of https://bugs.kde.org/show_bug.cgi?id=477025 I'm not sure if it's a Pager thing, but even with https://invent.kde.org/system/xwaylandvideobridge/-/commit/9ee3d7a21ee3069e37a205318914f48b2b597eaa applied (which is supposed to close 477394, 477595 and 477625 I still can see XWayland Video Bridge item in the overview. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453506] Need to kick hotkeys on release, not press
https://bugs.kde.org/show_bug.cgi?id=453506 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #6 from Yevhen --- Is there a chance to have this bug fixed on Wayland? For KWin Wayland I'm not aware of any workarounds. Old XKB patch (https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865.patch?h=xorg-server-bug865) doesn't help on Wayland. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 476344] New: Wayland: global scale reduces size of the virt-manager graphical console
https://bugs.kde.org/show_bug.cgi?id=476344 Bug ID: 476344 Summary: Wayland: global scale reduces size of the virt-manager graphical console Classification: Plasma Product: kwin Version: 5.27.8 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- Created attachment 162744 --> https://bugs.kde.org/attachment.cgi?id=162744&action=edit Scaling of the virt-manager graphical console on Wayland SUMMARY On the Wayland session, when a user increases the value of the "Global scale", Virtual Machine Manager's graphics console scales as well showing virtual machine content in a very small size. STEPS TO REPRODUCE 1. Go to the System Settings > Display and Monitor > Display configuration 2. Set "Global scale" to 125% 3. Launch QEMU/KVM virtual machine using virt-manager 4. Go to the graphical console OBSERVED RESULT The rendered image is very small (approx 1/3 of the expected image) EXPECTED RESULT Graphical console doesn't get scaled SOFTWARE/OS VERSIONS Linux: Fedora 39 Kinoite KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION X11 version does seem not affected. Screenshots attached. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 476344] Wayland: global scale reduces size of the virt-manager graphical console
https://bugs.kde.org/show_bug.cgi?id=476344 --- Comment #1 from Yevhen --- Created attachment 162745 --> https://bugs.kde.org/attachment.cgi?id=162745&action=edit Scaling of virt-manager graphical console on X11 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 476353] New: Trigger keyboard layout switch shortcuts on release, not press
https://bugs.kde.org/show_bug.cgi?id=476353
Bug ID: 476353
Summary: Trigger keyboard layout switch shortcuts on release,
not press
Classification: Plasma
Product: kwin
Version: 5.27.8
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: input
Assignee: kwin-bugs-n...@kde.org
Reporter: xalt7x.serv...@gmail.com
Target Milestone: ---
SUMMARY
Nowadays many application shortcuts involve Ctrl+Shift and Alt+Shift
combinations. On Linux desktops some shortcuts for keyboard layout switching
conflict with them. For example, if a user binds "Ctrl+Shift" for keyboard
layout switching, combinations like Ctrl+Shift+C (paste into terminal emulator)
or Ctrl+Shift+Z (Redo action) wouldn't work as "Shift" will be used for
keyboard layout switching. It's an infamous X11 XCB issue that gets inherited
on Wayland. All previous bug reports suggested changing XCB behavior to trigger
a keyboard layout switching on hotkeys release rather than on press. An
unofficial patch for X11 still exists but it doesn't work for Wayland.
STEPS TO REPRODUCE
1. Open "System Settings" > "Keyboard" > "Layouts" > "Shortcuts for Switching
Layout" > "Main Shortcuts"
2. Select Ctrl+Shift option for "Switching to another layout"
3. Copy some terminal command (.e.g., echo 1) to your clipboard
4. Open a terminal emulator (e.g. Konsole)
5. Press Ctrl+Shift+V
OBSERVED RESULT
The command gets pasted to the Konsole
EXPECTED RESULT
The command doesn't get pasted to the Konsole
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 39 Kinoite
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.10
ADDITIONAL INFORMATION
This issue is important mostly because this old XCB provides bad UX:
1. For users who are comfortable with those classic ("Windows") combinations
2. For users that are not aware of this issue. Some programs expose these XCB
options (e.g. KDE System Settings, GNOME Tweaks), and some installers (e.g.
Fedora Anakonda or Debian installer) might even select Alt+Shift by default for
non-English locales. No one warns about potential issues. As a result, users
receive broken shortcuts (e.g. Alt+Shift+Tab) until they somehow find a way to
fix it.
There was the same bug for KWin X11 and as the XCB bug won't be fixed, KDE
maintainers suggested opening another bug.
Related topics:
https://bugs.kde.org/show_bug.cgi?id=453506
https://bugs.freedesktop.org/show_bug.cgi?id=865
https://gitlab.freedesktop.org/xorg/xserver/-/issues/258
https://aur.archlinux.org/packages/xorg-server-bug865
https://gitlab.freedesktop.org/wayland/weston/-/issues/207
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 453506] Need to kick hotkeys on release, not press
https://bugs.kde.org/show_bug.cgi?id=453506 --- Comment #8 from Yevhen --- (In reply to George from comment #7) > (In reply to Yevhen from comment #6) > > Is there a chance to have this bug fixed on Wayland? > > For KWin Wayland I'm not aware of any workarounds. Old XKB patch > > (https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865. > > patch?h=xorg-server-bug865) doesn't help on Wayland. > > It will most likely never be fixed by Wayland because it inherited > libxkbcommon, that employs this very bug/behaviour. As it was never fixed in > Xorg, because the specification is just old and bad (but it worked for > 40-something years and people are afraid to change something like that with > no new spec in sight). > > There may be some kind of a solution by the KDE team, as was discussed here > and elsewhere, but I doubt that, given little numbers of people who care or > whatever. And there's also this argument that you can change your hotkeys to > something like Win+Space (or any other ungodly combination) and pretend that > this bug doesn`t exist. I know, it's sad, but even I did it in the end. > > Anyway, you can try and submit a bug as per Andrey's request. I'll gladly > join the discussion. Thanks for the answer and suggestion. The new issue is here → https://bugs.kde.org/show_bug.cgi?id=476353 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 476353] Trigger keyboard layout switch shortcuts on release, not press
https://bugs.kde.org/show_bug.cgi?id=476353 Yevhen changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Yevhen --- Accidentally found older bug report https://bugs.kde.org/show_bug.cgi?id=420493 So, I'm marking this one as a duplicate. *** This bug has been marked as a duplicate of bug 420493 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #6 from Yevhen --- *** Bug 476353 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453506] Need to kick hotkeys on release, not press
https://bugs.kde.org/show_bug.cgi?id=453506 --- Comment #9 from Yevhen --- As it turns out, there was an even older related bug report: https://bugs.kde.org/show_bug.cgi?id=420493 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476394] New: Access to notification history requires password if the list contains past kio-admin related actions
https://bugs.kde.org/show_bug.cgi?id=476394 Bug ID: 476394 Summary: Access to notification history requires password if the list contains past kio-admin related actions Classification: Plasma Product: plasmashell Version: 5.27.8 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Notifications Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com CC: k...@privat.broulik.de Target Milestone: 1.0 Created attachment 162783 --> https://bugs.kde.org/attachment.cgi?id=162783&action=edit Screencast of the Notification history "kio-admin" issue SUMMARY If the user performed some "kio-admin"-related action (e.g. copied files in Dolphin) and it was saved in the Notification history, after PolKit authentication expires (5 minutes), the user will be asked for a password after opening the "Notification" widget. STEPS TO REPRODUCE 1. Create root-owned directory sudo mkdir -p /tmp/test 2. Create test file inside this directory sudo fallocate -l 1G /tmp/test/1G-File 3. Using Dolphin file manager navigate to the /tmp/test/ directory 4. Gain administrative privileges using admin:// KIO protocol Input admin:/tmp/test in the address bar and enter password 5. Make a copy of the 1G-File using drag'n'drop and rename function 6. Use the "Notification" widget or tray item to make sure that the "copy" action was recorded in the notification history. 7. Wait until Polkit's temporary authorization expires (on most distros it's hardcoded to 5 minutes) 8. Open the "Notification" widget or tray item to see the Notification history OBSERVED RESULT I need to input the administrator password presumably because Plasma needs access to the admin:/// location EXPECTED RESULT I'd like to get asked for a password only during some interaction with the Notification history list item (e.g. "Open" action). Alternatively, I don't mind getting interaction with admin:/// disabled on the Notifications widget or tray item SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 39 Kinoite (also tested with Debian 12) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Screencast which shows this issue, is attached to this report. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476394] Access to notification history requires password if the list contains past kio-admin related items
https://bugs.kde.org/show_bug.cgi?id=476394 Yevhen changed: What|Removed |Added Summary|Access to notification |Access to notification |history requires password |history requires password |if the list contains past |if the list contains past |kio-admin related actions |kio-admin related items -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 --- Comment #7 from Yevhen --- I've tested Andrey suggestion from https://bugs.kde.org/show_bug.cgi?id=453506#c3 Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could be "Meta", "Alt", "Shift" and "Control", according to the https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/modifier_only_shortcut_test.cpp) which triggers action on release (not press). So I assigned "Shift" to the qdbus command to switch the keyboard layout kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout' qdbus org.kde.KWin /KWin reconfigure Looks like this is the way! Now I can switch keyboard layouts with a single "Shift" press. But when I use combinations involving "Shift", the keyboard layout doesn't change and combinations seem to work properly. E.g., I can type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal emulator, etc. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 420493] Events fire only on key-press instead of on key-release, impossible to blank screen on keypress.
https://bugs.kde.org/show_bug.cgi?id=420493 --- Comment #8 from Yevhen --- (In reply to Yevhen from comment #7) > I've tested Andrey suggestion from > https://bugs.kde.org/show_bug.cgi?id=453506#c3 > Since Plasma 5.8 we can bind "Modifier-only" KWin shortcut (for now it could > be "Meta", "Alt", "Shift" and "Control", according to the > https://invent.kde.org/plasma/kwin/-/blob/Plasma/5.27/autotests/integration/ > modifier_only_shortcut_test.cpp) which triggers action on release (not > press). > So I assigned "Shift" to the qdbus command to switch the keyboard layout > > kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' > 'org.kde.keyboard,/Layouts,org.kde.KeyboardLayouts,switchToNextLayout' > qdbus org.kde.KWin /KWin reconfigure > > Looks like this is the way! Now I can switch keyboard layouts with a single > "Shift" press. But when I use combinations involving "Shift", the keyboard > layout doesn't change and combinations seem to work properly. E.g., I can > type capital letters and other symbols, use Ctrl+Shift+V paste on a terminal > emulator, etc. P.S. qbbus method call for "Alternative shortcut" (which supports "OSD on layout change" on both Wayland and X11) works as well: kwriteconfig5 --file kwinrc --group 'ModifierOnlyShortcuts' --key 'Shift' 'org.kde.kglobalaccel,/component/KDE_Keyboard_Layout_Switcher,org.kde.kglobalaccel.Component,invokeShortcut,Switch to Next Keyboard Layout' qdbus org.kde.KWin /KWin reconfigure -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 473881] New: False detect of "background activity" for Flatpak apps
https://bugs.kde.org/show_bug.cgi?id=473881 Bug ID: 473881 Summary: False detect of "background activity" for Flatpak apps Classification: Plasma Product: xdg-desktop-portal-kde Version: 5.27.7 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com CC: aleix...@kde.org, jgrul...@redhat.com, n...@kde.org Target Milestone: --- Created attachment 161254 --> https://bugs.kde.org/attachment.cgi?id=161254&action=edit Screencast showing auto-close of Flatpak apps on Wayland and X11 sessions SUMMARY On Wayland session xdg-desktop-portal-kde mistakenly detects that Flatpak app as running in the background. Then it shows "special" notification. With many popular Flatpak apps (e.g. org.libreoffice.LibreOffice, org.mozilla.firefox, com.google.Chrome) dialog appears right after program launch. Notification has "Find out more" button. if the user clicks on it, a dialog will appear that will inform that app is running in the background so user need to either "Allow" it or "Force quit". If user simple closes this dialog, action "Force quit" will be chosen automatically and application will automatically close as well. After subsequent launches, the program will close automatically in a few second. As a workaround user needs to override "background" permission with some GUI (like "Flatseal") or command flatpak permission-set background background org.mozilla.firefox yes STEPS TO REPRODUCE (also attached screencast) 1. Login into Wayland session (easier to reproduce) 2. Install some application from Flathub flatpak install flathub org.mozilla.firefox 3. Launch installed app flatpak run org.mozilla.firefox 4. Few seconds after launch notice notification about "Background activity" 5. Click "Find out more" button 6. See dialog with a question about "Background activity" and buttons "Allow", "Force quit". 7. Close this dialog (application will be closed automatically) 8. Relaunch Flatpak application OBSERVED RESULT Application silently closes EXPECTED RESULT KDE Portal should not detect "Background activity for visible applications. KDE Portal should not set "Background" permission if the user closes the dialog and does not select any action, SOFTWARE/OS VERSIONS Linux: Fedora 38 Kinoite KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION As you can see from the screencast, on X11 session KDE Portal have far less false detects of "Background activity". However if permission "Background" is set as denied, apps on X11 session will auto-close as well. Related bugs: https://bugs.kde.org/show_bug.cgi?id=466325 https://bugs.kde.org/show_bug.cgi?id=468805 https://github.com/flathub/org.libreoffice.LibreOffice/issues/249 -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 473881] False detection of "background activity" for Flatpak apps
https://bugs.kde.org/show_bug.cgi?id=473881 Yevhen changed: What|Removed |Added Summary|False detect of "background |False detection of |activity" for Flatpak apps |"background activity" for ||Flatpak apps -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 463298] New: Add number overlay to quickly identify app/window number
https://bugs.kde.org/show_bug.cgi?id=463298
Bug ID: 463298
Summary: Add number overlay to quickly identify app/window
number
Classification: Plasma
Product: plasmashell
Version: master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Task Manager and Icons-Only Task Manager
Assignee: plasma-b...@kde.org
Reporter: xalt7x.serv...@gmail.com
Target Milestone: 1.0
Created attachment 154723
--> https://bugs.kde.org/attachment.cgi?id=154723&action=edit
Number overlay on Ubuntu Dock
GNOME Extensions (Dash to Dock, Dash To Panel) has option called "Number
overlay".
When you switch to some window on a panel using Super+[0-9] (or Super+Q) a
badge with a number over app icon appears.
This feature greatly helps with productivity witch a large number of tasks on a
panel. For example if there's only 4-5 apps running/pinned on a panel, for
average user it's not a problem to find each number and use shortcut
Super+{0-9] . But if there's more (it's a common-case when app windows are
ungrouped), IMO, user won't bother to count or them and use aforementioned
combination (using instead Alt+Tab, mouse selection on a panel etc).
Number overlay appears with GNOME Extension if user:
1) Switches apps with Super+[0-9]
2) Press special keyboard shortcut for that (Super+Q)
3) selected "Always visible" option (it might conflct with different in
As for design and conflict with different badges (progress bar, notifications,
sound), this number overlay could be placed:
- over aforementioned badges (like "Dash to Panel" does). However this one
would conflict with "Always visible" option
- on the opposite side of the task-manager element (this might conflict with
either "sound" indicator or "notification" badge)
I've attached screenshot of "Number overlay" on Ubuntu Dock ("Dash to Dock"
GNOME extension version).
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 460911] New: Default "Maximum rows" value breaks usability of centered "Task Manager" items on a horizontal panel
https://bugs.kde.org/show_bug.cgi?id=460911 Bug ID: 460911 Summary: Default "Maximum rows" value breaks usability of centered "Task Manager" items on a horizontal panel Classification: Plasma Product: plasmashell Version: git-stable-Plasma/5.26 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: 1.0 Created attachment 153154 --> https://bugs.kde.org/attachment.cgi?id=153154&action=edit Recording how to get centered Task Manager with 2 rows SUMMARY Plasma 5.19 introduced better panel spacers so we could actually perfectly center "Task Manager" (as it's shown at @niccolove tutorial (https://youtu.be/mlN9EeKMMsA)) However currently "Task Manager" option which is called "Maximum rows" (for horizontal panel, "Maximum columns" - for vertical) has default value "2". And with such value after adding spacers on both sides of the "Task Manager" we're getting very small icons placed in 2 rows. In order to fix this user must got to settings of the "Task Manager" and lower value of "Maximum rows" to "1". I guess this value is some kind of legacy from very old KDE releases and currently could be safely dropped to "1" by default. STEPS TO REPRODUCE (for vanilla KDE Plasma 5.26.1) 1. Right click on a panel, "Enter Edit Mode" 2. add 2 "Spacers" 3. Place one Spacer to left to the "Icons-Only Task Manager", second - right to the "Icons-Only Task Manager" Recording is attached as well OBSERVED RESULT Size of the Task Manager icons doesn't change and they're placed in one row EXPECTED RESULT Size of the Task Manager icons changes to very small they get placed in two rows SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.26 KDE Plasma Version: 5.26.1 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460911] Default "Maximum rows" value breaks usability of centered "Task Manager" items on a horizontal panel
https://bugs.kde.org/show_bug.cgi?id=460911 --- Comment #1 from Yevhen --- Created attachment 153155 --> https://bugs.kde.org/attachment.cgi?id=153155&action=edit Screenshot of the centered task manager with small icons -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460911] Default "Maximum rows" value breaks usability of centered "Task Manager" items on a horizontal panel
https://bugs.kde.org/show_bug.cgi?id=460911 Yevhen changed: What|Removed |Added Attachment #153154|Recording how to get|Recording how to get description|centered Task Manager with |centered Task Manager with |2 rows |tiny icons -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460911] Default "Maximum rows" value breaks usability of centered "Task Manager" items on a horizontal panel
https://bugs.kde.org/show_bug.cgi?id=460911 Yevhen changed: What|Removed |Added Attachment #153155|Screenshot of the centered |Screenshot of the centered description|task manager with small |task manager with tiny |icons |icons -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 460958] New: Make password change friendly for fscrypt users
https://bugs.kde.org/show_bug.cgi?id=460958 Bug ID: 460958 Summary: Make password change friendly for fscrypt users Classification: Applications Product: systemsettings Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_users Assignee: plasma-b...@kde.org Reporter: xalt7x.serv...@gmail.com CC: uhh...@gmail.com Target Milestone: --- Fscrypt is a modern alternative for escryptfs (which at some point Ubuntu used for a "home" encryption). After initial setup fscrypt is generally hassle-free largely thanks to it's PAM module. Password change is automatically handled as well but there's a little caveat: "Usually, the PAM module pam_fscrypt.so will automatically detect changes to a user's login passphrase and update the user's fscrypt login protector so that they retain access their login-passphrase protected directories. However, sometimes a user's login passphrase can become desynchronized from their fscrypt login protector." So user shouldn't use sudo or root account for a 'passwd' command, otherwise he will have to update login-passphrase protector manually (or change password back). Unfortunately fscrypt users which change password with a standard KDE Plasma "System settings" dialogs face the same issue as with "elevated" 'passwd' command. For some reason fscrypt pam module doesn't receive new password so user need to rollback it or update manually with a command (which fscrypt nicely prints on CLI but obviously it's not visible for GUI users) P.S. I've also tried the same on GNOME 42. There password change with native dialogs happens imperceptibly for fscrypt user. STEPS TO REPRODUCE *** Disclaimer: not all distros and filesystems provide fscrypt support yet. My steps where tested on Kubuntu and KDE Neon with EXT4 filesystem *** 1. Setup and configure fscrypt with a PAM module a) sudo apt -y install libpam-fscrypt b) sudo tune2fs -O encrypt "/dev/" # (e,g, /dev/sda2 , /dev/nvme0n1p2 , /dev/vda1 ; check yours with "sudo fisk -l") c) sudo fscrypt setup d) mkdir ~/fscrypt e )sudo fscrypt encrypt ~/fscrypt --user=$USER f) touch ~/fscrypt/file - select "1 - Your login passphrase (pam_passphrase)" - input $USER password 2. Log-out and Log-in 3. Make sure that ~/fscrypt/file gets unlocked after login 4. Try to change user password with a command passwd $USER 5) Log-out, log-in and make sure that ~/fscrypt/file is still gets unlocked automatically 6) Change user password with "systemsettings" dialogs OBSERVED RESULT ~/fscrypt/file is encrypted EXPECTED RESULT ~/fscrypt/file is decrypted SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.26 KDE Plasma Version: 5.26.1 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION I've also tried the same on GNOME 42. There password change happens imperceptibly for fscrypt user. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461322] New: Simple badge/indicator of unread notifications
https://bugs.kde.org/show_bug.cgi?id=461322
Bug ID: 461322
Summary: Simple badge/indicator of unread notifications
Classification: Plasma
Product: plasmashell
Version: master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Task Manager and Icons-Only Task Manager
Assignee: plasma-b...@kde.org
Reporter: xalt7x.serv...@gmail.com
Target Milestone: 1.0
Created attachment 153406
--> https://bugs.kde.org/attachment.cgi?id=153406&action=edit
Reference for a simple indicator of unread notifications
SUMMARY
Basically this is alternative request for the #460760
(https://bugs.kde.org/show_bug.cgi?id=460760). That report was closed because
it had idea for a hack with unpredictable consequences. Developers and users
clearly won't be happy with buggy numbers on badges ("-1". "0") etc.
This one is much simpler and doesn't look that much different from sound
markers, volume controls etc on application icons or previews so I hope
developers will consider this option.
As we all know currently there's only one proper universal API for notification
badge - Unity API. KDE Plasma supports it but most applications doesn't and
most probably never will for multiple reasons. So with default "Icons-Only Task
Manager", user which was away for some time could easily miss that application
had some updates (chat message, email etc).
Having used "RocketBar" GNOME extension* for some time I realized that It's not
that important to have a number of unread messages (535 messages from social
network groups or 150 unread emails). But simple red indicator/badge on top of
an application icon could be enough to get the user's attention to the program.
Some would actually prefer it over badges with numbers as it looks much
cleaner.
I've attached screenshot with comparison of RocketBar* implementation and
classic badges.
KDE Plasma clearly knows which application generated notification and when that
notification has been read. So I hope implementation of this won't be very
hard.
STEPS TO REPRODUCE
1. Receive a notification about new message at any messaging application that
doesn't support UnityAPI ("Thunderbird", "Google Chat", Viber, Skype, Electron
chat apps etc)
2. Check if application icon at "Icons-only Taskbar has an "unread
notification" badge
OBSERVED RESULT
Application icon doesn't inform about new messages
EXPECTED RESULT
Application icon has a badge with an unread messages counter
* https://github.com/linux-is-awesome/gnome_extension_rocketbar
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 461322] Simple badge/indicator of unread notifications
https://bugs.kde.org/show_bug.cgi?id=461322 --- Comment #2 from Yevhen --- (In reply to Nate Graham from comment #1) Thanks for the explanation. If you don't mind I still have a few questions :) > Some apps use system notifications, some don't. That's true (e.g. Viber) and naturally they don't show-up at the notification history > Some update their own counts dynamically, some don't. I'm not sure but looks like that's a problem for https://bugs.kde.org/show_bug.cgi?id=460785 as well. I didn't inspect how RocketBar deal with this. Possible workaround is to remove badge when user switch to the application window. Thanks in advance! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464366] New: Limit the minimum window size
https://bugs.kde.org/show_bug.cgi?id=464366 Bug ID: 464366 Summary: Limit the minimum window size Classification: Plasma Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com Target Milestone: --- Created attachment 155344 --> https://bugs.kde.org/attachment.cgi?id=155344&action=edit Demonstation of the issue with KWin SUMMARY Some programs don't limit size of it's windows so user could accidentally resize them to unusable state. Primary example is LibreOffice ([bugreport](https://bugs.documentfoundation.org/show_bug.cgi?id=151870) at LibreOffice bugtracker) Issue is reproducible on both X11 and Wayland sessions. I've also tried other desktop environments. On GNOME X11 it's more or less the same but with GNOME Wayland or Windows 10 minimum size is limited to a headerbar height. KWin rule is a very nice and simple workaround for this issue but still would be great to have some safe defaults. STEPS TO REPRODUCE 1. Launch LibreOffice Calc 2. Drag diagonally by some corner OBSERVED RESULT Window resized to tiny size so I'm enable to close it with a left click. I have to use context menu (Alt+F3, right click on taskbar) Meta+RMB resize. EXPECTED RESULT Some sensible minimum size limit so user could easily use window controls, drag window, resize it back etc SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Version doesn't really matter as it's also reproducible on the latest KDE Neon (5.26.80) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464366] Limit minimum window size by default
https://bugs.kde.org/show_bug.cgi?id=464366 Yevhen changed: What|Removed |Added Summary|Limit the minimum window|Limit minimum window size |size|by default -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464366] Limit minimum window size by default
https://bugs.kde.org/show_bug.cgi?id=464366 Yevhen changed: What|Removed |Added Component|decorations |general -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464366] Limit minimum window size by default
https://bugs.kde.org/show_bug.cgi?id=464366 --- Comment #2 from Yevhen --- (In reply to Vlad Zahorodnii from comment #1) > Libreoffice doesn't set reasonable minimum size > > [ 891583.742] -> xdg_toplevel@37.set_min_size(0, 29) > > Please report this issue to libreoffice developers. It's reported already (https://bugs.documentfoundation.org/show_bug.cgi?id=151870) I don't know what to add to that bugreport. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464366] Limit minimum window size by default
https://bugs.kde.org/show_bug.cgi?id=464366 --- Comment #3 from Yevhen --- (In reply to Vlad Zahorodnii from comment #1) Anyway, thanks for looking at it. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 482800] Kate hangs if the open sysfs file has been modified externally
https://bugs.kde.org/show_bug.cgi?id=482800 Yevhen Popok changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Yevhen Popok --- (In reply to Christoph Cullmann from comment #5) > Hi, the info provided some hints. > Could you try out the patched version? This solved the problem. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[KRdp] [Bug 488858] Add option to force software H264 encoding even when a valid radeonsi device is present
https://bugs.kde.org/show_bug.cgi?id=488858 Yevhen Popok changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #2 from Yevhen Popok --- (In reply to Akseli Lahtinen from comment #1) > You can try to force software encoding with following: > > KPIPEWIRE_FORCE_ENCODER=libx264_baseline krdpserver -u test -p test > > or > > KPIPEWIRE_FORCE_ENCODER=libx264 krdpserver -u test -p test > > Does either of these work for you? If so, maybe this flag could be used in > Fedora Kinoite to force it, until if/when we can come up with additional GUI > setting? The problem is that libx264 is not in the main repository but on the RPMFusioion (https://github.com/rpmfusion/x264). Which means that just like with openh264, that still requires user actions. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488204] Klipper messages are saved in the Notification History since Plasma 6.0
https://bugs.kde.org/show_bug.cgi?id=488204 --- Comment #4 from Yevhen Popok --- (In reply to Yevhen Popok from comment #3) > (In reply to Yevhen Popok from comment #0) > > ADDITIONAL INFORMATION > > I didn't figured out how to set make configuration specifically for Klipper > > so for now as a workaround I've set "urgency level" for plasmashell > > "Notifications" to "Low" (notification with the "Low" urgency are not saved > > to Notification History by default) > > > > ~/.config/plasma_workspace.notifyrc > > [Event/notification] > > Action=Popup > > Urgency=Low Turns out, it's mostly useless workaround because sometimes it breaks switching between entries (e.g., keyboard shortcut triggers notification but doesn't switch to the next/previous entry). for now I just hide the Notifications element in System Tray. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 482800] Kate hangs if the open sysfs file has been modified externally
https://bugs.kde.org/show_bug.cgi?id=482800 Yevhen Popok changed: What|Removed |Added Summary|Kate freezes if an open |Kate hangs if the open |file with Linux device |sysfs file has been |information has been|modified externally |modified externally | -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 488177] New: Dolphin can't open files or terminal window in sysfs directories
https://bugs.kde.org/show_bug.cgi?id=488177 Bug ID: 488177 Summary: Dolphin can't open files or terminal window in sysfs directories Classification: Applications Product: dolphin Version: 24.05.0 Platform: Other OS: Linux Status: REPORTED Keywords: regression, usability Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: xalt7x.serv...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Dolphin 24.05 can't open files in sysfs directories (e.g., /sys/devices). "Open terminal here" doesn't work as well. STEPS TO REPRODUCE 1. Go to /sys/devices/system/cpu/cpu1/ 2. Try to open "online" file 3. Also try to select "Open Terminal Here" from right click menu OBSERVED RESULT After clicking on a file Dolphin shows errors "WorkingDirectory= may not be below /proc/, /sys/ or /dev/" After trying to open terminal window, I see a similar error in output "kf.kio.gui: Failed to launch process as service: "app-org.kde.konsole@e156273d27aa4b15980cf5421e36f26c.service" "org.freedesktop.DBus.Error.InvalidArgs" "WorkingDirectory= may not be below /proc/, /sys/ or /dev/"" EXPECTED RESULT I can launch files and new terminal windows from sysfs directories. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Kinoite Rawhide (preview of Fedora 41) KDE Plasma Version: 6.0.90 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Dolphin 24.02.2 doesn't have this issue -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 453661] Global shortcuts are not working across multiple keyboard layouts (US and CZ for me)
https://bugs.kde.org/show_bug.cgi?id=453661 Yevhen Popok changed: What|Removed |Added CC||xalt7x.serv...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488204] New: Klipper messages are saved in the Notification History since Plasma 6.0
https://bugs.kde.org/show_bug.cgi?id=488204
Bug ID: 488204
Summary: Klipper messages are saved in the Notification History
since Plasma 6.0
Classification: Plasma
Product: plasmashell
Version: 6.0.0
Platform: Other
OS: Linux
Status: REPORTED
Keywords: regression, reproducible, usability
Severity: normal
Priority: NOR
Component: Clipboard
Assignee: plasma-b...@kde.org
Reporter: xalt7x.serv...@gmail.com
Target Milestone: 1.0
Created attachment 170267
--> https://bugs.kde.org/attachment.cgi?id=170267&action=edit
Screencast demonstrating the issue (Plasma 5.27 vs Plasma 6.0)
SUMMARY
Plasmashell native clipboard manager sometimes generates messages (e.g., when
user cycles through history items using hotkeys).
On Plasma 5.27 they were not saved on Notification History (presumably thanks
to commit 120aed57 ("Keep Klipper notifications out of notification history") -
https://invent.kde.org/plasma/plasma-workspace/-/commit/120aed57ced1530d85e4d522cfb3697fbce605fc).
However, on Plasma 6.0 and 6.1 Beta Notification tray item (or a separate
widget) notifies user of new unread messages whenever the notification for the
current history item expires.
This regression may be related to Plasma 6 cleanup (e.g., commits a5e40fe5 and
8fa3fbf2).
STEPS TO REPRODUCE (screencast attached as well)
1. Right click on clipboard system tray item and select "Configure
Clipboard..."
2. On "Shortcuts" section set some shortcuts for "Previous History Item" (e.g.,
Meta+Shift+z)
3. Copy few times different text so it will be saved as Clipboard Manager item
4. Press the "Previous History Item" shortcut
5. Wait ~5 seconds until Clipboard Notification expires
OBSERVED RESULT
Notification tray item informs that there's a new item in the Notification
History
EXPECTED RESULT
Clipboard Manager notification is not saved to Notification History.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora Kinoite 40
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1
ADDITIONAL INFORMATION
I didn't figured out how to set make configuration specifically for Klipper so
for now as a workaround I've set "urgency level" for plasmashell
"Notifications" to "Low" (notification with the "Low" urgency are not saved to
Notification History by default)
~/.config/plasmanotifyrc
[Event/notification]
Action=Popup
Urgency=Low
--
You are receiving this mail because:
You are watching all bug changes.
[klipper] [Bug 408989] klipper should not record selection changes to notification history
https://bugs.kde.org/show_bug.cgi?id=408989 Yevhen Popok changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=488204 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488204] Klipper messages are saved in the Notification History since Plasma 6.0
https://bugs.kde.org/show_bug.cgi?id=488204 Yevhen Popok changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=408989 --- Comment #2 from Yevhen Popok --- (In reply to Nate Graham from comment #1) > > This regression may be related to Plasma 6 cleanup (e.g., commits a5e40fe5 > > and 8fa3fbf2). > Can you share Invent URLs to these commits? I can't figure out which repo > they're in. Sure. It's on the plasma-workspace repo: https://invent.kde.org/plasma/plasma-workspace/-/commit/a5e40fe5 https://invent.kde.org/plasma/plasma-workspace/-/commit/8fa3fbf2 Also here's Kai's fix for bug 408989 - https://phabricator.kde.org/D21963 Though it's just my theory, I didn't try to get standalone Klipper back. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 488204] Klipper messages are saved in the Notification History since Plasma 6.0
https://bugs.kde.org/show_bug.cgi?id=488204 --- Comment #3 from Yevhen Popok --- (In reply to Yevhen Popok from comment #0) > ADDITIONAL INFORMATION > I didn't figured out how to set make configuration specifically for Klipper > so for now as a workaround I've set "urgency level" for plasmashell > "Notifications" to "Low" (notification with the "Low" urgency are not saved > to Notification History by default) > > ~/.config/plasmanotifyrc > [Event/notification] > Action=Popup > Urgency=Low Here I mentioned incorrect file, should be ~/.config/plasma_workspace.notifyrc -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 482800] Kate hangs if the open sysfs file has been modified externally
https://bugs.kde.org/show_bug.cgi?id=482800 --- Comment #3 from Yevhen Popok --- Created attachment 170567 --> https://bugs.kde.org/attachment.cgi?id=170567&action=edit GDB backtrace (In reply to Christoph Cullmann from comment #2) > Could you provide some backtrace where we are stuck or use perf to check in > which function we are hanging around? I added backtrace generated with GDB + debuginfod on KDE Neon Developer Edition. Hope this helps. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459389] Copy and paste do not work in Wayland when using some text editors in konsole and some applications
https://bugs.kde.org/show_bug.cgi?id=459389 Yevhen Popok changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #31 from Yevhen Popok --- I have the same issue on Fedora 40 and QEMU/KVM-based virtual machines (started with Virt Manager or Gnome Boxes) . (In reply to Lorenzo Bettini from comment #30) > I cannot copy and paste from host to VM and > vice-versa, when the VM is KDE Wayland. Same here. I'm using Fedora 40 and QEMU/KVM-based virtual machines (Virt Manager / Virt Viewer / Gnome Boxes). Can we please re-open this issue? Seems like it's not resolved. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 480947] Discover is randomly restarting the search for updates after displaying the results for few seconds
https://bugs.kde.org/show_bug.cgi?id=480947 Yevhen Popok changed: What|Removed |Added CC||xalt7x.serv...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 425054] KWin crash when repeatedly triggering present windows hot corner
https://bugs.kde.org/show_bug.cgi?id=425054 Yevhen Sayenko changed: What|Removed |Added CC||yevhensaye...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 483055] Dolphin does not have a mechanism for mounting network shares in userspace
https://bugs.kde.org/show_bug.cgi?id=483055 Yevhen Popok changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #3 from Yevhen Popok --- This is actually implemented in kio-fuse, See: https://invent.kde.org/system/kio-fuse#running-kio-fuse-manually > Let's assume you want to make the files at > ftp://user:password@server/directory accessible in your local file system. > send the corresponding mount command > dbus-send --session --print-reply --type=method_call --dest=org.kde.KIOFuse > /org/kde/KIOFuse org.kde.KIOFuse.VFS.mountUrl > string:ftp://user:password@server/directory > If it succeeded, you will get the location that the URL is mounted on as a > reply. In this case it would be $dir/ftp/user@server/directory and the > directory will be accessibly at that URL. > After your work is done, simply run > fusermount3 -u $dir > to unmount the URL and exit kio-fuse. Unfortunately it uses single kio-fuse top directory (e.g., /run/user/1000/kio-fuse-IKQugV) for different mounts so you can't really unmount some particular network location. That might be one of the reason why this feature is still not exposed to the GUI. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 483055] Dolphin does not have a mechanism for mounting network shares in userspace
https://bugs.kde.org/show_bug.cgi?id=483055 Yevhen Popok changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=432856 -- You are receiving this mail because: You are watching all bug changes.
[kiofuse] [Bug 432856] Can't reopen remote files using common "File, Open recent" menu option
https://bugs.kde.org/show_bug.cgi?id=432856 Yevhen Popok changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=483055 -- You are receiving this mail because: You are watching all bug changes.
