KDE-Connect and KDED

Yuri Samoilenko kinnalru at gmail.com
Fri Mar 7 07:48:17 UTC 2014


Good morning!


> > I talking about possibility to start/stop/autostart. How often do you use
> > system services in /etc/init.d/ ? I'am using it very rare(once per week),
> > but i CAN stop/restart ssh, samba, dedicated virtuaboxes, apache, ntp,
> bind
> > and so on.
> For this we can add an option into the kcm, where it will be more
> discoverable
> btw.
>

I'am agreed but I can't uderstand who will start the main daemon to KCM
interact with? To prevent misunderstanding: KCM module must interact with
someone, whi already started - with who? And who must start this daemon?


> > What do you talking about? kdeconnect daemon consumes just about 2.5 mb
> of
> > memory. All other memory(qt/kde libraries) already shared between desktop
> > environment. Listening on socket to wait for incoming data/connection is
> > not consuming CPU, so CPU usage for kdeconnect when idle is 0.0%.
> > ANY plasma/QML applet consumes CPU and memory _much_ more than simple
> > daemon that just listen port.
> Yeah, we have to add/remove the applet as well when no devices are
> connected.
>

Agreed.


> Then let's add an option in our KCM to make things simple and usable.
> We did this in BlueDevil and worked quite nice.
>

Again with whom KCM will interact?


>  > Any dbus service consumes more CPU and memory than simple kdeconnectd
> > daemon.
> This is incorrect since kdeconnectd is already a dbus service.
>

Ofcourse(you can't drop dbus at all). But it start once. I mean yet another
dbus daemon which will spawn "device communication instances" with dbus
too. If i understand you right. If not - sorry.


> To use ZERO memory user can completly disable kdeconnectd through KDED
> > module by just removing checkbox in systemsettings like many other KDE
> > services for example touchpad, remote control, nepomuk(!) and other.
> The point is that by using the KDED we can use only a few K of private
> memory
> when no devices are connected.
>
> Remember that only the shared memory is *shared*, the private is not. In
> the
> case of Qt there is a lot of private memory for things like i18n, l10n,
> settings etc that it won't be shared unless you do some dirty hacks like
> dlopen (like we do in kdeinit).
>

Ofcourse.


> Depending the Qt/KDE libraries on use the private memory overhead is
> usually
> from 3 to 9Mb. Let's imagine we have an average of 6, that multiplied by
> the
> amount of KDED I have right now running, 30 produces a total memory saving
> of
> 180Mb of ram.
>

You tell "in general", of cource ANY application can overhead. But please
tell about emmory usage of our daemon not KDED control inteface.

Anyway, I can see how this complicates things way more than what is
> desirable,
> so I'm going to give it a try and if I can't achieve it on an hour I will
> drop
> the idea.
>

No problem, I hope reach success in it!

The my main idea is to follow UNIX way - do not make things more complex
that neaded to reach the result. By "complex" I mean the number of
technology, the amount of code, number of interaction within subsystems and
so on. I we can drop KDED and make more universal way to control
kdeconnect(ubuntu, LXDE, windows) I will happy!


Best regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140307/31af0d35/attachment.html>


More information about the KDEConnect mailing list