Re: [gst-devel] Totem or no Totem was Re: GNOME Development Series Snapshot 2.3.0: "Mighty Atom"

[Bastien Nocera <hadess hadess net>]

On Sat, 2003-04-12 at 11:33, Christian Fredrik Kalager Schaller wrote:
> On Sat, 2003-04-12 at 11:13, Bastien Nocera wrote:
> > On Fri, 2003-04-11 at 16:59, Christian Fredrik Kalager Schaller wrote:
> > > On Fri, 2003-04-11 at 14:00, Bastien Nocera wrote:
> > > > On Fri, 2003-04-11 at 09:08, Jeff Waugh wrote:
> > > > > <quote who="Jeff Waugh">
> > > > > 
> > > > > > But all of this is what the proposal process is meant to address -> it's
> > > > > > up to you guys to convince us to include your software.
> > > > > 
> > > > > Ahr, this came out wrongly. That's not how it should always work, and
> > > > > certainly not for every proposed module. Some things are proposed almost by
> > > > > default - fontilus and nautilus-cd-burner are good examples of these.
> > > > > They're already regarded as stable, have obvious maintainers, simple goals,
> > > > > are appropriately aligned with the goals of the desktop release, fill nice
> > > > > feature gaps that users will like, etc.
> > > > 
> > > > I feel cheated. Nobody said anything against adding Totem to the desktop
> > > > release, and it has all the properties enounced above. Why is it not
> > > > getting in the desktop release ?
> > > 
> > > If nobody said anything before against adding Totem to the desktop
> > > release before then let me do so now (sorry Bastien). 
> > > 
> > > I think that adding a media player to the desktop release that do not
> > > use the standard media backend and do not use the standard gconf keys
> > 
> > Doesn't use the "standard media backend", I agree. Doesn't use the
> > standard gconf keys, no, there's no need for them, they're autodetected,
> > it works out of the box on most machines. (The audio output can be
> > configured via gconf for my very own testing purposes, it's not
> > configurable in the UI). In fact, needing to have gconf keys seems to me
> > like it's a "flaw" in design more than anything else.
> I disagree, autodetection is a somewhat usefull feature for apps that
> are being downloaded from the net to be compiled and installed on
> operating system unknown, but for stuff being shipped together with
> distributions it is next to worthless. If there is a public demand for
> it somewhere along the pipeline we could put together a libao plugin for
> gstreamer which would give autodetection support.

Of course there is public demand for autodetection!

And by "autodetection", I'm talking about simple, "ALSA or OSS" and "Xv
or plain Xshm", nothing that wouldn't break on distributions.

> Anyway this doesn't hide the issue that we should not ship stuff in
> GNOME that means we provide many different parallel set of drivers and
> features.In the same way that we do not ship GNOME with multiple GUI
> toolkits we should not ship GNOME with different multimedia systems if
> we are serious about providing our users and developers with an
> integrated system instead of this weeks top of the pops apps.

Since when is "the multimedia backend" something user-visible ? I'm not
advocating using anything but GStreamer for GNOME applications... when
it's the right piece of software for the job. In that case it wasn't.

> > > defined for audio and video ouput and which contains functionality
> > > already bundled with nautilus-media would be a mistake.
> > 
> > Apart from the thumbnailer, nautilus-media and Totem don't have anything
> > in common.
> It was the thumbnailer I was refering to.
> 
> > > The GNOME 2.x series is supposed to be about creating an integrated
> > > desktop where the 1.x series to often had the feel of a meta project for
> > > separate projects and adding Totem would be a typical GNOME 1.x kinda of
> > > addtion due to reasons mentioned in the first paragraph. 
> > 
> > Totem currently is the only movie player that's close to be integrated
> > to the desktop. What exactly would be missing for it to be integrated?
> And in what exact manner is Totem more integrated than Gst-player?

Drag'n'drop, recent files, mime-type association and desktop entry (the
last 2 are in gst-player as well), asks for passwords when we need one.

> > > I think if that if we really want to be shipping an official media
> > > player for 2.4 then gst-player is a better candidate at this point in
> > > time. The only real strenght Totem/Xine has in the comparison at this
> > 
> > No disrespect to the great deal of work Julien put in gst-player, but I
> > don't think it's as complete, easy to use, or "just works"-style enough
> > to be in the desktop release. That's why we are working together to get
> > a GStreamer back-end to Totem.
> The GStreamer backend is still vapourware at this point as it has been for 
> a long time, having talked about it for 6 months doesn't make it any
> more real. And there is still the question about wether a generic extra
> tier atop differing media playback systems will work well or just give
> us something that works well with one backend and works somewhat with
> another.

Fair enough. If you fancy rewriting the whole lot of what's in Totem
just because we're changing one widget, knock yourself out...

> > > point in time is support for more properietary formats, none of which
> > > any of our major distributors will probably dare ship anyway, which
> > 
> > If you're talking about the DLLs, yes, it's a problem. For the rest, I
> > know that Debian ships totem (thanks to Sebastien), Frederic was going
> > to include Totem in Mandrake cooker, and Matthias is distributing it on
> > freshrpms.net. (and I just noticed that all these people are French ;)
> Not primarly the dll's, I am talking about all these reverse engineered
> codecs for Microsoft and Apple formats. Of the three you mention only
> one is a company, and it is a non-US company.
> 
> Anyway this brings me back to my point in the reponse to Jeff, that the
> number of formats we can safely support at this point in an official
> GNOME release is so small and obscure that it makes a video player kinda
> redundant.

Oh, since when should we hold off onto giving a GNOME seal of approval
for a piece of software because one country in the whole world has a
different idea of what is legal?

> > > makes the point kinda moot, because people who want to view those
> > > formats would have to download extra packages to do it anyway.
> > 
> > There's much more than the formats it supports. Here it goes:
> > - it "just works" (audio and video output are autodetected, no need for
> > configuration, so is the "Optical media drive")
> > - it supports fast CDDA playback on more than just Linux (see the CDDA
> > input plugin, it works on BSDs, Solaris and Linux)
> > - it has an easy-to-use and HIG compliant interface
> > - the sound output works on BSDs, Linux, Solaris and Irix
> > - it supports external subtitle files
> > - it supports LIRC
> > 
> > That's a list of things that Totem supports, and that aren't available
> > in GStreamer. That doesn't mean that GStreamer isn't a good piece of
> > software, it's just that for playback software, it's not as powerful as
> > xine is.
> I think I have responded to this higher up in the mail. I to make it
> clear I am not saying that Totem is a bad app, I am just saying it
> shouldn't go into the official GNOME desktop.
> 
> > (I hope that people will start using the BaconVideoWidget in their
> > applications for playback, it would ease the port to GStreamer when it
> > is done.)
> Well we already have new projects using the gstplay widget which doesn't need 
> porting to GStreamer.

Which ones ?

> > So, in the end, I really think that Totem has its place in the desktop
> > release, even if it isn't based on GST.
> I guess we disagree here.

I gathered that much.

-- 
Bastien Nocera <hadess hadess net>