Kevin Krammer posted on Sat, 30 Jul 2011 14:48:45 +0200 as excerpted:
Kevin Krammer posted on Sat, 30 Jul 2011 14:48:45 +0200 as excerpted:
> On Saturday, 2011-07-30, Duncan wrote:
>> [gentoo] a semantic-desktop= dependency that should be
>> semantic-desktop?,
>> 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. =:^)
>
> I hope you mean bug as in wishlist entry :)
> Extending upstream project files to have more modularity might be
> awesome but not having it is hardly a defect. Well, that is as far as I
> understand how Gentoo work :)
Well, to the extent that the USE dependency is semantic-desktop= instead
of semantic-desktop?, it's a bug. Actually, it's one a prominent gentoo
developer and the gentoo/qa lead just blogged about in a different
context, as well. (Watch the wrap.)
http://blog.flameeyes.eu/2011/07/27/tinderbox-limits-blockers-collisions-and-conflicting-requirements
However, to the extent that it would require further break-down of the
upstream shipped modules, you're correct, it's wish-list. A useful point
to make, indeed.
>> > 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. =:^)
>
> 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.
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.
>> 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...)
>
> 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.
> 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.
--
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.
