KMail Now Supports A Unified Inbox While KDE Keeps Getting Polished

[phoronix]

Phoronix: KMail Now Supports A Unified Inbox While KDE Keeps Getting Polished

Come KDE Applications 18.12 in time for the holidays, the KMail KDE email client will finally offer a unified inbox...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-KMail-Unified-Inbox

[Wilfred]

One would hope they have fixed the stability and email eating bugs now.

[boxie]

Wikipedia lists 26 linux email clients (there are more).
Resources are limited, needs are not.
Open source is made to fight that bullshit duplication of efforts, it is made so Claws Mail team can work together with Thunderbird team, improving their performance if that is their goal, or make a new theme if looks is the point. Are th
ere key differences? Discuss them, and eventually fork with that VERY LITTLE thing, sharing as much code as possible. You want to remove the bloat? Make the program display a form on startup to help discuss given issue.
There always is a better way than starting a new SHIT. No email client is good, I like mutt the best, but it is crazy bad, as some other people decided to make their own clients instead of working on it.
"Hey, but mutt is CLI, and KMail is not!" - so what? make a library that manages core stuff and just write as many interfaces as you want.. while prefering new themes over new toolkits. Make sense people. You probably start a new project
because someone over some mailing list has hurt your feelings or is not of your faith.

Why does every 'desktop environment' thinks it needs its own set of programs? I like Plasma (but dwm beats the crap out of it), OK desktop environments are a bit harder to collaborate, but they still can do so, and should
They just display some widgets, manage keybindings etc.
It is better to improve theming, so programs look better across other desktop environments than to make a new program for the environment, while trying not to make so many environments in the first place, and just tweaking some 'settings'
of existing one. Look, Ubuntu did that! They dumped Unity, and switched over to GNOME, hey, it IS possible, oh boy!

Going lower and lower the software stack it becomes harder and harder to follow these rules (Kernel = very hard; Language = hard; DE = medium; Some program = FUCKING EASY)

Maybe your software company doesn't allow you to do so? (e.g. Red Hat probably won't allow you to work on Plasma instead of GNOME) OK, that is the situation where you have no power, but then don't allow that company to claim it is open-so
urce. Boycot it.

Interestingly, where it is the hardest to do, the more people are likely to do so (look how many people collaborate on e.g. LINUX KERNEL) as going their usual way is mostly useless, and they notice it, but they don't when the effort to ma
ke a new one is lower (but higher than collab) and they are capable of 'succeeding' in their fake worldview.

Look now, there are so many distros, but we need to tweak every single one of them. Boot process is SHIT on them (multitude of config files to correct that, and some problems still persist, because noone will noce them as they build their
own set of problems). Installing new software outside of "repo"? BTW. have you noticed that every apt or pacman or yum downloads lots of data just to show you there are new packages? Is this present on android? Yum has deltas, but why do
esn't apt? What do they do so differntly so they need to implement half baked new one?(yum is slow)

Code can be a burden, but it can be an asset.

Tell me what don't you understand?

So - Rant time?

1) There is nothing wrong with competition. Linux has a bunch of friendly competition between the DE's - they also have a whole bunch of collaboration.

2) The great thing about forking? you can work in your own universe and then, if you choose, you can issue a PR!

what you see as "duplicated effort" is often people scratching their own itches. Nothing wrong with that.

[Vistaus]

BTW. have you noticed that every apt or pacman or yum downloads lots of data just to show you there are new packages? Is this present on android? Yum has deltas, but why do
esn't apt? What do they do so differntly so they need to implement half baked new one?(yum is slow)

Code can be a burden, but it can be an asset.

Tell me what don't you understand?

Well, Linux is based around package management while Android is not. The content in the Play Store gets loaded and pushed from Google's servers because they have the server capacity. On Linux, even if we disregard the package management, not even the most popular Linux has the same server capacity to do that.

[Vistaus]

