Bug 132218

Well, thanks to the Frugalware KDE Maintainter -- crazy -- I found the solution.

sudo nano /usr/share/services/kded/knemod.desktop
change X-KDE-Kded-load-on-demand=true to false
And add this :
X-KDE-Kded-autoload=true

Its an upstream problem, and imo still a bug, so I am not marking it as resolved.

This change was introduced by Dirk 6 days ago and went into KNemo 0.4.4 
without me noticing it (revision 570451).

Dirk, could you please comment on this change. Why was it changed? I don't 
know if Load-on-demand really fits for KNemo? How is it supposed to 
be 'demanded'? For me it seems to fit more as a service that the user can 
enable or disable on its own.

Thanks,

	Percy

On Thursday 10 August 2006 19:28, Rohan Dhruva wrote:
[bugs.kde.org quoted mail]

I was just trying to fix that knemod loads itself even though the user never
requested this. it is not acceptable for a multi-user installation that when the application is installed, every user gets knemod loaded. 

there has to be either a wrapper application / system tray or a normal kicker applet that requests the nemod service and that is configured by the user, or knemod itself has to store its state in some config file. 

But that makes KNemo absolutely unusable - how am I supposed to get it to start on every kde startup, if I want ?

Wouldn't it work when we use 

X-KDE-Kded-autoload=false
X-KDE-Kded-load-on-demand=false

so that KNemo stays a startup service but doesn't get started automatically for every user? But I fear that many users then will complain about KNemo not starting after they have installed it even not after the next login. So I should place a huge note on the KNemo download site that users have to start KNemo in the service manager in order to use it after installation. I think I can live with that.

       Percy

Mhmm, Dirk has a point here.

Maybe we could add 'Show in systray' option to each interface.
If this option is enabled for at least one interface, kcm module
could write a ~/.kde/services/kded/knemod.desktop  with changed
X-KDE-Kded-* settings.  A little kconf_update
script can adapt existing knemo setups.

Running a autostart script on session login or using something like
X-KDE-Kded-autoload[e] = knemo-load-or-not
seem more hackish to me (and does not help to speedup kde session startup ;)

Until there's an solution, a note at the start of knemo kde-apps page can't
hurt.

Achim 

I am not sure if I understood the problem completly, so here is how I understand it:

The problem seems to be that KNemo is installed as a startup service that gets started automatically when the user logs in the next time. As this seems to be the case for every user this behaviour is not desired in a multiuser-environment. So Dirk changed KNemo to run as a on-demand-service which makes it necessary to create a wrapper or something like this in order to let each user decide if it wants KNemo to run.

Now my suggestion is to keep KNemo as a startup service but to not start it automatically. The user must start KNemo in the service manager if he wishs to use it. This way we have no problem in multiuser-environments but we also do not have to create a wrapper on our own as KDED can already serve as such. I assume that the settings of the service manager are per user and not one setting for all users.

To archive my suggestion I would change the 2 lines in the desktop files to read:

X-KDE-Kded-autoload=false (in order to avoid the automatic start of KNemo)
X-KDE-Kded-load-on-demand=false (to keep KNemo as a startup service)

Am I right with my explanation and can we agree on this solution?

Okay, I just checked my proposal and it seems it doesn't work. If I put the above mentioned lines into my knemo.desktop file KNemo does neither show up as load-on-demand service nor as startup service. I have taken a look at KDED config file and found out that the information if a startup service is started automatically or not is stored there. So this information cannot be put into our deskop-file.

Right now I am clueless what do to. The KDED readme says that there has to be a DCOP call in order to load KNemo on demand. I am not sure if the use-case 'multiuser environment' is enough to take this effort and build a little wrapper that does this job.

Hi Percy,

I'm a bit confused what desktop file you use.

I nopwtried here with system wide config file (setup as Dirk demanded ;)

$ grep -i x-kde-kded- /usr/share/services/kded/knemod.desktop
# X-KDE-Kded-autoload=true
# X-KDE-Kded-load-on-demand=false
X-KDE-Kded-load-on-demand=true


and with the following 'user config (that can be different for all
users):

$ cat ~/.kde/share/services/kded/knemod.desktop
[Desktop Entry]
# xxx
X-KDE-Kded-autoload=true
X-KDE-Kded-load-on-demand=false
# X-KDE-Kded-load-on-demand=true
# xxx

With this setup an already configured knemo start up as
before.  Without ~/.kde/share/services/kded/knemod.desktop
knemo does not run, but is listed in KDE services.  AFAIU
this is just what we want to achieve.

So I still keep up my suggestion in comment #6.

 o add a 'Show in System Tray' option to each interface
 o if for at least one interface this option is set:
   + use whatever DCOP call is necessary to start the
     load-on-demand knemo service.
   + use $KDEHOME/.share/service/kded/knemo.desktop
     as above to start knemo on future session logins.


