[vitunes] Re: vitunes: d.walter@xxxxxxx post needs approval
- From: kilian <kilian.klimek@xxxxxxxxxxxxxx>
- To: vitunes@xxxxxxxxxxxxx
- Date: Sat, 19 Feb 2011 23:22:06 +0100
Hi,
On Sat, Feb 19, 2011 at 04:54:00PM -0500, Ryan Flannery wrote:
> Hi Daniel,
>
> I just got this message from the freelists.org "admin-reject", because
> this email isn't subscribed. Forwarding to the list...
>
> Also, I thought I had this fixed... will investigate later tonight...
>
> On Sat, Feb 19, 2011 at 4:43 PM, FreeLists Mailing List Manager
> <ecartis@xxxxxxxxxxxxx> wrote:
> > This message was received for a list you are a moderator on, and
> > was marked for moderation due to the following reason:
> > Non-member submission to closed-post list.
> >
> > To approve this message and have it go out on the list, forward this to
> > vitunes-repost@xxxxxxxxxxxxx
> >
> > If you wish to decline the post, change the 'apppost' below to 'delpost'.
> > If you wish to edit the post, change it to 'modpost' and edit the message
> > as needed - not all mail programs will work with modpost.
> >
> > DO NOT DELETE THE FOLLOWING LINE. �Ecartis needs it.
> > // apppost 4D603986:3E2B.1:ivgharf
> >
> > From d.walter@xxxxxxx �Sat Feb 19 16:43:34 2011
> > Return-Path: <d.walter@xxxxxxx>
> > X-Original-To: vitunes@xxxxxxxxxxxxx
> > Delivered-To: vitunes@xxxxxxxxxxxxx
> > Received: from localhost (localhost [127.0.0.1])
> > � � � �by turing.freelists.org (Avenir Technologies Mail Multiplex) with
> > ESMTP id F2BC9D6A411
> > � � � �for <vitunes@xxxxxxxxxxxxx>; Sat, 19 Feb 2011 16:43:33 -0500 (EST)
> > X-Virus-Scanned: Debian amavisd-new at localhost.localdomain
> > Received: from turing.freelists.org ([127.0.0.1])
> > � � � �by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port
> > 10024)
> > � � � �with ESMTP id Sd9D6YRok4BH for <vitunes@xxxxxxxxxxxxx>;
> > � � � �Sat, 19 Feb 2011 16:43:33 -0500 (EST)
> > Received: from mail.0x90.at (static.21.59.46.78.clients.your-server.de
> > [78.46.59.21])
> > � � � �by turing.freelists.org (Avenir Technologies Mail Multiplex) with
> > ESMTP id 2F80DD6A40E
> > � � � �for <vitunes@xxxxxxxxxxxxx>; Sat, 19 Feb 2011 16:43:32 -0500 (EST)
> > Received: from bsdserver (unknown [127.0.0.1])
> > � � � �by mail.0x90.at (Postfix) with ESMTP id 22F904556798
> > � � � �for <vitunes@xxxxxxxxxxxxx>; Sat, 19 Feb 2011 21:50:24 +0000 (UTC)
> > X-Virus-Scanned: amavisd-new at 0x90.at
> > Received: from mail.0x90.at ([127.0.0.1])
> > � � � �by bsdserver (mails.0x90.at [127.0.0.1]) (amavisd-new, port 10024)
> > � � � �with LMTP id mJhz8CJo-i-y for <vitunes@xxxxxxxxxxxxx>;
> > � � � �Sat, 19 Feb 2011 21:50:22 +0000 (UTC)
> > Received: from amok.home (188-22-140-234.adsl.highway.telekom.at
> > [188.22.140.234])
> > � � � �(using TLSv1 with cipher AES128-SHA (128/128 bits))
> > � � � �(No client certificate requested)
> > � � � �by mail.0x90.at (Postfix) with ESMTPSA id EA4494556454
> > � � � �for <vitunes@xxxxxxxxxxxxx>; Sat, 19 Feb 2011 21:50:21 +0000 (UTC)
> > Content-Type: text/plain; charset=us-ascii
> > Mime-Version: 1.0 (Apple Message framework v1082)
> > Subject: Re: [vitunes] Easier Collaboration?
> > From: Daniel Walter <d.walter@xxxxxxx>
> > In-Reply-To: <AANLkTikRHLdEpuDDA+bPBROgOAnQeFN34Jtr3wu1k9Yd@xxxxxxxxxxxxxx>
> > Date: Sat, 19 Feb 2011 22:43:18 +0100
> > Content-Transfer-Encoding: quoted-printable
> > Message-Id: <AA3C13D1-C485-4B82-977B-043FB7AA951A@xxxxxxx>
> > References: <AANLkTikRHLdEpuDDA+bPBROgOAnQeFN34Jtr3wu1k9Yd@xxxxxxxxxxxxxx>
> > To: vitunes@xxxxxxxxxxxxx
> > X-Pgp-Agent: GPGMail 1.3.1
> > X-Mailer: Apple Mail (2.1082)
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > On Feb 19, 2011, at 9:49 PM, Ryan Flannery wrote:
> >
> >> Hi List,
> >>=20
> >> I apologize for falling behind on the diffs being sent (I was recently
> >> "volunteered" for a committee at University). �I'm interested in
> >> trying to make the process a bit easier/quicker.
> >>=20
> >> What do you guys think about using the github repo as master, and
> >> using the fork+pull-request model for development? �I'm inteterested
> >> in this, or similar because:
> >>=20
> >> 1. I want your names stay attached to your diffs & work, more than
> >> just my comments "=46rom ..." in the commit messages. �You guys did =
> > the
> >> work, you deserve the credit. �It's also nice to have a valid
> >> annotate/blame view :)
> >>=20
> >> 2. Maintaining the development in one location where other's efforts
> >> are linked-to would be nice.
> >>=20
> >> 3. Ease. �I know github can be fickle occasionally, but overall with
> >> other projects I've worked on, it works quite well.
> >>=20
> >> We could accomplish similar on gitorious/bitbucket or even a private
> >> repo, but I'd prefer to use github if possible.
> >>=20
> >>=20
> >> Obviously, thoughts and comments are welcome!
> >> -Ryan
> >>=20
> > Hi Ryan, hi list,
> >
> > sounds like a great idea, I've already forked vitunes on github so
> > it's fine with me.
>
> Nice. I'm already following you.
>
> > I'd also like to announce that I'm currently working on a alternative
> > player using gstreamer.
>
> Very Nice! I've been dying to get multiple backends for vitunes working.
>
> > I currently investigating how it could be=20
> > easily integrated in vitunes, so that one can select which backend
> > to use.
>
> I'm not sure on the best way to add the structure either.
>
> One thought is the following:
> 1. The player structure has a "backend" type, from, say, an enum of
> supported backends.
> 2. The functions in player.c switch on this and execute the
> appropriate functions for each backend.
> 3. The code for each backend could be in seperate files, say
> "player_mplayer.[h|c]", with just the functions needed for the vitunes
> functionality. Or a subdirectory "player/mplayer.[h|c]. I think I
> like the subdirectory idea better.
>
> With this, we could have one build support multiple backends, and
> perhaps a command-line flag or config option to select which.
>
> The big problem I see with supporting multiple backends:
> 1. The player_monitor() function... that's a nasty bit of
> mplayer-specific goo. It handles the timing update and playing the
> next file in a playlist when one ends. Is that easy to port to
> gstreamer? Further, is it easy to get a unified way of doing things
> between gstreamer/mplayer/foo?
>
> 2. That's all I can think of for now... gotta run.
>
> Anybody else have comments on this? I'd love to hear.
The easiest way (I can think of) to do this is probably to use function
pointers and a backend struct. Something like this:
--snip--
...
typedef (void)(*play_func)();
typedef (void)(*pause_func)();
tyepdef struct {
char *name;
play_func play;
pause_func pause;
...
} player_backend_t;
player_backend_t *backends[] = {
&mplayer_backend,
&gstreamer_backend,
...
};
player_backend_t *current_backend;
...
--snip--
-kilian
>
> > I'll probably do it via a Makefile switch, so that one can =
> > either
> > use the gstreamer backend or stick with mplayer.
> >
> > I'll commit the patches to my github repo as soon as I have a prototype
> > and will let you all know about it.
> >
> > Any ideas or comments on this ?
>
> Just the above for now.
>
> Also, THANKS!
>
> -ryan
>
Other related posts:
