[Powerdevil] [Bug 441057] Support 60% Charge Limit threshold for Lenovo Ideapad and Legion laptops
https://bugs.kde.org/show_bug.cgi?id=441057 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486610] New: Support locking tabs
https://bugs.kde.org/show_bug.cgi?id=486610 Bug ID: 486610 Summary: Support locking tabs Classification: Applications Product: dolphin Version: unspecified Platform: Exherbo OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: bars: location Assignee: dolphin-bugs-n...@kde.org Reporter: li...@bernd-steinhauser.de CC: kfm-de...@kde.org Target Milestone: --- SUMMARY First, thanks for developing dolphin, I've been using it ever since it was first included in KDE 4 and really enjoy using it. However, there are sometimes still features that I'm missing and one of those is the ability to lock tabs. I know this feature from Free Commander, which I do use on Windows systems. Here, three versions can be selected, of which each can be useful in their own way. I like this feature, because I have folders (e.g. code folders) that I use very often and together with the ability to rename tabs (which is also not implemented) it makes it easier and better to keep the tabs organized. 1. Lock tab, don't allow navigation 2. Lock tab, allow navigation to subfolders 3. Lock tab, allow any navigation The expected behavior would be the following: - Could be implemented by context menu on tab button - When navigation against the locking rule is requested (e.g. parent folder), create a duplicate of the tab that is not locked and jump to that folder - If navigation is allowed: when selecting a different tab and then going back to the locked tab, jump back to the originally locked folder. (This is debatable for 2., but should be the behavior for 3.) - When attempting to close the tab, ask for verification SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.8-amdgpu (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C90 System Version: 1.0 ADDITIONAL INFORMATION Here is a link to the Free Commander online help that also describes the feature: https://www.freecommander.com/fchelpxe/en/Tabareawithtabs.html -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 447139] Lock location of multiple Dolphin windows.
https://bugs.kde.org/show_bug.cgi?id=447139 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #1 from Bernd Steinhauser --- Can't you achieve that using window rules, e.g. matching the window title? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 436318] Save session doesn't work under Wayland
https://bugs.kde.org/show_bug.cgi?id=436318 --- Comment #97 from Bernd Steinhauser --- (In reply to Patrick O'Callaghan from comment #96) > > (you'll have to scroll down. The current list archive system doesn't seem to > offer links to a specific message). Click on the link symbol in the upper right corner of the message. https://lists.fedoraproject.org/archives/list/k...@lists.fedoraproject.org/message/HP26SLPOXK264324MAJMVC24MDEMOXQ7/ -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 484995] When taking rectangle screen shot, screen edge triggers should be blocked
https://bugs.kde.org/show_bug.cgi?id=484995 --- Comment #4 from Bernd Steinhauser --- I tried with a single screen and there I couldn't reproduce it or only if I used tricks like Alt+Tab to steal the focus away from spectacle. Interestingly, when I went back to multiscreen (same setup as before), I couldn't reproduce it either anymore. No idea what is different now. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 484995] When taking rectangle screen shot, screen edge triggers should be blocked
https://bugs.kde.org/show_bug.cgi?id=484995 --- Comment #2 from Bernd Steinhauser --- (In reply to Noah Davis from comment #1) > On my 2 monitor setup, it seems that the screen edge hotspots are only > triggerable when the spectacle window near a hotspot is not focused. Hm, not quite sure what you mean. I'm using a 2 monitor setup and I've setup the upper left screen edge. No matter what window is focused, it always seems to trigger for me? -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 484995] New: When taking rectangle screen shot, screen edge triggers should be blocked
https://bugs.kde.org/show_bug.cgi?id=484995 Bug ID: 484995 Summary: When taking rectangle screen shot, screen edge triggers should be blocked Classification: Applications Product: Spectacle Version: 24.02.1 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: li...@bernd-steinhauser.de CC: k...@david-redondo.de Target Milestone: --- SUMMARY When entering (rectanlge) screenshot mode, I don't think anybody would want to activate any of these effects, but rather just select the area they want to capture. Thus, for the time until the selection was finished, spectacle should tell the kwin to block these as well as possibly other gesture-activated functions. (That is, unless on some devices a gesture would be required to exit the selection mode?) Note that I wasn't sure whether this classifies as a bug or a wishlist item. Personally I see it as the former, since in my opinion currently something is happening that really shouldn't be happening, but I could see why one would consider it just as a wish. I also wasn't sure if this should be assigned to spectacle or some plasma component. STEPS TO REPRODUCE 1. Systemsettings -> Mouse & Touchpad -> Screen Edges -> Setup some action there, e.g. "Overview" 2. Start spectacle's rectangle selection via hotkeys 3. Move the cursor towards the screen edge as configured previously OBSERVED RESULT The selected effect executes. EXPECTED RESULT Desktop should ignore screen edge and stay in selection mode. SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.7.11-amdgpu (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C90 System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 484363] New: Sometimes, on a multimonitor setup, screen locker fails to unlock screen and shows "Unlock" button that does nothing
https://bugs.kde.org/show_bug.cgi?id=484363 Bug ID: 484363 Summary: Sometimes, on a multimonitor setup, screen locker fails to unlock screen and shows "Unlock" button that does nothing Classification: Plasma Product: kscreenlocker Version: 6.0.2 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- SUMMARY This is very similar to what was reported in bug 456210, except that that bug is for Plasma 5 and is supposed to be fixed. Unfortunately, it doesn't happen every time, so it's unclear what the exact circumstances are. STEPS TO REPRODUCE 1. Lock screen 2. Enter password to unlock screen 3. Click the "Unlock" button that appears OBSERVED RESULT Nothing happens. EXPECTED RESULT Unlock screen. SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.9-amdgpu (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C90 System Version: 1.0 ADDITIONAL INFORMATION A workaround is to unlock the screen by switching to a TTY, performing a login and then using loginctl to unlock the screen: loginctl unlock-session 2 There is not much in the journal suggesting that there is an issue with login, screen locker or similar: kwin_wayland[1606]: kwin_core: XCB error: 147 (BadOutput), sequence: 63170, resource id: 1127, major code: 140 (RANDR), minor code: 30 (SetOutputPrimary) kwin_wayland[1606]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state kwin_wayland[1606]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state kscreenlocker_greet[2558460]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile kwin_wayland[1606]: kwin_core: KWin::LayerShellV1Window doesn't support setting maximized state kwin_wayland[1606]: kwin_core: KWin::LayerShellV1Window doesn't support setting fullscreen state kscreenlocker_greet[2558460]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/NoPasswordUnlock.qml:26: ReferenceError: tryToSwitchUser is not defined kscreenlocker_greet[2558460]: file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/NoPasswordUnlock.qml:26: ReferenceError: tryToSwitchUser is not defined All other messages are just kernel finding new devices because the screens were turned on and a lot of complains from and about firefox. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 408775] Do not close/destroy tab when closing view
https://bugs.kde.org/show_bug.cgi?id=408775 --- Comment #32 from Bernd Steinhauser --- (In reply to Kurt Hindenburg from comment #31) > Let us know if you still have this issue on a recent version As I wrote in the previous post, I'm fine with closing the issue. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Under certain circumstances when using multiple monitors, "unlock" button is clickable but does nothing
https://bugs.kde.org/show_bug.cgi?id=456210 --- Comment #84 from Bernd Steinhauser --- Despite being marked as resolved, this still occurs to me sometimes on Plasma 6.0. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 473472] Discover crashes when refreshing updates
https://bugs.kde.org/show_bug.cgi?id=473472 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 426276] Split view: change view shortcuts
https://bugs.kde.org/show_bug.cgi?id=426276 --- Comment #6 from Bernd Steinhauser --- (In reply to Alfonso Murolo from comment #5) > Interesting, is that also supported in tmux? (I do not have a lot of > experience with it). Neither do I, but here's an excerpt of the manual: https://www.man7.org/linux/man-pages/man1/tmux.1.html#DEFAULT_KEY_BINDINGS ; Move to the previously active pane. n Change to the next window o Select the next pane in the current window. p Change to the previous window. Up, Down, Left, Right Change to the pane above, below, to the left, or to the right of the current pane. In terms of tmux, a window is what we call a tab or view for Konsole. A pane is a terminal in that view/tab. So yes, it does have that capability. Interestingly, it has bindings for cycling through terminals forward, but not backward. For going back, there is only the option to select the last pane, which goes back and forth between the last two used panes. > What I am currently unsure about your formulation, is that your concept > implies a linearization and a consequent sorting of the splitted views, in > order to cycle through them in a predictable manner. If this feature is > already implemented somewhere in a manner which is generally accepted, that > would be good to know to take it as reference. tmux does this by assigning an index to the panes, which is also how I'd propose to do it. It's the simplest (and most common) way of dealing with this issue. Like you also have an index for the tab ordering when cycling through UI elements using the tab key. In case you want to know, in tmux, you can briefly display the pane index by using Ctrl+b and q. Also keep in mind that using cursor keys can be ambiguous as well. Say you have one terminal left and two terminals split top/bottom on the right. Now if you're in the left and you use the shortcut to go right, which should Konsole choose? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 426276] Split view: change view shortcuts
https://bugs.kde.org/show_bug.cgi?id=426276 --- Comment #4 from Bernd Steinhauser --- That's remappable, it's called "Focus Above/Below/Left/Right Terminal". What at least I meant was something like "Cycle Through Terminals in Current View". That's of course less specific than the one with arrows, where you can specify the direction, but I rarely split a view into more than two terminals, so it'd be a better fit for me. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 483608] Discover Crash when searching
https://bugs.kde.org/show_bug.cgi?id=483608 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #2 from Bernd Steinhauser --- Can confirm this. I found that it only happens for me if I have "Home" selected when starting the search. If I select "All Applications" and then search, it works fine without crashing. Like for Tammes, I only use Discover for Flathub, since my package manager does not support appstream. So it seems likely that it's related to that. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 426276] Split view: change view shortcuts
https://bugs.kde.org/show_bug.cgi?id=426276 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #2 from Bernd Steinhauser --- I second this. As a workaround, I tend to use the shortcut Ctrl+Tab to toggle between two view panes, but obviously that only works if these two were the last two used, because it actually toggles between the last two used tabs. I really miss a dedicated shortcut to do that. :( -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 482316] Close to system tray not working after program start
https://bugs.kde.org/show_bug.cgi?id=482316 --- Comment #1 from Bernd Steinhauser --- I should note that I had a friend test this, too. So it's verified on at least 2 computers. However, both were running Exherbo Linux. -- You are receiving this mail because: You are watching all bug changes.
[konversation] [Bug 482316] New: Close to system tray not working after program start
https://bugs.kde.org/show_bug.cgi?id=482316 Bug ID: 482316 Summary: Close to system tray not working after program start Classification: Applications Product: konversation Version: 1.10.24020 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konversation-de...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- SUMMARY *** One the new kf6-based version, when having the system tray enabled in the options, it will not work properly initially after the program start. Clicking on the x to "close" the window, will not minimize the program to the system tray, but instead nothing will happen. (Also not closing of konversation) Left click on the system tray icon will also not do anything. *** STEPS TO REPRODUCE 1. Install the specified version from KDE apps 24.02 2. Open konversation, enable system tray 3. Close konversation 4. Open konversation again, click on the x to close the window OBSERVED RESULT Nothing happens. EXPECTED RESULT konversation should minimize to system tray SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.8-amdgpu (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7C90 System Version: 1.0 ADDITIONAL INFORMATION A possible workaround is to deactivate system tray in the options and then activate it again afterwards. Then it will work until the program is restarted. Thus step 3 and 4 in the list above. However, this doesn't seem to work every time, so at least once I had to deactivate/activate the system try twice for it to work again. In that case, clicking on the icon works to minimize, too. -- You are receiving this mail because: You are watching all bug changes.
[palapeli] [Bug 481175] New: Cannot create new puzzles
https://bugs.kde.org/show_bug.cgi?id=481175 Bug ID: 481175 Summary: Cannot create new puzzles Classification: Applications Product: palapeli Version: 2.1.240195 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: majew...@gmx.net Reporter: li...@bernd-steinhauser.de CC: kde-games-b...@kde.org Target Milestone: --- SUMMARY Since I upgraded to the release candidate based on kf6, I can't create a new puzzle. I get stuck at the screen saying "Choose a slicing method" and no matter what I choose, the "Next" and "Finish" buttons remained deactivated. STEPS TO REPRODUCE 1. Update to current release candidate 2. Create a new puzzle 3. Select image, provide metadata and click on next 4. Select a slicing method OBSERVED RESULT Can't progress/finish the creation SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 Kernel Version: 6.7.3-amdgpu (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I've verified this on my laptop, which is running RC2 on Arch Linux. This laptop has never run Plasma 5 and especially never run palapeli before, so it started with a clean config. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 34362] Support for configuring additional mouse buttons
https://bugs.kde.org/show_bug.cgi?id=34362 --- Comment #57 from Bernd Steinhauser --- (In reply to miranda from comment #56) > (In reply to Bernd Steinhauser from comment #55) > > Yes, that works. It would still be a good thing if mouse buttons could be > > assigned directly, so you can avoid having to assign a key (combination) to > > that button. Personally, I think that it should not matter to the DE whether > > a button event was triggered by a mouse button and key presse or even a > > button press by a game controller. > > Apologies if I wasn't clear, that was in response to Nate - I agree with you > here. A workaround is just that, a workaround, meaning from my perspective > the feature request should still be open. I think it's ok if this one is closed, but as a mid- to long-term goal, it should still be on the list in my opinion. It might be helpful though to put that into a new feature request outlining the problems and goals more precisely. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 34362] Support for configuring additional mouse buttons
https://bugs.kde.org/show_bug.cgi?id=34362 --- Comment #55 from Bernd Steinhauser --- (In reply to miranda from comment #54) > Wouldn't binding a keyboard button to a mouse button, followed by an action > to a keyboard button, be considered a workaround? The original bug report > seems fairly clear. Yes, that works. It would still be a good thing if mouse buttons could be assigned directly, so you can avoid having to assign a key (combination) to that button. Personally, I think that it should not matter to the DE whether a button event was triggered by a mouse button and key presse or even a button press by a game controller. The current implementation works sufficiently to cover the needs of most, I guess, but there are limitations, e.g.: - Combining Modifiers with mouse buttons might not work, as most of the time you'd want to assign a key combination to the mouse button and not a single key stroke. e.g. you assign Meta+F1 to button 7, but then you can't use Meta+button 7 for other things. - The configuration is not device-specific. There surely are arguments pro and con this, but if you are using multiple mice, it might not make sense to assign button 7 to the same key combination on both devices, since they could be located at completely different positions - Currently, it'll only search the first level for a key, which can lead to unwanted effects, if you're not using a standard layout or trying to access positions that are not on the first level on the standard layout. I created a bug for this, but it's not been fixed yet. (In reply to David Redondo from comment #50) > As this has been mentioned you can now bind arbitrary key combinations to > extra mouse buttons. I just tested it and it works fine for (bound > printscreen to a side button for testing). So I am closing this as resolved. > If it doesnt work for people (as it seems to not do for Bernd) please file a > new bug I experienced two bugs with this, one of which has been fixed, but the other one is still open. Nevertheless, I can use it, working around the limitations of the current system, and have been doing so for more than half a year now on Wayland exclusively without using imwheel or similar. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471381] Double-click text selection not possible for newly opened pages
https://bugs.kde.org/show_bug.cgi?id=471381 --- Comment #1 from Bernd Steinhauser --- Created attachment 159856 --> https://bugs.kde.org/attachment.cgi?id=159856&action=edit Short video demonstrating the problem Here's a short video showing this. I start on page 200, where I selected before. double-click works fine. I go forward to page 201 and try to double-click select, but it doesn't work. I select some text via click-drag select and now the double-click select works as well. Back to page 200, double-click select still works fine there. Forward to page 201, double-click select still works fine there. Forward to page 202 and try to double-click select, doesn't work. I select some text via click-drag and after that double-click select works fine. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471381] New: Double-click text selection not possible for newly opened pages
https://bugs.kde.org/show_bug.cgi?id=471381 Bug ID: 471381 Summary: Double-click text selection not possible for newly opened pages Classification: Applications Product: okular Version: 23.04.2 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: EPub backend Assignee: okular-de...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- SUMMARY First thanks for providing an epub backend to Okular, it's a very welcome feature! :) Normally, you can select a word in the text selection mode by double clicking on that word (at least for a double-click setup, I don't know how it behaves if KDE is set to single-click). In epub files I found this to be unreliable specifically on pages on which there was no text selected before. e.g. if I select via left-click and drag and then double click a word, the word is selected correctly. If I then proceed to the next page and try to double-click, nothing happens. I first have to make a random drag selection before I can double-click to select a word on that page. Going back to any page on which there was something selected, it works right away. STEPS TO REPRODUCE 1. Open an epub file (tested with multiple ones) 2. Try to select via double click 3. Select via click-drag 4. Try to select via double click again OBSERVED RESULT First time trying double click, nothing is selected EXPECTED RESULT Selecting via double click should always work SOFTWARE/OS VERSIONS Operating System: Exherbo KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.3.8-amdgpu (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I also tried this with PDF, but there I could not reproduce the problem. It's also a bit annoying that Okular always includes the punctuation in the word selection, which is very unusual. But that is not specific to epub, it happens in other backends, too. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 424798] Standard double click and drag text selection to select words, triple click to select whole lines
https://bugs.kde.org/show_bug.cgi?id=424798 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 326972] epub backend should support 'page-break-inside: avoid;' and render accordingly
https://bugs.kde.org/show_bug.cgi?id=326972 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 384070] Text based genertors need reloading the file after font size change
https://bugs.kde.org/show_bug.cgi?id=384070 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #14 from Bernd Steinhauser --- (In reply to Andrej Halveland from comment #13) > Yeah, sure. > > The Application Dashboard seems to open on the wrong (external) monitor. Ok, thanks. Then it really seems you're observing the exact same thing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #12 from Bernd Steinhauser --- I'd say it's the same. Could you also try the dashboard, just for completeness? Just switch the menu to the dashboard alternative temporarily. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #10 from Bernd Steinhauser --- Is xrandr actually working correctly on wayland or is there a wayland-specific command? Could it be a config problem? I did wipe my plasma config files when 5.27 was released, so I wouldn't expect it, but who knows? Could I actually do a bisect between 5.27.0 and 5.27.5 on plasma-workspace (or -desktop?) only, without changing the rest of plasma (and frameworks)? Or is there a chance that the change was in some framework or a different part of plasma? Would 5.27.0 work with frameworks 5.105? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #9 from Bernd Steinhauser --- Created attachment 158630 --> https://bugs.kde.org/attachment.cgi?id=158630&action=edit xrandr when things go wrong -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #8 from Bernd Steinhauser --- Created attachment 158629 --> https://bugs.kde.org/attachment.cgi?id=158629&action=edit xrandr when everything is positioned correctly -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #7 from Bernd Steinhauser --- (In reply to Nate Graham from comment #6) > It looks like the only differences in the outputs of those commands is that > the screens are changing orders in the files. Their actual data is all > correct and identical. > > Does the `xrandr` output also differ between the correct and incorrect > states? I wonder if it could be Bug 466149. >From what I can tell, xrandr shows the same behavior, i.e. the assignment of the "primary" tag stays with the HDMI screen, but the order of the outputs is changed, meaning that HDMI is now listed first instead of DP. I'll attach the output in a second. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #5 from Bernd Steinhauser --- Created attachment 158600 --> https://bugs.kde.org/attachment.cgi?id=158600&action=edit plasma applets config file -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #4 from Bernd Steinhauser --- Created attachment 158599 --> https://bugs.kde.org/attachment.cgi?id=158599&action=edit kscreen-doctor -o; when positioning is wrong -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #3 from Bernd Steinhauser --- Created attachment 158598 --> https://bugs.kde.org/attachment.cgi?id=158598&action=edit kscreen-doctor -o; when positioning is correct -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #2 from Bernd Steinhauser --- Created attachment 158597 --> https://bugs.kde.org/attachment.cgi?id=158597&action=edit kscreen-console bug; when positioning is wrong -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 --- Comment #1 from Bernd Steinhauser --- Created attachment 158596 --> https://bugs.kde.org/attachment.cgi?id=158596&action=edit kscreen-console bug; when positioning is correct -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 469227] New: When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen
https://bugs.kde.org/show_bug.cgi?id=469227 Bug ID: 469227 Summary: When switching screens on in specific order, tooltips and dashboard may appear at wrong positions/screen Classification: Plasma Product: plasmashell Version: 5.27.4 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: generic-multiscreen Assignee: plasma-b...@kde.org Reporter: li...@bernd-steinhauser.de CC: aleix...@kde.org, notm...@gmail.com Target Milestone: 1.0 SUMMARY Got two screens, one connected via DP (priority 2, left) and one connected via HDMI (priority 1, i.e. "primary", right). My panel is relatively close to the standard panel layout, except that I use dashboard as a start menu instead of kickoff. When I start up, everything is working as expected all the time, i.e. nothing goes wrong until I turn off the screens. If I turn off the screens and then turn them on again, it depends on the order of switching them on whether the positioning of several things is correct or not. Variant 2: 1. DP (priority 2) on 2. HDMI (prioriy 1) on Result: correct positioning Variant 2: 1. HDMI (prioriy 1) on 2. DP (priority 2) on Result: incorrect positioning I found two ways of fixing this. Either the screens are switched off and then switched on again according to variant 1. Or the primary screen switch in the kcm is switched back and forth between the two screens. correct positioning: Dashboard shows up on the (primary) screen where the panel is. Tooltips (e.g. task manager, or the notification popup, when you click on the bell) show up at their correct positon. All context menus show up at the correct positions. incorrect positioning: Dashboard shows up on the priority 2 screen. Tooltips show up on the primary screen, but are aligned to the left screen edge (the one between the two screens). Some context menus show the same behavior as the tooltips: right click on clock, systray items and empty panel area right click on task manager items shows the context menu at the correct position, as does it for any other context menu (e.g. in some app like konsole or firefox). I did not observe any other apps/widgets to misbehave. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.27.4 KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 ADDITIONAL INFORMATION It doesn't seem to happen every time I use variant 2, but in the clear majority of my tries. It could depend on how quickly I proceed with the second screen, but I'm not sure yet. If it would be helpful, I might try to investigate this specifically. Since variant 2 is the way I normally switch on my screens after turning them off, I'm about 90% sure that this bug didn't happen in the first versions of 5.27. Unfortunately, I don't have a quick way to test this specifically without major effort. If it's clear in which git repo I have to look, I could try to bisect the issue. There are two bug reports that could be related. bug 468613 reports a wrong positioning of the task manager tooltips, but in this case they do end up on a wrong screen, so I'm not sure if it's the same thing. bug 383067 I reported years ago, where the dashboard also appeared on the wrong screen. But in this case it was only the dashboard and I actually reported it as working before 5.27, so it might just be the same symptom. I tested on both X11 and wayland and at least the dashboard thing happens on both. For the tooltips I'm not 100% sure, at least in the few tries I did, they didn't appear wrongly positioned. -- You are receiving this mail because: You are watching all bug changes.
[ksmserver] [Bug 436318] Save session doesn't work under Wayland
https://bugs.kde.org/show_bug.cgi?id=436318 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 385951] Some applications dont show menubar after disabling global menu again
https://bugs.kde.org/show_bug.cgi?id=385951 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #13 from Bernd Steinhauser --- There's many more. I recently put the global menu in the title bar, just to try it out again. Big mistake. Ever since, I have been fighting to get the menu bar back in so many apps. Dolphin, ksudoku, konsole, just to name a few. In some cases, Ctrl+m helps, in others it doesn't. e.g. for ksudoku I couldn't find any way to get it back other than to edit the rc file. I really would not recommend anybody to use the global menu unless they are 100% sure they will never want the menubar back. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 154804] Add option for alternative Drag&Drop behaviour
https://bugs.kde.org/show_bug.cgi?id=154804 --- Comment #48 from Bernd Steinhauser --- (In reply to sbahling from comment #39) > Of course on a computer system there are other options than "moving" and we > should have ways to access those options via key modifiers or using > alternate mouse buttons. I don't think we can come up with defaults that > everyone is happy with. I just hope we can make the behavior configurable. Key modifiers and even alternate mouse buttons are for power users only. Except for a few really known ones (like CTRL+c and CTRL+v), you really can't expect an ordinary user to remember any shortcut. The typical user doesn't even know key combinations like Meta+e or Meta+l. Heck, I consider myself a well-knowing PC user and even I really don't see the point in the about million key combinations that KDE defines by default. Actually it's so many, that I really avoid them (to some degree), because chances are high you hit a wrong key and something awful happens. In my opinion (and this is only my personal opinion), about 80% of them should default to "None", but have a "suggested key combination" instead, a concept that doesn't exist currently (and also might not be wanted by others, don't know). Anyway … you really can't expect people to know that left mouse button will move and e.g. Ctrl+LMB will copy. RMB drag, as I described in the first post, maybe, but even that is a concept that most users wouldn't incorporate into their workflow. The current way is actually a pretty smart way to give a typical user a way to decide between copy and move without needing to remember key combinations. Hence it should be the default. (In reply to Nate Graham from comment #41) > Someone submitted patches that implemented the requested change, but > ultimately abandoned them because we couldn't figure out a way to always > copy by default instead of moving when dragging across devices (for safety). But why change the behavior in that case? IMO it's an inconsistency that shouldn't exist. If I would still want it to move by default, I would also want it to do that when I move files from one filesystem to another. (I think it's filesystems that matter here, not devices.) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 458978] Focus stealing prevention setting makes no sense on Wayland
https://bugs.kde.org/show_bug.cgi?id=458978 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #2 from Bernd Steinhauser --- (In reply to Nicolas Fella from comment #0) > Focus stealing prevention is an inherently X11-thing. On Wayland > applications can't steal focus by default and can only raise themselves in > controlled circumstances. > > Therefore the focus stealing prevention combobox in the window behavior > settings makes no sense on Wayland in its current form. So how to prevent something from stealing focus? Years ago I opened this bug about the device notifier and there I was told to use focus stealing prevention if I don't want the notifier to steal focus when I plug in e.g. a usb drive. https://bugs.kde.org/show_bug.cgi?id=354309 Now this doesn't work anymore and – for me – it's still a highly annoying thing, because I regularly use a USB drive that I can't mount using solid/udisks; I have to (and want to) do it via shell. At least – in favor of the argument in the other bugs – nowadays you can do something with the keyboard in the device notifier, so kudos for that. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 439135] Color management on Wayland
https://bugs.kde.org/show_bug.cgi?id=439135 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 388583] Tooltip placement sometimes obscures the file
https://bugs.kde.org/show_bug.cgi?id=388583 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 455645] Tooltip frequently covers filenames when it appears
https://bugs.kde.org/show_bug.cgi?id=455645 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Under certain circumstances when using multiple monitors, "unlock" button is clickable but does nothing
https://bugs.kde.org/show_bug.cgi?id=456210 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465463] For some extra buttons kwin emits key events set for another extra button
https://bugs.kde.org/show_bug.cgi?id=465463 --- Comment #8 from Bernd Steinhauser --- (In reply to David Redondo from comment #7) > Thank you, for the the very detailed report! Well, directly after the whole kwin restarting issue, the ability to rebind mouse buttons was the major holdback for me personally regarding the switch to Wayland. My muscle memory is just way too trained using these after +10 years of using imwheel. So the motivation to dig deep to analyze this was quite high for me. :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] mouse button rebinding is incompatible with upper level symbols in keyboard layouts
https://bugs.kde.org/show_bug.cgi?id=464735 Bernd Steinhauser changed: What|Removed |Added Summary|kwin emits no or wrong key |mouse button rebinding is |events when binding extra |incompatible with upper |mouse buttons on Wayland|level symbols in keyboard |and using Neo 2 layout |layouts |variants| --- Comment #9 from Bernd Steinhauser --- I've changed the bug title to better match the actual problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735
--- Comment #8 from Bernd Steinhauser ---
Created attachment 156124
--> https://bugs.kde.org/attachment.cgi?id=156124&action=edit
Patch to only search the first two levels in a layout.
In src/plugins/buttonrebinds/buttonrebindsfilter.cpp the symbol is converted to
a keycode in line 291:
// KKeyServer returns upper case syms, lower it to not confuse modifiers
handling
auto keyCode = KWin::input()->keyboard()->xkb()->keycodeFromKeysym(sym);
This uses the function keycodeFromKeysym that is now in src/xkb.cpp.
This function iterates over all keysyms and levels, in that order, returning
the first match for the requested symbol.
Restricting this lookup process to level 0 and 1 fixes the issue for me, since
the doubled keys are on higher levels. I've attached that patch for reference.
btw, I had to use both level 0 and 1, because I think the comment is actually
false and there is no conversion to lower case.
i.e. if 'A' is requested (and that is what is output by KKeyServer, even if 'a'
was originally set), it will only find it if level 1 is searched as well.
Unfortunately, this might not really be a desirable solution, since this makes
symbols on upper levels unusable for shortcuts.
The problem is that with the current design of the function, this won't work
anyway, you will always only get symbols on level 0 as an output.
Thus, even if an upper level symbol is set in kcm_mouse, it'll misbehave.
For example, if you set # ('numbersign') in the standard US layout, you need to
press Shift+3. kcm_mouse will correctly assign the character # to the mouse
button and keycodeFromKeysym will correctly determine the key AE03 in this
layout.
However, the output will be '3', because the Shift to level 1 is omitted.
Therefore, my proposal would be that keycodeFromKeysym returns both keycode and
level, or, alternatively, a second search levelFromKeysymAndKeycode is
performed to determine the correct level of the requested symbol on a specific
Keycode.
Unfortunately, my c++ skills are too limited to properly implement this. :(
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 465463] For some extra buttons kwin emits key events set for another extra button
https://bugs.kde.org/show_bug.cgi?id=465463 --- Comment #6 from Bernd Steinhauser --- Thanks for looking into this. I can confirm that the change fixes the issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 465463] For some extra buttons kwin emits key events set for another extra button
https://bugs.kde.org/show_bug.cgi?id=465463 --- Comment #2 from Bernd Steinhauser --- (In reply to David Redondo from comment #1) > Sounds like our filter somehow mixes up extra button 2 and 3. Could you > paste the > '[ButtonRebinds][Mouse]' section of ~/.config/kcminputrc just to be sure > that it writes the correct config for button 2 and 3? Sure: [ButtonRebinds][Mouse] ExtraButton1=Key,A ExtraButton2=Key,B ExtraButton3=Key,C ExtraButton4=Key,D ExtraButton5=Key,E (I reassigned them to A-E before doing this, as this makes it easier to test follow the effects) So the KCM is doing the right thing. But it's not just Button 3, the whole thing is messed up. Here is what happens when I use wev with this setup: Button 1: a Button 2: b Button 3: b Button 4: b Button 5: c (Button 4 and 5 correspond to the left/right action on the scrolling wheel. I can map those to regular buttons instead of horizontal scrolling using ratbagd or solaar.) So something is wrong with the way it increments, maybe? There is also a button 13, which is not really a button, but the (mechanical) switch that activates/deactivates clickless scrolling. I can set that, too and it will correctly output the key that I set for this button. So maybe just the increment isn't the answer either? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735
--- Comment #7 from Bernd Steinhauser ---
First, I opened bug 465463, since I think that I actually found two bugs at the
same time and just wasn't sure whether they are connected or not. Now I'm
pretty sure that they have nothing to do with each other.
Here, I will only report on my findings with the key events when using
non-standard keyboard layouts.
I investigated this a bit further and I do think I understand now what is going
on. I was especially surprised to find that kwin has problems with keys like
the cursor keys or Page Up/Down, which are standard keys and are not modified
by Neo 2 or any other of the mentioned layouts.
These keys are defined by xkb in /usr/share/X11/xkb/symbols/pc, online link:
https://github.com/freedesktop/xkeyboard-config/blob/master/symbols/pc#L61
key {[ Insert ]};
key {[ Delete ]};
key {[ Home]};
key {[ End ]};
key {[ Prior ]};
key {[ Next]};
Now one special thing that Neo 2 invented and that was adapted by other layouts
like adnw or l3 is that you have a second set of these keys (and others as
well) when using the so-called "M4" modifier (which is Level5 in xkb), as shown
here:
https://dl.neo-layout.org/grafik/bilder-einzeln/flat/neo-4-tkl.path.svg
This is a pretty handy thing for quickly moving in a text without needing to
move your hands from the main keyboard keys, but it means there are now e.g.
two keys with the entry Prior. These are defined in
/usr/share/X11/xkb/symbols/de. Online link:
https://github.com/freedesktop/xkeyboard-config/blob/master/symbols/de#L439
e.g. for Prior:
key { [ x, X, ellipsis,
Greek_xi,Prior, Prior,
Greek_XI,NoSymbol ] };
Now, I assume that kwin (or kwindowsystems, I'm not familiar with the code)
will perform a lookup for these symbols and it will find the one in 'de' first.
Thus, it will emit key without any modifier, which for Neo 2 corresponds
to the symbol 'x', which is exactly what I get when checking it with wev.
Dvorak on the other hand does not introduce additional Prior/Next etc. keys,
hence it's not affected, despite moving around a lot of keys.
I assume the solution for this would be to always first check the symbols in
'pc105' as defined in the 'pc' file, since this is the basis for all layouts
and then proceed with any additions on top of that.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 465463] New: For some extra buttons kwin emits key events set for another extra button
https://bugs.kde.org/show_bug.cgi?id=465463 Bug ID: 465463 Summary: For some extra buttons kwin emits key events set for another extra button Classification: Plasma Product: kwin Version: 5.26.90 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- Originally, I mentioned this issue in bug 464735, but I'm now pretty sure that it's a separate issue and especially is independent from the keyboard layout (i.e. also happens with the standard variant for de or us layout). SUMMARY Extra buttons can be configured in the kcm individually, but the key events emitted can be the same as set for another button. This might suggesting that there is something wrong with the button numbering? STEPS TO REPRODUCE 1. Use a Mouse with at least(?) 3 extra mouse buttons (e.g. forward, back, side/extra) 2. Assign keys or key sequences to each one of them 3. Use wev to test whether the emitted keys match the setting OBSERVED RESULT Extra button 3 will always emit the key set for extra button 2, even if no action is set for extra button 3 If extra button 2 is not set, both with report their individual default function, even if an action is set for extra button 3. EXPECTED RESULT The set key events should be emitted. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.26.90 (tested also on 5.26.4) KDE Plasma Version: 5.26.90 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION I tested this on both Exherbo Linux and Arch Linux with the latest beta. I tested two mice: Logitech M705 and Logitech Anywhere 2S. Both show this behavior. I don't have any mice available right now from other vendors to cross-check it there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735 --- Comment #6 from Bernd Steinhauser --- FYI: I gave this merge request a spin: https://invent.kde.org/qt/qt/qtbase/-/merge_requests/239 The problem persists. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735 --- Comment #5 from Bernd Steinhauser --- Ok, I think I've got the layout thing figured out now as well. This happens only for some keys, like Page Up/Down. In my test on Arch I made the mistake to use a regular key (e.g. "e"). If I set the shortcut to Page Up, I get the same behavior described above on both systems. I also asked another person running kwin Wayland on Exherbo with a different mouse to test this and the result was the same. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735 --- Comment #4 from Bernd Steinhauser --- Ok, so I've been able to do some tests with both Plasma 5.26 and 5.27 Beta (from the [kde-unstable] repository) on another system running another distribution (Arch Linux) with the exact same mouse (Logitech M705) as well as another model (Logitech Anywhere 2S). My observations: 1. I could not observe any difference between the two Plasma versions in this regard, so a regression seems unlikely. 2. I was not able to reproduce the keyboard layout problems. Independently of the layout, the same key events were emitted. So this could be a problem with my local system, I need to investigate. Right now I have no idea where this could be coming from. 3. The other part of the problem was reproducible with both mice. Some of the buttons, although recognized differently by the kcm, emit the exact same shortcut events as another button, even though they were set to something different. In some cases the shortcut events aren't triggered at all, although set in the kcm and present in kcminputrc. 4. Using solaar, I was able to switch the wheel left/right action from scrolling to extra buttons. I was able to assign those as well, but the same problem persists, I can assign them individually, but one of these two also emits the same shortcut as Extra Button 2 and the other one does not work at all (when setting a shortcut). btw, when assigning a mouse button, it fails to recognize the button press most of the time. I have to hit the button many times until it finally triggers. This is not a hardware problem, if I monitor the mouse using wev, every single button press is recorded. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 341862] "Make Seamless Advanced" / "Resynthesizer" like filters
https://bugs.kde.org/show_bug.cgi?id=341862 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464130] "Show in Activities" option disappears from the titlebar context menu
https://bugs.kde.org/show_bug.cgi?id=464130 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #6 from Bernd Steinhauser --- Could it be that all other activities were stopped? Because this is the behavior I observed in that case. Personally, I'd say that the menu should still stay there, because it would be a quick way to resume an activity, i.e. by moving a window to that activity. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464991] New: Add titlebar action to move to next activity using the mouse wheel
https://bugs.kde.org/show_bug.cgi?id=464991 Bug ID: 464991 Summary: Add titlebar action to move to next activity using the mouse wheel Classification: Plasma Product: kwin Version: 5.26.90 Platform: Exherbo OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: activities Assignee: kwin-bugs-n...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- In Systemsettings -> Window Management -> Window Behavior -> Window Actions on can define an action to be carried out when using a modifier key and a mouse action. Here, I used the mouse wheel action to quickly move an app to the next/previous desktop by using the Meta + mouse wheel on the titlebar. Now I have switched to using activities and found that there is no corresponding option available. Hence, I propose that such a feature is added. :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424648] Keep order of activities
https://bugs.kde.org/show_bug.cgi?id=424648 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 460478] Dolphin crashes on monitor turn on
https://bugs.kde.org/show_bug.cgi?id=460478 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 415156] Support configuration of gaming mice via libratbag as a KCM in the systemsettings
https://bugs.kde.org/show_bug.cgi?id=415156 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735 --- Comment #3 from Bernd Steinhauser --- Just wanted to add one more detail: If I remove all of the extra button bindings, button 1 and 2 are restored to their original functionality back and forward, button 3 does nothing, i.e. it doesn't imitate button 2. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland and using Neo 2 layout variants
https://bugs.kde.org/show_bug.cgi?id=464735 Bernd Steinhauser changed: What|Removed |Added Summary|kwin emits no or wrong key |kwin emits no or wrong key |events when binding extra |events when binding extra |mouse buttons on Wayland|mouse buttons on Wayland ||and using Neo 2 layout ||variants --- Comment #2 from Bernd Steinhauser --- Ok, I think I just figured out why this is happening for me, but most likely not for others. First, I think there are actually two bugs here. The first is that I can configure Extra buttons 2 and 3 in the kcm separately, but kwin will always emit the same signal for both (that that was set for extra button 2). Should I open another bug report for this? The second bug is happening because I'm a user of the de layout in the variant 'neo'. As you can see here https://www.neo-layout.org/ this layout shuffles around a lot of keys and I think kwin is getting confused by that. I found the following Layout (Variant) German (Default): correct English (Default): correct English (Dvorak): correct German (Dvorak): correct German (Neo 2): Ctrl+PgUp -> Ctrl+x, Ctrl+PgDn -> Ctrl+w German (Bone): Ctrl+PgUp -> Ctrl+x, Ctrl+PgDn -> Ctrl+j German (Neo 2, QWERTZ): Ctrl+PgUp -> Ctrl+t, Ctrl+PgDn -> Ctrl+q German (Neo 2, QWERTY): Ctrl+PgUp -> Ctrl+t, Ctrl+PgDn -> Ctrl+q German (Aus der Neo Welt): Ctrl+PgUp -> Ctrl+adiaeresis, Ctrl+PgDn -> Ctrl+adiaeresis ??? So it's not just the keys that are moved around, but especially there seems to be some problem with Neo 2 and related layouts (Bone and "Aus der Neo Welt" are layouts that were done by people working previously on Neo 2). Note that in none of these layouts, the Ctrl, PgUp and PgDn keys are changed to something else. So the proper steps to reproduce would be: 1. Add German (Neo2, QWERTY) to layout switcher (suggest this one, as it leaves the normal key layout as is, in case you need to type 2. Set up an extra mouse button in kcm_mouse 3. Use wev to verify that the correct key combination is emitted 4. Switch to German (Neo 2, QWERTY) 5. Use wev again to check the key combination ??? This is what wev is telling me for "Aus der Neo Welt": [14: wl_keyboard] key: serial: 24630; time: 6488324; key: 37; state: 1 (pressed) sym: Control_L(65507), utf8: '' [14: wl_keyboard] modifiers: serial: 1; group: 0 depressed: 0004: Control latched: locked: [14: wl_keyboard] key: serial: 24632; time: 6488324; key: 28; state: 1 (pressed) sym: adiaeresis (228), utf8: '' -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] kwin emits no or wrong key events when binding extra mouse buttons on Wayland
https://bugs.kde.org/show_bug.cgi?id=464735 --- Comment #1 from Bernd Steinhauser --- I just found out that Extra button 2 emits Ctrl+x, which is not something that I configured. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 464735] New: kwin emits no or wrong key events when binding extra mouse buttons on Wayland
https://bugs.kde.org/show_bug.cgi?id=464735 Bug ID: 464735 Summary: kwin emits no or wrong key events when binding extra mouse buttons on Wayland Classification: Plasma Product: kwin Version: 5.26.90 Platform: Exherbo OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: input Assignee: kwin-bugs-n...@kde.org Reporter: li...@bernd-steinhauser.de Target Milestone: --- SUMMARY If the extra mouse buttons are configured via kcm_mouse, on some occasions, the event is not carried out. It can also happen that actually a different key event is emitted, i.e. one that was configured for a different button. e.g. my kcminputrc right now is: [ButtonRebinds][Mouse] ExtraButton1=Key,Ctrl+PgUp ExtraButton2=Key,Ctrl+PgDown ExtraButton3=Key,Ctrl+W (btw, shouldn't these settings be in the device-specific part of the config file?) So kcm seems to generate the file correctly, the Button numbers and key combinations match what I set in the kcm. However, when I press one of the buttons, e.g. in a browser window (Falkon or Firefox), for Extra Button 1 and 3, it emits Ctrl+W, for Extra Button, nothing is emitted (it also doesn't do its default function "back"). This is persistent even after restarting the system. I'm not sure if kwin is at fault here or if it's the kcm, but something is not working as it should. bug 460345 looks similar, but is already fixed in the version I'm running. STEPS TO REPRODUCE 1. Use a mouse with configurable extra buttons (so at least 8 buttons?) 2. Assign key combinations to these buttons 3. Check whether the configured key combinations are emitted OBSERVED RESULT No or the wrong key combination is emitted in some cases. EXPECTED RESULT The configured key combinations should be emitted when a button is pressed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.26.90 (I think it is also present on 5.26, but I'm not 100% sure.) KDE Plasma Version: 5.26.90 KDE Frameworks Version: 5.102.0 Qt Version: 5.18.8 ADDITIONAL INFORMATION I'm using a Logitech M705 mouse. This mouse has a total of 10 buttons, of which button 10 (the thumb button) is not used in a standard config. On X, I assign this button via imwheel to the key combination Ctrl+W to quickly close windows/tabs in certain programs like Falkon or Firefox. Additionally, I assign the left/right click of the scroll wheel to Ctrl+PgUp and Ctrl+PgDown to switch tabs in the browser. I never use the lef/right click of the scroll wheel to navigate left/right anywhere, so would be wasted functionality for me. Now obviously, imwheel does not work on Wayland anymore, so for Wayland I need a different solution. Fortunately, kwin seems to support configuring mouse buttons on Wayland, so I tried it. On Wayland, 3 extra mouse buttons are recognized. 1 and 2 are the buttons that are configured as forward and back in a standard config. Extra Button 3 is what is recognized as Button 10 on X11 and does not have a standard function assigned to it. I started with this button and assigned the key combination Ctrl+W to it. At first, this did not work at all, so at first I thought that this functionality is completely broken. I did later on investigate more and found that I also can set Extra Button 1 and 2 and so I tried that and came up with the configuration above. This is not exactly what I want, since I would have to give up the forward/back functionality, but it's better than nothing. However, I did then find out, that the behavior changed and now two buttons result in Ctrl+W, while Button 2 does nothing, as described above. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 34362] Support for configuring additional mouse buttons
https://bugs.kde.org/show_bug.cgi?id=34362 --- Comment #49 from Bernd Steinhauser --- (In reply to Rob Kam from comment #48) > Twenty years later and this is still unresolved? > > Going to System Settings > Input Devices > Keyboard > Advanced > Swap ESC > and Caps Lock is a piece of cake. > > Then going to System Settings > Input Devices > Mouse there is nothing for > changing e.g. > Wheel Down > Screen down > Wheel Up > Screen up > Button Forward > Control + Left click > Button Back > Shift + Left click Well, when you're on Wayland, there is actually an interface for setting up the additional mouse buttons, but it only works for extra mouse buttons (10+) and not for those that are mapped by default (1-9). And at least with the current versions even that is broken, e.g. you can assign a keypress event to a mouse button, but it won't work. In principle if you would like to reassign buttons 8 (back) and 9 (forward), you could remap your mouse so that these are e.g. button 11 and 12 and then you should be able to reassign them to a keyboard combination you could then use. I haven't checked though whether this works, because as mentioned above it's broken. And it should be possible to directly assign mouse buttons in khotkeys (bug 96431). But in general I agree, it should be possible in the kcm to remap mouse buttons to different functions or even a key combination. I would like to have a list of detected mouse buttons, each with a dropdown list and a couple of predefined mouse actions, e.g. the default mouse actions + selected commands (like those listed for the screen edges), e.g. present windows, peek at desktop, activity manager, close tab … And as the final settings I would like to have "Mouse button 10" (if it's button 10) or "Use as hotkey", so that it can be assigned to any (possibly program-dependent) hotkey function and "Key combination". Of course that also means that there is some duplication in the functionality, but I think it would be nice to present a selection of predefined commands to the user. For me, these possibilities are – together with the problem of restarting kwin – the main showstopper to switch to Wayland. On X11, I'm using imwheel, but that doesn't work on Wayland anymore. There are some options out there to get something like imwheel on Wayland, too, but they basically require working around the compositor and usually are way more complicated to setup, so I really would like to avoid those. Plus, I think in 2023, it should be really possible to properly setup your mouse in KDE without needing to fall back to 3rd party programs. :/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Hang in KIconTheme update
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #25 from Bernd Steinhauser --- Ah ok. That's not the case for me, I can't switch windows the whole thing hangs. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 436627] Mouse gestures don't work in Wayland
https://bugs.kde.org/show_bug.cgi?id=436627 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] Hang in KIconTheme update
https://bugs.kde.org/show_bug.cgi?id=463353 --- Comment #23 from Bernd Steinhauser --- (In reply to Patrick Silva from comment #21) > On my Arch Linux sometimes Plasma hangs while pacman installs updates, not > kwin. > I use ext4 file system. bug 463681 marked as duplicated is about Plasma. How can you distinguish between plasma hanging and kwin hanging? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 463353] With BTRFS filesystem, KWin freezes while the system is updated
https://bugs.kde.org/show_bug.cgi?id=463353 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #18 from Bernd Steinhauser --- Also affected by this running Exherbo Linux with btrfs as filesystem. The screen freezes for about 15-20s when the shared mime database is updated during a package installation. I'm sure it's an output freeze, since the digital clock (indicates seconds for me) stops as well. I think it started somewhere around mid December, possibly with the change to 5.26.4, but I'm not sure. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 417615] Option to disable kdeconnect
https://bugs.kde.org/show_bug.cgi?id=417615 --- Comment #18 from Bernd Steinhauser --- Ah, I forgot one thing. You might need to adapt the Exec part, because it might be different on my distribution. So replace ExecStart=/usr/x86_64-pc-linux-gnu/libexec/kdeconnectd with the path that is given in the file org.kde.kdeconnect.daemon.desktop you pulled out of autostart. If the file would be distributed via the package manager, the correct path would be entered when building the package. e.g. it would look something like this: ExecStart=@CMAKE_INSTALL_FULL_LIBEXECDIR@/kdeconnectd -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 417615] Option to disable kdeconnect
https://bugs.kde.org/show_bug.cgi?id=417615 --- Comment #17 from Bernd Steinhauser --- Created attachment 155243 --> https://bugs.kde.org/attachment.cgi?id=155243&action=edit KDE Connect systemd user unit Sorry, somehow I totally forgot about this. Anyway, here is a proposal for a systemd user unit. First, move /etc/xdg/autostart/org.kde.kdeconnect.daemon.desktop out of that autostart dir and make sure KDE Connect is not started (possibly kill it). Keep in mind that this file will come back if you reinstall or upgrade the package. Then copy the file to ~/.config/systemd/user and do # One time so systemd picks up the new file: systemctl --user daemon-reload # to start/stop: systemctl --user start kdeconnect.service systemctl --user stop kdeconnect.service # to enable, which means it is started automatically when you login (and killed when you logout. The --now part also starts/stops it right away systemctl --user enable --now kdeconnect.service # and disable systemctl --user disable --now kdeconnect.service # output status and log (add e.g. -n 30, if you want to have more log lines) systemctl --user status kdeconnect.service The restart part isn't really necessary, it's merely a precaution to avoid spamming with restarts, should kdeconnect continue to crash for whatever reason. >From what I can tell, it works normally. I'm not sure about one thing though. The xdg autostart file mentions "X-KDE-Wayland-Interfaces=org_kde_kwin_fake_input". I'm not sure what this does and if this means that it should be started after kwin? We can't add a dependency on kwin, since 1. it's unclear whether the user actually uses the systemd units to start KDE (even though it's the default now) and 2. there is no kde.service, but two seperate service files plasma-kde_x11.service and plasma-kde_wayland.service. I could maybe add something like After=plasma-kcminit.service, if that would make sense. Someone knowing the internals of kdeconnect better might help here. There might be another way and that would be Type=dbus. Here we can actually let the service wait for the appearance of a certain service on dbus, e.g. org_kde_kwin_fake_input. However, I don't have any experience with this type of service yet, so I'd first would like some input on what org_kde_kwin_fake_input actually does and whether it's be necessary to add a dependency here before making the whole thing more complex. ;) If you want a GUI to manage the systemd units, there is systemdgenie, which should be available via the typical package ressources. Unfortunately, I don't think it's shipped with the default KDE installation, but I'm not sure. Could also depend on the distribution. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 383067] wayland: application dashboard appears on wrong screen
https://bugs.kde.org/show_bug.cgi?id=383067 Bernd Steinhauser changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from Bernd Steinhauser --- Tried on 5.26.5 with kwin/wayland again and now it seems to work. So I guess it was fixed somewhere along the road. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 399232] Add linux pass backend to KDE Wallet service
https://bugs.kde.org/show_bug.cgi?id=399232 --- Comment #15 from Bernd Steinhauser --- (In reply to michaelk83 from comment #13) > (In reply to Bernd Steinhauser from comment #11) > For KeePass, there is a standard file format (`.kdbx`) that multiple > applications can work with, and indeed there are many KeePass variations > that all work with this format, some platform-specific like Keepass2Android, > others more cross-platform, like KeePassXC. Of those, KeePassXC can also act > as a Secret Service backend. But it comes with its own UI, which while it is > Qt, is not fully integrated with KDE, and will likely stay that way. There > is some work there to separate its core from its GUI, so eventually it might > provide Secret Service headless. Or someone could implement a separate > Secret Service backend that could work with `.kdbx` files. > Well, yes, KeePassXC will surely want to stay independent and that's alright. What I wanted to say is that it might be easier to use that as a starting point and then modify parts of it to integrate better with KDE instead of writing a completely new thing that supports kdbx. Especially, since I would also want other features from KeePassXC as well, like the password generator, restricting app access to certain groups etc. -- You are receiving this mail because: You are watching all bug changes.
[kwalletmanager] [Bug 399232] Add linux pass backend to KDE Wallet service
https://bugs.kde.org/show_bug.cgi?id=399232 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #11 from Bernd Steinhauser --- (In reply to michaelk83 from comment #9) > Regardless, KWallet (both parts of it) has been suffering from lack of > developers for at least half a decade. AFAIK, it's an old, neglected piece > of software, full of all sorts of problems. I expect that once the migration > to Secret Service is more mature, KWallet will eventually be discontinued. > KeePassXC is a popular alternative, but once again, it's not a front-end. > KeePassXC is a complete package of its own, backend + front-end in one. But > it is cross-platform, has many good features, and can present the same > Secret Service API to client applications. > True, but KeePass (not sure if with or without XC) can also kind of act as a backend. e.g. for Gnome, there is a gtk UI available that is based on KeePass. Similarly, it might be possible to provide something that is based on KeePass, but integrates better with KDE. Given that KeePassXC is already using Qt for its UI, it might actually be easier than the Gnome part that is out there. It would certainly help if KDE's password manager would use a file format that is better exchangeable with other tools. Right now, if you're using kwallet, you're more or less stuck with it (and thus with a broken tool) unless you're willing to do a full manual migration to some other tool. -- You are receiving this mail because: You are watching all bug changes.
[ksecretsservice] [Bug 313216] Release a working version of KSecretService
https://bugs.kde.org/show_bug.cgi?id=313216 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 417615] Option to disable kdeconnect
https://bugs.kde.org/show_bug.cgi?id=417615 --- Comment #16 from Bernd Steinhauser --- (In reply to Forest from comment #15) > (In reply to Bernd Steinhauser from comment #14) > > > I'd say the better fix would be to [...] > > instead provide a systemd user unit that starts kdeconnect. > > Not everyone uses, or even wants, systemd. (Or linux, for that matter.) > Please don't add dependencies on it. > Ah, not this again … But ok, let's skip the useless discussion. 1. Plasma is moving towards systemd user units already, as I wrote above. It's the default method to startup Plasma these days. So it kind of makes sense to go a similar path with kdeconnect. (Yes, you can use kdeconnect outside of Plasma, but just about every other DE is also moving towards systemd support/integration) 2. A systemd service unit does *not* introduce a dependency on systemd. It's merely an instruction for systemd to tell it what to do when this service is enabled and/or started. If you don't use systemd, it's just a small text file that will sit on your computer unused. You can of course also choose not to install it. I guess though that any sensible distribution would install it. 3. Just like with Plasma, you can still use the old, flawed, method to start it up. XDG autostart will not go anywhere. If you're unhappy with the old method, feel free to create an alternative approach that does not use systemd. Nothing holding you back there. Just don't expect somebody else to drop a better solution just because you don't like it. systemd is the current standard for Linux and for that reason alone it makes sense to support it. Especially, since this support comes at advantages, which is why everybody is using it. > KDE already has way to manage things like this, with the Background Services > and Autostart control panels. > I'd expect this to move to systemd as well. There is no reason to maintain a second, system to manage background services and autostart functionality, when you're already using a better one that even can be used across DEs. Likely, it will remain though for quite some time, for compatibility reasons and because it takes will and time to do the changes. Thus, in the future (+5 years?) it might go the way of the dodo, we'll see. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 417615] Option to disable kdeconnect
https://bugs.kde.org/show_bug.cgi?id=417615 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de --- Comment #14 from Bernd Steinhauser --- (In reply to Forest from comment #12) > However, I think a better fix would be to identify > whatever is making org.kde.kdeconnect d-bus requests at session startup, and > prevent that instead. I'd say the better fix would be to remove the xdg autostart variant and instead provide a systemd user unit that starts kdeconnect. Since Plasma is started by systemd units nowadays, this step seems to be the logical solution, I'd say. That way, the user can enable/disable it like other user services. I'll try to implement and test that during the holidays. It should also be possible to actually only start kdeconnect if there is a request on the appropriate port. e.g. some distributions start sshd only if there is a request on the port. (via the sshd.socket unit) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 408775] Do not close/destroy tab when closing view
https://bugs.kde.org/show_bug.cgi?id=408775 --- Comment #30 from Bernd Steinhauser --- So, since the feature is already there, you can close this bug report, if you'd like. The remaining part seems to be to just improving the UI. As a suggestion there: for me the intuitive way would be to right click on the tab and then activating an option there, just like you can detach a tab. So basically right click -> "Move terminal to new split view" would do the same thing that dragging the header to a tab does, activating the split selection. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 408775] Do not close/destroy tab when closing view
https://bugs.kde.org/show_bug.cgi?id=408775 --- Comment #29 from Bernd Steinhauser --- Thanks for the info. Moving a split back does work indeed. I didn't see those buttons, because in my icon scheme they are not visible … :/ (These are the first (and only so far) buttons where I observed a problem.) The split also works, but getting there is quite advanced. I would've never even thought of making this move like that. ^^ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 335330] Screen flickering after Triple buffering detection: "NOT available"
https://bugs.kde.org/show_bug.cgi?id=335330 Bernd Steinhauser changed: What|Removed |Added Resolution|--- |WORKSFORME Status|CONFIRMED |RESOLVED --- Comment #15 from Bernd Steinhauser --- I do still see some flickering in kwin, but I don't think it's related to this bug, so closing this as resolved. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 408775] Do not close/destroy tab when closing view
https://bugs.kde.org/show_bug.cgi?id=408775 --- Comment #27 from Bernd Steinhauser --- Just had a look at this again to see if it is still valid. In principle, everything works like designed, so there is no bug, but personally, I'd still like to have the option to actually split existing tabs. I often have the situation that I'm working on specific tasks in two tabs and then decide I want to have them next to each other … and later on then I would want to have them in separate tabs again. The current way that splits are always new sessions and are always destroyed once you undo the split is ok for many tasks, but overall, it's a bit limited. I think Konsole could improve there. So I still would like to see something implemented there. ;) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 360113] Configured and Applied Screen Config do not match
https://bugs.kde.org/show_bug.cgi?id=360113 Bernd Steinhauser changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #2 from Bernd Steinhauser --- Oh, yeah this was a thing, but I think along the road it was fixed at some point. So, it's working nowadays. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #61 from Bernd Steinhauser --- (In reply to Nate Graham from comment #60) > This bug report is only about Plasmashell's mapping of containments to > screens; if any screens are themselves not turning on properly, that's an > issue in KScreen, not here. I would recommend that you file a new bug > report. And yes, it could also be caused by a GPU driver issue! But isn't kscreen the key here? Is assigning IDs based on EDID, connector, serial number or whatever really something that plasmashell should do? Personally, using multiple screen setups for various reasons, I wouldn't want to tie a panel to a specific monitor, but to a specific screen in a screen layout, where the layout would be determined by kscreen and the screens in that layout are just enumerated/IDed. Now this of course would have to be consistent, but if it isn't, I would see this as a bug in kscreen, not plasmashell? So far, most of the bugs I experienced with multiple screen layouts turned out to be bugs in kscreen anyway. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #59 from Bernd Steinhauser --- (In reply to Nate Graham from comment #53) > Unfortunately EDID/serial number are not reliable either. Some monitors have > the serial number set to the same value for every monitor in a particular > product line, for example. > > But yes, the problem with identifying screens by connector ID are also > well-known, and that's the subject of this bug report. Do other Linux desktops actually get this right? If so, how do they do it? Also, how does Windows do it? Because, at least with Windows 7/10, I've never experienced this there. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 383067] wayland: application dashboard appears on wrong screen
https://bugs.kde.org/show_bug.cgi?id=383067 --- Comment #11 from Bernd Steinhauser --- (In reply to Philipp A. from comment #10) > I therefore want back the “there is no primary monitor” mode. Applications > launch on the window where the mouse is, all panels and windows always stay > where they are (until something’s unplugged, then they’re shunted somewhere > accessible). Actually your wish regarding window placement doesn't have anything to do with a primary screen. In fact, there is an option in System Settings -> Window Management -> Window Behavior -> Advanced for exactly that. Just set "Window placement: Under Mouse". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #41 from Bernd Steinhauser --- (In reply to arne anka from comment #11) > So, what's the idea of a "primary screen" and what is it to do with the > placement of widgets, panels etc? Being a multi-monitor user for decades now, for me it's mainly the placement of the panel. I usually only have a panel on the primary screen. Take e.g. a Laptop. There you have to think of different scenarios: 1. Usage of the laptop without any additional screen. The integrated screen now is the primary screen and shows the panel. Of course in this case you don't really need a primary screen. 2. Usage of the laptop in a docking station, so a regular workplace. Often you have one or two additional screens attached, and you might want to move the panel to one of the additional screens as soon as you connect them. 3. Connecting an (possibly unknown or unconfigured) external screen. In this case you might want to keep the integrated screen as primary. Of course, if all your screens have an identical layout (including a panel), then it doesn't really matter, but if they are not identical, then the primary screen definition can help to setup screen layout properly without having to make too many assumptions, e.g. in case 3. Furthermore, there is one additional aspect: some programs tend to ignore the window placement by the window manager and always open up on the primary screen. While they really shouldn't do that, it might not be possible to change it (i.e. closed source stuff), so being able to set the primary screen can help to handle those programs instead of them opening up on some random screen they think is the primary one. There is even an example in the KDE world for this: the application dashboard I am using this to start applications and I noticed this when trying out Plasma on Wayland a couple of years ago. (Back then?) Plasma on Wayland didn't have a way to set a primary screen, so in my screen layout, the panel with the button for the application dashboard was on one screen (which I would've set as primary, but it wasn't possible), however the dashboard would open on the *other* screen when clicking the button, since that screen was the "primary" (first?) screen in the layout and there was no way to prevent this behavior. See bug 383067. For me, that was an absolute showstopper and I immediately switched back to X11. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 427092] btrfs multiple device handling
https://bugs.kde.org/show_bug.cgi?id=427092 --- Comment #26 from Bernd Steinhauser --- (In reply to Peter from comment #25) > #workaround: mount manually as root. something like > # mount mnt > #works. There is no need for root. you can just run udisksctl mount -b Note that there is a chance (n-1)/n that the mounted fs will be represented by a device other than the one you passed to udisksctl. In that case udisksctl (or dolphin) will ask you for a password to unmount it, which is a bit annoying. I rarely mount anything using dolphin nowadays, because in most of my cases (I use raid1 regularly) it's a very bad idea to do that. Instead I use udisksctl directly a lot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[frameworks-solid] [Bug 427092] btrfs multiple device handling
https://bugs.kde.org/show_bug.cgi?id=427092 Bernd Steinhauser changed: What|Removed |Added CC||li...@bernd-steinhauser.de -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442158] primary display in wayland
https://bugs.kde.org/show_bug.cgi?id=442158 --- Comment #18 from Bernd Steinhauser --- (In reply to Philipp A. from comment #17) > I have that on, but most games place themselves on the “primary screen”. > That’s why I was happy that up until now on Wayland, all APIs for that > returned the active screen. Then I would assume that it is a (separate) bug you should report. ;) It could be related to bug 383067 that reported a couple of years ago for a specific widget, but it could also be unrelated. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442158] primary display in wayland
https://bugs.kde.org/show_bug.cgi?id=442158 --- Comment #16 from Bernd Steinhauser --- (In reply to Philipp A. from comment #15) > Yeah, that’s exactly what changing the “primary monitor” means for plasma > currently. I want my panels to stay on the physical monitor I put them on > and I only want fullscreen apps to launch on the projector. > > This is effortlessly provided by the previous Wayland behavior of “apps > launch on the screen where the cursor is”, and impossible with the new > behavior even with profiles. > > I therefore want an option to revert plasma’s behavior to what it did before > 5.24. Did try with Plasma yet, but on X11, this is accomplished by the option "Active screen follows mouse" in Systemsettings/Workspace/Window Behavior. If you activate that, programs will open on the screen your cursor is currently on. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 442158] primary display in wayland
https://bugs.kde.org/show_bug.cgi?id=442158 --- Comment #14 from Bernd Steinhauser --- (In reply to Philipp A. from comment #12) > How can I turn this off? > > I love being able to open things on the desktop I currently care about. > “Primary” is really not a concept that makes sens if you have e.g. a > projector. > > I hate having to change the primary monitor through settings when wanting to > play a game on my projector. You shouldn't have to. Or at least only once. Then upon plug/unplug or switch on/off kscreen should switch the layout automatically changing the primary to the one that you selected. Alternatively the "Display Configuration" entry in the systray could have a layout selection of nameable layouts that you pre-configured. e.g. "Projector Gaming" where the projector is then primary and "Normal Desktop", where the projector is off. While Windows generally sucks for multi-monitor use, this is one of the few things they get right. I only configured my working laptop once for the 3 environments I use (Office with 2 external screens, Home with 1 external screen and mobile with only the laptop screen) and it switches automatically and reliably between the three if the corresponding external screens are available. Plasma on the other hand is a real pain when it comes to multi-monitor. Even nowadays it keeps shifting around backgrounds and screens after a couple of sessions even without any hardware changes. This is so annoying that I basically gave up doing much configuration of the desktop/panel/etc. because it'll be obsolete soon enough anyway. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 383067] wayland: application dashboard appears on wrong screen
https://bugs.kde.org/show_bug.cgi?id=383067 --- Comment #9 from Bernd Steinhauser --- (In reply to Mikhail Ramendik from comment #8) > Fair point, this means I misread your view of this bug (I was mostly > referring to Bernd's comment. which explicitly mentioned the primary monitor > issue). > > I reopened to undo my change, but I do think that any further suggestion > must first take into account the changes that were merged in bug 442158. > FOor those of us who don't build from source this means waiting for 5.24. Not quite sure what you mean. I only mentioned the primary screen, because I thought that it could be related to that, but I don't know if it's true. In general, I'd expect the dashboard to appear on exactly the screen I clicked the menu button and not on some other, random screen. I'll try though with the newly implemented primary on wayland – which together with this bug was the main reason I could not switch to wayland yet – and tell you if it works now or not. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 432476] New: Option to only unlock LUKS device
https://bugs.kde.org/show_bug.cgi?id=432476
Bug ID: 432476
Summary: Option to only unlock LUKS device
Product: dolphin
Version: unspecified
Platform: Exherbo Packages
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: dolphin-bugs-n...@kde.org
Reporter: li...@bernd-steinhauser.de
CC: kfm-de...@kde.org
Target Milestone: ---
SUMMARY
I have an external USB storage case which I use for data storage and backups.
Each of the disks is a LUKS container (yes, the whole disk, but that shouldn't
matter here) and combined they hold a btrfs filesystem with raid1 profile.
e.g.
Backup1 LUKS
---> Backup btrfs
Backup2 LUKS
---> Backup btrfs
Now I do like that dolphin provides support for encrypted devices/partitions,
but in such a case multiple problems arise.
e.g. if only one device is present with the raid1 profile by standard it can
not be mounted (because it's degraded in that state), which confuses udisks
and/or dolphin.
In addition, each of the devices results in a device ("Backup" in the example
above), which results in unnecessary clutter, since it's the same filesystem
(with the same UUID, label etc.), but that's a minor thing.
A bit more critical is that if the wrong device "Backup" is selected (it is
impossible to know which is the correct one), udisks and/or dolphin does not
recognize whether the filesystem was mounted and tries again, which results in
an endless loop which can only be stopped by killing the udisks daemon (at
least I didn't find another way yet).
I suspect that is because it will try to mount e.g. dm-1, but dm-0 is mounted
since btrfs detects that it's the same fs and since udisks checks for dm-1
instead.
This can even bring down the system, because if unnoticed it will created mount
points Backup until the system slows down to an unresponsible state (yes,
that happened to me, I think the numbers were above 2000 at that state).
Might be an upstream bug, though, since it's possible udisks fault.
Now, I am aware that this is a corner case, so I won't even bother with
requesting all of that fixed.
However, I think the easiest step (and that would already be a relieve for me)
towards better support of such layouts would be if in addition to the mount
option in dolphin (and actually the device notifier as well), I could also have
the option to just unlock the device.
That way I could prevent udisks trying to mount the fs unless all devices have
been unlocked.
Unlocking of multiple devices would be king, but have to be realistic here ...
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.10 / 5.20.5
(available in About System)
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
udisks is 2.9.1, in case that matters.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 354309] Don't take focus when showing device notifications
https://bugs.kde.org/show_bug.cgi?id=354309 --- Comment #11 from Bernd Steinhauser --- (In reply to Bernd Steinhauser from comment #10) > I experimented a lot with focus stealing prevention, from "None" to "High". > Here in this case, "Low" will be sufficient to suppress the focus stealing. > I ended up turning the focus stealing prevention off though, since it > sometimes results in undesired effects with some applications (would need to > try it to get some examples, since it's been a while since I digged into > this), like pop-ups or dialogs in applications not gaining focus. I do now remember what made me mainly drop the focus stealing prevention from my settings: if it's activated, even at "Low" setting, programs activated by clicking on a systray icon (e.g. wallet manager or akregator) sometimes do not raise to the top and do not gain focus, but will open up in the background, which is highly annoying, because they were activated explicitly on my request. This doesn't happen every time, but often enough to make me get rid of the focus stealing prevention. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 354309] Don't take focus when showing device notifications
https://bugs.kde.org/show_bug.cgi?id=354309 --- Comment #10 from Bernd Steinhauser --- (In reply to Nate Graham from comment #9) > Am I understanding that you turned off focus stealing protection? What's it > set to? "None"? > > I've set the bug status to "needsinfo" pending your response. Please change > back to "reported" or "resolved" when you respond, thanks. I experimented a lot with focus stealing prevention, from "None" to "High". Here in this case, "Low" will be sufficient to suppress the focus stealing. I ended up turning the focus stealing prevention off though, since it sometimes results in undesired effects with some applications (would need to try it to get some examples, since it's been a while since I digged into this), like pop-ups or dialogs in applications not gaining focus. However, my main argument against the current behavior is actually a different one. While personally I think the focus stealing is annoying, others could see that differently *if* it was useful for *anything*, but it isn't. It steals focus, but there is – afaics – nothing you can do. I could understand, if you could e.g. select an action for a drive to be mounted using the cursor keys and enter or select a program to be used with the device, but that does not seem to be the case. btw. the annoyance is even higher, because you can't just get back to your program (e.g. Konsole) by pressing Alt+Tab once, instead you have to do it twice, because the task switcher will first switch to a different program. (Possibly because the device notifier is not enlisted as a program in it?) -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 360430] kscreen randomly rewrites screen configuration
https://bugs.kde.org/show_bug.cgi?id=360430 --- Comment #7 from Bernd Steinhauser --- I didn't have this anymore for quite some time, so might close this as resolved (one way or another). -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 357727] Failed to retrieve current config: "Backend invalidated"
https://bugs.kde.org/show_bug.cgi?id=357727 Bernd Steinhauser changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #2 from Bernd Steinhauser --- I don't find the messages anymore in the logs, so I guess it's been fixed at some point. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 383067] wayland: application dashboard appears on wrong screen
https://bugs.kde.org/show_bug.cgi?id=383067 --- Comment #3 from Bernd Steinhauser --- Still present today (5.19.0) and for me one of the main show-stoppers why I can't switch to plasma on wayland, because now the dashboard (which I strongly prefer over the other menu options) will *always* show up on the wrong screen and there is no way to change the behavior because on plasma/wayland they removed the possibility to set a primary screen. (and seem reluctant to add it again for some reason …) -- You are receiving this mail because: You are watching all bug changes.
