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
_______________________________________________
kde mailing list
kde@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
