[kde-linux] kmail and kdewallet
kevin.krammer at gmx.at
Mon Dec 29 13:57:49 UTC 2008
On Monday 29 December 2008, Jethro Tull wrote:
> Does anyone know where can i get the logs of kwallet?
> when i load it through a konsole session i don't get any log. kmail doesn't
> output any relevant info about getting infos from kwallet.
KWallet is implemented as a plugin for the KDE session daemon kded, thus its
output never appears in the output of applications making calls to it.
> So this problem is quite difficult to backtrace.
> anyway, it looks quite like a benign problem, i don't understand how
> developers could build such a bug and not be able to solve. it's been long
> i first requested for help for this in this mailing list.
My guess would be that, since it is a bug, it has not been specifically been
built, but rather is triggered by certain circumstances.
Staying at that assumption, it could be difficult to reliably determine the
causes for these circumstances or the design of any component involved could
make it hard to fix or even just work around.
> is kmail hardcoded to call kwallet? or is there any daemon that analyzes
> interrupts and runs kwallet when kmail send a signal for infos such as
As far as I know, access to the wallet is an explicit task of the client
application, i.e. it calls wallet functions through D-Bus and the wallet
returns the requested information.
I read somewhere that this can be a bit tricky since applications do this
synchronously, so the current KWallet maintainer and his GNOME counterpart
have started to work on a new authentication storage which should, among
other things like unifying authentication access, also address some of the
> it seems that kde has been being written for many years and
> developers only add code when new ideas come but never try to get the
> previous code to be more optimized and robust.
Actually I think most time is spent on improvement rather than new
New functionality is obviously more visible, since it usually changes
application interfaces (e.g. new menu or toolbar entry), changes workflows,
is highlighted in articles and reviews.
Nicely demonstrated by all the many man-years of work gone into KDE4 libs and
infrastructure, the replacing of hacks with clean implementations,
reorganisations of code and dependencies, etc. being totally hidden by a
couple of visual changes.
> when a bug is declared then
> it is not really eradicated but just hidden. as an example take the bug:
> Bug 109773:
> 'Get New Wallpaper' ticks wrong item.
> when this bug was soved a new complain came. it is Bug 126190:
> 'Get New Wallpapers' blocks while downloading
> in a few words the initial problem was as following:
Well, the reported bug has been fixed.
Probably not as elegantly as possible, but most likely the only viable way
within resource limits.
Then there is a new report which is actually a wish item, i.e. the ability for
background downloading, probably even multipe downloads.
The associated developers might not have time to implement this new
functionality or a feature freeze might block adding new features.
It sounds like a good idea to do the downloading in the background, but
sometimes it is wiser to put some work into maintenance even if some users
would rather have their wish item implemented.
Unfortunately, once such a new features it gets implemented, it will get a lot
more attention than any of the work done internally, resulting in other users
complaining about new features being added.
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-linux