4.7 nepomuk won't die

Sun Jul 31 15:27:20 BST 2011

Kevin Krammer posted on Sun, 31 Jul 2011 15:29:06 +0200 as excerpted:

> On Sunday, 2011-07-31, Duncan wrote:
>> Kevin Krammer posted on Sat, 30 Jul 2011 14:48:45 +0200 as excerpted:
>> > On Saturday, 2011-07-30, Duncan wrote:
> 
>> >> > As for a setting controlling startup: lets assume there would be
>> >> > an option which would prohibit Akonadi server start. Should all
>> >> > applications then show an error asking whether to change that
>> >> > setting? E.g. KMail saying "You have disabled access to emails. Do
>> >> > you want to Quit KMail or Enabled email access?"
>> >> 
>> >> IMO?  The way kmail and akonaditray handle it is good.  When
>> >> the app is invoked, the main window is disabled, with the notice
>> >> and a button to turn on akonadi, thus enabling the window.
>> > 
>> > Hmm, so instead of starting Akonadi on-demand switch to a model where
>> > it is either autostarted at session login or not and have
>> > applications appear with their error overlay in case the latter
>> > option is the user's policy?
>> > 
>> > Current behavior assumes that people launching an application did so
>> > because they wanted to use it, thus having the Akonadi client start
>> > Akonadi server.
>> 
>> Yes.  The "troublefree" default would obviously be to start akonadi
>> when an app needs it.  Just make that subject to a veto, with the
>> option presumably placed somewhere in (kde, not system) settings.
> 
> So something like this:
> - by default start Akonadi when an application needs it
> - have an option that makes application start without starting
> Akonadi and letting the user start it through the error overlay?

Yes. =:^)

>> But to be clear, /something/ is evidently starting it /regardless/ of
>> need at present.  Or at least /something/, I'm presuming it's akonadi,
>> is triggering the warning notification (three times immediately on top
>> of each other) about nepomuk being off in relation to akonadi
>> functionality, even tho I no longer have any apps actually needing
>> akonadi.
> 
> I think you are correct that the notification about Nepomuk triggered by
> some Akonadi process. However this also implys that there is something
> accessing Akonadi, otherwise it wouldn't have been started.

What I finally did (after a kde restart not only had akonadiserver 
starting, but taking 97% cpu (of only one core out of four, 97/400 IOW, 
thank goodness!), for whatever reason!) was tell the package manager 
(portage) to install_mask any file named akonadiserver, then rebuild the 
akonadi-server package which contains it.

Next kde restart, no more 97% cpu, and no more irritating warnings about 
nepomuk!  =:^)

As for something accessing akonadi, what you say indeed makes sense, but 
I don't know what it might have been, unless (1) simply loading kdepim-
common-libs (by akregator) loads it since the package was compiled with 
it, AND/OR (2) the fact that I /had/ kmail set to start with the kde 
session (before I switched to claws-mail) somehow continued to trigger 
akonadi-server even after kmail was uninstalled.

Actually... does akonadi-server get tracked by the kde session?  Because 
if so, it might be that the saved session was triggering it?

If not that, also keep in mind that I switched to kde4 back with 4.2.4 
(and was trying to run it with little success periodically since before 
4.0) so if akonadi had been set to either start with kde or set to start 
with kmail during any of that period, including the early kdepim 4.4 
series, and that setting got into my user config, it could have possibly 
still been being invoked.

> You could use "fuser" on the Akonadi server socket next time that
> happens to see which process is on the client end of the connection.

If it hadn't decided it wanted to hog a core... when I wasn't even using 
it!

>> >> By contrast, the nepomuk notification warning that apparently
>> >> akonadi generates when nepomuk is off, is QUITE irritating, in
>> >> particular because there's no obvious "don't warn me again"
>> >> checkbox

>> > Seems we need a way for applications to inform the user which part of
>> > their functionality is not available when Nepomuk is not available.
>> > E.g. KMail detecting the Nepomuk not running situation and telling
>> > the user that search, address completion, distributionlists, filters
>> > on email, etc will not be available.

FWIW, even without nepomuk, email filters continued to work here, at 
least thru kdepim 4.6.1.  What 4.7 does as I said I don't know since I 
finished the conversion and unmerged kmail just before I upgraded to 
4.7.  I thought it was only mail-search, and IIRC did test and confirm 
that, after you told me.  Before that I thought it was only for the 
krunner functionality and external search, etc (which I didn't need and 
indeed had the krunner module for contacts, etc, turned off, as 
recommended in *base).  Oh, and event scheduling integration, etc, which 
I didn't use anyway (and resented korganizer being pulled in by the 
gentoo ebuilds, as you may recall I commented).

But perhaps for 4.7 or in the future...

Meanwhile, yes, a warning significantly less vague than the current 
warning would be useful.  If it's email full-text search but subject/from 
search still works, say so.  If it affects filters (or not), say so 
specifically.  If it affects scheduling/event integration, that too.

>> > Probably with an additional option to enable these now, i.e. changing
>> > the Nepomuk config accordingly.
>> 
>> Yes.  The notification mechanism could still be used, but make it
>> conditional on actually starting kmail or something else that needs
>> nepomuk running (which it presumably would be if akonadi itself only
>> started when actually needed), and most important, have an option to
>> "don't warn me again".  If having such an option means it can't be a
>> notification but must be a dialog, due to notification limitations,
>> fine. Sometimes users /do/ know what they're doing, and don't mind a
>> warning the first time, but if it happens /every/ time it gets
>> irritating rather fast, so that option to turn off the warning is
> vital.
> 
> I think notifications as implemented by Plasma support this kind of
> action. Makes sense to allow it to be treated as an optional feature by
> choice.
> 
> Will try to discuss such an improvement at the Berlin Desktop Summit.

=:^)

Meanwhile... I just finished converting my feeds over to something else 
as well, and finally got rid of kdepim entirely, allowing unmerging of 
the entire semantic-desktop framework except for soprano (but it's 
rebuilt without any backends, so is just plugging in stub-apis), as 
apparently koffice-libs requires it, and I have krita installed in 
ordered to get full-alpha-channel png editing, for my superkaramba 
background pngs.

So the noise from my akonadi/semantic-desktop complaints should decrease 
by orders of magnitude, now.  =:^/

But I'll do another post with the details of that.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.