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.
> EXAMPLES
> ========
>
> 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
changes.
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.
Thanks,
--
Martin
Reply to: