[vitunes] Re: vitunes: d.walter@xxxxxxx post needs approval
- From: Daniel Walter <sahne@xxxxxxx>
- To: vitunes@xxxxxxxxxxxxx
- Date: Sun, 20 Feb 2011 00:19:11 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Feb 19, 2011, at 11:30 PM, Ryan Flannery wrote:
> Hi List,
>
> On Sat, Feb 19, 2011 at 5:22 PM, kilian <kilian.klimek@xxxxxxxxxxxxxx> wrote:
>> 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--
>
> This is much better. This is what should be done.
Hi,
yeah, this sound like an idea. I'll integrate it tomorrow and push the patches
to github.
It seems that I'll be much faster than I thought.
thanks for all the great ideas,
daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAk1gT+8ACgkQcXoydAw3IkTsmwCghDBVrxOsPyHqdr758loEsZff
zYgAninQSWLe3Of/j1do60c/67+J3Hwa
=mhrr
-----END PGP SIGNATURE-----
Other related posts:
