Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: AW: A basic statement about VDR (was: AW: Re: MPlayer <-> VDR, first try)



*This message was transferred with a trial version of CommuniGate(tm) Pro*
yes ...
i think most people think this would be the best solution.
klaus already told he hi is planing such a API, but not released yet ;-(

mfg Johannes


----- Original Message -----
From: "Marc Stauff" <news@stauff.org>
To: <vdr@linuxtv.org>
Sent: Sunday, October 14, 2001 1:50 PM
Subject: [vdr] AW: A basic statement about VDR (was: AW: Re: MPlayer <->
VDR, first try)


> *This message was transferred with a trial version of CommuniGate(tm) Pro*
> Your statement makes perfect sense to me, thats exaktly what i think. Of
> course you, as a private person, cant implement every feature somebody
wants
> in a non-provit project.
>
> Thats why i thought of making a common api in your software. So you could
> leave that fancy  and (to you more or less useless) features to someone
> else.
>
> Right now, everyone who wants to add something to your software just hacks
> it somewhere in your source. So, new version -> nothing works anymore, and
> different patches dont (always) work together.
>
> But if you once make a "official" hook in your software, so one can add
> something in a predifined way, everyone could write different "plug-ins"
to
> your software, and you would not have to care about poeple whining why
their
> feuture does not get implementet. They would just have to install the
> plugin-module, and perhaps add a line in a config-file, which library to
> load. And for each library, a special entry in the on-screen menu could
> appear or something like this.
>
> Then, there would be a mplayer plugin, a mp3 plugin, a divx-encode plugin,
a
> switch-on-your-toaster plugin or whatever. Ok, a "different-skins" plugin
> would perhaps not work, because it would have to touch core components,
but
> you cant have everything ;-)
>
> In the end this would save your time !
> If yoy think this is nonsense, bad luck :-|
>
> > -----Ursprungliche Nachricht-----
> > Von: kls@cadsoft.de [mailto:kls@cadsoft.de]Im Auftrag von Klaus
> > Schmidinger
> > Gesendet: Sonntag, 14. Oktober 2001 12:14
> > An: vdr@linuxtv.org
> > Betreff: [vdr] A basic statement about VDR (was: AW: Re: MPlayer <->
> > VDR, first try)
> >
> >
> > Marc Stauff wrote:
> > >
> > > Is there a Linux-Tool you can use to do one-click divx-encoding
> > ? It would
> > > be great if you could choose a vdr-recoring (or a DVD !!!) with the
> > > remote-control, and then a low-priority thread should be started that
> > > automaticaly converts it to DivX. And all DivX-Movies should be
playable
> > > from a seperate menu, too. That would be really great !!
> > >
> > > I do not think that such stuff is a great problem.
> > > Vdr should habe a common Api, with wich you can link enhancements
(like
> > > Mplayer, and all the others) to it, and that does not change with
every
> > > version. Then you would not have to start from the beginning
> > with every new
> > > version, and soon Vdr would be able to do really everything
> > from mp3 to dvd
> > > for everybody, not only the people who have the time to hack it
> > in it again
> > > and again !
> >
> > Well, I guess it's about time I issue a basic statement about this.
> > When I started developing VDR, I did this because I wanted to have a
> > digital sat receiver and video recorder, which at the time was
> > not available
> > in stores the way I wanted it to be. When the Siemens DVB card
> > came out and
> > convergence published their Linux DVB driver, I happily started
> > coding VDR.
> > Soon I realized that this might be useful for others, too. So I
> > went public
> > and apparently many people shared the idea of having such a device.
> >
> > Meanwhile there have been several contributions which I have
"officially"
> > adopted (because they directly fit into the original idea of having a
> > digital sat receiver and video recorder - and yes, also because I myself
> > found them (mostly) useful). I am well aware that there are other
patches
> > out there which are still awaiting to make their way into the "official"
> > source, but those are things that I myself don't use or need, and
> > therefore
> > I am currently not spending time adopting them (it's not just
> > "applying the
> > patch" - there's a lot more to it! Sometimes patches just "wildly" hack
> > things into the original source in order to implement a specific
function,
> > which could be done a lot more "elegant", or which just don't fit into
the
> > "big picture"). Ok, call me "selfish" if you like, but you should keep
in
> > mind that for me VDR is a "hobby project", in which I can only invest
the
> > little free time I have. And since the intended functionality of
> > sat receiving
> > and recording is already working pretty good, I tend to do other
> > things on weekends
> > now ;-)
> >
> > Currently I'm really considering very carefully whether to release a new
> > version of VDR, because the next thing that happens is usually a flood
of
> > messages asking "Why hasn't this patch been adopted?" or "When will that
> > patch finally make its way in?" or (the worst of all) "Why haven't _YOU_
> > implemented this important function yet, which _I_ need so much?".
> >
> > And then there are the never ending requests that "VDR should integrate
> > this other program" or "VDR should be integrated into that other
program".
> > VDR _is_ VDR!! If you want another program, take another one! Or modify
> > VDR in any way you like - it's open source and FREE!
> >
> > I hope I haven't offended anybody with this message - if so,
> > please forgive me,
> > that was not what I intended. I just wanted to point out what VDR
> > is to me,
> > and why it takes longer for some patches to be "officially" adopted.
> > A patch that implements a nice feature that makes great sense for
> > the basic
> > use as a digital sat receiver and video recorder (or DVD player, for
that
> > matter) and touches only very few places in the source code just has a
lot
> > better chance of being adopted than a patch that is widely spread
> > over the entire
> > source and implements some special feature that goes beyond the
> > original idea
> > (like playing MP3 - sometimes I get the feeling that people think
*EVERY*
> > piece of software must be able to play MP3s, heck, even every
> > appliance, like
> > toasters or fridges, should be able to do that). And, last but
> > not least, I always
> > try to "keep it simple". Fancy stuff like "skins" or the like
> > have priorities
> > next to zero.
> >
> > Don't get me wrong, I'm not saying that I will never adopt
> > patches like the MP3
> > patch! It's just that their priority to _me_ is rather low, and
> > therefore I take
> > the liberty to decide to spend _my_ time on other things. Of
> > course I will, as
> > I further develop VDR, always keep in mind to make it more and
> > more flexible
> > and easier to implement new features. But that's a gradual
> > process that takes time.
> > Until then I can't help it, but those who want to have a special
> > feature that is
> > currently only available as a patch will have to apply that patch
> > on every new
> > release of VDR (since they won't come out as often as during the
> > past few months
> > now, this shouldn't be too much work ;-).
> >
> > I truly hope that this message doesn't start an endless thread...
> >
> > Klaus
> > --
> > _______________________________________________________________
> >
> > Klaus Schmidinger                       Phone: +49-8635-6989-10
> > CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
> > Hofmark 2                               Email:   kls@cadsoft.de
> > D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
> > _______________________________________________________________
> >
> >
>
>
>
>




Home | Main Index | Thread Index