Forcing the user to use 'KDE services' to start knemo
is IMHO not a good idea.

Achim

On Monday 14 August 2006 09:03, Percy Leonhardt wrote:

> Wouldn't it work when we use
>
> X-KDE-Kded-autoload=false
> X-KDE-Kded-load-on-demand=false


Possible, needs to be tried. I'll check. 


Dirk

But Dirk, didn't Percy just say in comment #8 that those lines don't work ?

Okay, to sum up things:

- At the moment the kc module of KNemo uses a DCOP call to KNemoD to find out if the user wishs to configure a certain interface. Because of this KNemo now gets started when a kc module is opened. This is not intenionally but a side effect. This must be removed if we try to implement the new solution so KNemo is going to lose this feature or at least kc module first has to check if KNemo systray is enabled by the user and only in that case makes its DCOP call to it.
- In the configuration dialog I add a new option 'Show in systray' and store this information in the KNemo configuration file and have to store a modified knemo.desktop file in $KDEHOME/.share/service/kded/
- If the user disables the option again I have to remove the desktop file.

So mostly this new option 'Show in systray' adds or removes the modified knemo.desktop file. 

If the user now opens the service manager and disables KNemo by disabling the checkbox in 'Use' KNemo would no longer be started. Even if the option in the configuration still says 'Show in systray'. Am I right?

Hi Percy,

sounds fine. Just to side notes:

AFAIU is when one writes a config value to 
  $KDEHOME/share/services/kded/knemod.desktop
that is the same as in the systemwide config file
there nothing writen in into the users file.
So it should not be necessary to delete the file.

About stopping/disabling knemo in KDE services you are right AFAIU it.  Can knemo kcm module should check on startup (or) if at least one 'Show in SystemTray' is set is set and ask user

  knemo Network Monitoring serivice is disabled.  But at least one interface
  is configured to use the service.   Start Network Monitoring service?

  [no] [yes]

This catch the obsure case that knemo serive was disabled.  Knemo kcm
module has at least one 'Show in SystemTrag' set.  User check the kcm
module, see it's set and leaves with exit.

It's not the first time I heart that a bug is fixed with 'open setting,
press save' and the bug is gone.  (FWIW run into excactly this problem
with kgpg last night too)

Achim

I am not yet happy with this solution. It sounds like a rather huge effort to get the functionality of KNemo that it already had the last 2 years...

What if we keep the knemo.desktop file like it was before and install or modify the kdedrc-file? All that we need is to tell KDED not to start KNemo automatically but still list it as a startup service.

What I don't know is how this can be achieved. Do we need a little script that adds or modifies the kdedrc while installing KNemo and is such a script also usable for people that use binary packages? And what about people like me that install KNemo in ~/.kde?

The advantage I see is that there is no need to change anything with KNemo and we still have only one (and in my opinion correct) place to (de-)activate KNemo: the service manager.

Opinions, suggestions?

Hi Percy,

Starting/stopping knemo in KDE services may be technically correct,
but for usability POV it's wrong IMHO.  The user does not need to
know how it's implemented.  Knemo has a kcm module and everything
should be reachable there.

'Show in SysTray' option is also useful for this problem at hand,
and IMHO fixes additionaly another design problem, that one has
to delete an interface setting in knemo to 'Show in SysTray'.

About implementation details:

o instead of saving config to kded/knemod.desktop we could also use
  a AUTOSTART script that reads knemorc and start knemo servie via
  dcop.  But because kded scan already */services/kded/*.desktop
  this autostart feels like a hack to me.

o Changing settings in kdedrc is no good idea.  I'm sure the
  kded devel wrote the 'scan-services/kded/*.desktop' feature
  just to prevent other playing 'games' with kdedrc itself.

Apart from the UI changes, and the additioal check of 'Show in systray'
before creating a monitor instance for an interface, the usage of services/kded/knemod.desktop
seems trival to implement (for my naive non-programmer POV) because we rely on standard feature of KDE config files.

 o openConfg kde_services, "kded/nemod.desktop"
 o if show-in-systray then
       writeconfig
          X-KDE-Kded-autoload=true 
          X-KDE-Kded-load-on-demand=false
   else
       # keep in sync with installed distributed kded/knemod.desktop
       writeconfig
          X-KDE-Kded-autoload=false 
          X-KDE-Kded-load-on-demand=true
   
KDE config class will locate existing config files and use correct
dir below ~/.kde when writing back.

Mhmm, sounds like several one-liner patches here and there.
So _maybe_ (big question mark here ;) I'm able to do it. 
If nobody picks it up before I can try next week.

Achim

Hi Achim,

I will (try to) implement it over the weekend. Maybe (another question mark here ;-) ) I have something to test for you on sunday evening.

Cheers, Percy :-)

Is fixed in SVN and KNemo 0.4.5.

*** Bug has been marked as fixed ***.

Thank you very much for fixing the bug ! :-)

Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I will be closing this bug.