Another example:
There was a news a few days ago that Nano text editor improved performance by 70%. Well.. There is also VIM and Emacs. They should be using same core libs just different user interface and keybindings (wouldn't it be nicer the more they shared?).

I disagree, but aside from that: if you want text editors to use the same core libs, then please only include Nano and Vim. Emacs is waaaay more than just a text editor, so it's not even in the same ballpark as Nano and Vim.

Valve once said something like that "it's best when everyone is on the same level", that is the case.

That's kind of what Unix developers used to say: "Make each program do one thing well."

[TemplarGR]

While i don't agree with everything tichun wrote, he has a point. There is oftentimes wasteful duplication of effort in the open source world.

Still, most apps reuse a ton of common libraries so it is not like they keep reinventing the wheel. For example all email programs use the same openssl library... Also, most of the "hard" code has already been done on the toolkit side. The code that differs typically is the code that would differ even if the code was just a fork and you wanted a different appearence and a couple of different features etc.

[Luke_Wolf]

*a bunch of stupid shit -- SNIP*

Open Source is a pure meritocratic anarchy. Because this is the case people are going to do whatever the hell they want. Which means that they're going to create duplicate projects if they want to regardless of your or anyone else's wishes that everyone would just work on a single project. This is a good thing. If things were done your way we'd always be stuck with the legacy of old garbage, utterly incapable of innovating or changing with the times. There would be no Wayland, no LLVM, no Rust.

People like you love to spend your time acting like we're so terribly off because of this, but are we really? The answer is a hard no. LLVM is doing so well as a duplicate competing project to GCC and for that matter Microsoft's own MSVC that LLVM built binaries are becoming quite common even on Windows. Now consider the DE's you people love to whine about, Has KDE or GNOME ever really been that much worse off than the Microsoft Windows version it was competing with? The honest answer is no. They have always had their rough edges, but their rough edges have really been no worse than their proprietary competitor at the time.

In so far as Linux has had technical issues "preventing adoption" (rather than the real factors of missing software people want to run and OEMs not installing it by default on anything) it's been on a level where there is no real duplication in the sense you're complaining about, and that would be with its drivers. This has been the one area that Linux has been historically worse than Windows on with a lot of pain around wifi and graphics in particular. Do note, I'm not saying OSS doesn't/hasn't suck(ed), but that the proprietary competitors that do work like you want Open Source to have done no better in the grand scheme of things.

[polarathene]

Thanks for calling what ive said a stupid shit while not adding anything already known to the conversation.

I don't know if it's helpful but from a developers point of view/experience. A tonne of small programs might get rewritten as a learning experience or practice, and as others have said to scratch an itch. Sometimes I might have a project I want to work on, I may find existing libraries that do what I want and utilize them, or for whatever reason I may write my own one(provided I deem the time/effort required and knowledge to do so as worth it).

Sometimes it's because existing one is in a language I'm not comfortable with or my other code isn't going to have as good of a time integrating with, it could be a perf issue and I want to provide better perf or features and for some reason contributing that to an existing project isn't desirable(perhaps I just want to create a subset of the functionality it does with a slight change that benefits me but maybe not their users so much, just because you fork it and go through efforts to adopt and develop on a foreign codebase and create a PR in effort to merge it back doesn't mean it'll be welcomed/merged all the time, sometimes the PR gets blocked by upstream for various reasons and you're strapped for time that you cannot appease them).

I have contributed to existing projects/apps in the past though. For example I briefly used macOS and the excellent iTerm2 app, it lacked a transparency feature for a visual preference I had, rather than rewrite my own terminal app which'd be insane waste of my time and really not of interest to do for me as a project, I looked into the open-source code, bunch of obj-c and something else I think that was foreign to me, but I was able to locate the code I wanted to modify across several files, got it working, updated the GUI settings across a few files for it and sent in a PR on Gitlab, got some feedback, made the changes, PR got accepted and feature merged.

So it does happen obviously :P There are some projects I want to do where I bet some people have already written code that does similar or the same sort of things mine will do. But they're challenges and learning experiences I want to tackle myself and use as portfolio to demonstrate my skills in that area(embedded hardware robot with some 3d printing for it's body, using machine vision and various sensors controlled over a smartphone app, another is 3D data processing/optimizing, I want to use Rust, and while there are a few implementations of the Octree datastructure, none are all that popular or imo complete to what I'd like, I also have some niche features I want to support along with the PLY format for streaming the data to iterate on vs the more common approach of loading the data into memory all in one go(not an option for the size of data I'm working with)).

Hope that helps I do agree with you about things like e-mail benefiting from shared modular codebase for backend/frontend, but you have existing legacy code and projects, and various people interested in working on e-mail software from different backgrounds and interests, what's ideal isn't always practical in the real world I guess? People will contribute to existing projects if they feel like it, not much you can do to change that, just let them contribute how they like, be that existing or new, it's not like new things don't take up popularity and build new communities/interest in things So while you might see it as not so great, it may be better in the long run.

[Happy Heyoka]

I like that there's two pages of ranting and hardly a mention about the actual change to KMail/Akonadi.
Not sure a unified "inbox" would be high on my list of changes but maybe I'm missing something (and I use three mail accounts via KMail/Akonadi)

Emacs is waaaay more than just a text editor

Emacs is an awesome operating system... when did they fix it so you could edit text?

[TheBlackCat]

Wikipedia lists 26 linux email clients (there are more).

<snip>

There always is a better way than starting a new SHIT. No email client is good, I like mutt the best, but it is crazy bad, as some other people decided to make their own clients instead of working on it.

Kmail is the first graphical, open-source, Linux email client on that list.

make a library that manages core stuff and just write as many interfaces as you want.. while prefering new themes over new toolkits. Make sense people.

The first stable release of Mutt didn't occur until months after the first stable release of Kmail.

And let's be realistic: it is often very, very hard to split up a monolithic application into a library. Unless it was designed that way from the beginning, writing a new library from scratch is often much less work.