Version: (using KDE 4.2.4) Compiler: gcc-Version 4.3.3 (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) OS: Linux Installed from: Gentoo Packages hi, so i was browsing with opera and suddenly the complete desktop froze. i think it is because opera crashed, but it also could be only plasma responsible for that. i cannot tell. mouse was still working but i couldnt click anything, no kde menu, no desktop items etc... had to ctrl+alt+f1 login with a user and kill opera -> after that worked again. my issue: plasma shouldnt freeze just because another app doesnt want to work anymore (at least i think the other app is responsible for that) similar behavior when the internet connection is down. the complete plasma interface thinks it is ok to not allow any input for a long time ~1minute... also: that kind of behavior shouldnt be found at a desktop since it doesnt use the internet. internet dependent apps/widgets - well it is ok there but not the complete system....
Some issues regarding Internet connection and Plasma being idle/unresponsive were fixed IIRC. The issue about Opera is strange. Are you sure you weren't doing any other action within Plasma itself? Thanks
good to hear about the internet issue. i had the right click menu just opened in opera and it was the 2nd time that happened. i think i didnt do any other actions on plasma. i try to make sure better next time it happens.
Some other questions: Plasma may be hanged/freezed, but some other apps should still work, like the task switcher (Alt+Tab), which is KWIn, or the application launcher (Alt+F2) which is KRunner If you had any other shortcut to launch apps they should work too. If all the apps were hang, and you couldn't do anything, then this could be Plasma unrelated, and more like a whole XOrg hang, or something general like that Regards
hmm i put that on my check list for the next time
"similar behavior when the internet connection is down." using the "remember the milk" widget? if not, what other widgets are you using? "had to ctrl+alt+f1 login with a user and kill opera -> after that worked again." if that's truly the case, then i'd guess it was an x.org issue. plasma and opera don't talk to each other except via the window manager (for the taskbar) and they don't share any common infrastructure other than x.org.
remember the milk? no. i use weather station (only widget that needs a internet connection[but it is most of the time showing the same temp/humidity]) an analogue clock, disk space, cpu usage in the taskbar, some shortcuts for some apps/folders, and 5 folderview areas... :) hmm @ x.org :/
I can add that Plasma always freezes when NetworkManager widget waits for the backend to do something. When connecting to a wired network, it freezes for ~1 second, and when connecting to mobile broadband - for 5-10 seconds.
Hello, I think I am experiencing a similar issue, that's why I am commenting here rather than opening a new bug. I have the "Folder View" applet (set to $HOME) in one of my two activities and in my $HOME I have a .desktop file pointing to a NFS device. The content of the .desktop file is something like: [Desktop Entry] Dev=my-nas-device:/mnt/nas Icon=network-server MountPoint=/media/nas ReadOnly=false Type=FSDevice UnmountIcon=drive-harddisk Now, if the nfs device is not correctly unmounted - e.g. remotely rebooted or shut down via ssh - plasma-desktop completely freezes, it is not even found by kquitapp and I have to terminate it with kill or killall. As in stated comment #3, other apps continue to work (krunner, kwin etc.) To make plasma-desktop work again I have to kill plasma-desktop, then unmount the nfs device with $ umount -l /media/nas and relaunch plasma-desktop. Thank you.
Mh, not really sure if that case should be handled in the same bug report, as the root cause seems to be a bit different. Anyways, leave it here. Regards
*** This bug has been marked as a duplicate of bug 184062 ***