Fedora 15 KDE 4.6 feature page, comments/feedback?

[Kevin Kofler]

Manuel Escudero wrote:
> I like it, I seriously like it :D I'm in favor of changing the default
> phonon backend for VLC.
> With this, we will give support for a ton of formats more in the default
> players and if I'm
> not wrong, maybe we will experience a better user experience (sorry for
> being redundant)

No, sorry. If we get VLC into Fedora, it will be a version with all the 
patent-encumbered stuff ripped out, just like our current xine-lib 
packaging. You'd have to install a vlc-extras-freeworld (name subject to 
change) just like you have xine-lib-extras-freeworld now.

Another issue is that VLC only supports WebM through FFmpeg, so it will not 
be supported out of the box in Fedora. (FWIW, xine-lib doesn't support it at 
all at this time, it crashes on .webm files.) So from that point of view 
(WebM support), GStreamer would be the best option.

But there are other issues than just codec support to consider as well: 
features (not all backends support everything, which means some applications 
work better with one backend than with another), stability (crashes and 
other bugs are annoying) etc.

> RECOMENDED APPS FOR EVERY DAY USE:
> 
> audacious

Duplicates the functionality of JuK (currently shipped on the live CD), 
Amarok (what most KDE users use, and what we'd likely add if space permits) 
and arguably Dragon Player (also shipped on the live CD). We already have 
enough options without adding a non-KDE one.

> guvcview

I'm not sure we need something like this by default, but we'd rather ship 
Kamoso than guvcview for this purpose. (Kamoso is not yet in Fedora, but 
it's in our plans.) Again, we prefer KDE apps on a KDE spin.

> kmess

Duplicates a subset of Kopete's functionality.

> pidgin

Duplicates Kopete's functionality and is not a KDE app.

> gimp

Well, you have a case arguing for a non-KDE app there (though Krita is nice, 
too, but photo editing isn't a focus for the developers; Digikam can be used 
for some photo editing, but it's primarily a viewer), but I'm not convinced 
it makes sense to stuff it onto a live image. It isn't on current Fedora 
GNOME live CDs anymore, due to size, and Ubuntu stopped shipping it by 
default even earlier.

> gparted

Why not kde-partitionmanager?

IMHO it's a useful suggestion to put a partition management tool onto the 
live image to allow using it for rescue purposes, but again I don't see why 
we'd use a GTK+ one rather than a KDE one.

> sound-juicer

I'm not sure a CD ripper is needed by default, even more so if we (re)add 
K3b which also has ripping support. But if we want to ship a CD ripper, we 
should ship kaudiocreator which was recently (re)added to Fedora. (It got 
lost during the KDE 4 transition, but now there's a working KDE 4 version 
which got packaged.)

> xchat

Duplicates Konversation's functionality and is not a KDE app.

Look, I use XChat, I even comaintain it, but still I don't see why we'd ship 
it on the KDE spin. (And if Sho_ finally fixes Konversation to send quit 
messages reliably, I'll probably switch to it. In fact I had tried to switch 
and that bug was what made me go back to XChat.)

> multiget

Duplicates KGet's functionality and is not a KDE app.

> k3b

That one was left out of the F14 live image for space reasons only.

> banshee

Duplicates the functionality of JuK (currently shipped on the live CD), 
Amarok (what most KDE users use, and what we'd likely add if space permits) 
and arguably Dragon Player (also shipped on the live CD). We already have 
enough options without adding a non-KDE one (or two, with audacious!).

> xsane

I'm not sure we need something like this by default, but we'd rather ship 
Skanlite than xsane for this purpose. Again, we prefer KDE apps on a KDE 
spin.

> vlc

Mostly just duplicates the functionality of Dragon Player. There's some 
support for video editing, but it's no kdenlive, and anyway most users will 
never use it for anything other than playback, which Dragon Player does just 
fine.

As I said in the first paragraph, you have to keep in mind that if we ship 
VLC, it'll be WITHOUT support for patent-encumbered codecs, so you'd still 
have to add that post installation. (It would be no different than Dragon 
Player from that point of view.)

> kdenlive

Unfortunately, kdenlive depends on patent-encumbered packages which are not 
easily split into non-encumbered parts, so it cannot be shipped in Fedora.

> firefox

There are many flamewars over the default browser, but IMHO Konqueror is 
just fine.

Firefox is not a KDE app, our Firefox maintainers refuse to ship openSUSE's 
KDE integration patches because they are not upstream, Firefox's trademark 
policies suck (to the point that I personally think we shouldn't ship it in 
Fedora at all) and the Firefox/xulrunner stack is huge and wastes a lot of 
space, for functionality that's essentially a duplication of Konqueror's.

> unrar

This is not Free Software and therefore cannot be on Fedora nor any Fedora 
spin.

> p7zip p7zip-plugins

p7zip makes sense, to allow Ark to open 7z archives, I'm not convinced we 
need -plugins on the default installation though.

> java-1.6.0-openjdk

This is huge, we aren't shipping any Java app by default, so do we really 
have to drag in the JRE? OK, you can use Java applets in Konqueror with it, 
but how many websites still use applets these days?

> java-1.6.0-openjdk-plugin

FYI, Konqueror/KHTML doesn't use this, it has its own Java integration. (Not 
sure about WebKitPart though, I think it does use the plugin.)

> ntfs-config

What for? We support NTFS read/write out of the box. (We ship ntfs-3g and 
write support is enabled by default.)

> wine

Sorry, but no.

This is a complete no go for the x86_64 live image because it drags in tons 
of 32-bit multilibs on x86_64 (unless you want to ship only W64 support 
there, but the default wine metapackage is rigged to install W32 support as 
well, because that's what most people actually want), and we're not going to 
ship extra software on the 32-bit spin only.

> azureus

I'm not sure a dedicated BitTorrent client is needed by default because KGet 
has basic BitTorrent support, but if we want to ship one, we should ship 
KTorrent, which is a KDE app. (In fact, the main reason we omitted KTorrent 
is space.)

> tucan

I really don't think this one makes sense to ship by default. Even if it 
were a KDE app (which it is not), I don't think we'd include it by default. 
It just doesn't fulfill the criterion of being useful to the majority of our 
userbase.

> kid3

This one might actually make sense to ship, if there's space for it. I'm not 
sure though. Also note that JuK has some basic support for tagging files, 
and Amarok (which isn't currently on the live image, for space reasons) has 
quite decent tagging support.

> kipi-plugins

This was omitted for space reasons, it makes sense to readd it.

        Kevin Kofler