Re: Performance issue with plasmoid and dataengine combination
Hi Martin, > what I would suggest for starters is to find where the CPU draining happens. Thank you for the suggestion, I'll look on it as soon as I'll have ability. -- Sincerely yours, Evgeniy Alekseev email: i...@arcanis.me ICQ: 407-398-235 Jabber: arca...@jabber.ru ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Performance issue with plasmoid and dataengine combination
Hi there,
I'm experiencing the following performance issue with one of my pet project
[1]. After some time plasmashell (some times it happens after 1 day uptime,
sometime more) uses one CPU core on 100% without any additional actions from
my side. The same issue was observed by at least one of users, in other hand I
should note that on my another PC there is no such issue.
After some debugging I've found that this issue is accompanied by increasing
queue of updates from DataEngine which was still not processed. I suppose the
issue is caused by the fact that my plasmoid is being subscribed on updates
from about 100 sources from systemmonitor DataEngine.
The issue occurs only for KF5 version (KDE4 version is not affected by this
issue). And still persists even I increase update interval (I've tried to set
it to 5 sec instead of default 1 sec), or even if I use QtConcurrent to work
with received data from DataEngine. Also I should note that all methods
related to DataEngine functions take place in C++ part of the widget (because
it is recommended to avoid many C++ calls from QML code).
I suppose that *probably* if I will use less sources it will solve the issue,
but I'm not sure in it (unfortunately it will take some time to change
architecture to use only user requested sources).
Are there any other possibilities which I may check to avoid this issue? Or is
it possible that the problem maybe in DataEngine mechanics (e.g. DataEngine
freezes updates when screen is locked and send all missing data after screen
unlock)? Or maybe I just misuse DataEngine and there are better practice for
my case?
The code which I use the following. Here is I create connection [2]:
Plasma::DataEngineConsumer *deConsumer = new Plasma::DataEngineConsumer();
m_dataEngines[QString("systemmonitor")] =
deConsumer->dataEngine(QString("systemmonitor"));
And connect all available sources (sources which are not used will be dropped
later by using DataEngine::disconnectSource() method) [3]:
m_dataEngines[QString("systemmonitor")]->connectAllSources(parent(),
m_interval);
And finally the following method is used to connect DataEngine update signal
and update slot [4]:
void AWKeys::dataUpdated(const QString &sourceName,
const Plasma::DataEngine::Data &data)
{
QtConcurrent::run(m_threadPool, this, &AWKeys::setDataBySource,
sourceName, data);
}
1. https://github.com/arcan1s/awesome-widgets
2. https://github.com/arcan1s/awesome-widgets/blob/development/sources/
awesome-widget/plugin/awdataengineaggregator.cpp#L87
3. https://github.com/arcan1s/awesome-widgets/blob/development/sources/
awesome-widget/plugin/awdataengineaggregator.cpp#L76
4. https://github.com/arcan1s/awesome-widgets/blob/development/sources/
awesome-widget/plugin/awkeys.cpp#L424
--
Sincerely yours,
Evgeniy Alekseev
email: i...@arcanis.me
ICQ: 407-398-235
Jabber: arca...@jabber.ru
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Several plasmoid instances
Hi, David, Thank you for your reply. On Saturday 18 July 2015 12:19:17 David Edmundson wrote: > There /should/ be no difference until the app developer opts in, with a > line in the .desktop file > > X-KDE-PluginInfo-Version=3.0 > > Can you link to your applet? Here is a link [1]. But seems no need to check the source code since the source of such behaviour has been found :) > The only time you'd have a problem is if you used singletons; the solution > in that case is obviously to not use singletons. Thank you, seems it is the problem (I'm casting the plugin as a singleton). I will rewrite plugin part to do not use singletons. But I have another question: why it works before update? 1. https://github.com/arcan1s/awesome-widgets -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Several plasmoid instances
Hi, there! I'm a developer of several Plasma 5 widgets. After components upgrading (if I understand correctly the issue has been caused by the upgrading of plasma- frameworks to 5.12.0) my users have found that several instances of the same widget are no longer allowed. (To be more precise they are allowed but show the same data.) I've researched the issue and found that the problem is in data transfer between plugin (C++) and ui (QML) plasmoid parts. I believe the issue has been caused by the fact that: 1. All plasmoids load the one plugin instance. or 2. Each plasmoid loads the own plugin instance but all of them use the one. Is there a correct way to run each plasmoid with own plugin instance and to do the bijection between plugin and ui in runtime? -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Get panel list and hidding them via C++ module
On Tuesday 10 February 2015 12:32:49 Sebastian Kügler wrote: > Why not just add the ability to hide a panel with a shortcut? Just an idea that some related items may be collected by one item (e.g. Plasmoid) to prevent similar actions to configure item. (BTW I didn't find ability to hide panel by configuring it, could you please describe how can I do it?) -- Sincerely yours, Evgeniy Alekseev email: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Get panel list and hidding them via C++ module
Hi Sebastian, On Monday 09 February 2015 13:59:21 Sebastian Kügler wrote: > Not possible, the QtQuick code's access to the C++ bits (Applet, Containment > is now very limited by design). > No, the separation between model (Plasma::Applet, Plasma::Containment, etc.) > and the views (implemented in QtQuick) is deeper in Plasma 5, that's partly > a conscious design decision, and partly mandated by moving everything to > QtQuick. Ok, thank you. > That's not possible in Plasma 5, and it's a conscious design decision. > Applets are not supposed to meddle with other applets, they're > self-contained outbound, and managed by the surrounding containment. I've expected something like this, thanks for explanation. > Let's take a step back, though. What do you actually want to achieve? Maybe > there is a way to make that possible within the design of Plasma. > > Have you looked at desktop scripting to achieve what you are looking for? There is an applet on which I'm working now (rather, on porting) which provides some concepts from minimalistic WMs (predominantly tiling ones) which besides the basic functions (simply control by desktops) was able to hide selected panels by hotkey pressing. I.e. atm this action should look like such applet [1]. As long as I don't bond to any prefered realization, it may be implemented by any reasonable way, e.g. Dbus calls, library functions (but calling external application/script is an undesirable way of course). 1. http://kde-look.org/content/show.php/Panel+Toggle?content=149654 -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Get panel list and hidding them via C++ module
Hello, Recently I have run into the following problem: how to get panel list (even w\o additional filtering) and hidding them from an applet? With KDE4 I have used the following method: 1. From plasmoid I have called containment()->corona() to get pointer to corona object. 2. Then I have used iteration on containments in the current corona() with filter by ContainmentType. 3. And set found containments hidding by calling Containment->view()- >setVisible(false). With Plasma 5 I have found the following problems: 1. Unfortunately in the default way (i.e. if C++ module inherits from Qobject) I didn't find ability to get pointer to current corona. Is it possible to get it at the moment? 2. Current containments have not view() method and seems have not method to set them hidding. Is there such ability in the current version? Also I have looked at QML bindings, but didn't find any ability to implement such functional too. Thanks in advance =) -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Some issues with porting KDE4 plasmoid to Plasma5
At Tuesday 25 November 2014 10:23:37 Marco Martin wrote: > On Sunday 16 November 2014, Evgeniy Alekseev wrote: > > Hello, > > > > Some time ago I've started a porting of my plasmoids and dataengines to > > the > > newest Plasma and found some problems with it. I've ported a DataEngine > > w\o > > any problem, but I have issues about a Plasmoid. I've read API reference > > and look at examples from plasma-next and didn't find solutions. > > > > First of all I want say that I don't plan to use QML/JS now and plan to > > develop of my plasmoids in pure C++. Firstly it is related to other > > project > > in Plasma5 pure C++ plasmoids are not possible anymore, the c++ api was for > QGraphicsView (since plasma was based on top of it) plasma5 is based on top > of scene graph, so the only way to write an UI is trough QML. > You can still use C++ in a dataengine or a private QML import. > > > parts which is in C++/Qt and I don't want to use additional languages w\o > > any special necessity. Also as far as I understand the core plasmoid part > > (on which I have issue too) still shoul be written in C++. Also I try to > > avoid using deprecated functions. > > > > My questions are: > > > > 1. Is there any alternative to Plasma::PopupApplet? If there is not, is > > there a plan to implement it? > > all applets are popupapplets now. > see > http://notmart.org/blog/2014/02/making-plasmoids-qml-api-better/ > > especially the section "Compact and full representations" > > > 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? > > For example, I didn't find old Applet::setLayout() and > > PopupApplet::setWidget() methods. > > no, only QML is allowed, and subclassing Applet doesn't really work anymore. > If you have a complex QWidget ui in theory you could still have it by > implementing it in a QML import, then making ti show from a slot invoked by > qml. > > > 3. How can I connect DataEngine to my Plasmoid? The old method which I > > used > > was dataEnigne(), some new applets use this method too, but it doesn't > > exist in the newest Plasma headers. Some new widgets such as nm-applet use > > Plasma::DataEngineManager::self()->engine() constuction, but > > Plasma::DataEngineManager class doesn't exist in the Plasma too =( > > see the QML bindings: > https://techbase.kde.org/Development/Tutorials/Plasma2/QML2/API#Data_Engines Thank you for the answer and the links! Seems all my questions are QML porting retaled, so I'll look on it and hope will port own KDE stuff successfully =) Thank you again. -- Sincerely yours, Evgeniy Alekseev email: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Some issues with porting KDE4 plasmoid to Plasma5
Hello, Some time ago I've started a porting of my plasmoids and dataengines to the newest Plasma and found some problems with it. I've ported a DataEngine w\o any problem, but I have issues about a Plasmoid. I've read API reference and look at examples from plasma-next and didn't find solutions. First of all I want say that I don't plan to use QML/JS now and plan to develop of my plasmoids in pure C++. Firstly it is related to other project parts which is in C++/Qt and I don't want to use additional languages w\o any special necessity. Also as far as I understand the core plasmoid part (on which I have issue too) still shoul be written in C++. Also I try to avoid using deprecated functions. My questions are: 1. Is there any alternative to Plasma::PopupApplet? If there is not, is there a plan to implement it? 2. Is there a possibility to paint complex UI w\o using QML (in C++ code)? For example, I didn't find old Applet::setLayout() and PopupApplet::setWidget() methods. 3. How can I connect DataEngine to my Plasmoid? The old method which I used was dataEnigne(), some new applets use this method too, but it doesn't exist in the newest Plasma headers. Some new widgets such as nm-applet use Plasma::DataEngineManager::self()->engine() constuction, but Plasma::DataEngineManager class doesn't exist in the Plasma too =( If you need a reference to my plasmoid, example on which I'm working now may be found here [1] (it is more simple than the second one). 1. https://github.com/arcan1s/netctl-gui -- Sincerely yours, Evgeniy Alekseev e-mail: darkarca...@mail.ru ICQ: 407-398-235 Jabber: arca...@jabber.ru signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
