Hello Harald, KDE maintainers and developpers,

first thanks for the factual reply.

On Sat, 8 Aug 2009, Harald Sitter wrote:

> Well, then lets take a look at it form a non-clicki-bunti POV.
>
> kded should be started independently, since it is much more verbose
> than applications, for a very good reason as I tend to believe. Also
> kded is an own application anyway. Only for user convenience KDE
> applications would startup kded if it is not running already, so that
> clicki-bunti-users do not have to worry about it.

OK

> Should one considering this very reasonable point and still not start
> kded independently and let an app start kded, one should at least  make
> sure all output gets passed to /dev/null.

However that assumes that users should somehow know that this is
necessary-

> To a more useful analysis of the "problem"...
>
> _Any_, I repeat, _any_ KDE app can use the troublesome module. As a
> matter of fact most will do via the http kioslave (that to my knowledge
> tries to use the networkstatus module to access link information and
> thus timeout immediately if no connection is available at all), also any
> application that would want to have status information about the network
> link status would either implement access on networkstatus via a
> kioslave or do it in the app directly.
>
> Meaning that the following apps will for sure use networkstatus:
> * KDEPIM
> * Amarok (last.fm, lyrics and whatnot)
> * KTorrent
> * Konqueror
> * Kopete
> * most Plasma applets
> ...
>
> The query frequency is set by the app itself, so the more often it tries
> to access the status, the more often will kded report that it is not
> available. Also, the more apps are querying the more output you get, due
> to increased query volume.
>
> All those apps are perfectly capable of living without the module (which
> is mostly the point of kded modules that are shipped independent from
> the app), still it is desirable to have the module installed, otherwise
> the apps will not be able to treat network loss (properly). Thus it
> makes sense to have this message displayed
>
> So, to get back to your question, yes I consider this a feature, so
> should you, since a smoothly running system is in the interest of every
> non-clicki-bunti user.
>
> What we can do about it?
> * We can increase the query frequency of each app (i.e. maintain 3
>   billion patches)
> * We can make each package depend on workspace-bin (thus forcing the
>   better part of the KDE desktop upon every user and devalue the point
>   of kded modules)
> * We can make these warnings disappear all along and thus prevent users
>   that actually try to find out why the apps are unable to track network
>   status of diagnosing the problem

Or the warnings could go to some log, such as ~/.xsession-errors or
~/.kde/tmp-$user-$host/kded.log

> * We can make kded track it's own verbosity (that of course requires
>   kded to store information when a uniquely identified message was sent,
>   and define a maximum frequency to that, in return we get more mem
>   usage and still didn't get rid of the warnings)

I lack the knowledge the workings of kdeapp<->kded<->ksycoca<->modules
and so am wondering whether the situation is really that dramatic that a
resolution would require _significant_ storage. I.e. ksycoca is designed to
hold service and configuration information in the first place. So knowing
that some module has not been loaded - here: because it's not there - is
part of the configuration information. Whoever is responsible for loading
the module can warn in the log that it was not found. Next time the module
is needed the code required for loading the module can check the relevant flag
"i_have_allready_reported_the_status_of_the_module", return a negative
answer to the requester, not log anything else and be done with it. That would
not inflate in any noticeable way the storage demands of KDE?

> What's it gonna be?

With my limited knowledge I'd suggest to
a) have a log for non-critical messages and to only show critical problems
   to the user by default
b) remember whether access to some module has allready been tried without
   success and not re-report that fact.

I realize that my initial reply wasn't (once again) emotionaly neutral (as in
"sachlich") so thanks to you for going ahead in a constructive way all the
same. I guess you agree that all apps should be fun and/or convenient to
work with and avoid annoying the user uselessly (here: the user only needs
to know once, that something is not OK and it's arguable whether the problem
at hand is as important as to necessitate writing to stderr (?)), if it's 
reasonably
avoidable. My impression is that a technical solution should be possible
without any exagerated measures?

Thanks,
*t


** Changed in: kde4libs (Ubuntu)
       Status: Incomplete => New

-- 
kded can't find "kded/networkstatus.desktop"
https://bugs.launchpad.net/bugs/381447
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to