KDE-Connect and KDED

[Albert Vaca]

I would actually remove the KDED and add a simple and multi-desktop
autostart file, but there is no *good* way to manage autostart services in
linux: If we install it as an autostart file in a system (root) folder and
a user wants to disable it, he has to find the .desktop file in the system
and remove or edit it!! and it gets even worse in a cross-desktop
perspective, where you have to add flags to launch apps only in certain
desktop environments.

So, meanwhile we do not have a proper KCM to manage autostart services
(actually I feel like creating one, but I do not have time for it :( ) I
would keep the KDED just to have some user interface (even though that's
not the point of the KDEDs).

In another hand, as I said before, making the dbus service launch the
process if it's not running already is a good thing (and dbus supports it
easily) that I think we want to have.

On Fri, Mar 7, 2014 at 8:48 AM, Yuri Samoilenko <kinnalru at gmail.com> wrote:

> 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.
>
>
> _______________________________________________
> KDEConnect mailing list
> KDEConnect at kde.org
> https://mail.kde.org/mailman/listinfo/kdeconnect
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140308/05f8be68/attachment.html>