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 (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. 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? > 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. 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. > >> 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. 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. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ 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.
