[kdeconnect] [Bug 476513] Cannot turn off automatic share from the device
https://bugs.kde.org/show_bug.cgi?id=476513 Geekley changed: What|Removed |Added CC||mrgeek...@gmail.com See Also||https://bugs.kde.org/show_b ||ug.cgi?id=479919 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 479919] Let us disable automatic clipboard sharing from Android too (so I can share only when clicking the button)
https://bugs.kde.org/show_bug.cgi?id=479919 Geekley changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=476513 -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 479919] New: Let us disable automatic clipboard sharing from Android too (so I can share only when clicking the button)
https://bugs.kde.org/show_bug.cgi?id=479919 Bug ID: 479919 Summary: Let us disable automatic clipboard sharing from Android too (so I can share only when clicking the button) Classification: Applications Product: kdeconnect Version: unspecified Platform: Android OS: Android 10.x Status: REPORTED Severity: normal Priority: NOR Component: android-application Assignee: albertv...@gmail.com Reporter: mrgeek...@gmail.com CC: andrew.g.r.hol...@gmail.com Target Milestone: --- SUMMARY On the Linux side of KDE Connect's Clipboard Sharing Plugin, there's an option to disable "automatic sharing the clipboard from this device". So this works from PC side. Please add the same option on the Android side too. Currently, there is a "send to clipboard" button, but no option to disable auto-sharing. Whenever I copy or cut something on Android, it's being always sent even if I don't click the button. But if I disable the plugin on Android, then I can't share it at all (even though the button still exists in the persistent notification). On that note, you could also improve by showing multiple clipboard entries on the in-app button so I can pick one entry to send, not necessarily the last one. STEPS TO REPRODUCE 1. On Android, open KDE Connect and go to the plugin settings for the paired device. 2. Enable synchronize clipboard plugin. 3. Copy some text. OBSERVED RESULT There's no additional options for the plugin like on PC side. Copied text appears on the PC clipboard too automatically. EXPECTED RESULT Plugin configuration on Android should show an option to disable auto-sharing like on PC. When disabled, text is sent only when clicking one of the sent to clipboard buttons. The button to sent to clipboard inside the app could list all clipboard entries, starting from the latest, so you can pick which one to send. The other buttons (in persistent notification and quick panel) can just keep sending the last entry. SOFTWARE/OS VERSIONS Android: 10, on a Samsung Phone KDE Connect App: 1.29.0 from F-Droid ADDITIONAL INFORMATION This setting on PC is great because then I have the option to share only when I click the button. I don't want to synchronize anything automatically - I want to only send clipboard explicitly. I don't want to worry about what's on my clipboard (e.g. passwords, arbitrary text) beyond that device, maybe being persisted for a long time. Overriding the other clipboard gets in my way if it's not explicitly intended. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460631] Krita command line export freezes while Krita GUI is open
https://bugs.kde.org/show_bug.cgi?id=460631 --- Comment #7 from Geekley --- Still happening on 5.1.5. I also noticed that when converting from a webp file, the "opening webp" window is shown even from the command line. As I understand, this command is meant to be used in batch processing and shouldn't show any GUI. In fact this window is weird - I'd expect all files are opened in a lossless manner, and preferences apply only when saving (like with png). I don't know if a similar thing happens on other formats that might have such "opening windows" (are there others?). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #18 from Geekley --- First issue: Maybe it's easy to solve by just deleting the file before re-creating it on read-write mode or something like that. Second issue: Actually, it might not be related to that warning after all; on closer inspection, this font-size-adjust attribute is on the text that's being shown correctly (imported/pasted from Inkscape svg), not on the one that is not rendered (Legend vector layer made in Krita). In any case, if this is more related to the vector layer support feature and out-of-scope, then ignore this part I guess. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #17 from Geekley --- I've tested with 5.1.5 and, just a reminder, some issues here (other than the vector layer thing) still persist. TIFF exportation is weirdly behaving differently when the file exists - it's not deterministic. Each time the file is overwritten, file size keeps increasing. This issue happens on both GUI and command-line exportation (I tested on this file RGBA-8-sRGB). I didn't test this before, but it seems plausible to assume this was introduced with the read-write mode thing (it doesn't happen on EXR). Though minor, I'd say it's still a bug. It's still having inconsistent results between command-line and GUI exportation of the same file with (presumably*) same settings. I tested RGBA-8-sRGB.tif.kra and when exporting from GUI, the file is perfect, even vector layers are OK. When I had tested command-line though, at first on batch exportation (all-kra-convert.sh), I got broken files. Then I tested again, exporting only this file: flatpak run org.kde.krita --export RGBA-8-sRGB.tif.kra --export-filename RGBA-8-sRGB-sh.tif And the file wasn't broken this time, though it wasn't perfect like from GUI (some text** isn't shown). So, unless it has something to do with settings, there's inconsistency between GUI and command-line exports. I tried batch again but they weren't broken this time, so who knows what happened... * (I say presumably because unfortunately there's no way to enforce/ensure specific exportation settings, so I expect it to use last used settings; a feature to set those via command-line/json would be great and also significantly help testing). ** May be related to this warning - though it's strange that the issue is only via command-line: krita.file: WARNING: 'font-size-adjust' SVG attribute is not supported! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #13 from Geekley --- Created attachment 154718 --> https://bugs.kde.org/attachment.cgi?id=154718=edit Example file that Krita reads incorrectly (fully white issue) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #12 from Geekley --- > I'll try and commit the first set of patches (this issue and the EXR > grayscale import/export) today so you can try with the nightlies of tonight. Cool! I've tried 5.1.4 and I can see the checkbox issue was fixed and the green issue too. Files are still broken (mostly because of the vector layers), but there has been improvements. Some EXR files (e.g. GrayA-16-linear.exr) that were opening as fully transparent in Krita before (when preview was green), now at least show something, but colors that should be grayscale currently appear as fully white in Krita (but are grayscale in Gwenview, GIMP, Dolphin previews). So, it's not just writing, there must be some additional issue in reading EXR files too. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #6 from Geekley --- Created attachment 154452 --> https://bugs.kde.org/attachment.cgi?id=154452=edit Exported files after retrying script now to ensure flatten image I kept them in the same folder as the originals. I hope I did it right. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #5 from Geekley --- Created attachment 154450 --> https://bugs.kde.org/attachment.cgi?id=154450=edit Dolphin previews of "broken", retrying script now to ensure flatten image -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #4 from Geekley --- Created attachment 154449 --> https://bugs.kde.org/attachment.cgi?id=154449=edit Dolphin previews of original sent files from "broken" folder -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 --- Comment #3 from Geekley --- > > - Sometimes vector layers aren't exported. > [BUG] I was able to consistently reproduce the latter error with your files, > but only when not flattening the files. Did you test both GUI and command line? I ran a quick test here: `flatpak run org.kde.krita --export CMYK-8-cp.tif.kra --export-filename CMYK-8-cp.tif` and I got the inconsistency I said before: > 6. Sometimes exporting from Krita GUI gives a different result from the > command-line (bug!), but this result is still broken for one reason or > another. > This is correct and consistent with `Store Alpha Channel (transparency)` > being unset by default on your end. I'm a bit confused because I thought I always enable alpha. So I just tested TIFF exportation and I found something really weird in the GUI. "Flatten the image" was checked and "Store alpha" was unchecked and disabled/locked. When I uncheck flatten, alpha becomes checked and still locked. When I check flatten again, alpha becomes checked and UNLOCKED! This has to be a bug and might have caused either the issue itself or some confusion in my testing. I don't know if it's always like this or if it happens on some specific case. > It'd be great if you could send the affected files here plus previews of > each, to understand what the graphical glitches are. I'll add just the screenshots for now (little time). The "broken" folder is from the original files I sent. The "broken-retry" is what I tried again now, double-checking that it should use flatten image (in case it didn't do that the first time); both were generated from that command line script. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460631] Krita command line export freezes while Krita GUI is open
https://bugs.kde.org/show_bug.cgi?id=460631 --- Comment #6 from Geekley --- (In reply to Halla Rempt from comment #5) > Please don't change the version number: it's not the last version that still > has the bug, but the version for which the bug was first reported. Oh, OK. Sorry for the confusion. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460631] Krita command line export freezes while Krita GUI is open
https://bugs.kde.org/show_bug.cgi?id=460631 Geekley changed: What|Removed |Added Version|5.1.1 |5.1.3 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460631] Krita command line export freezes while Krita GUI is open
https://bugs.kde.org/show_bug.cgi?id=460631 --- Comment #4 from Geekley --- My main issue with this bug is that, since the call from the other app needs to be synchronous, Krita freezing freezes the waiting app as well, with no explanation to the user. :( I'm aware having a second apt installation besides flatpak works (though yes, older version can have different results), but in any case I can't require users to have 2 Krita installations... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461975] New: Broken EXR and TIFF when exporting from some color spaces
https://bugs.kde.org/show_bug.cgi?id=461975 Bug ID: 461975 Summary: Broken EXR and TIFF when exporting from some color spaces Classification: Applications Product: krita Version: 5.1.3 Platform: Flatpak OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: mrgeek...@gmail.com Target Milestone: --- Created attachment 153852 --> https://bugs.kde.org/attachment.cgi?id=153852=edit Test files - source images, broken files and exportation script SUMMARY I've made some files with the objective of testing whether Krita (especially via command-line) is exporting files correctly from all color spaces. When the KRA file is in certain color spaces, exporting to EXR and TIFF formats creates broken files. I'm attaching a compressed TAR with all files used for testing, and with a bash shell script to facilitate exporting all files at once. STEPS TO REPRODUCE 1. Extract the attached file and enter the Krita-ColorTest folder. 2. On the subfolders, check the bad files generated from conversion; they have similar names to the corresponding source KRA file in the top-level folder. E.g. *.exr.kra means a KRA file is bad when exporting to EXR. *.exr+tif.kra is bad when exporting to both EXR and TIFF. 3. In Krita, make sure the last used export settings for EXR and TIFF don't use any weird/advanced option that could cause incompatibility. E.g. make sure exportation will flatten the image. Since there's no command-line flags for such options, you might have to manually export some arbitrary file just to make sure the correct settings will be remembered when exporting from command-line. 4. Make sure Krita GUI is closed before running the command-line, so it doesn't freeze (bug #460631). 5. Then, you can run the shell script to re-export those files via command line. They'll be generated next to the source, not on the subfolders. 6. Sometimes exporting from Krita GUI gives a different result from the command-line (bug!), but this result is still broken for one reason or another. OBSERVED RESULT The source KRA files use paint and vector layers. - Sometimes vector layers aren't exported. However, even if you convert all layers to paint layers, they'll still be broken because of other problems: - No files export alpha channel correctly (result often has opaque background, sometimes image is totally empty). - Most files in Gray/Alpha color space export Gray channel incorrectly (often file is green). - Some files appear broken in other viewers (in addition to the problems above when opening in Krita), e.g. some TIFF previews are all messed up in Dolphin. - Files in "encodedBadly" folder have incorrect colors because the result expects linear colors but they didn't convert from sRGB, so they're lighter than the original. This can be seen by inspecting the "0.5" gray in the middle. Triangle was sRGB gray (should be close to #808080) and circle was linear gray (should be 0.5f in linear space, equivalent to #bcbcbc); tertiary colors also use the same logic. EXPECTED RESULT Files must look like the original, at least when opening them in Krita (but preferably also in other apps like Gwenview, GIMP). Colors must correspond too. If the format doesn't support something, it'd be better to have a lossy or heavier conversion than a broken or badly encoded file. SOFTWARE/OS VERSIONS Operating System: Kubuntu 22.10 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.0-23-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-5300U CPU @ 2.30GHz Memory: 11.1 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 5500 ADDITIONAL INFORMATION I don't expect broken images in the color spaces not included in the attachment. I had made a similar test for 5.1.1 for (pretty much) all color models, exporting to PNG, EXR and TIFF. However, files are CC0, so feel free use them and this script method to make conversion tests in Krita development if desired. Such automated scripts can help testing many files at once, so I suggest using a similar method to test: - Whether conversions are breaking files. - Whether command-line conversions are different from GUI exporting. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #13 from Geekley --- https://github.com/sddm/sddm/issues/1609 I've added the summary from here and a link to this page. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460631] New: Krita command line export freezes while Krita GUI is open
https://bugs.kde.org/show_bug.cgi?id=460631 Bug ID: 460631 Summary: Krita command line export freezes while Krita GUI is open Classification: Applications Product: krita Version: 5.1.1 Platform: Kubuntu OS: Linux Status: REPORTED Severity: major Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: mrgeek...@gmail.com Target Milestone: --- SUMMARY (a) When running a command-line command like --export or --export-sequence, the process does not run until Krita is closed. This makes it impossible to use the commands (e.g. from external apps) while working in Krita. It doesn't matter which file is open in Krita, it just won't execute the command while GUI is open for some reason. This happens both on 5.1.1-flathub and 5.0.2-apt at least. I don't know when the bug was introduced. (b) A very similar problem also happens (at least in 5.1.1-flathub; don't know if it's because of flatpak) where it freezes on splash screen when either: - Krita GUI is open (with or without files open) and `flatpak run org.kde.krita` is run - A Krita file is open in the GUI and `flatpak run org.kde.krita samefile.kra` is run to open the same file All of these only unfreeze after Krita GUI is closed. STEPS TO REPRODUCE 1. Open Krita GUI (e.g. from app launcher) 2. Open terminal and run the command (e.g. `krita --export file.kra --export-filename file.webp`; also happens with other commands) OBSERVED RESULT Process is stuck (if command was to open GUI, it's stuck on splash screen), and only unfreezes when Krita is closed. EXPECTED RESULT No Krita command-line commands should ever freeze. Export commands should work regardless of whether Krita GUI is open. Ideally, export commands should even be allowed to run in parallel. Same for export-sequence (animation frames). SOFTWARE/OS VERSIONS Krita: 5.0.2 (apt) and 5.1.1 (Flathub) Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-50-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-5300U CPU @ 2.30GHz Memory: 11.1 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 5500 ADDITIONAL INFORMATION This looks similar to #342672 and #400459 but it seems to be a different bug. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 446180] New: No longer possible to preview text files only on information panel while keeping file type icon
https://bugs.kde.org/show_bug.cgi?id=446180 Bug ID: 446180 Summary: No longer possible to preview text files only on information panel while keeping file type icon Product: dolphin Version: 21.08.1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: panels: information Assignee: dolphin-bugs-n...@kde.org Reporter: mrgeek...@gmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Before I upgraded Kubuntu (and Dolphin), I was able to have Dolphin somehow set to show text file (e.g. .txt, .sh, .ini, etc) previews ONLY on information panel. I can't remember the exact setting or how I made that work, but it's gone now, it seems. STEPS TO REPRODUCE 1. Open Dolphin on a folder with files, e.g: a.txt, b.png, c.pdf, some-prog (a sh/shebang file), etc 2. Have both compact mode and info panel on and set to show previews. 3. Open Dolphin settings, General, Previews, and toggle "Text Files" on/off OBSERVED RESULT The preview setting is tied to both the compact view icons and info panel. EXPECTED RESULT Should be somehow able to config Dolphin to set text previews to only show on info panel / hover tooltip while retaining file-type icons, and while non-text previews (images, pdf, etc) still appear on both. SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-21-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I'm pretty sure I had that working before (at least in compact view, Kubuntu 20.10), but it stopped working with Kubuntu upgrade. I can't remember if I changed some setting or if that setting didn't apply to info panel (it would just always show the preview regardless?). It seems the "preview" setting is "unified" now or something? That's bad because I want text previews, but I don't want that to screw up the file type icons. I see I can disable previews on compact mode, but that disables it for everything, including image previews as well; that doesn't help. That's unfortunate, because a proper preview REALLY helped with finding files easily. And you know, sh/executable files don't always have an extension, so I REALLY need it to show the file type icons for text files. Now I can't get both at the same time, and text files look like pdf files :( -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 406821] Dark UI color theme breaks default LightTheme
https://bugs.kde.org/show_bug.cgi?id=406821 --- Comment #17 from Geekley --- (In reply to Frank from comment #15) > You have to upgrade to KDE Applications 20.04 or above. 19.12 will not fix > it. > > If you upgrade to Kubuntu 20.10 the issue will be fixed as it uses KDE Apps > 20.08. I've just upgraded to Kubuntu 20.10, but the issue persists... :( $ apt list --installed dolphin* dolphin/groovy,now 4:20.08.2-0ubuntu1 amd64 [installed,automatic] $ apt list --installed kde* kde-cli-tools-data/groovy,groovy,now 4:5.19.5-0ubuntu1 all [installed,automatic] kde-cli-tools/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kde-config-gtk-style-preview/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kde-config-gtk-style/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kde-config-screenlocker/groovy,now 5.19.5-0ubuntu1 amd64 [installed,automatic] kde-config-sddm/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kde-config-tablet/groovy,now 3.2.0-3build1 amd64 [installed,automatic] kde-config-whoopsie/groovy,now 15.10ubuntu2 amd64 [installed,automatic] kde-spectacle/groovy,now 20.08.2-0ubuntu1 amd64 [installed,automatic] kde-style-breeze/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kde-style-oxygen-qt5/groovy,now 4:5.19.5-0ubuntu1 amd64 [installed,automatic] kdeconnect/groovy,now 20.08.2-0ubuntu1 amd64 [installed,automatic] kded5/groovy,now 5.74.0-0ubuntu1 amd64 [installed,automatic] kdegraphics-thumbnailers/groovy,now 4:20.08.1-0ubuntu1 amd64 [installed,automatic] kdenetwork-filesharing/groovy,now 4:20.08.1-0ubuntu1 amd64 [installed,automatic] kdeplasma-addons-data/groovy,groovy,now 4:5.19.5-0ubuntu1 all [installed,automatic] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 435131] SDDM allows login password prompt in 2 screens independently instead of syncing them
https://bugs.kde.org/show_bug.cgi?id=435131 --- Comment #2 from Geekley --- Ah, thanks! Indeed it's already reported at https://github.com/sddm/sddm/issues/743 Posting it here in case anyone else tries to find it -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 435131] New: SDDM allows login password prompt in 2 screens independently instead of syncing them
https://bugs.kde.org/show_bug.cgi?id=435131 Bug ID: 435131 Summary: SDDM allows login password prompt in 2 screens independently instead of syncing them Product: plasmashell Version: 5.18.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Multi-screen support Assignee: aleix...@kde.org Reporter: mrgeek...@gmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 SUMMARY When using 2 screens, the SDDM login shows in both screens INDEPENDENTLY! For example, you can type a password in one screen and a different password on the other, or select 2 different users on each screen. STEPS TO REPRODUCE 1. Boot Kubuntu. Make sure you have a second screen connected. 2; You're at SDDM. Type a password, press left/right,etc. OBSERVED RESULT Notice how the other screen doesn't change. You can even type a different password on the other screen, or select a different user. What will happen when you press enter? This is not right. EXPECTED RESULT If having both screens is allowed, they should be in sync. Anything you do in one must be reflected on the other. Or, you could show the login prompt in just one of the screens, and just empty BG on the other (though this is likely a bad idea!). SOFTWARE/OS VERSIONS OS: Kubuntu 20.04 64-bit Linux Kernel: 5.4.0-70-generic KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 ADDITIONAL INFORMATION Likely irrelevant, but I'm on a laptop, connecting to a TV/monitor, using a normal 15-pin VGA cable, not HDMI. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 Geekley changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INTENTIONAL |--- Ever confirmed|0 |1 --- Comment #11 from Geekley --- Actually, I've done more testing and SDDM still has some of these bugs even with ReuseSession=true. I took notes of the steps, in a "branching" form. STEPS TO REPRODUCE AND OBSERVED RESULTS (I merged multiple bugs I noticed when starting with the same steps, you may need to redo a few times from start to see the other "branch") prereq0a. ReuseSession=true in sddm conf; using always Plasma session, not gnome prereq0b. Have at least 2 users (in my case, they have same password, this may be relevant!) 1. Start with a fresh (re)boot of Kubuntu (don't just logout); you're at login screen. 2. Login User1 at SDDM 3. Winkey+L, Switch User; you're back at SDDM 3a. BUG#1! If you click Reboot, it takes a long time. It seems to be waiting at least 1 minute or so on purpose before rebooting, but there's no visual indication of this wait, or option to kill processes to reboot immediately (like in Windows). Again, from step 3: 4. Choose User2 at SDDM and login 5. Winkey+L, Switch User; User1 at tty1 is shown 6. Start New Session; you're back at SDDM 7. Login User1 again at SDDM 7a. BUG#2! You're back to lock screen of User2, not User1. At least it's asking for the password. 8. At this lock screen, type password to go back to User2 9. CTRL+ALT+DEL, Logout 9a. BUG#3! You're now logged to User1! This time it didn't even ask for the password (maybe having same password for both users is related to this somehow? I didn't test with different passwords)! 10. Winkey+L, Switch User 10a. BUG#4! Now there's an Unused Session! If you use this session, you're at a black screen with empty console prompt (tty2?). CTRL+ALT+DEL here will reboot, again, after long wait of > 1 minute. Again, from step 10: 11. Instead of the unused session, choose Start New Session; you're back at SDDM 12. Try to login as User2 now (type password, enter) 12a. BUG#5! You're back to User1 again! It's asking for password. Unused is still there! 12b. Not sure what happened here, but it seems that if you wait 1+ minute, it goes back to SDDM on its own? Was it logging out under the hood?? I'm not 100% sure, but I think that I just waited, because I was taking notes on a paper; I don't think I clicked New Session. Anyways, from step 12, quickly: 13. Login back to User1 again from that lock screen 14. CTRL+ALT+DEL, Logout 15. It does seem like you have to wait 1+ minute here... now you're back at SDDM 16. Try to login at User2 (password, enter) 16a. BUG#6! It seems like it would have succeeded (fade out transition), but you end up in SDDM still! If you now try User1 the same happens! You can't login to either! There's definitely something wrong in the way SDDM and/or Plasma is handling these sessions. Something about tty1/tty2, I don't know. But I don't think this happens when using GDM with Plasma. EXPECTED BEHAVIOR I'd expect that ReuseSession=true would make it so that those options "use this session" or "start new session" would not even show up (it would always behave like in step 3, even with multiple users logged in). It think this setting should make "Switch User" in lock screen ALWAYS take you to SDDM (not stay in lock screen to see the other sessions). Then on SDDM (not lock screen), you'd be able to see some visual indication on each user of whether or not they're already logged in. For example, a dot next to the user avatar img, or some text like "(logged in)" after the user name. And if you try to reboot or shut down from there, it should show a dialog asking for confirmation, like: "Some users are still logged in, are you sure?"; that dialog can have the wait time of 1+ minute to kill it if you don't click anything; or the option to cancel or shut down immediately without waiting. And it would never use tty2 for anything GUI if I don't explicitly ask for it (like by pressing CTRL+ALT+F2 or something). All GUI sessions are in tty1, in fact, a novice user shouldn't even notice that this is a thing. SOFTWARE/OS VERSIONS OS: Kubuntu 20.04 64-bit Linux Kernel: 5.4.0-70-generic KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #10 from Geekley --- Thanks! I've set it in a `/etc/sddm.conf.d/reuse.conf` and it worked after a reboot! Good to know it will be default. That does solve the problem, and makes a lot more sense. While it's technically still a bug for people who'd use duplicate GUI sessions, I'd say whatever. This is likely an extremely rare use case anyways, and it's only fair that it's not properly supported (and it must be a pain to test things taking this in consideration). In fact, I wonder what would even be a valid use case for that? Legit question. I couldn't find info in a quick search on the web. Maybe for people to be able to test Gnome/Plasma or X/Wayland in parallel or something? Testing environment vars? Is this, like, a feature mostly for helping developers test things? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 Geekley changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #7 from Geekley --- > I think CTRL+ALT+F7 / CTRL+ALT+F1 doesn't work either. I tested now and CTRL+ALT+F1 did seem to bring me out of the softlock at first (I could go back to the logged session), but it was still buggy because "Leave session" command didn't work after that. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #6 from Geekley --- Sorry for the delay. I had to use dpkg-reconfigure to switch back to sddm (I had changed to gdm3 because of this bug). Here's the output after changing back: $ sddm --example-config [Autologin] # Whether sddm should automatically log back into sessions when they exit Relogin=false # Name of session file for autologin session (if empty try last logged in) Session= # Username for autologin session User= [General] # Halt command HaltCommand=/bin/systemctl poweroff # Input method module InputMethod=qtvirtualkeyboard # Comma-separated list of Linux namespaces for user session to enter Namespaces= # Initial NumLock state. Can be on, off or none. # If property is set to none, numlock won't be changed # NOTE: Currently ignored if autologin is enabled. Numlock=none # Reboot command RebootCommand=/bin/systemctl reboot [Theme] # Current theme name Current=ubuntu-theme # Cursor theme used in the greeter CursorTheme= # Number of users to use as threshold # above which avatars are disabled # unless explicitly enabled with EnableAvatars DisableAvatarsThreshold=7 # Enable display of custom user avatars EnableAvatars=true # Global directory for user avatars # The files should be named .face.icon FacesDir=/usr/share/sddm/faces # Theme directory path ThemeDir=/usr/share/sddm/themes [Users] # Default $PATH for logged in users DefaultPath=/bin:/usr/bin # Comma-separated list of shells. # Users with these shells as their default won't be listed HideShells= # Comma-separated list of users that should not be listed HideUsers= # Maximum user id for displayed users MaximumUid=6 # Minimum user id for displayed users MinimumUid=1000 # Remember the session of the last successfully logged in user RememberLastSession=true # Remember the last successfully logged in user RememberLastUser=true # When logging in as the same user twice, restore the original session, rather than create a new one ReuseSession=false [Wayland] # Enable Qt's automatic high-DPI scaling EnableHiDPI=false # Path to a script to execute when starting the desktop session SessionCommand=/etc/sddm/wayland-session # Directory containing available Wayland sessions SessionDir=/usr/share/wayland-sessions # Path to the user session log file SessionLogFile=.local/share/sddm/wayland-session.log [X11] # Path to a script to execute when starting the display server DisplayCommand=/usr/share/sddm/scripts/Xsetup # Path to a script to execute when stopping the display server DisplayStopCommand=/usr/share/sddm/scripts/Xstop # Enable Qt's automatic high-DPI scaling EnableHiDPI=false # The lowest virtual terminal number that will be used. MinimumVT=1 # Arguments passed to the X server invocation ServerArguments=-nolisten tcp # Path to X server binary ServerPath=/usr/bin/X # Path to a script to execute when starting the desktop session SessionCommand=/etc/sddm/Xsession # Directory containing available X sessions SessionDir=/usr/share/xsessions # Path to the user session log file SessionLogFile=.local/share/sddm/xorg-session.log # Path to the Xauthority file UserAuthFile=.Xauthority # Path to xauth binary XauthPath=/usr/bin/xauth # Path to Xephyr binary XephyrPath=/usr/bin/Xephyr -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 406821] Dark UI color theme breaks default LightTheme
https://bugs.kde.org/show_bug.cgi?id=406821 --- Comment #16 from Geekley --- Thanks! I asked for a backport on launchpad (is that the right place for this? do I need to provide more info?) https://bugs.launchpad.net/ubuntu/+source/dolphin/+bug/1901431 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 409380] Formatting by KSyntaxHighlighting::SyntaxHighlighter of normal text seems to be dropped partially (Qt >=5.13.0/5.12.4)
https://bugs.kde.org/show_bug.cgi?id=409380 Geekley changed: What|Removed |Added CC||mrgeek...@gmail.com --- Comment #7 from Geekley --- Still happening: https://bugs.kde.org/show_bug.cgi?id=406821 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-syntax-highlighting] [Bug 406821] Dark UI color theme breaks default LightTheme
https://bugs.kde.org/show_bug.cgi?id=406821 Geekley changed: What|Removed |Added CC||mrgeek...@gmail.com --- Comment #14 from Geekley --- Still getting this bug on updated Kubuntu 20.04. Plain text is white on white, while syntax colored text is displayed as normal. Dolphin 19.12.3 Linux (x86_64) release 5.4.0-52-generic Qt 5.12.8 KDE Plasma 5.18.5, KDE Frameworks 5.68.0 Plasma Color Scheme: Breeze Dark -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 375951] locally integrated menus
https://bugs.kde.org/show_bug.cgi?id=375951 Geekley changed: What|Removed |Added CC||mrgeek...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424322] Switch user does not work
https://bugs.kde.org/show_bug.cgi?id=424322 Geekley changed: What|Removed |Added CC||mrgeek...@gmail.com --- Comment #8 from Geekley --- I just reported a possible duplicate of this, with additional info. https://bugs.kde.org/show_bug.cgi?id=426194 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #2 from Geekley --- Oops, just noticed possible duplicate: https://bugs.kde.org/show_bug.cgi?id=424322 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 --- Comment #1 from Geekley --- Output of Command: apt list *sddm* | grep installed kde-config-sddm/focal,now 4:5.18.4.1-0ubuntu1 amd64 [installed,automatic] sddm-theme-breeze/focal-updates,now 4:5.18.5-0ubuntu0.1 amd64 [installed,automatic] sddm/focal,now 0.18.1-1ubuntu2 amd64 [installed,automatic] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 426194] New: OS Soft-lock when locking screen and switching back to the same user; running session isn't restored
https://bugs.kde.org/show_bug.cgi?id=426194 Bug ID: 426194 Summary: OS Soft-lock when locking screen and switching back to the same user; running session isn't restored Product: plasmashell Version: 5.18.5 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: Lock/logout Assignee: plasma-b...@kde.org Reporter: mrgeek...@gmail.com Target Milestone: 1.0 SUMMARY When locking Plasma session, and clicking switch user, I can't go back to same user (unlock session) in SDDM. Plasma tries to start new session, but shows nothing. Whole system soft-locks and can't be interacted with. Keystrokes don't work. Can't recover from this state without a shutdown. STEPS TO REPRODUCE Steps I tested: 0a. (have multiple user accounts, may be relevant) 0b. (you may want to open some app; but make sure no important apps / files are open since you'll have to force a shutdown) 0c. (you may want to set some FG and BG apps to load on startup, to see the missing title bar effect) 0d. (not sure if relevant, but in System Settings > Startup and Shutdown > Desktop Session, you may want to set it to "Start with empty session") 1. Lock screen (META+L) 2. Click switch user 3. Choose same user, type password, enter 4. Wait for Plasma startup animation 5. There is a black screen / BG; system soft-locks 6. Test various keystrokes; but can only use power button here (press, no need to hold); takes a while to shutdown or reboot Combinations that I didn't test, but might cause this too: - Using Menu > Leave > Lock Screen (instead of shortcut) - PROBABLY YES - Switch user directly (without Lock Screen first) - PROBABLY NOT - Switch to different user, then back (using various methods) - PROBABLY NOT - Anything involving terminal (CTRL+ALT+F7 / CTRL+ALT+F1) - NO IDEA OBSERVED RESULT After entering password, previous session isn't restored / unlocked. Plasma/Breeze presentation screen is shown, as if trying to start a new session. It seems to fail to start a new session. BG / Plasma UI isn't loaded, so a black screen is shown. The apps configured to load on startup are loaded (and seem kind of interactable), but windows have no title bar. The apps that were open when locked session are nowhere to be seen, but I assume they're still running. The taskbar / task manager panel isn't loaded. OS Keyboard shortcuts (such as CTRL+ALT+DEL) don't seem to work as expected (should show options to logout, etc). I think CTRL+ALT+F7 / CTRL+ALT+F1 doesn't work either. Unable to recover from this state (soft-lock? hang?). The only thing that seems to work is pressing (no need to hold) the laptop power button. When I do that, screen goes black. After long wait, it shuts down or reboots the computer "gracefully" (I hope?). EXPECTED RESULT Screen should be unlocked, and all apps from running session should be restored. SOFTWARE/OS VERSIONS OS: Kubuntu 20.04 64-bit Linux Kernel: 5.4.0-45-generic KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Output of Command: apt list plasma* | grep installed plasma-browser-integration/focal-updates,now 5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-calendar-addons/focal,now 4:5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-dataengines-addons/focal,now 4:5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-desktop-data/focal-updates,focal-updates,now 4:5.18.5-0ubuntu0.1 all [installed,automatic] plasma-desktop/focal-updates,now 4:5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-discover-backend-fwupd/focal-updates,now 5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-discover-backend-snap/focal-updates,now 5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-discover-common/focal-updates,focal-updates,now 5.18.5-0ubuntu0.1 all [installed,automatic] plasma-discover-snap-backend/focal-updates,focal-updates,now 5.18.5-0ubuntu0.1 all [installed,automatic] plasma-discover/focal-updates,now 5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-framework/focal,now 5.68.0-0ubuntu1 amd64 [installed,automatic] plasma-integration/focal,now 5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-nm/focal-updates,now 4:5.18.4.1-0ubuntu1.1 amd64 [installed,automatic] plasma-pa/focal-updates,now 4:5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-runners-addons/focal,now 4:5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-thunderbolt/focal,now 5.18.4.1-0ubuntu1 amd64 [installed,automatic] plasma-vault/focal-updates,now 5.18.5-0ubuntu0.1 amd64 [installed,automatic] plasma-wallpapers-addons/focal,now 4:5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-widgets-addons/focal,now 4:5.18.4.1-0ubuntu2 amd64 [installed,automatic] plasma-workspace/focal-updates,now 4:5.18.5-0ubuntu0.1 amd64 [installed,automatic] ADDITIONAL INFORMATION When I talk about "restoring session" I mean unlocking screen,
