In 2010 I participated in the first Akademy-br organized by Sandro Andrade with support from KDE e.V. It was a great time for me to meet new faces of the KDE community in Brasil. It as also during Akademy-br 2010 that I started to work on Knetworkmanager and later in Plasma NM. Last year we did not succeed in realizing the second Akademy-br :-(. This year we not only received again support from KDE e.V. but we are expanding: instead of a Brazilian event we are organizing a Latin America event with participation of KDE developers from Argentina, Colombia, Peru and, of course, Brasil :-D
I would like to thank KDE e.V. for supporting LAkademy 2012. The event is going to take place in Porto Alegre city (south of Brasil) from April 27th to May 1st. The event is going to be more like a sprint than a Akademy since our focus is in contributing code to KDE and spread the KDE community in this part of the world.
Blog about Linux and KDE.
Monday, March 26, 2012
Sunday, March 4, 2012
Desktop Freezes in 4.8.x
Hi all,
As I wrote in Plasma NM 0.9.0 release post the main reason for 0.9.0 release was bug #287002 "panel freezes". You problaby have noticed the freezing problem after upgrading to 4.8.0, me too.
The source of the problem is the fact that kded is sometimes frozen by one or more of its modules. Plasma NM < 0.9.0 used to do several synchronous calls to networkmanagement module in kded, specially to get the signal strengh of wifi access points and 3G connections. You can imagine how often wifi access points (all access points in range, even the ones you are not connected to) can trigger signal strengh... signals :-/ Yes, every often.
Any delay in kded causes freezes in Plasma NM's plasmoid and since any plasmoid can also freeze the entire plasma-desktop process the problem is propagated to the entire desktop. I have heard a lot of complaints about kded and Plasma being susceptible to freezes caused by one of their modules (plasmoids in Plasma case), you do not need to repeat them in the comments section of this post. Any Plasma developer is aware of the problem by now, I just do not know if anybody is working on fixing it, so do not ask me.
Several weeks ago I pushed a commit to make Plasma NM use asynchronous API to retrieve data from networkmanagement module. There is also a commit to kde-workspace to do the same for the Solid ModemManager backend, the same change went to QtModemManager as well. This last commit will be in kde-workspace 4.8.1. Those changes seem to easy the problem but, of course, it does not solve it since other plasmoids trying to contact kded will also cause freezes in the desktop.
In bug #287002 it is stated that apper is one of programs that freezes kded. Just as a notice I have never used apper. Until now everybody that has disabled apper's kded module reported that it fixes the freezing problem. You can try it yourself, just go to systemsettings -> Startup and Shutdown -> Service Manager, locate the "apper" service, stop it and uncheck the checkbox in "Use" column for that service. Then click on the "Ok" button.
It is curious that only with 4.8.0 those problems become visible. Plasma NM uses synchronous calls to contact kded since the begining, in 4.4.x time. That is even before I started to use Plasma NM. I guess several other programs do use synchronous DBus API. You can check that by looking for the QDBusReply object declaration and waitForfinished() calls in your source code. If you are using them you should really think about how to avoid them, specially if your program is a plasmoid and/or contact a kded module.
As I wrote in Plasma NM 0.9.0 release post the main reason for 0.9.0 release was bug #287002 "panel freezes". You problaby have noticed the freezing problem after upgrading to 4.8.0, me too.
The source of the problem is the fact that kded is sometimes frozen by one or more of its modules. Plasma NM < 0.9.0 used to do several synchronous calls to networkmanagement module in kded, specially to get the signal strengh of wifi access points and 3G connections. You can imagine how often wifi access points (all access points in range, even the ones you are not connected to) can trigger signal strengh... signals :-/ Yes, every often.
Any delay in kded causes freezes in Plasma NM's plasmoid and since any plasmoid can also freeze the entire plasma-desktop process the problem is propagated to the entire desktop. I have heard a lot of complaints about kded and Plasma being susceptible to freezes caused by one of their modules (plasmoids in Plasma case), you do not need to repeat them in the comments section of this post. Any Plasma developer is aware of the problem by now, I just do not know if anybody is working on fixing it, so do not ask me.
Several weeks ago I pushed a commit to make Plasma NM use asynchronous API to retrieve data from networkmanagement module. There is also a commit to kde-workspace to do the same for the Solid ModemManager backend, the same change went to QtModemManager as well. This last commit will be in kde-workspace 4.8.1. Those changes seem to easy the problem but, of course, it does not solve it since other plasmoids trying to contact kded will also cause freezes in the desktop.
In bug #287002 it is stated that apper is one of programs that freezes kded. Just as a notice I have never used apper. Until now everybody that has disabled apper's kded module reported that it fixes the freezing problem. You can try it yourself, just go to systemsettings -> Startup and Shutdown -> Service Manager, locate the "apper" service, stop it and uncheck the checkbox in "Use" column for that service. Then click on the "Ok" button.
It is curious that only with 4.8.0 those problems become visible. Plasma NM uses synchronous calls to contact kded since the begining, in 4.4.x time. That is even before I started to use Plasma NM. I guess several other programs do use synchronous DBus API. You can check that by looking for the QDBusReply object declaration and waitForfinished() calls in your source code. If you are using them you should really think about how to avoid them, specially if your program is a plasmoid and/or contact a kded module.
Subscribe to:
Posts (Atom)