[kde-linux] kmail and kdewallet

[Kevin Krammer]

On Tuesday 30 December 2008, Jethro Tull wrote:

> When i wrote the above statement i was meaning that they seem to not to
> care that much about optimisation and stability. KDE is still considered as
> a resource consuming environment.

That is mostly a myth. Due to shared runtime infrastructure and libraries the 
per application overhead is very low, resulting in a low overall resource 
footprint for a KDE session.
Lubos Lunak once had a very interesting comparison of different setups in one 
of his blog articles.

> often appear in aggressive ways. I don't understand why a simple web page
> with some images cannot still not be scrolled smoothly with konqueror.

I have never experienced scrolling problems in Konqueror. Neither when wheel 
scrolling nor when smoothscrolling.

> > 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.
>
> oh really? Sounds good! i have to check it. I usually wait some time enough
> that minor new releases are done when a big new thing comes out.

I often do this as well.
One thing about internal improvements like for example the new hardware API 
Solid is that there is basically a one release cycle delay between becoming 
available in the framework and being available to users as application 
developers make use of them.

It can be more than one cycle if features built upon such improvements are not 
on top of the application developers' TODO lists.

> > Well, the reported bug has been fixed.
>
> huh...? >-|

As far as I understood your previous posting, the GUI no longer enters this 
erronous state.

> > Probably not as elegantly as possible, but most likely the only viable
> > way within resource limits.
>
> whew... not elegantly at all.
>
> so multiple downloading is out of resource limits?????

Yes, limited developer resources can mean that redesign/refactoring for 
support of multiple concurrent downloads is out of question at times.

> > Then there is a new report which is actually a wish item, i.e. the
> > ability for background downloading, probably even multiple downloads.
>
> since UNIX i think all ever developers have concentrated their efforts to
> make systems able to run any program while some are already running in the
> background.

Yes, running multiple processes is trivial.
Running multiple processes working on the same overall task through 
communication is already quite challenging.
Running multiple jobs within the same process is even harder.
Running multiple jobs within the same process which was not designed for doing 
that is basically out of question.

> > The associated developers might not have time to implement this new
> > functionality or a feature freeze might block adding new features.
>
> background downloads or multiple downloads do not sound to me as a new
> functionality. I don't understand why if konqueror can download many things
> at a time, "Get new wallpapers" implementation cannot.

Konqueror was designed to handle multiple concurrent jobs and can keep track 
of each jobs state, etc.
"Get new wallpaper" might not have been.Unfortunately concurrency is not 
something that can easily be "bolted on". It requires different internal 
structures, e.g. like the above mentioned state tracking.

> > 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.
>
> I don't see what's so harsh in that feature.

Since I don't know the code in question I can only assume that moving from a 
single job based operation model to one with multiple jobs would have most 
likely required to rewrite the whole thing.

It is still a good feature request, but a wish not a bug nevertheless.

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/20090107/aa14e8e6/attachment.sig>