>I think that, in the end, we have three options:
>
>1. Get kaboodle up to snuff.
Yes, improving kaboodle to support all modern formats is a huge
bite. Short term we only need to debug and patch why kaboodle is
failing with even the older formats. That provides us some
temproary breathing room.
>2. Move kmplayer into tde-multimedia.
If we do this then we might consider pulling kaboodle from the
sources and abandon kaboodle.
I'm not against the idea of pulling kmplayer into tdemultimedia,
but another option is we promote kmplayer as part of the base
package set. If we start promoting kmplayer, I'm in favor of a name
change.
>3. Move kaffeine into tde-multimedia.
Same as kmplayer: we promote kaffeine as part of the standard
package set.
Darrell
>No, leave the patch in place - I'll make an update.
>I hope soon :)
Okay. I believe the path I used in the patch is the normal
installation location as intended from upstream. Therefore other
distro maintainers who use a different path are changing that
location.
Darrell
On Tuesday 04 February 2014 16:08:45 you wrote:
> >7) all distros support mplayer in one form or another
>
> I suppose this is a packager problem, but the original idea of a
> default player is no external dependencies.
>
> MPlayer is well supported but is not part of a stock installation
> on all distros. Other dependency presumptions exist in Trinity (for
> example, xine for amarok), yet nominating kmplayer as a default
> video player and moving into tdemultimedia means MPlayer needs to
> be installed.
>
> Audio players are not the same challenge. We have kaboodle, noatun,
> and juk, all installed by the base package tdemultimedia.
>
> Fixing kaboodle gets us half way home. The other half is update
> kaboodle to support newer generations of avi/mpg and like or not,
> probably should support flv. For a default player that will
> suffice. People who want extensive video format coverage are going
> to install something else anyway.
>
> For Trinity users those additional apps will be kaffiene and
> kmplayer for video and amarok for audio. Not a problem for those
> types of users. We are discussing a basic default video player for
> the first-time out-of-the-box Trinity experience.
>
> Darrell
Never could get kaboodle & kmplayer to 'just work' for random streaming
media, checking the 'depends' for those two comes up with a
signifcantly shorter list of codecs et al installed compared to mplayer
and (my fav) vlc. this is on a Debian system.
Problem with desktop environments, apps that no longer or never did
work, not being able to go outside the box and use best of breed apps.
TDE has some 'best' apps, mine=gwenview, digikam, k3b, kmail, can using
other non-tde apps be considered ? Is this what the gtk-qt widget stuff
is for?
--
Peace,
Greg
>I would like to tag the current sources and binaries R14.0.0 RC1,
>as it
>appears that we have finally cleared the Blocker and Critical
>reports from
>the R14 Etherpad.
>
>Are we ready for this or are there any objections?
The etherpad hasn't received updates in a while. We need some
hacking.
Blocker:
========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd
=Blocker
Critical:
=========
http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd
=Critical
Michele is working on 1825, but could use help. That is an ugly bug
from a public relations perspective. The comments provide a lot of
details.
1853 needs attention.
1821 hasn't been touched.
1813 can be closed after the last comment is implemented.
Regressions:
============
1825 is bad (already mentioned in Critical). The others should
receive attention but probably could survive the R14.0.0 cut.
Patches Available:
==================
Lots of patches sitting out there that have not been reviewed.
Likely many could be pushed.
Other:
======
* The new web site should be tested before moving toward a release
date.
* There is a laundry list of items in the R14 checklist etherpad
that need attention.
Darrell
>I've had success with 'xine' 'kmplayer' (very slow) 'mplayer' (ok
>but full screen) and 'kaffeine"
Yes, but those apps are not default apps. Kaboodle is the only base
app that plays videos.
Xine is indeed a dependency for several Trinity apps, but all of
those apps are not base installation apps, like amarok, kaffeine,
kmplayer, etc.
Darrell
>This gets us no closer to solving the problem of a viable default
>video player, though, unless we want to shift KMPlayer into tde-
>multimedia.
Merging kmplayer is worth a discussion, unless we fix kaboodle with
nominal effort and pain. We're no longer in the 1990s --- we really
do need a working default video player these days.
We have two hurdles with kaboodle:
Broken in R14. I can play audio files with some user accounts and
can't start kaboodle at all with other accounts. Probably something
at my end, but consistently I can't play videos.
The supported video formats are few and they are both early
generation versions. Yes, both. As far as I can tell the only
supported formats are early generations of AVI and MPG.
I filed bug reports against both issues.
Darrell
>7) all distros support mplayer in one form or another
I suppose this is a packager problem, but the original idea of a
default player is no external dependencies.
MPlayer is well supported but is not part of a stock installation
on all distros. Other dependency presumptions exist in Trinity (for
example, xine for amarok), yet nominating kmplayer as a default
video player and moving into tdemultimedia means MPlayer needs to
be installed.
Audio players are not the same challenge. We have kaboodle, noatun,
and juk, all installed by the base package tdemultimedia.
Fixing kaboodle gets us half way home. The other half is update
kaboodle to support newer generations of avi/mpg and like or not,
probably should support flv. For a default player that will
suffice. People who want extensive video format coverage are going
to install something else anyway.
For Trinity users those additional apps will be kaffiene and
kmplayer for video and amarok for audio. Not a problem for those
types of users. We are discussing a basic default video player for
the first-time out-of-the-box Trinity experience.
Darrell
>I don't speak or read additional languages, but I would like to
>see
>i18n files receive attention too.
>
>I try to remember to update the i18n files when I make changes in
>the main files, but I don't always remember (I'm working on
>updates
>now to match some recent patches). Considering all of the renaming
>
>and rebranding changes made in git, I suspect the i18n files are
>in
>horrible shape.
>
>We have made changes to the top level help handbooks. I am certain
>
>no related updates have been made in the i18n files.
>
>There is the challenge of when we update screen captures to update
>
>the i18n versions too. That probably does not require a native
>language speaker, but does require toggling to the other language
>to create the screen capture.
>
>Part of our focus when we address the i18n files should be to
>develop a guideline so as a group we can update i18n files as much
>as possible when we modify the main files.
We should have a bugzilla status option such as I18NREVIEW and
FIXED_I18NREVIEW to help us update i18n files.
Refer to bug report 1813 for a similar idea for help handbooks.
Darrell