[plasmashell] [Bug 456418] Color picker applet doesn't pick a color
https://bugs.kde.org/show_bug.cgi?id=456418 MountainX changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|REOPENED --- Comment #7 from MountainX --- (In reply to Antonio Rojas from comment #6) > > *** This bug has been marked as a duplicate of bug 454974 *** Bug 454974 reports that the result is "returns black". This bug appears to be different and not a duplicate of 454974. Furthermore, this bug is not resolved as of plasmashell 5.25.4 while 454974 was marked as fixed in 5.24.7. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454974] DBus method ColorPicker.pick fails to retrieve color (returns black)
https://bugs.kde.org/show_bug.cgi?id=454974 MountainX changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #24 from MountainX --- (In reply to MountainX from comment #23) > (In reply to Antonio Rojas from comment #22) > > *** Bug 457311 has been marked as a duplicate of this bug. *** > > That bug says the result is "returns black". This bug appears to be > different and not a duplicate. Furthermore, this bug is not resolved as of > plasmashell 5.25.4 while that bug was marked as fixed in 5.24.7. I apologize. I added this comment to the wrong bug. Will add it to 456418 where it belongs. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454974] DBus method ColorPicker.pick fails to retrieve color (returns black)
https://bugs.kde.org/show_bug.cgi?id=454974 MountainX changed: What|Removed |Added Resolution|FIXED |--- CC||davestechs...@gmail.com Status|RESOLVED|REOPENED --- Comment #23 from MountainX --- (In reply to Antonio Rojas from comment #22) > *** Bug 457311 has been marked as a duplicate of this bug. *** That bug says the result is "returns black". This bug appears to be different and not a duplicate. Furthermore, this bug is not resolved as of plasmashell 5.25.4 while that bug was marked as fixed in 5.24.7. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 457142] I am *never* seeing the clock on the lock screen
https://bugs.kde.org/show_bug.cgi?id=457142 --- Comment #7 from MountainX --- Created attachment 150957 --> https://bugs.kde.org/attachment.cgi?id=150957&action=edit LockScreen_20220727_190914 screen shot lock screen as requested -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 457142] I am *never* seeing the clock on the lock screen
https://bugs.kde.org/show_bug.cgi?id=457142 --- Comment #5 from MountainX --- (In reply to Nate Graham from comment #4) > That's really odd. Can you attach a screenshot of your lock screen when the > auth prompt is visible, and a screenshot of your lock screen when the auth > prompt disappears? I can, but it is also very simple to describe it completely in text: 1. when the auth prompt is visible: - upper left area of screen: nothing is displayed - upper right area: nothing - lower left: keyboard icon with text description of my keyboard layout - lower right: battery icon with percent charging text - center, upper: user avatar with text of username below it - center middle: text input box for password with ">" button to right. - center lower: hibernate and suspend clickable icons - background: my wallpaper If I enable media controls in settings, they are visible. When I uncheck them (as they are currently), they are not visible. Checking or unchecking the clock setting has no effect whatsoever. 2. when the auth prompt disappears: - background: my wallpaper (exactly the same wallpaper as in #1) Nothing else is shown at all. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 457142] I am *never* seeing the clock on the lock screen
https://bugs.kde.org/show_bug.cgi?id=457142 --- Comment #3 from MountainX --- (In reply to Nate Graham from comment #2) > Hmm, none of those errors seem related to the clock. Do you have anything in > ~/.local/share/plasma/desktoptheme/? If so, can you print the contents? I do not have that folder. And inside ~/.local/share/plasma/, I only have: plasmoids: -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 454074] Clock missing on lock screen
https://bugs.kde.org/show_bug.cgi?id=454074 --- Comment #10 from MountainX --- (In reply to Nate Graham from comment #9) > The video in the original report depicts a valid state, so I suspect it was > caused by the same misunderstanding that other people reported in Bug > 429468, which has been resolved for Plasma 5.26 by clarifying the text in > the config window. > > If you're *never* seeing the clock on the lock screen--either when the auth > prompt is visible or also when it's not visible--that would be a different > bug. Can you file a new bug report for it? In that bug report, please run > `kscreenlocker_greet --testing` and paste the output. > > (note: if kscreenlocker_greet is not be in your $PATH, you'll have to locate > it manually) > > Thanks! Does my comment in Bug 457142 contain the info you need? I included the output of `kscreenlocker_greet --testing` (and I didn't see anything useful in there, but I'm not a dev). -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 457142] I am *never* seeing the clock on the lock screen
https://bugs.kde.org/show_bug.cgi?id=457142 --- Comment #1 from MountainX --- output of kscreenlocker_greet --testing [code] $ /usr/lib/kscreenlocker_greet --testing file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:222: ReferenceError: wallpaper is not defined file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:0: ReferenceError: wallpaper is not defined file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:0: ReferenceError: wallpaper is not defined file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/VirtualKeyboard.qml:8:1: module "QtQuick.VirtualKeyboard" is not installed file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml:0: ReferenceError: wallpaper is not defined Locked at 1658786137 file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool file:///usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/components/UserList.qml:43:9: Unable to assign [undefined] to bool QXcbClipboard: SelectionRequest too old QXcbClipboard: SelectionRequest too old QXcbClipboard: SelectionRequest too old ... QXcbClipboard: SelectionRequest too old QXcbClipboard: SelectionRequest too old QXcbClipboard: SelectionRequest too old [/code] Sorry, can't seem to find the right method to format code here or in bugzilla.readthedocs.io -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 457142] New: I am *never* seeing the clock on the lock screen
https://bugs.kde.org/show_bug.cgi?id=457142 Bug ID: 457142 Summary: I am *never* seeing the clock on the lock screen Product: kscreenlocker Version: 5.25.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: davestechs...@gmail.com CC: bhus...@gmail.com Target Milestone: --- I am *never* seeing the clock on the lock screen This issue was previously discussed in Bug 454074, but my issue is slightly different from that bug. Plasma Workspace is installed from the "Extra" Arch Linux repo. All my files in /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/ appear to be original and unmodified. usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockOsd.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreen.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MainBlock.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MediaControls.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/NoPasswordUnlock.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/config.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/config.xml All those files are owned by the plasma-workspace 5.25 package. My theme is Breeze Dark. My Plasma Style is Breeze Dark. Splash Screen is Breeze. The only non-standard components I'm using are: 1. Sugar Dark sddm login theme, but I have read that the login and lockscreen themes are independent. 2. the ClassiK application style, but this clock issue existed long before I ever install ClassiK. 3. Window Decorations are ClassiK. # STEPS TO REPRODUCE 1. Use Breeze Dark theme 2. In System Settings > Workspace Behavior > Screen Locking > Configure, check the box: Show [x] Clock 3. Lock the screen and look to see Clock either when the auth prompt is visible or when it's not visible. In my case, no clock is ever shown. Strangely, the issue is present on my laptop and desktop and another Arch Linux device too. OBSERVED RESULT Clock is not shown when the auth prompt is visible Clock is not shown when the auth prompt is invisible EXPECTED RESULT I used to have a clock on the lock screen. It disappeared some time ago and I don't know why. Have been trying for a long time to get it back. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 5.25 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.4 (built against 5.15.4) -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 454074] Clock missing on lock screen
https://bugs.kde.org/show_bug.cgi?id=454074 --- Comment #8 from MountainX --- My theme is Breeze Dark. It is the standard package, not a fork. It is installed from the "Extra" Arch Linux repo. All my files in /usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/ are original, unmodified. usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockOsd.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreen.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/LockScreenUi.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MainBlock.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/MediaControls.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/NoPasswordUnlock.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/config.qml usr/share/plasma/look-and-feel/org.kde.breeze.desktop/contents/lockscreen/config.xml All those files are owned by the plasma-workspace 5.25.3.1-1 package. The only non-standard component I'm using is an sddm login theme, but I have read that the login and lockscreen themes are independent. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 429468] Screen locker KCM option to hide clock is misleading
https://bugs.kde.org/show_bug.cgi?id=429468 --- Comment #14 from MountainX --- (In reply to Nate Graham from comment #13) > I would suspect you're using a 3rd-party login screen theme or a fork of the > default one, rather than the default Breeze theme. Afaik, I'm using the stock Breeze dark theme and my lock screen is Breeze. What is the best way to check that I'm using the lock screen theme you expect me to be using? Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 454074] Clock missing on lock screen
https://bugs.kde.org/show_bug.cgi?id=454074 --- Comment #7 from MountainX --- (In reply to David Edmundson from comment #6) > I believe this is fixed for 5.25.0 Not fixed for me. Arch Linux $ plasmashell --version plasmashell 5.25.0 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 429468] Screen locker KCM option to hide clock is misleading
https://bugs.kde.org/show_bug.cgi?id=429468 --- Comment #12 from MountainX --- (In reply to Nate Graham from comment #9) > I see the problem. > > What this setting does is to *always* show the clock, even when the password > prompt and user avatar are hidden. That's the result I would like. Can you explain how to make it happen? None of the settings I have tried will make the clock visible under any circumtances. I used to have a clock always on my lock screen. Not sure why it went away and I haven't been able to get it back. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456418] Color picker applet doesn't pick a color
https://bugs.kde.org/show_bug.cgi?id=456418 MountainX changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 Status|NEEDSINFO |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456418] Color picker applet doesn't pick a color
https://bugs.kde.org/show_bug.cgi?id=456418 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #5 from MountainX --- I am experiencing this issue on Arch Linux KDE on multiple devices (desktops and laptops). Happens with nvidia propriety driver on desktop and Intel graphics on laptop. All Arch systems are fully updated. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 429468] Screen locker shows clock despite "Clock" being unchecked in Screen Locking KCM
https://bugs.kde.org/show_bug.cgi?id=429468 --- Comment #8 from MountainX --- (In reply to Nate Graham from comment #7) > Can confirm this issue. MountainX, let's discuss your issue in Bug 454074. I'm happy to discuss it in either issue report. Thank you for your interest in working on this. If you need more info, let me know. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 454074] Clock missing on lock screen
https://bugs.kde.org/show_bug.cgi?id=454074 MountainX changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|WORKSFORME |--- -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 454074] Clock missing on lock screen
https://bugs.kde.org/show_bug.cgi?id=454074 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #3 from MountainX --- I have the same issue, also on Arch Linux. Unfortunately, it is not resolved for me. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 429468] Screen locker shows clock despite "Clock" being unchecked in Screen Locking KCM
https://bugs.kde.org/show_bug.cgi?id=429468 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #6 from MountainX --- My problem may be related to this, although the specific issue is exactly the opposite. Under System Settings > Workspace Behavior > Screen Locking > Appearance (Configure), I have `Show: Clock` checked. But the clock is not shown on the lock screen. I cannot locate any errors related to this. Everything else related to the lock screen works as expected. I don't normally show the Media Controls, but if I check that, they are shown, and when I uncheck it, they are not shown. The clock is the only lock screen feature I notice that refuses to work. I'm running KDE Plasma 5 on Arch Linux, fully updated. The problem affects my desktop and laptop (both run Arch). Under the directory `~/.local/share/plasma/` my only file/folder is `plasmoids`. I do not have a `~/.local/share/plasma/look-and-feel/` directory. I assume it should work without a custom theme and I assume I don't have that folder because I don't have a custom theme installed. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 306257] Add a feature so that we can save and restore a dolphin session
https://bugs.kde.org/show_bug.cgi?id=306257 --- Comment #15 from MountainX --- @Jens Lallensack RE: "Bookmark Tabs as Folder…" That's interesting, but not intuitive. Where can we learn more about using this new feature? So far I don't get it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 429622] Re-enable “show password” button on login screen
https://bugs.kde.org/show_bug.cgi?id=429622 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #4 from MountainX --- I support re-adding it. It's essential for us. We had no problems with it. But removing it has caused me lots of support headaches. I vote for putting it back as-is and then work on addressing the issues without removing essential functionality. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 416478] SDDM theme: the password box is tiny
https://bugs.kde.org/show_bug.cgi?id=416478 --- Comment #5 from MountainX --- FYI I stopped using the breeze theme for sddm. (I switched to sugar-dark.) However, if this issue has been fixed, I am interested in switching back. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #11 from MountainX --- 1. I did further testing on two desktop computers. I used the same user-places.xbel file on both. (Copying the file from one computer to the other seems to work fine.) The large version of that file increases Dolphin startup time by at least 400% on both computers. On the faster computer, Dolphin startup time goes from 0.49 seconds to 2.045 seconds. (The effect is greater on the other computer.) Deleting the user-places.xbel file results in dramatic speed up. Using a file with more entries (including entries on NFS mounts and with custom icons) results in dramatic slow down. This is confirmation of what I reported earlier after more testing on the second computer. On a computer where Dolphin performs very snappy I was able to make it become very sluggish simply by copying the larger user-places.xbel to it (without making any other changes). 2. The slow startup is not just the first time. With Dolphin open, opening a new window is just as slow as the first startup. File dialogs become consistently slow, so it seems whatever is slowing Dolphin down is not being cached. 3. Next I looked at the effect of NFS mounts separate from my Places bookmark entries. I started by deleting user-places.xbel, and let Dolphin create the minimal version. As mentioned, I have 10 NFS mounts defined in /etc/fstab. I timed Dolphin startup time. Then I removed all NFS mounts from /etc/fstab on one computer and umounted all those mounts, and again let Dolphin create a minimal user-places.xbel (which is now very small). Removing all NFS mounts from the computer makes a further improvement in Dolphin start up time. This reinforces the value of an option in Dolphin to ignore (do not read, access) certain entries in user-places.xbel. Many of mine are never opened in Dolphin, but I have to pay a cost for them every time I open Dolphin or any KDE file dialog. 4. Next I deleted Dolphin settings (~/.config/dolphinrc) and tested that way. Then I manually recreated all my original Dolphin settings (split pane view, etc.). I did not detect any effect on Dolphin startup time. I believe I can rule out dolphinrc as being responsible for a significant startup delay. Bottom line: it's user-places.xbel, NFS mounts and maybe folder icons. And the effect of these things on Dolphin startup time KDE file dialogs is huge. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #10 from MountainX --- I was able to do further testing. I found some interesting things. 1. This issue is affected greatly by ~/.local/share/user-places.xbel. Deleting that file causes Dolphin to create a new one that contains only local storage devices and remote mounts (such as NFS) that are listed in /etc/fstab. This seems to be the minimal user-places.xbel that is possible in Dolphin. Comparing the minimal user-places.xbel to a "large" version with 30 user bookmarks, half of which have a customized icon, I see a difference in Dolphin startup time of over 600%. With the "large" user-places.xbel my Dolphin startup time is 2-3 seconds. KDE file dialogs are also similarly slow to come up. The the minimal version of user-places.xbel, KDE file dialogs open without any apparent delay and Dolphin has a minimal delay (I estimate half a second). The approximate half second delay may be due to the fact that my minimal version includes 10 NFS mounts. I create intermediate versions, each with varying amounts of my own bookmarks in Places (which increases the items in user-places.xbel compared to the minimal). With each increase, there is a corresponding longer startup time for Dolphin and a corresponding longer time for KDE file dialogs to come up. I had seen this behavior before, but now we have verified it in a more rigorous way. I am highly confident that user-places.xbel can have a strong negative impact on Dolphin start up times (and KDE file dialogs). The relationship is 100% causal and 100% reproducible. 2. I believe there may be another factor involved as well. I have access to another computer running Arch Linux and the same versions of KDE (latest). A colleague and I tested similar configurations of user-places.xbel. The second computer does not show as steep a decline in Dolphin performance with increasing entries in user-places.xbel. The effect is still present, but much more moderate. I will continue experimenting to see if I can find this missing factor. I have some guesses: - Is it the icons used for folders? Maybe. - Is it the NFS mounts? No. We set up both computers with the same NFS mounts in /etc/fstab. - Is it the Dolphin startup directory? No. - Is it a hardware difference (such as CPU, RAM, SSD or GPU) between the test computers? No. - Is it recently-used.xbel? Apparently no (with simple testing). 3. There are no obvious differences in the straces or perf reports between the two computers. Obviously, we do not have debug symbols and we do not know how to do debugging or perf testing in great detail. One computer has much better Dolphin startup time and KDE file dialog performance than the other, but they do not have overall different performance on benchmarks or apps. (The slightly faster machine is the one with slower Dolphin & file dialogs). Questions: 1. We would like to copy versions of user-places.xbel from one computer to another for testing. How can we handle the unique ID in each entry in this file? What are those ID's matched against? Example: 1580172204/1 2. Is there a way I can test Dolphin without any entries in user-places.xbel (without altering /etc/fstab)? 3. what other files, besides user-places.xbel and recently-used.xbel, could impact Dolphin startup times? Should we test with a specific dolphinrc configuration? Or should we delete that file for testing? Suggestions: Can you add an "ignore" feature (not simply "hide" the display of the entry, but more like "do not access") that would avoid placing unwanted system mount points in user-places.xbel? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #8 from MountainX --- > I need the perf output of hotspot. I don't have the debug symbols. Is the perf output of hotspot still of use to you? If so, how do I get it? I'm not seeing an output option in hotspot commands/menus. Do you mean the raw perf.data file I recorded with `perf record`? I used `perf record --call-graph lbr dolphin`. Is that sufficient? Sorry, all this is new to me. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #6 from MountainX --- Created attachment 128986 --> https://bugs.kde.org/attachment.cgi?id=128986&action=edit Hotspot bottom up Attachment 2 of 2. Is this normal for Dolphin startup? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #5 from MountainX --- Created attachment 128985 --> https://bugs.kde.org/attachment.cgi?id=128985&action=edit Hotspot top down Attachment 1 of 2. Is it normal for Dolphin's startup processes to be dominated by QImageReader::read()? This perf data was recorded just for opening Dolphin. No other activity occurred. I use custom images for several dozen folder icons. Could that cause a performance issue? I also use my own icons for all the items in my Places bookmarks. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #4 from MountainX --- > the problem should be obvious using a flamegraph tool such as > https://github.com/KDAB/hotspot This looks interesting. A lot of it is over my head, but I am willing to give it a try. > pay attention to its caveat (super user rights) I don't understand the steps at https://github.com/KDAB/hotspot#recording-with-perf-without-super-user-rights Here are some questions I have: >> This is achieved by applying these steps, bundled into a script that is run >> via kdesudo or kdesu. Do I run `kdesudo elevate_perf_privileges.sh` before launching the HotSpot tool? > Using Hotspot: First of all, record some data with perf. To get backtraces, > you will need to enable the dwarf callgraph mode: >> perf record --call-graph dwarf What are the exact steps I would need to do? Is this correct? 1. kdesudo elevate_perf_privileges.sh 2. perf record --call-graph dwarf dolphin 3. open the HotSpot GUI? > It would need the debug symbols still to be useful I don't think I will be able to compile packages from source. Is it still worth doing any of this? I will proceed even without debug symbols if this will allow me to see if Dolphin is being slowed by a configuration in my user profile (such as some *rc file) or by something like a large list of recently used files, etc. If the information will be granular enough to allow me to learn something, I will proceed to investigate even without being able to compile the executable with debug symbols. On the other hand, if it is a complete waste of my time, let me know and we'll have to hope somebody with more skills can provide the debug info. > How many files or folders does your home folder contain? 183 at level 1 using 'wc -l' Setting Dolphin to open at another location doesn't affect the issue. > Does this happen when dolphin or the kde file dialog open any directory at > launch ? Yes. > Do you have many symlinks in your home ? No. > Do you have network drives ? If yes how many ? Yes. Around 10 NFS mounts. > Is it reproducible under Wayland ? I can't answer that. > Do you use Arch as well ? With same version ? Yes, I am running Arch. My current Dolphin version is 20.04.1. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 --- Comment #2 from MountainX --- This old post sounds similar to my issue: https://forum.kde.org/viewtopic.php?t=119733 I checked and Gwenview is also slow to open (like in that link) also in Dolphin, File menu | New Window is just as slow as initially opening Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 422306] Dolphin and KDE file dialogs open very slowly
https://bugs.kde.org/show_bug.cgi?id=422306 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #1 from MountainX --- I am seeing the same issue. I commented on it in the other bug report # 393977. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393977] Dolphin has become very slow after recent update
https://bugs.kde.org/show_bug.cgi?id=393977 --- Comment #31 from MountainX --- I look forward to testing git commit 60475571926d79ffad90061985f39c3ce9c686d1. Thanks for the working being done on it. I believe that fix will help with the issue of changes to the Places bookmarks being very slow. In the OP and the comments of this bug report at least two other issues are mentioned: 1. a memory leak 2. Dolphin and KDE file-open dialogs in all KDE applications open slowly. It takes about 2 seconds for the file-open dialog to display in Kate or any other application. The memory leak may not be related to this issue (Dolphin slow for specific operations) so I won't say more about it. However, the Places bookmarks are related to the long delay in Dolphin and KDE file-open dialogs opening up. I state this because when I delete ~/.local/share/user-places.xbel, the issue goes away and these dialogs (and Dolphin) open very quickly. That should be easy to confirm. If you make a large enough bookmarks list to see the problem on adding or editing a bookmark, you should also see file-open dialogs become slow to come up. My question is should I make a separate bug report or is this likely related to the fixes being done here? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393977] Dolphin has become very slow after recent update
https://bugs.kde.org/show_bug.cgi?id=393977 --- Comment #29 from MountainX --- >> Maybe it would also help to have an option to tell this code to ignore >> certain mounts? >Right click on the entry in the place menu > Hide, it's that simple. That does not remove the items from ~/.local/share/user-places.xbel Instead of "hide" I was suggesting an "ignore" feature that would avoid placing unwanted system mount points in user-places.xbel. The name of the file implies they are user-places, which seems to indicate it should contain only entries the user is interested in. Just my thoughts. Thank you for your work on this issue! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393977] Dolphin has become very slow after recent update
https://bugs.kde.org/show_bug.cgi?id=393977 --- Comment #27 from MountainX --- > I was able to reproduce the bug adding many many entries to my bookmark > menu... That's good news. Thanks for your work on this issue. I would like to add an observation. In my case I do not have to add "many many" entries. Dolphin automatically adds entries for all mount points. The mere fact that my system has 15 NFS mounts and more than one local storage device is sufficient to cause this issue with a modest number of my own bookmark entries in Places. If I delete these autogenerated entries from `user-places.xbel`, Dolphin puts them back -- even though I don't need or use them in Dolphin. Maybe it would also help to have an option to tell this code to ignore certain mounts? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393977] Dolphin has become very slow after recent update
https://bugs.kde.org/show_bug.cgi?id=393977 --- Comment #25 from MountainX --- close Dolphin mv ~/.local/share/user-places.xbel ~/.local/share/user-places.xbel.bak open Dolphin The above steps eliminate the slowness. That also eliminates all my Places bookmarks, so it is not a solution. For testing, it does indicate that the comment by Nate Graham (2018-05-08) is looking in the right direction. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393977] Dolphin has become very slow after recent update
https://bugs.kde.org/show_bug.cgi?id=393977 MountainX changed: What|Removed |Added CC||davestechs...@gmail.com --- Comment #24 from MountainX --- I'm investigating slow UI responsiveness in Dolphin on my desktop & noticed this bug report. I also run Arch Linux. What caught my attention is this part of the report: "In particular, adding or moving a bookmark in the Places panel has a delay of several seconds." That is the same behavior I'm observing. Adding a new bookmark to Dolphin's Places sidebar has a long delay and it causes the Dolphin UI to freeze for this time. The same delay is seen if I edit the item in Places and change its display name, or remove an item. I timed dragging & dropping a local directory onto Places. It took 15 seconds for that item to appear in Places, but Dolphin was still unresponsive for an addition 10 seconds. It was about 25 seconds before I could navigate or use the UI. The delay is almost the same for a name change. Deleting an item from Places seems to require about 15 seconds. Other operations in Dolphin do not appear to be slow, and the overall experience is not slow. There is one thing I notice that it not mentioned by the OP. All KDE file-open dialogs open slowly. It takes about 2 seconds for the file-open dialog to display in Kate or any other application. GTK file-open dialogs are nearly instant. wc -l ~/.local/share/user-places.xbel 1649 I use KDE on a number of different devices. The computer used for the timings mentioned above has 128 GB of RAM, a Samsung Pro NVMe, nVidia RTX 2080 GPU and an Intel i9-9900K. It has 15 NFS shared folders mounted. It has a large & slow internal HDD that is only used for automated backups and I don't open this backup location in Dolphin anyway. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 416478] SDDM theme: the password box is tiny
https://bugs.kde.org/show_bug.cgi?id=416478 --- Comment #3 from MountainX --- This info is very helpful! I appreciate understanding the issue now. - does their /usr/share/sddm/themes/breeze/theme.conf file exist? Yes. - does it have 'fontSize=10' specified inside? No. Happy to provide more info. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 388025] Failed to create backup copy
https://bugs.kde.org/show_bug.cgi?id=388025 --- Comment #6 from MountainX --- Kate 17.08.3 is able to save files to SSHFS mounts and make the backup copy when that option is enabled. Starting with Kate 17.12.0, when the "backup on save" option is enabled, Kate produces an error dialog and fails to make the backup copy on save. In an effort to isolate this, I started with an Arch Linux system that had not been updated in about two weeks. It was running Kate 17.08.3 and making backup copies on saving files to SSHFS mounts was working correctly. I attempted to upgrade only Kate from 17.08.3 to 17.12.0. However, that is not possible, as Kate 17.12.0 requires a new version of qt5-base and a number of other components. I'm running Arch Linux, and Arch doesn't support partial upgrades anyway. So I am forced to do a full system update in order to move from Kate 17.08.3 to 17.12.0. But when I do that upgrade, Kate 17.12.0 fails to be able to make backup copies on saving the file. The problem also happens in the latest version of KWrite. However, KWrite does not produce the error dialog. It fails silently (not a good thing when this means that your expected backup copies simply are not made). -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 388025] Failed to create backup copy
https://bugs.kde.org/show_bug.cgi?id=388025 --- Comment #5 from MountainX --- (In reply to Dominik Haumann from comment #3) > The only change I can find is this one: > - https://bugs.kde.org/show_bug.cgi?id=377373 > - > https://cgit.kde.org/ktexteditor.git/commit/ > ?id=f34b10f77be12c748afaf020581a678b7293525e > > If you revert this change, does it work for you again? On my system running Kate 17.12.0 (where making the backup copy fails), testing Kate's "Save Copy As..." feature works as expected. The copy has the correct permissions and no errors are produced. I would say that's not related to this issue. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 388025] Failed to create backup copy
https://bugs.kde.org/show_bug.cgi?id=388025 --- Comment #4 from MountainX --- (In reply to Dominik Haumann from comment #3) > The only change I can find is this one: > - https://bugs.kde.org/show_bug.cgi?id=377373 > - > https://cgit.kde.org/ktexteditor.git/commit/ > ?id=f34b10f77be12c748afaf020581a678b7293525e > > If you revert this change, does it work for you again? For me, this change occurred on the update from Kate 17.08.3 to Kate 17.12.0. @Dominik, the changes you reference are much older. They were already present in Kate 17.08.3, which does not have the bug. I am happy to provide additional information if you tell me what to send. I'm not a developer and I do not have developer tools installed. But I can send logs or run specific tests. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 246028] wish for being able to save "sessions" (with multiple tabs)
https://bugs.kde.org/show_bug.cgi?id=246028 --- Comment #6 from MountainX --- I hope this is still being considered -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 306257] Add a feature so that we can save and restore a dolphin session
https://bugs.kde.org/show_bug.cgi?id=306257 --- Comment #11 from MountainX --- I remain very interested in this feature. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 388025] New: Failed to create backup copy
https://bugs.kde.org/show_bug.cgi?id=388025 Bug ID: 388025 Summary: Failed to create backup copy Product: kate Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: davestechs...@gmail.com Target Milestone: --- Version 17.12.0 Arch Linux (fully updated) To reproduce: Kate Settings > Open/Save > Advanced tab Under "Backup on Save" check local files and remote files. Apply. All other settings can be default. Mount an SSHFS share. Save a file to that location. After saving it, attempt to modify it and save it again (which will cause Kate to produce a backup file). (You may need to close it and reopen the file before modifying. But I'm not sure about that step.) Expected result: File is saved, backup copy is made and no error messages are producted. Actual result - error message shown next: Failed to create backup copy. -- Kate For file /home/user/documents/test.txt no backup copy could be created before saving. If an error occurs while saving, you might lose the data of this file. A reason could be that the media you write to is full or the directory of the file is read-only for you. [Try to Save Nevertheless] [Cancel] I checked permissions and disk space. Both are fine. Permissions have not changed, my user owns the file and the containing directory and has rw permissions. I'm using only about 2% of the space on the device. Other editors (e.g., nano) work normally. If I disable creating backups in Kate settings, Kate works normally and I do not receive any error messages. On my systems that are still running Kate 17.08.3, saving to the SSHFS mounts works as expected with backups. The problem happens when Kate is upgraded from 17.08.3 to 17.12.0 with no other changes to SSHFS or anything else (as far as I can tell - of course, the Kate upgrade comes with a lot of other packages too, so I cannot rule out some other component as being the cause of of issue). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 306257] Add a feature so that we can save and restore a dolphin session
https://bugs.kde.org/show_bug.cgi?id=306257 --- Comment #7 from MountainX --- The prior comment from Jay sums up my feelings as well. I remain very interested in this feature. > I use KDE on Linux as my primary desktop, but after having gotten used to > using the QTTabBar plugin for Windows File Explorer, which allows creating > and saving groups of tabs, I am really missing something like this for > Dolphin. Most browser's "save tabs as folder" would be fine for me, but it > would be nice to save split views, etc. I would think this would be fairly > easy to implement (like Konqueror and Konsole do), as it should be pretty > much the same code as they use (file URLs...). -- You are receiving this mail because: You are watching all bug changes.
