[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: improving the UX with the default KDE installation

Am Mittwoch, 15. März 2017, 19:01:16 CET schrieb fradev:
> The default KDE/Plasma 5 installation in Stretch, via task-kde-desktop, in
> my opinion doesn't provide the best user experience because of the many
> applications installed by default.
> While the experience with the Plasma desktop is pretty good, the same
> cannot be said for some KDE applications. To improve the situation, at
> least for me, in different occasions I had to:
> - manually install only the required KDE applications in a minimal Debian
> setup;
> - or manually remove all the unwanted KDE applications in the default KDE
> installation (and break meta-packages).

There are metapackages of finer granularity available like kde-standard, 
kdegraphics, kdemultimedia.

> ========
> Let's start with Konqueror, installed by default in the case discussed

Konqueror is still quite a central part in Plasma. It is used by default for 
web shortcuts and for URLS like "man:/ls" oder "info:/".

Of course from a security point of view it would be better to not install it.

> Same story with some of the KDEPIM applications installed by
> task-kde-desktop/kde-standard. I'm a Kmail user but like many others I know
> that Kmail can be a difficult beast to handle, it has its bugs, akonadi
> could be a pain sometimes, and it lacks developer manpower too (and maybe
> it will be replaced by Kube in the future).

For me, and I am a heavy user of KDEPIM, it works reliably meanwhile. I didn´t 
recreate Akonadi databases since quite a while. The last time I did, was 
because for work IMAP account the MySQL grew beyond any sanity, but that was 
an error in my settings as I activated offline storage for mails. Well I did 
this due to the extreme unreliability of Exchange IMAP, but that is nothing 
Akonadi can be made responsible for. There are some issues with reconnecting 
with an unreliable IMAP server within Akonadi… and I would have liked to see a 
newer version of Akonadi… but unfortunately it didn´t make it.

Of course one can argue whether to depend on a KDEPIM client with the standard 
set of packages for a DE, but… for me at least I am not fond of living in all 
those Web 2.0 applications. I want local clients. The Internet has more than 
one protocol.

> Despite I'm using Kmail I will probably suggest to other users and newcomers
> to try Icedove/Thunderbird instead, or simply use their e-mail accounts via
> web browser if it is too much for them. In my opinion Kmail and friends
> should not be installed by default.

And Thunderbird has more development activity? *Not at all*.

Also it does not integrate very well with a Plasma desktop. Especially the file 
dialog from GTK, which in my opinion provides the worst file dialog I have ever 
seen regarding usability.

> There are other cases like that or minor redundancies, such as Kate and
> Kwrite installed altogether. Why install them both?

These are not redundancies. KWrite is a smaller editor for some quick work on 
a file, Kate is the extended version of it. It is upstream decision to provide 
both and I think it would be extra work for Debian Qt/KDE Team to split out 
kwrite from the upstream packaging.

So, you see all of this is arguable. One size does not fit all. Of course there 
are distros whose developers make other choices, but I personally like it that 
in Debian Plasma is quite close to what upstream provides. I don´t want the 
distro to mess around with it more than necessary.

It may be good from a security point of view not to install Konqueror by 
default tough. But I am not sure what parts of Plasma desktop would break by 
doing so. And it would need to be tested.

And for Jessie I think bigger changes to the default set of packages are not 
suitable anymore. If you really see a single package here and there that 
absolutely doesn´t make any sense anymore, one that still points at stuff that 
was in older KDE SC 4 stuff for example, you are always invited to provide a 
bug report for the team to consider.

Just given the freeze Debian is in now… it is most important to provide *very* 
*specific* reports. Broader changes like the ones you suggest are, I think, out 
of the scope what could still be sensibly done *and* tested in time for 
Stretch. So it may be a good idea to bring this up again after the release of 
Stretch where Debian Qt/KDE developers have more freedom to make bigger 

All that said: I asked in upstream about Konqueror several times. 
Unfortunately its still not very good maintained. Its a pity regarding 
webbrowsers. Cause aside from the engines of Chromium and Firefox no one seems 
to keep up with recent developments anymore. Unfortunately both engines are 
difficult to separate from their browsers. Qt did it with Blink engine in 
Chromium, packages in Qt as Qt WebEngine. So far I think they provide a new 
version of it with every major release of Qt. How good their security support 
for Qt Webengine in older Qt releases is I didn´t evaluate. At least KDEPIM – 
not the version in Debian tough – migrated to using Qt WebEngine. But 
Konqueror didn´t.

Also there are still some developments at least on KHTML.


Reply to: