KDEPIM 4.6 prob^Wimpressions

[Duncan]

Alex Schuster posted on Thu, 14 Jul 2011 16:36:06 +0200 as excerpted:

> Duncan writes:
> 
>> Alex Schuster posted on Wed, 13 Jul 2011 13:20:50 +0200 as excerpted:
>> > Oh, these newsticker applets.

>> But I had forgotten that kde4 even /had/ a knewsticker for awhile, then
>> it simply went away at some update or another.
> 
> I still have the 'News' plasmoid. Just tried it again, it says 'Fetching
> the news feed failed'.

I gave up on that one some time ago, and haven't tried it recently.  IIRC, 
its format wasn't useful for me, anyway.  Akregator was/is better, if not 
perfect.

>> Or if akregator could close the browser pane and only show the feed
>> tree and "headers pane", with clicking on a header loading the full
>> article in the configured browser.
> 
> Did you file a feature request?

No.  At first things were moving well and I figured it would improve over 
time, anyway.  Then kdepim, including akregator, was "stuck" waiting for 
akonadified kmail.

Now it's unstuck, but I'll wait to see where kdepim 4.7 (presuming it 
syncs with the rest of kde's cycle some time during 4.7) goes, since 4.6 
was pretty much focused on just getting kmail2 working and out the door.  
After I see what changes, if any, akregator and kmail 4.7 brings, I'll 
see about feature requests.

... Or just start trying other solutions, I don't know which...

> I like [akregator] the way it is, although the
> browser engine is not that good, probably because it uses Konqueror.

Actually, I think it might use qt-webkit, tho I'm not sure.  Whatever it 
is, it seems to do fine for text content only, but either by design or 
due to bugs, it ignores images, here.  I think it's a bit confused as to 
what it actually wants the internal browser to be/do, whether it wants it 
to be a text summary only, or whether it wants to be a real browser.

Really, I think the problem with akregator is that it got ported to kde4 
and they got the basics working, then its devs either ended up retasked 
to help with the big kmail akonadi switch or moved on to other things, 
perhaps permanently, and akregator has been in basic maintenance mode 
only, since then. 

Really, I think what akregator needs most is a dev or two just paying it 
some real attention for a couple development cycles, to get it past the 
"just barely ported to kde4 and got working" feel it has ATM.  That would 
probably solve some of the UI issues within a couple 6-month cycles, 
including the present inflexibility of the layout, the sort of broken 
combined-view-mode functionality, AND the internal viewer/browser's 
confusion on whether it wants to be a quick text-mode summary viewer 
only, or a real browser.  I may be wrong here, but particularly with qt 
and kdelibs' already solid base, those seem to me to be like they should 
be somewhat trivial tweaks that shouldn't take /that/ much development 
time, probably more time to test and debug than to actually implement 
(for the browser, just adding forward/back/stop/refresh and supporting 
images would be nice, or drop that functionality for the summary viewer 
pane only and let it just call the external browser for everything else, 
either one)

> So I configured Akregator to use Firefox as external browser.

Same here.

> Firefox also has RSS capabilities, which I did not try, maybe this would
> work better.

I haven't really used firefox's RSS either, but from what I've read and 
the little I have used them, it implements them *WAY* differently, as 
what it calls "live bookmarks".  Firefox's default news "bookmark"/menu 
is a feed, and its most-viewed function is similarly implemented as a 
feed.

That /works/, but it feels too much like "cloud technology" for me.  I 
want to feel like I'm browsing the feed locally, and clicking on a link 
to go remote and get the details, if desired.  The firefox implementation 
feels like it's all remote, like I'm in the browser all the time (as I 
very literally am,  when I'm reading feeds their way).  I'd probably not 
be too happy with chrome (the OS) for the same reason, except worse, as 
then it'd be the browser ALL THE TIME, NO ESCAPE!

> I like Konqueror more, its look&feel, but it has more
> problems than Firefox. I think that some day I will have to make the
> switch to Firefox like you already did.

There's that inevitable feel to it, for sure...  What got me was how 
blase' all the kde folks seemed to be to glaring konqueror issues like no 
proper ssl/tls certificate management, while all the while calling it 
ready for ordinary use.  4.7 finally fixes that (there's certificate 
management in kcontrol itself, finally, tho I still seriously miss 3.x's 
much better setup, with the ability to see at a glance and deactivate all 
the 40-out-of-158-bits, 56-out-of-128-bits, etc, certificates), but I 
simply cannot see how very many of the kde folks could /possibly/ be 
"eating their own dogfood" as it were, in the form of actually using the 
konqueror browser they provide for real money things like banking and 
online shopping, even at times from public access points, and find the 
former situation at all tolerable.  The only /possible/ logical 
conclusion, then, is that they simply didn't care, because they were 
using something else, presumably firefox or chrome/chromium.

That realization, plus the long-time hassle of trying to browse with 
scripting off by default without an extension such as noscript (and in 
general firefox's extension community, since it's unreasonable to expect 
a very limited upstream developer community to be able to provide that 
sort of stuff, and konqueror's community is simply too small to handle 
it), was what did it for me, with the final straw being the 4.6.3 double-
form-submissions bug.  Once a platform's developers themselves are using 
other things instead (we're not talking about bootstrapping, where such 
may be necessary for a time, but the other end, deserting a sinking ship, 
when it again becomes necessary), it's time to jump-ship.

And while the corporate types might not be very happy with firefox's new 
development and versioning policy, and it does create challenges for 
extension authors as well, it's unlikely mainstream extensions such as 
noscript, adblock+, configuration mania, master-password, etc, will fall 
by the wayside, and I /like/ the newer, faster update policy. =:^)

>> But I miss the filters, too, especially as I try to make my
>> feed-reading time more efficient.  There's a LOT of stories I'd filter
>> if only I could, while keeping those feeds.

This one could take longer to develop and to properly test, but as I try 
to prioritize my computer time and make room for "real life", it's really 
needed.  The simple fact is that I've already dumped a number of feeds 
because I simply didn't have the time, and I'm still spending way more 
time with it than is sustainable.  Slogging thru stuff I'd not even be 
seeing if I could filter it is the worst -- just registering it and 
skipping onto the next entry takes time, and it adds up when you're doing 
triple-digit articles/day, with about half of it stuff you'd skip 
entirely if there was a feasible way.  And arbitrary filtering is what 
computers are /supposed/ to be good at!

Generally making the interface more efficient would help some as it would 
cut down the seconds per would-be-ignored-if-possible entry, but getting 
those entries out of my face entirely would cut that time to zero.

> Using feeds is relatively new to me, I didn't even know other readers
> have these features. Maybe that's why I don't miss them.

I've been using feeds for awhile, but obviously haven't found the perfect 
feed-reader for me.  If the early 4.7 (thru say kde 4.7.1 or .2) timeframe 
doesn't bring some sort of akregator development I'll file bugs, and if 
there's no useful activity on them by kde 4.8, I'll probably be looking 
for another solution, for feed-reading, mail-reading, or both.
 
>> (FWIW, kmail isn't perfect here either.  If I had my way, I'd have it's
>> tri-pane layout arranged much like I do pan's, full width headers at
>> the top so I can get all the usual columns and a reasonable width
>> subject/ title without horizontal scrolling, folder tree and body pane
>> below, with the folder tree actually to the right instead of the
>> left[.  B]ut kmail's pane layout isn't [that flexible.]
> 
> Yes, clipping the top of the folder view and enlarging the message list
> would be nice. It would be cool if one just could drag the panels as one
> likes, like I do in Amarok.

Indeed.


> There really must be something about it why I _still_ like [amarok]
> so much.

Weird how the psyche works, at times, isn't it?

>> > And about KMail... it does not show _any_ mail any more. In the
>> > folder view, I see folders with unread messages, but those were still
>> > unread when I logged out of KDE. It does not scan for new mails. An
>> > when I select any folder, it does not show the contents, it just says
>> > it's fetching the contents, and I should wait.

FWIW, I had a kmail crash when I booted this "morning" (I actually turned 
the system off overnite, last nite! well, "overnite" for me, anyway, not 
really the clock time).

When I got the crash dialog, I hit the restart and it did, but then it 
wouldn't fetch mail at all.  No fetch progress down in the corner, 
nothing.  Stopping and restarting akonadi got that back, but of course I 
then had to go thru the double-kwallet-dance thing again.

Anyway, as I was doing all that, I was thinking about this thread and 
wondering if that's what happened to you.  It seems that under some 
circumstances, if kmail crashes, when it comes back up it doesn't get a 
proper connection to akonadi.  It could very well be an akonadi bug, 
triggering the kmail crash in the first place, then not letting kmail 
connect after it's restarted, until akonadi is restarted.

But stopping and restarting akonadi seemed to cure it.  AFAIK that's 
actually the second time that's happened to me, now.

> I made some more progress. I wanted to delete my IMAP resource and the
> one for the local folders. Before this, I made a backup of all ~/.*
> stuff, but the Akonadi module (in the system tray) also has an option
> back up the Akonadi stuff. I tried that, but I get an error message that
> neither mysqldump nor bzip2 can be found. This worked fine two weeks
> ago, and both binaries are still on my system.

Again, that's because akonaditray hasn't really been updated for the 
sqlite backend driver, yet.  I think the backup functionality only works 
with the mysql backend, presently.

Unfortunate, but while the filesystem backup method may seem old 
fashioned these days, it does still seem to work. Fortunately! =:^)

> Whatever. I deleted both resources, but the local folders resource is
> being re-created instantaneously (with a path of
> ~/.local/share/local-mail). Then I added an IMAP resource. Nothing
> happened. I clicked again, and after a while, I had two new IMAP
> resources.

IMO, this is part of the problem.  The UI currently lacks indicators that 
it's actually still processing our last request.  So sometimes we humans 
click again, or try to go on to doing something else that depends on the 
first action being completed to work correctly.  If the second action is 
done before the first completes, there's either data-loss or a crash due 
to a race condition, if not BOTH a crash and data-loss!

I realized this in real-time the other day after I deleted a kmail dir I 
had just moved all the messages out of.  Akonadi was still processing the 
move in the background so if kmail actually did the delete when I asked, 
it would have deleted some of the mails before they actually got moved.  
Fortunately it queued the second action until after the first was 
completed, but the problem was that it wasn't not evident in the kmail UI 
that akonadi was still processing the move in the background (the mail 
listing had disappeared in the kmail display for that folder).  Back in 
the old kmail, actions like that were generally synchronous, and you'd 
simply get the busy pointer either immediately, or if you tried doing 
anything else with that folder, until after it had safely completed the 
first action.  There's nothing wrong with making it asynchronous so the 
user can go on to doing something else, but something in the UI, say an 
update spinner on that directory, should let the user know that it's not 
safe to do anything else at least with that dir, ESPECIALLY something 
like delete it, just yet.

As I said, much to my relief after I realized what I had done, kmail/
akonadi actually caught that and queued the second action, but I think 
some of the current issues may be just that sort of thing, where the 
problem is NOT caught.  There's definitely some UI feedback and kmail/
akonadi cooperation robustness work to complete, here.

> I deleted one, and wanted to change the settings of the first
> one. Nothing happened. I waited for some minutes, then I tried to close
> the window. I was told the application lo longer reacts, so I killed it.
> Oh my. But the next time I did the same, it worked just fine.

This sort of thing would be handled by proper GUI indicators, as well.  
When you hit delete on the one, you'd get a spinning indicator on it if 
you could work on other items meanwhile, or for the whole app if it was a 
synchronous operation for the whole app.  If the spinner froze or spun 
unreasonably long, you'd kill it, much as you did, expect that the app 
would have communicated to you via its indicators that you couldn't 
change the settings on the second one while it was working, so you 
wouldn't have even tried.

> In the settings there is an entry for the trash, that was empty before.
> In the new resource, it is already defined, the name is 'Mülleimer'. In
> KMail, however, it shows up as 'Müllemer', with a missing 'i'. Strange. 
> It isn't being used anyway, my local folders also have one.

Interesting.

> Deleting via hotkey again does not work, I am being told that this
> hotkey is ambigous, but I do not see how.

I do enough hotkey customizing that I'm familiar with ambiguous hotkey 
errors.  But usually kde's good enough to tell me what the conflict is 
(tho sometimes the action itself itself isn't as clear as it might be, 
out of the context in which one set it), and give me the option to cancel 
the change or override the old one.  I often immediately cancel, then 
decide which I want to keep and try again.  If it's really unclear what 
the old one was both from my memory and the prompt it gave me, I figure I 
must not use it enough for it to be worth keeping anyway, and override.  
But that only tends to happen with default hotkeys I never use, so it's 
not a huge problem.

If you're getting that it's ambiguous but it's not listing what the other 
action is, or giving you a cancel/override option, then I'm guessing the 
app must be doing its own thing rather than using kde's builtin hotkey 
handling.  That's... unfortunate, because the builtin does work 
reasonably well, and it's really useful to get conflict notifications 
from other parts of kde too.

> The 'Could not create collection' notification which I had every few
> minutes no longer happens, this is good. But sending mails did not work,
> they just stay in the outbox of my local folders.
> 
> Finally, it worked out. I think I had to go to the identity settings and
> select folders for sent mails, drafts and templates. I'm doing this
> often these days, after changing settings, those folders are set to
> arbitrary locations, which sometimes no longer exist. Now some of the
> mails I sent yesterday are _somewhere_ along my folders, which I have a
> lot of.

I had to do that several times, after I deleted the current folder set 
and recreated/reimported.

The annoyance for me was the rather large set of filters I have, most of 
which set a special header (so I can track what filter applied) and move 
the message to a particular dir, trash for spam, particular dirs (family, 
list, slashdot, etc) for various ham.  Very little mail ends up remaining 
in my inbox by default, and most of what does is spam that's not caught 
by one of the spam filters.  Thus, the filters both sort my mail as it 
comes in and act as both a blacklist (active move to trash) and whitelist 
(move to some dedicated dir), with what's left being effectively 
blacklisted by default.  I could add a final filter to move them to the 
trash too, but it's useful to be able to see at a glance that no sort-
filters applied.

Anyway, the result is a rather large (~50) filters that sort mail into 
various boxes as it comes in.  And a local-folders reset, in addition to 
forcing a reimport, forces me to go thru all 50 of those filters, 
resetting them to the appropriate new folders.  By about the third time, 
that's getting VERY frustrating!

Fortunately, it only happened to me three times, and the third time was 
entirely PEBKAC error, when I deleted local-folders due to a 
misunderstanding of akonadi functionality.

http://en.wiktionary.org/wiki/PEBCAK
http://en.wikipedia.org/wiki/Pebcak

> While writing this last paragraph, I opened the Akonadi settings in
> order to look up the exact name of the 'KMail-Maildir' resource I was to
> write about.
> I found two additional resources (akonadi_maildir_resource_12 and _13),
> no idea where those come from, clicked one, and Kontact crashed. At
> least my mail was not gone (only the subject, this happens every time
> KMail quits while there are open composing windows).
> These resources have no folder configured, it is empty, so I deleted
> them. But it's scary how stuff appears in it and  don't know why.

I had a bunch more of those recently, too.  Mainly notes, which I don't 
use anyway, so I had no problem deleting all but the one that pointed to 
an actual location (which I kept in case I /do/ decide to use it some 
day).

They seem to appear in connection with akonadi (or system) crashes, etc.  
I suspect in my case they were generated when I was playing around with 
an unstable OpenGL screensaver, that locked up the system including the 
kernel *HARD* (so hard that if it happened during disk activity, the LEDs 
would freeze in the ON state!).  That was awhile ago, but the extra notes 
resources didn't display as bad until I opened them in ordered to see 
where they pointed, and I hadn't noticed them.  So I don't know for sure 
that's when they appeared, but it seems likely.

> Speaking of 'scary': Akonadi is. Before, mail setup was relatively easy.
> But now, mail is not fetched from the IMAP server, but from strange
> resources that do weird things, multiply by themselves, use database
> concepts I do not know much about, and all that. It's an additional
> layer between that complicates things. I don't say this is a bad thing,
> I see there are benefits, but it's scary, and I had much trouble with
> it.

Indeed.  I believe I've posted before about how first year engineers get 
it drummed into their head how complexity affects reliability and 
maintainability, and how "bloat" at least can be argued to be justifiable 
as useful to /someone/ so it's tough to draw the line, but that "anti-
features" such as the activation features MS added to XP were simply over 
the line (added complexity that unlike ordinary bloat, benefits NO users, 
in fact, rather the opposite) and that's why I jumped to Linux.

Well, the added complexity of akonadi isn't an anti-feature, but I don't 
believe it has been demonstrated to be worth the very real cost in terms 
of reliability and maintainability, yet, either.  Time will tell, but 
meanwhile, the feature is extracting a very real cost from users, and I'm 
honestly not sure this one will still be around to see how it all turns 
out.  It's not amarok level for me yet, and certainly not MS eXPrivacy, 
but trends don't look particularly hopeful at this point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
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.