User: Password:
|
|
Subscribe / Log in / New account

Stephenson: hackweek9: Lightweight KDE Desktop project

Will Stephenson describes the KLyDE project, which is aimed at the creation of a lightweight KDE desktop. "As has been repeated on Planet KDE over the past decade, KDE is not intrinsically bloated. At its core, it jumps through a lot of hoops for memory efficiency and speed, and is modular to a fault. But most packagings of KDE take a kitchen sink approach, and when you install your KDE distribution you get a full suite of desktop, applets and applications. The other major criticism of KDE is that it is too configurable. The KlyDE project applies KDE's modularity and configurability to the challenge of making a lightweight desktop. However, what I don't want to do is a hatchet job where functionality is crudely chopped out of the desktop to fit some conception of light weight."
(Log in to post comments)

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 12, 2013 16:15 UTC (Fri) by alankila (guest, #47141) [Link]

This sounds promising. KDE needs not just simplification, IMHO it also needs visual polish. Elements seem to be just thrown around wherever they fit, and there's generally too many features at presented at once. UI content panes have borders which often do not align vertically when set side by side because some elements above the panes have different height. Icons have varying styles and sizes between applications. In buttons, either the text or the icon is typically not precisely vertically aligned.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 12, 2013 17:35 UTC (Fri) by raven667 (subscriber, #5198) [Link]

I think that moving settings out of the main UI and into an advanced settings tool, as well as removing settings that have difficult to validate interactions with the rest of the system is a great idea, something that the GNOME designers got right when they learned to do this all those years ago.

Personally I tried installing the kbunutu packages on a laptop and was actually horrified by all the clutter, and I used to be a KDE user since version 1 in 1998 or so. I felt like I was in the bad part of town with all the neon lights and street hawkers coming at me from every angle because of the clutter. Maybe it's because I've been using MacOSX for a few years now that I greatly prefer the clean simple, iOS inspired feel of GNOME 3

visual polish

Posted Apr 12, 2013 21:13 UTC (Fri) by Richard_J_Neill (guest, #23093) [Link]

I agree. One of the problems with the KDE4 series is that applications have enormous chunks of featureless grey, partly because the horizontal lines that split the UI apart have been removed. Also, one ends up with very large blocks of unused screen space.

KDE 4.10 is good, but the GUI design is too focused on optimising for "aesthetics" as opposed to maximising for clarity, readability, and ease of use.

Personally, I thought KDE3.5 looked better - but then, I've always the look of considered OSX to be something to run away from, rather than to emulate.

Imho, desktops should almost never animate anything, should appear as quickly as possible, and should have moderate contrast and sharp borders. Use colour not for aesthetics, but for usability: for example the vertical scroll-bar should be a different colour to the background, and while I like the visual hint of greying out minimised windows on the taskbar, it's now mid-grey on slightly lighter grey, and I can't easily read the text!

visual polish

Posted Apr 13, 2013 3:15 UTC (Sat) by rsidd (subscriber, #2582) [Link]

The grey text disease is widespread. Why do so many sites use grey text? I like to use my tablet at very low backlight setting in a dark room, but such sites are impossible to read then (they're hard enough otherwise). I realise you're talking about minimised windows but it's important that their titles be readable too.

visual polish

Posted Apr 14, 2013 9:12 UTC (Sun) by alankila (guest, #47141) [Link]

It impacts me doubly because I run a hack that renders text in gamma corrected way on Linux. Since the average result of lack of gamma correction is darkened text, this process turns everything even lighter, and these light-gray websites then become very light indeed. Courier is the worst, as it's light to start with and becomes almost unreadable.

Luckily, it is possible to combat the problem by emphasizing the glyphs, for instance FreeType has a function to embolden outlines by a variable amount, and I'm currently happy with slight excess saturation in the 3-tap LCD filter. One other problem is that hinting is generally designed for the default rendering, and now destroys the shapes of the glyphs and the weights of the lines and curves. Without hinting, there's some blurring depending on how well features align to the pixel grid. I tried per-glyph offsets in rendering to improve contrast but this can't be done vertically because jumping glyphs look very distracting, though horizontally it looked fairly OK.

visual polish

Posted Apr 14, 2013 13:51 UTC (Sun) by sebas (subscriber, #51660) [Link]

So you are changing the text rendering algorithm on your system, but not the text color to adjust for it?

visual polish

Posted Apr 15, 2013 15:29 UTC (Mon) by alankila (guest, #47141) [Link]

Well the text color is decided by the web pages or whatever. I was just lamenting that it's a bit tricky to get good-looking text rendering, each approach seems to have its own set of tradeoffs. My preferred approach exhibits the unbearable lightness of rendering, but it can be combated if some distortion of weight is acceptable.

visual polish

Posted Apr 13, 2013 9:16 UTC (Sat) by misc (subscriber, #73730) [Link]

I think it was sun who did a study about animation, and how they allowed users to understand better for example where the windows have gone, or stuff like this.

Of course, that doesn't mean that all animation are good, far from it. But there is some value in their usage.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 15, 2013 4:09 UTC (Mon) by brianomahoney (guest, #6206) [Link]

As someone who has just has a KDE4.4 to KDE10.0 upgrade wished on them by SuSE I should like to add (on a non KDE forum, whose moderators are insufferably complacent and smug):

1. Kmail 2.x is a disgrace, it neither imports old data or works properly, and the akonadi integration is unhelpful and flawed.

IT looks like downgrades, to 1.x are essentially impossible.

2. The KDE system is very poorly documented and the build system byzantine.

3. Configuration is a nightmare.

4. Reliability is poor.

Personally, I have decided to use Claws, and add what I want to it, like making Maildir++ work again and fixing the odd rough edge. But it basically works very well.

If I have another buggy disconuity I will ditch KDE entirely, it is pretty, but I want something robust!.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 15, 2013 18:14 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> 2. The KDE system is very poorly documented and the build system byzantine.

Odd. AFAIR, the KDE docs were pretty good. Have they been neglected? Granted, once you get away from the libraries into the applications, things did get worse, but the libraries had excellent docs. Just compare to the GTK/GNOME docs which tend to document functions, argument names, and return values with short descriptions and if you're *really* lucky you'll get a snippet of code with how to use it in conjunction with other functions (usually I end up resorting to grep'ing some project's codebase to get an idea of how it's usually used).

As for the build system, I've found that CMake build systems are usually easier to get working as an end user if I need to configure something extensively[1]. However, I don't know

[1]I can see all options in the curses editor and set them incrementally; with autoconf I need to keep building on a monster configure command since each ./configure resets all options back to the default.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 15, 2013 18:16 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Completing this thought:

> However, I don't know…

…how deep you'll have to go in dependencies to get KMail 1 working which can be a pain if dependency searching in the CMake isn't set up well. Plus the libraries probably conflict with the newer versions (if the newer ones don't work as-is).

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 9:02 UTC (Tue) by niner (subscriber, #26151) [Link]

The effort of compiling KMail 1 is probably better spent in simply starting with KMail 2 from scratch instead of trying to import stuff. With a clean slate start (just setting up your IMAP mailboxes) KMail 2 is definitely faster, more reliable and more featureful than KMail 1 ever was. It solves many longstanding problems and is definitely a step in the right direction.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 11:13 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

On the other hand, if you have four gb of local mail that you don't want to lose access to, and a pop3 account you cannot convert to imap, kmail2 is still very problematical. I used an obs repo that provided kmail1 for a long time, but recently tried to move to kmail2, and that was quite painful. It actually still is really painful, with new mail not getting filtered properly, undeletable duplicate messages in folders and sometimes even lost mail.

I'm digging into the source, but have a hard time finding my way around yet.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 11:41 UTC (Tue) by anselm (subscriber, #2796) [Link]

It's probably time for someone to reimplement KMail from scratch.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 12:57 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

Nah. Implementing an application from scratch only means you're going to make all the old mistakes over again, and probably add some new mistakes. Besides throwing away all the gui code, which is perfectly fine.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 13:04 UTC (Tue) by anselm (subscriber, #2796) [Link]

Yes, but it's what happens in KDE when the going gets difficult …

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 21:34 UTC (Tue) by HelloWorld (guest, #56129) [Link]

> Nah. Implementing an application from scratch only means you're going to make all the old mistakes over again, and probably add some new mistakes.
Yeah right. So who needs Linux when there's Solaris? Who needs Postfix when there's sendmail? Who needs Dovecot when there's Cyrus? Who needs clang when there's gcc?

The truth is: yes, you can fuck up a rewrite. And you can make it a roaring success. And as far as kmail is concerned, I think the latter is anything but impossible. I can't count the number of times kio_imap4 hung on my system. It really doesn't work well for me (which is why I often use Claws-Mail today).

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 21:50 UTC (Tue) by anselm (subscriber, #2796) [Link]

There's no doubt that coming to a problem with new insights based on experience with the existing solutions and new research can lead to better solutions. Hence Postfix instead of Sendmail. However, Postfix is completely independent from Sendmail, so whether it exists or not does not matter to Sendmail users who have no intention to change their MTA. The problem starts when people notice that, say, the Kmail codebase has amassed enough digital barnacles that it would be better to start over, and then pass off the new Kmail as a replacement for the old before it can do everything that the old version did.

The KDE method of doing things is to go for a complete rewrite, push the new version before it has feature parity with the old, and – this is the KDE 4.x phenomenon – then (a) claim that it is so much better organised internally that any thinking person can't but see that it is a big improvement even if it does less than its predecessor, and (b) point out that since the code is freely available, people who are missing features should go in and add them themselves. If you then don't do that, you can't have been missing that feature badly enough, so it doesn't matter. If you're lucky the people involved keep working on the code in question and it may reach feature parity with the previous incarnation eight or ten minor versions of KDE later, but if you're not lucky they will go off to do something else and the code will have to wait for the next person to come along and do a complete rewrite from scratch.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 11:00 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]

So this is what is going to happen if you rewrite KMail.

You create a graphical mail application. Of course you need Calendaring, too. And contact management. And Todo. So, you develop these 4 applications. Maybe someone helps out, trows in a feed reader or such. You happily add features where needed but not too much, you want to keep it slim, hey!

Of course, you need to have access to the contacts in the mail application. The mail app can directly read the contacts that the contacts app has access to, too but to avoid clashes with the contact mini-app you use DBus so they talk to each other. And you want to be able to have the contacts in the Calendar so you have appointments with people. Again, IPC to the rescue. You build on and people ask if you can show the online status in chat in the mail app - so you don't have to mail them but talk to them by mail. That makes sense. Now performance becomes a bit of an issue, so you cache the contacts in the mail app, the calendar app and well, you need todo access in the calendar app so you cache the todo's there too. Oh and todo also needs to access contacts. But let's be clear: you're not doing anything weird, this stuff needs to be simple, understandable (for the newcomers) but also scale - that's why you need cache and some database stuff. After all, with today's email load of 6-8 GB of mail and hundreds of contacts, it has to have some serious performance.

By now, you have everything 3-4 times in memory and in 3-4 different databases and caches. So, as a good programmer, you decide to re-engineer this: you need a common storage for this data. That will allow you to do the same thing but a lot better.

So, you make a great plan, a proper new architecture and you get to work. Unfortunately, you depend on a group of volunteers. This work is difficult so only the most 'core' members can do it, and time moves on - people get busy with other things so you lose people. Meanwhile you have to maintain the old applications too, as the new architecture is still far from ready. So you device a way to slowly migrate things over, and hope people can either bite through the birthing pains or come and help you out. But they don't, they don't get why this was needed, claim that Claws does mail just fine, and you get little help. Meanwhile, you've missed every possible deadline, it is 2013, your mail client (now just a for-two-years neglected GUI) is getting old and has issues of its own and everybody yells at you that you suck for even TRYING to fix the architecture behind their apps.

Somehow, you ended up with Akonadi. sjees. And I hope you will have learned that, surprise, doping PIM properly is HARD. That's why KMail/Akonadi/KDEPIM has issues: they are trying to build a PROPERLY engineered solution which actually WORKS for what people in 2013 want to do and that is not easy. It requires a solution which is complicated, so it needs a lot of testing, bugfixing, looking for corner cases. And with just a handful of volunteers, that is not easy to do.

There are surely some 'basic' use cases out there where you can use an app here and an app there. It will work for you. Might need the occasional sacrificial chicken and handwaving and it won't work that great with your company infrastructure, but hey, it works for you.

If you want calendaring, contacts, todo and all that scale-able and with multiple accounts and identities and grouping and proper security and performance - say, the stuff a modern company will need for its 2000 employees, KDE PIM is the only game in town. Or, of course, Microsoft Outlook. Groupwise, maybe.

That is why Kolab, which has as its mission to finally fix the final pillar of Free Software on the Corporate Desktop (PIM), is now working on KDEPIM. They are testing and stabilizing it as their customers will need it. So a year or two from now, it'll be quite good for what you want to do. Until then, help is welcome. And Boudewijn's attitude is far better for getting it finally done than yours - uninformed ranting never got far.

Have a nice day.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 12:33 UTC (Wed) by anselm (subscriber, #2796) [Link]

I don't disagree that KDEPIM based on Akonadi will be a fine piece of software when it is done. When it is done. I don't disagree that the problem to be solved, like incidentally many others of considerable interest to the community at large, is a difficult one that takes skill and experience.

However, the point is that you don't use something like that to replace outright what was there and worked (for all its shortcomings) when the new thing is only half-baked, and hope that the new thing will finally be all right six versions later once enough people have volunteered to fix the bugs and add the features that the previous version used to have and that the original developers couldn't be bothered to put in before inflicting the new code on the previous version's users as a non-optional replacement. (I consider myself a fairly competent developer but I'm not that interested in doing KDE stuff; I have my own projects to take care of and wouldn't have the time to figure out KDEPIM even if I wanted to. Does that disqualify me from using KDEPIM because I'm not in a position to help with developing it further?)

Arguably the way to do this sort of thing properly is to write a new program (or set of programs) based on the new architecture. You can eventually EOL the old program once the new program actually has all its features and there are well-debugged tools to assist with a migration from the old one etc., but in the meantime those people who are interested in the benefits of the new version can move over if and when they want. Let them use the old inefficient stuff for as long as they can stand it but don't force them to move to something that is only half-finished and doesn't work for them, just for your own convenience.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 13:09 UTC (Wed) by niner (subscriber, #26151) [Link]

So who exactly _forced_ you to abandon your well working setup and upgrade to one that doesn't? And why exactly do you thing you can demand from other people that they tend to a codebase for which they have no interest or not time when you are not prepared to contribute in any way?

FYI: the kmail 1 codebase is still out there, it's still free software. kdepim developers did what you want them to: they wrote a new program based on the new architecture. If people still want to use the old, _nothing_ is keeping them from it. It's your choice. But if you do, it's also your responsibility to do the maintenance work or find someone who does. I don't expect anyone else to clean my place either. Or if I do, I'm well prepared to pay them for it.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 13:42 UTC (Wed) by anselm (subscriber, #2796) [Link]

So who exactly _forced_ you to abandon your well working setup and upgrade to one that doesn't?

I'm tracking KDE in Debian. At some point the Kmail I'm using forced me to run a MySQL server just to cache some mail headers (I don't use the KDE addressbook program). I can live with that if I must but it's not exactly what I would consider great engineering.

And why exactly do you thing you can demand from other people that they tend to a codebase for which they have no interest or not time when you are not prepared to contribute in any way?

For the record, I do contribute to the free software community in enough different ways to not have to have a bad conscience because I don't want to also hack C++ code for KDE.

Having said that, I don't »demand« anything from other people. I respect the KDEPIM developers as clever programmers even if I don't agree with all the choices they make. Some of these choices mean that I don't respect them as great engineers but that is my privilege, just like it is their privilege, which I am not going to contest in any way, to do with their code whatever they please.

FYI: the kmail 1 codebase is still out there, it's still free software.

I know. I'm using it now. When Kmail 2.x lands in Debian I'll have a look to see whether it still works for me and if it doesn't I may start using something else that does.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 13:55 UTC (Wed) by niner (subscriber, #26151) [Link]

If this post were all you ever said on the topic, there wouldn't even have been a need for a discussion. But since we're at it: as a programmer, I think it's far better engineering to use a proven and solid storage component like MySQL than hand rolling it. And experience with the flaky hand rolled mail indexes in kmail 1 seems to confirm this. One could argue about which DBMS exactly would be better for the job and personally, I'd probably have never picked MySQL for the job but for now the existing solution just makes me a happy akonadi user. FWIW my initial reaction to this design decision was pretty similiar to yours. But the reliability and performance of the current version convinced me otherwise.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 21:36 UTC (Wed) by dlang (subscriber, #313) [Link]

Why do you need to cache all the headers locally anyway?

A good IMAP client knows how to query the server to leverage it's power (and local indexing)

For local files you will need to do something, but MySQL is a rather heavy thing to have to install just for this, using dbm or sqlite would seem to be much better fits for this type of task.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 23:00 UTC (Wed) by anselm (subscriber, #2796) [Link]

The KDE party line says that (a) the caching infrastructure must work even if you don't get your mail via IMAP, and (b) when Akonadi got started, SQLite couldn't cope with its requirements as far as concurrent access was concerned, hence Akonadi defaults to MySQL. There now appear to be PostgreSQL and SQLite backends in addition to the MySQL backend; the SQLite backend is said to be working »with limitations« and is mostly used on mobile devices.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 1:10 UTC (Thu) by HelloWorld (guest, #56129) [Link]

SQLite is a piece of crap anyway. You can specify all kinds of constraints when you create a table and it won't enforce many of them, not even the types. Really, what were they thinking? Developers write database schemas for a reason!

I'd also like to see some concrete evidence that SQLite is actuallylight-weight. I suspect that people think that essentially because of the cleverly-chosen name.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 1:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Compare the size of SQLite library to the size of MySQL embedded library. That's the answer.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 21:45 UTC (Thu) by HelloWorld (guest, #56129) [Link]

In 2013 there are still people who think *that's* a sensible metric? Oh come on...

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 22:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Yep. There is a difference between 1MLOC and 100kLOC. In maintenance and debugability, at least.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted May 4, 2013 11:19 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

Ok, so THAT is what lightweight means? Lines of code? It has nothing to do with features versus size or metrics like memory usage and performance? I say you're ignoring a few 'details' here.

As Martin Grasslin wrote in an angry blog post a while ago - the term lightweight is both heavily under-defined and over-used, mostly by and through ignorance.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted May 4, 2013 19:57 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, number of lines of code is a good proxy. A small number means that a project is focused on one thing and nothing else.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted May 6, 2013 7:20 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]

A small scope is just that - a small scope. Useless in most situations.

I'm all for keeping things small and simple and for me, a lower SLOC is certainly a feature - but just ONE feature. Performance and efficiency are other rather important ones. And the ability to, you know, do stuff I need, that also scores high.

In case of mail clients, doing one thing and nothing else (mail) was great in 1995. It's 2013 now and even your phone shows you twitter status updates in the contact app & grabs contact details and image from Facebook.

In case of SQL - a library which doesn't scale or perform in many real-world scenarios (despite its small SLOC count) is useless for those scenarios. And I mean - on mobile phones, even. I mean, it is great if you don't need concurrency (who has a multicore CPU or more than one app running, right?) or more than a small number of entries in the db.

Right tool for the right job - lightweight continues to be an empty concept. I'm happy to exploit the widespread love for the word but I expect smart people to know better than take it serious.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted May 6, 2013 8:32 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Quite a lot of projects don't NEED to scale to multiple CPUs and have esoteric features.

For example, SQLite is used to keep my contact book on my phone. It works fine even with a corporate address book with thousands of entries. Why would I need SQLite to scale to thousands of cores?

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 2:41 UTC (Thu) by dlang (subscriber, #313) [Link]

My point is that you should not need to have a mandatory caching layer at all. A good IMAP server will not need it, and the cost can be crippling under some conditions.

It's all well and good to offer one for non-IMAP systems, or to offer it as an option for IMAP system (not all IMAP servers are good)

But it shouldn't be mandatory for all collections.

I have mail folders with over 300,000 messages in them. having the mail client decide that it needs to download headers from every message when I just want to look at the last 30 messages in the folder is just unacceptable (and part of the reason I don't use kmail and other clients that act similarly)

Especially if you have poor or expensive connectivity, the idea that you _should_ have a local cache of this sort of thing is just wrong. It's just to expensive to populate.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 6:06 UTC (Thu) by anselm (subscriber, #2796) [Link]

The whole thing probably comes from the KDE project's love of abstraction layers.

I'm probably not the best person to defend the idea because I'm not convinced that it makes great sense, either. Then again I use offlineimap to sync all my mail to a local Dovecot instance because Kmail's client-side IMAP support used to really suck. For all I know it may be better now but I'm staying with this arrangement because it works well for me; »one tool for the job« etc. and no way am I allowing Kmail to go out on the Internet. As you say, a caching layer for e-mail metadata is superfluous in this case but this observation is apparently lost on the KDEPIM guys, or they would at least have introduced a »light-weight passthrough« option that made the API work but didn't actually cache anything within Akonadi.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 6:38 UTC (Thu) by dlang (subscriber, #313) [Link]

abstraction layers can be a good thing, but they key is picking the right ones.

In this case, instead of making the abstraction layer be a local database that holds info on all mail, local, remote, or IMAP and accessing that database directly, a better approach would have been to have the abstraction be a very thin layer over IMAP, and implement the needed indexing/caching only for the data sources that don't have the IMAP features (close to just implementing a local IMAP server, but without the need to handle all IMAP commands and corner cases, only what they use)

for those who don't know, good IMAP servers implement fast searching, sorting, threading on the server, so copying this data to a local database instead is falling into the trap of maintaining multiple copies of the same data unnecessarily (so you are guaranteed to have them get out of sync), and it means that if you have thousands or hundreds of thousands of messages in one folder (not uncommon on good IMAP servers), the client can spend a lot of time downloading headers when the user connects before the user can actually do anything.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 6:58 UTC (Thu) by niner (subscriber, #26151) [Link]

What you're missing is, that I want to access my IMAP mailbox even when I have no internet connection. So it can make sense to cache all the data locally even with IMAP.

Also fast searching and threading on the server are relatively recent IMAP features. At least they are only recently supported by IMAP servers. But you're right in that they are really awesome and we make good use of them in CiderWebmail which ironically does not do any caching at all. But since it's a webmail, having an internet connection is somewhat mandatory for use anyway :)

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 7:46 UTC (Thu) by dlang (subscriber, #313) [Link]

> What you're missing is, that I want to access my IMAP mailbox even when I have no internet connection. So it can make sense to cache all the data locally even with IMAP.

That is what things like offline IMAP are written for.

I don't dispute that you want to do that, and I don't say that it's a bad option to have.

However, forcing ALL IMAP users to suffer the pain of copying all their folders to each device just because some people want to work without a network connection is throwing away a lot of the advantage of IMAP.

I couldn't do that if I wanted to, my IMAP folders are large enough they wouldn't fit on some of my devices.

> Also fast searching and threading on the server are relatively recent IMAP features. At least they are only recently supported by IMAP servers.

depends on what you consider recent :-) Cyrus has supported them for quite a while.

Thanks for the link to CiderWebmail, I've been on the lookout for a good IMAP webmail client, I'll have to give it a try

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted May 4, 2013 11:20 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

Akonadi doesn't cache all your data if you have an on-line IMAP account. only disconnected imap caches a lot of data. So this whole discussion is rather moot...

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 12:47 UTC (Wed) by HelloWorld (guest, #56129) [Link]

Nobody is arguing against a properly engineered PIM solution. But the fact that you're doing something that is right in principle doesn't mean that it actually works well. As I said earlier, kio_imap4 often just seems to hang indefinitely, imap IDLE doesn't work (even though it's supposed to), and afaik Akonadi still doesn't work with an NFS home directory. Oh, and kmail still isn't able to handle folder names with Umlauts. And sure, I could report all that. Or I can just use something that does what *I* need.

And that doesn't include most of the stuff that you just listed. I don't "talk" to people via email, that's what XMPP is for. And I honestly don't understand why one would even need a calendar application these days when everybody uses their smartphone to manage appointments with (and contact/appointment synchronisation is one area where the open source desktop still sucks badly). And even if I saw a use for that, why would my calender need to access my contacts? I can have appointments with people just fine: Joe will send me an email with Subject "Lunch tomorrow at 13? (eom)", I'll reply with "OK (eom)" and type "Lunch with Joe" into my phone. And as you can see, my email program doesn't need to know about my calendar either, whoa! I have a feeling that things become much simpler when you do them this way, and I think most people do.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 13:00 UTC (Wed) by niner (subscriber, #26151) [Link]

So, _you_ don't need the functionality, so nobody else is allowed to? News for you: you are not the center of the world.

I _want_ my email program to have access to my calendar, so when I get a meeting invitation as ICAL attachment, I can click on accept and have it in my calendar. I do not want to have to type anything on a smartphone that I don't even have. And when I set up a meeting I want to click in my calendar and just add my business contacts and not have to type in a list of email addresses, thank you very much.

kio_imap4 hangs indefinitely and IMAP IDLE doesn't work? Ever thought about upgrading to current akonadi based kmail2 where these things are fixed?

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 17:03 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> So, _you_ don't need the functionality, so nobody else is allowed to?
I never said anything remotely like that. Heck, I wouldn't even know which part of my comment could be misunderstood that way. I'm just saying that the Akonadi developers shouldn't be surprised when the people who don't need that kind of functionality leave for something that does a better job at what they do need.

> kio_imap4 hangs indefinitely and IMAP IDLE doesn't work? Ever thought about upgrading to current akonadi based kmail2 where these things are fixed?
I have the most recent version of kmail from the Fedora repositories installed (version 4.10.1 according to the about dialog) and the relevant server does support IMAP IDLE. So yes, it's supposed to be fixed, and no, it doesn't actually work for me.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 11:17 UTC (Thu) by nye (guest, #51576) [Link]

>I never said anything remotely like that. Heck, I wouldn't even know which part of my comment could be misunderstood that way.

I don't think anything you said could be even plausibly construed to mean that by anyone not specifically intending to pick a fight.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 11:50 UTC (Thu) by niner (subscriber, #26151) [Link]

It's words like "I honestly don't understand why one would even need" or "even if I saw a use for that" that can convey such a meaning.

You wrote about kio_imap4 which is not used by kmail 2. Hence I got the impression that you were still using kmail 1. Especially since you cited problems that are supposed to be fixed in current Akonadi. As they are still there for you, I strongly suggest reporting them on bugs.kde.org. The developers really try to fix them but there are obviously many different problems leading to the same symptoms.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 18, 2013 22:40 UTC (Thu) by HelloWorld (guest, #56129) [Link]

kio_imap4 in fact isn't used any longer, sorry about that. Nevertheless, IMAP IDLE doesn't work for me. Anyway, my personal experience with bug reporting is that it hardly ever helps. I have other fish to fry and simply use another email client now.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 23, 2013 12:38 UTC (Tue) by nix (subscriber, #2304) [Link]

I believe it is strigi that doesn't work with an NFS home directory. Indexing, not caching. (Why you can't just run the indexer on the server and have the client query it over this 'network' thing we seem to have these days is not clear to me, but apparently you can't. Ah well, as of KDE 4.10 strigi can hardly index any file types anyway, so it's not much of a loss.)

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 29, 2013 23:07 UTC (Mon) by jkt_ (guest, #90352) [Link]

If you are interested in rewriting KMail from scratch, use IMAP instead of POP3 and don't need calendar integration, you might want to check out Trojitá as well.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 13:32 UTC (Tue) by BlueLightning (subscriber, #38978) [Link]

Existing filter rules have broken at least twice since I moved to KMail2 from 1 when Kubuntu switched over (first on initial migration and then again a few releases ago). In my case it wasn't too difficult to just re-create the rules and now filtering works just fine. A working import for existing rules would have been nice though.

FWIW, other than the searching UI being a bit painful and the find-as-you-type issue with address books (which I understand has been fixed in the last week or two) I am finding KMail2 to be quite good, and I use it every day with a large volume of mail. I am using IMAP and not POP3 however if that makes any difference.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 18:35 UTC (Tue) by brianomahoney (guest, #6206) [Link]

Sorry, this is just the kind of nonsense you hear on KDE's forums, which themselves are more than half the problem ... If someone said "Ah you have to have Dovecot to read your mail" I would laugh at them. Usual problem, too much distance between users and developers, added isolation from self important, self appointed GUI artists and Project Leaders leads to useless crap. M$ should have taught us that.

The real message here is kmail1 was perfectly functional, why was any of that broken at all. I strongly support Linus' view that you don't break stuff that is working for dreams of lipsticked pigs in supersonic flight.

Copying and moving mailboxes and messages in the view tree is basic, if akonadi stops that it must be fixed first. The other thinking is what led to Gnome and the KDE 3.4 -> 4.0 debacles.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 16, 2013 19:39 UTC (Tue) by niner (subscriber, #26151) [Link]

If you think, kmail worked perfectly well, you cannot have used it too much. Or more probable: it worked in your case, while in mine it did not. After resume from disk, IMAP connections would hang and I would have to kill -9 kmail. Frequently it's indexes would get corrupted leading to kmail duplicating every mail in my inbox.

Have you ever tried syncing your TODO lists with kitchensync? You would have to close kmail, so kitchesync can open it again, because accessing a mailbox was only possible with kmail running but it would only give you errors if kmail was running already. The same goes just for having a systray icon for displaying new mails.

kmail 1 never supported IMAP idle so it had to sync folders every couple of minutes. When it did, it was extremely slow.

Those and probably a couple more that I already forgot were real problems and just the ones I personally had with kmail 1. And those are all problems that kmail 2 fixed. So it's nice that you have nostalgic memory about kmail 1, but it was in fact very far away from perfection. kmail 2 for me is much closer but obviously there are different use cases and some work better than others. Same as with the old version.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 1:00 UTC (Wed) by brianomahoney (guest, #6206) [Link]

Sorry, I don't want to get into a my features/your features dispute, we have mail going to 4 offices on 3 continents stiched up with no single point of failure, until Kmail2 came. It dosn't work out of the Box with SuSE 12.3
it wont let me move mail from one folder to another, It wont import out Kmail 1 folder structure ... often Akonadi hangs, wont start, loops for no reason, and no I don't want it to index mail AT ALL.

The same feeble excuses make me convinced, on the face that the KDE project is not serious, which is very sad, they HAD a very good system 4.10.x has lots of eye kandy I don't want and many basic fuctionalities are broken, and that is no small thing. I do hope that the current kinder running the project are forked by people who that the "Erste muss arbeit" attitude, not don't be unkind and criticise.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 6:40 UTC (Wed) by niner (subscriber, #26151) [Link]

So you don't want to acknowledge, that there are use cases where kmail2 not only works, but brought real improvements, despite _users_ telling you so. Instead, you rather want to insult the developers whose work you use for free.

May be a great example of professional behaviour, but even so I hope KDE developers don't learn from it. This discussion obviously serves no purpose anymore.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 10:55 UTC (Wed) by anselm (subscriber, #2796) [Link]

So you don't want to acknowledge, that there are use cases where kmail2 not only works, but brought real improvements, despite _users_ telling you so. Instead, you rather want to insult the developers whose work you use for free.

It's the old dilemma: The developers want to be free to do what they want, but they also want to be taken seriously as platform providers. These two goals are to a very large extent mutually exclusive.

There may be valid reasons for a reimplementation of Kmail, and the end result may in fact lead to improvements for some (or many) users. However, if things that used to work with Kmail 1 no longer work with Kmail 2 then there is obviously a problem as far as providing a reliable platform is concerned. Complaining that pointing out this problem »insults developers whose work one uses for free« is not constructive.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 11:02 UTC (Wed) by niner (subscriber, #26151) [Link]

If things that used to work no longer work then that's a regression and should be reported as such on bugs.kde.org. Obviously the developers missed those use cases and need to be made aware.

It's not pointing out problems that insults the developers, it's insuling the developers that's insulting them. "I do hope that the current kinder running the project are forked by people who that the "Erste muss arbeit" attitude, not don't be unkind and criticise." does not point out any problems, it's just there for the insult.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 12:08 UTC (Wed) by anselm (subscriber, #2796) [Link]

"I do hope that the current kinder running the project are forked by people who that the "Erste muss arbeit" attitude, not don't be unkind and criticise." does not point out any problems, it's just there for the insult.

I would need to be able to parse that before I could even take it as an insult.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 17, 2013 21:41 UTC (Wed) by dlang (subscriber, #313) [Link]

And you don't seem to want to acknowledge that breaking existing users to add new features is a problem.

regressions are bad, in general, users care far more about their existing processes not breaking than they do about any new features.

In part, because if you regularly allow old stuff to break as you add new features, users find that they cannot rely on your software, and so they will not see your new features because they have to move to software that they can trust not to break them.

Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 12, 2013 16:19 UTC (Fri) by cyperpunks (subscriber, #39406) [Link]

Done right this could be very nice indeed! Thanks!

LXDE Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 12, 2013 18:52 UTC (Fri) by atai (subscriber, #10977) [Link]

LXDE works very well as a light weight desktop. LXDE of course is based on gtk+ 2 and GNOME related technologies

LXDE Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 12, 2013 19:30 UTC (Fri) by jospoortvliet (subscriber, #33164) [Link]

but there you don't have a choice. The plan with Klyde is that we give you a basic, sane default but you can still have what you want. As GNOME discovers, the average user does indeed only use 20% of the features in an ui, but they all use a different 20%. The trick is sane defaults and presentation, not dumbing down.

LXDE Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 13, 2013 3:21 UTC (Sat) by drag (guest, #31333) [Link]

Hence extensions and making it so people can add on third party programs to do other things.

The advantage to this is that extra '20%' you want is something that you are the only one forced to deal with. You can happily ignore the rest of everything knowing that it's probably has sane defaults that you will never see or be forced to deal with.

LXDE Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 13, 2013 5:35 UTC (Sat) by atai (subscriber, #10977) [Link]

Good luck achieving that without bloat. If your approach works, I am sure LXDE or GNOME will copy you.

Everyone wins

LXDE Stephenson: hackweek9: Lightweight KDE Desktop project

Posted Apr 13, 2013 13:47 UTC (Sat) by pboddie (guest, #50784) [Link]

Yes, credit is due for acknowledging the "objects of user hatred" and offering a solution that doesn't insist that everyone learn to like them.


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds