[kde-linux] kmail and kdewallet

[Kevin Krammer]

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.

Probably $HOME/.xsession-errors

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
> passwords?

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 
access perculiarities.

> 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 
functionality.
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:

[snip]

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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20081229/e1ee04aa/attachment.sig>