Summary: | Latte crashes after boot from autostart | ||
---|---|---|---|
Product: | [Plasma] lattedock | Reporter: | Somfai Márton <m4rci46> |
Component: | application | Assignee: | Michail Vourlakos <mvourlakos> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | jghodd, nate |
Priority: | NOR | Keywords: | drkonqi |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Screenshot after login
2 of 3 - locate and kill single instance of latte-dock. Desktop restored 3 of 3 - same session - restart of latte-dock from sys menu |
Description
Somfai Márton
2021-08-10 11:53:13 UTC
I can confirm that latte-dock v0.10.0 is broken. It's not functioning properly when started via KDE/Plasma Autostart. On login, the bottom half of the screen is blacked out and blocks any desktop functionality from mid-screen down. If you open a terminal and kill the latte-dock process, all desktop functionality returns. You can then start latte-dock from the system menu, and it starts and functions as expected. I have tried clearing the qmlcache, rebuilding the package in my build environment, building the master version from github, autostarting from xdg and attempted to start it from session restore. None of these approaches fix the problem. I have not found any evidence that the latte-dock process has crashed, it's simply interfering with the normal desktop startup. I have checked the logs for any sign of crashes - I haven't found any. I did note that my build of the master code did produce a drkonqi process which I have never been able to access. In the crash topic this is fixed (In reply to Jeff Hodd from comment #1) > I can confirm that latte-dock v0.10.0 is broken. It's not functioning > properly when started via KDE/Plasma Autostart. On login, the bottom half of > the screen is blacked out and blocks any desktop functionality from > mid-screen down. If you open a terminal and kill the latte-dock process, all > desktop functionality returns. You can then start latte-dock from the system > menu, and it starts and functions as expected. I have tried clearing the > qmlcache, rebuilding the package in my build environment, building the > master version from github, autostarting from xdg and attempted to start it > from session restore. None of these approaches fix the problem. I have not > found any evidence that the latte-dock process has crashed, it's simply > interfering with the normal desktop startup. I have checked the logs for any > sign of crashes - I haven't found any. I did note that my build of the > master code did produce a drkonqi process which I have never been able to > access. for the autostart issues: 1. You must make sure that the auto start desktop file used is updated properly 2. Remove all latte desktop files from: ~/.config/autostart/ 3. Add in ~/.config/autostart/ the new desktop file provided from Latte The crash comes when the system tries to autostart Latte more than two times. [root@bslxenvy64 latte]# cd /home/jghodd/.config/autostart [root@bslxenvy64 autostart]# ll total 8 -rw------- 1 jghodd jghodd 590 Jun 16 2020 kdock-thunderbird.desktop -rw-r--r-- 1 jghodd jghodd 301 Sep 17 2020 megasync.desktop lrwxrwxrwx 1 jghodd jghodd 50 Aug 9 16:52 org.kde.latte-dock.desktop -> /usr/share/applications/org.kde.latte-dock.desktop Don't need to reset my autostart. I use a symlink, so it's always pointing to whatever was most recently installed. The only time I found a double-start was if I logged out and logged back in without killing the latte-dock process before doing so. Created attachment 140663 [details]
Screenshot after login
First of 3 screenshots.
Created attachment 140664 [details]
2 of 3 - locate and kill single instance of latte-dock. Desktop restored
Shows the terminal where I locate the latte-dock process and kill it, showing how it clears the desktop.
Created attachment 140665 [details]
3 of 3 - same session - restart of latte-dock from sys menu
Restart latte-dock from the system menu. It seems as if instead of a double-start, it may be starting too early. I only ever find one running instance.
BTW, this is not resolved or fixed. I see the same issue with your master code base, so whatever the issue is, it's still there. I had a similar issue a few months ago with plasma, and it turned out the plasma developer who helped out found that components were being started before the corona startup was complete. Same issue here perhaps? (In reply to Jeff Hodd from comment #8) > BTW, this is not resolved or fixed. I see the same issue with your master > code base, so whatever the issue is, it's still there. > > I had a similar issue a few months ago with plasma, and it turned out the > plasma developer who helped out found that components were being started > before the corona startup was complete. Same issue here perhaps? Open a new topic, with details etc. The topic about the crash is fixed. Your topic is different. |