Kevin Krammer posted on Sat, 30 Jul 2011 12:13:27 +0200 as excerpted:
> On Saturday, 2011-07-30, Duncan wrote:
>
>> knode isn't akonadified... yet, altho there's an akonadi news resource
>> that looks like they're headed in that direction, and akregator doesn't
>> yet require it either, but given the trend, probably will. IOW, pretty
>> much every kdepim component either already requires it, or it appears
>> that it will by 4.8 or 4.9.
>
> Correct, that's the idea. Geting rid of all the needless code
> duplication and associated cruft which resulted in an unbearable
> maintenance nightmare.
... Which I recognize, and is the reason I'm not criticizing the move
itself, simply saying that path and my own have diverged. =;^(
>> And... the kdepim components that don't actually require it yet do
>> require kdepim-libs and kdepim-common-libs, the latter of which is part
>> of the kdepim module from kde and apparently must be built with akonadi
>> support regardless, thus bringing in akonadi if you're using any kdepim
>> apps at all, regardless of whether those apps actually require akonadi
>> themselves.
>
> Actually no. KDE's Akonadi client libraries are part of the kdepimlibs
> module which means it is considered a sufficiently recognizable
> dependency for the build system.
> Applications that do not use any of these libraries do not actually link
> against them, nor do they attempt to start the runtime components (not
> using the libraries basically implies that).
>
> Given Gentoo's highly adaptive build handling, it should be possible to
> have slightly extended KDE build system files which explicitly check for
> certain libraries in the kdepimlibs module and disable apps for which
> dependencies could not be found.
Yes. There's some gentoo/kde changes that need made in this regard,
including that gentoo/kde currently puts akonadi/nepomuk/strigi in the
same basket under USE=semantic-desktop, and worse, effective requires
that to be turned on for everything if it's turned on for one single item
(a semantic-desktop= dependency that should be semantic-desktop?, for
dolphin, gwenview, etc, so that if it's required for e.g. kmail, that
triggers it for kdelibs, which due to the = in place of ? for dolphin,
etc, triggers it for everything else.
Meanwhile, thanks for your direct statement on the matter. If I file a
gentoo bug on this as I've been intending to do, I will very likely quote
and link it. =:^)
>> Meanwhile, while it appears something is auto-starting akonadi even tho
>> I no longer have any akonadi resources setup and don't actually need or
>> want it running at all
>
> Resources never start Akonadi, they are started by Akonadi. So whether
> or not one has resources setup does only change whether or not Akonadi
> can request access to data.
>
>> , and from the looks of things there's no way to turn it off in
>> kcontrol (aka settings, called systemsettings even tho most of them
>> aren't, they're user-specific kde settings) as there is for some kde
>> services...
>
> Akonadi is not a KDE service. But since system settings is not just KDE
> settings it should probably include some settings for Akonadi as well
> (it actually did at some point, not sure why the resource configuration
> hasn't been re-added after the split-out of the server config).
>
> 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 (kdepim 4.6.1 version, as I mentioned, I don't have
4.7 installed so can't see whether it has changed) and akonaditray (which
apparently invokes kcmshell4 akonadi with its configure option, both 4.6
and 4.7 kdepim) handle it is good. When the app is invoked, the main
window is disabled (configured here as darkened), with the notice and a
button to turn on akonadi, thus enabling the window.
That's good! The warning/error stays out of my hair unless/until I open
an app that needs akonadi. =:^)
By contrast, the nepomuk notification warning that apparently akonadi
(both kdepim 4.6 and 4.7) generates when nepomuk is off, is QUITE
irritating, in particular because there's no obvious "don't warn me
again" checkbox, as there commonly is with warning dialogs. (That may be
a limitation of the kde notification framework, I don't know.
Regardless...)
There REALLY needs to be an option SOMEWHERE (discoverable, preferably in
the notification itself, if that's possible) to turn that off. If there
was, I may well have tolerated akonadi for somewhat longer, giving it a
chance to mature before I decided whether to be rid of it or not. But
that was just one irritation too far.
Also, for whatever reason, I seem to get that notification in triplicate,
three apparently identical notifications piling on top of each other (and
listed three separate times if I call them back by clicking the notifier
button), probably about five or ten minutes after kde starts so there's
obviously a timeout that expires, until which akonadi waits to see if
nepomuk comes up. Having three of them was mildly irritating as well,
but only mildly so because the notifications go away on their own after a
few seconds, and all three happen so close together that they go away
together as well, it wasn't NEARLY as irritating as having the warning
EVERY time I started kde, without ANY visible "don't bother me with this
again" option. However, it's of note here specifically because wherever
the disable option is put, it needs to apply to all cases. Because if a
user checks a don't warn me again option, I don't think they'll be
pleased to see the same warning popping up at the next kde start, even if
it's technically now only twice instead of three times.
--
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.
