Discussion about Zinf audio player development

Tim Lesher | 1 Oct 14:49

Re: upcoming changes

On Mon, Sep 30, 2002 at 07:39:40PM -0400, Ed Sweetman wrote:
> "write a port" means there is no windows port or build until one is 
> written.

I'm very much interested in keeping zinf working under win32.  Given
the state of upcoming changes, does it make more sense to try to keep
win32 working, or should I wait until the new codebase stabilizes?

--

-- 
Tim Lesher <tim <at> lesher.ws>
http://www.lesher.ws

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Ed Sweetman | 1 Oct 18:09

Re: upcoming changes

Tim Lesher wrote:
> On Mon, Sep 30, 2002 at 07:39:40PM -0400, Ed Sweetman wrote:
> 
>>"write a port" means there is no windows port or build until one is 
>>written.
> 
> 
> I'm very much interested in keeping zinf working under win32.  Given
> the state of upcoming changes, does it make more sense to try to keep
> win32 working, or should I wait until the new codebase stabilizes?
> 
well all the interfaces are going to be cleaned up ...things are going 
to be modularized.  And i dont care how hard it's going to be.  Nothing 
is going to be global at all. If you dont want to wait until the code 
base stabilizes you have to at leas wait until we're done ripping out 
the current win32 code.

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Tim Lesher | 1 Oct 18:39

Re: upcoming changes

On Tue, Oct 01, 2002 at 12:09:47PM -0400, Ed Sweetman wrote:
> is going to be global at all. If you dont want to wait until the code 
> base stabilizes you have to at leas wait until we're done ripping out 
> the current win32 code.

Will do.  I'll watch this space for more info.

I agree that what you're doing is a good idea, by the way.  If you're
still amenable to keeping a win32 port alive, I'll do that work.

--

-- 
Tim Lesher <tim <at> lesher.ws>
http://www.lesher.ws

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Ed Sweetman | 1 Oct 19:01

Re: upcoming changes

Tim Lesher wrote:
> On Tue, Oct 01, 2002 at 12:09:47PM -0400, Ed Sweetman wrote:
> 
>>is going to be global at all. If you dont want to wait until the code 
>>base stabilizes you have to at leas wait until we're done ripping out 
>>the current win32 code.
> 
> 
> Will do.  I'll watch this space for more info.
> 
> I agree that what you're doing is a good idea, by the way.  If you're
> still amenable to keeping a win32 port alive, I'll do that work.
> 

alive?  you'd have to give birth to it.  The old code is not being kept.

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Ian Williamson | 2 Oct 02:56

Picon

RE: upcoming changes

> Tim Lesher wrote:
> > On Tue, Oct 01, 2002 at 12:09:47PM -0400, Ed Sweetman wrote:
> >
> >>is going to be global at all. If you dont want to wait until the code
> >>base stabilizes you have to at leas wait until we're done ripping out
> >>the current win32 code.
> >
> >
> > Will do.  I'll watch this space for more info.
> >
> > I agree that what you're doing is a good idea, by the way.  If you're
> > still amenable to keeping a win32 port alive, I'll do that work.
> >
>
> alive?  you'd have to give birth to it.  The old code is not being kept.

I have to say I'm pretty disappointed you punted the Win32 stuff.  Not my
decision to make though.

The reason I helped out at all was to get a decent, common player for Win32
and Unix.  I understand that the project always was Unix based, but it seems
to me you've thrown away a fair amount of support and help.

Sorry to say I won't be helping any more.  Good luck.

IanW

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server

(Continue reading)

Ed Sweetman | 2 Oct 03:10

Re: upcoming changes

Ian Williamson wrote:
>>Tim Lesher wrote:
>>
>>>On Tue, Oct 01, 2002 at 12:09:47PM -0400, Ed Sweetman wrote:
>>>
>>>
>>>>is going to be global at all. If you dont want to wait until the code
>>>>base stabilizes you have to at leas wait until we're done ripping out
>>>>the current win32 code.
>>>
>>>
>>>Will do.  I'll watch this space for more info.
>>>
>>>I agree that what you're doing is a good idea, by the way.  If you're
>>>still amenable to keeping a win32 port alive, I'll do that work.
>>>
>>
>>alive?  you'd have to give birth to it.  The old code is not being kept.
> 
> 
> I have to say I'm pretty disappointed you punted the Win32 stuff.  Not my
> decision to make though.
> 
> The reason I helped out at all was to get a decent, common player for Win32
> and Unix.  I understand that the project always was Unix based, but it seems
> to me you've thrown away a fair amount of support and help.
> 
> Sorry to say I won't be helping any more.  Good luck.
> 
> IanW

(Continue reading)

Ian Williamson | 2 Oct 04:10

Picon

RE: upcoming changes

> not that you aren't appreciated, you are,  but there was very little
> programming interest coming from the win32 side and FAR more bugs coming
> from it...

No hard feelings  :)
I understand your justification and that's your decision to make.  It just
seemed to me a little harsh.  Like cutting off one leg because it hurts, you
lost a potentially large user base that you will never (likely) get back.

I don't have the time or will to do a full port to win32, so there really is
little I can do.

All the best!  Really.

IanW

-------------------------------------------------------
This sf.net email is sponsored by: DEDICATED SERVERS only $89!
Linux or FreeBSD, FREE setup, FAST network. Get your own server 
today at http://www.ServePath.com/indexfm.htm

Kristian G. Kvilekval | 3 Oct 21:42

Picon

RE: upcoming changes

I, too, feel uneasy about throwing away the win32 port.

Could someone summarize the current problems/state of the win32 code and
why it needed to be ripped out?    Since I am not building on win32,
I probably would not see how my mods would break that port anyway.

If incoming changes just broke the win32 code at least some
new maintainer would know where to start.   This seems to be less
work than saying "any new win32 work *must* be from scratch".

On the other hand, I recently asked if anybody had any experience
using the gdk-win32.   Might this be a way to keep the win32 port
working while the *nix development continued?

On other fronts, I agree fully to remove any C anachronisms from the 
C++ code.  In places, the memory management is a complete mess.
Haphazard use of STL, and standard classes (string in particular).
Some of these were probably caused by buggy win32 implementation of STL,
but from I have read elsewhere even win32 has a compliant STL and core
classes.

Secondly, I am interested in getting this to work with gtk 2/gnome2

Probably, alot of small/big problems and  would melt away with
this (truetype, i18n, etc).
In this direction, I have played around using glade
http://glade.gnome.org/    to at least throw
together the properties, playlist, and some dialogs.  I have used it
before and it really speeds up interface development.
I think we would also benefit from the separation of layout and

(Continue reading)

Ed Sweetman | 3 Oct 22:17

Re: upcoming changes

Kristian G. Kvilekval wrote:
> I, too, feel uneasy about throwing away the win32 port.
> 
> Could someone summarize the current problems/state of the win32 code and
> why it needed to be ripped out?    Since I am not building on win32,
> I probably would not see how my mods would break that port anyway.

complete reproduction of code (basically the win32 port is almost an 
entirely separate player)

Buggy use of that code to the point where it crashes on load, undefined 
symbols, randomly decides to never work again and stuff due to how 
windows dlls work and basically the player cant be implimented the same 
way as it is in unix so we have workarounds

uses VC which is hardly a free compiler.

Most of these bugs and problems maintaining the win32 is due to how it's 
implemented.  So we removed it. That way it can  be implemented correctly.

> If incoming changes just broke the win32 code at least some
> new maintainer would know where to start.   This seems to be less
> work than saying "any new win32 work *must* be from scratch".

It's not about being scared of breaking the win32 port.  The win32 port 
is already broken. Horribly.

> On the other hand, I recently asked if anybody had any experience
> using the gdk-win32.   Might this be a way to keep the win32 port
> working while the *nix development continued?

(Continue reading)

Kristian G. Kvilekval | 3 Oct 22:49

Picon

Re: upcoming changes

On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
> 
> complete reproduction of code (basically the win32 port is almost an 
> entirely separate player)
> 
> Buggy use of that code to the point where it crashes on load, undefined 
> symbols, randomly decides to never work again and stuff due to how 
> windows dlls work and basically the player cant be implimented the same 
> way as it is in unix so we have workarounds
> 
> uses VC which is hardly a free compiler.
> 
> 
> Most of these bugs and problems maintaining the win32 is due to how it's 
> implemented.  So we removed it. That way it can  be implemented correctly.

Probably all true, but killing a piece of code that other would 
like to try to maintain tends to drive away developers.
The project doesn't have that many active developers as it is.
Let's all pull in the same direction.

> >On the other hand, I recently asked if anybody had any experience
> >using the gdk-win32.   Might this be a way to keep the win32 port
> >working while the *nix development continued?
> 
> Yes, it could be.  But you'd have to rewrite it all anyway.
> 

Mostly just the threading stuff which is cross-platform already.

(Continue reading)

Ed Sweetman | 4 Oct 00:01

Re: upcoming changes

Kristian G. Kvilekval wrote:
> On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
> 
>>complete reproduction of code (basically the win32 port is almost an 
>>entirely separate player)
>>
>>Buggy use of that code to the point where it crashes on load, undefined 
>>symbols, randomly decides to never work again and stuff due to how 
>>windows dlls work and basically the player cant be implimented the same 
>>way as it is in unix so we have workarounds
>>
>>uses VC which is hardly a free compiler.
>>
>>
>>Most of these bugs and problems maintaining the win32 is due to how it's 
>>implemented.  So we removed it. That way it can  be implemented correctly.
> 
> 
> Probably all true, but killing a piece of code that other would 
> like to try to maintain tends to drive away developers.
> The project doesn't have that many active developers as it is.
> Let's all pull in the same direction.
> 
> 
>>>On the other hand, I recently asked if anybody had any experience
>>>using the gdk-win32.   Might this be a way to keep the win32 port
>>>working while the *nix development continued?
>>
>>Yes, it could be.  But you'd have to rewrite it all anyway.
>>

(Continue reading)

Kristian G. Kvilekval | 4 Oct 01:01

Picon

Re: upcoming changes

On Thu, 2002-10-03 at 15:01, Ed Sweetman wrote:

   <snipped>

> 
> I have over 150 processes open 24/7.  None use libglade. that includes 
> mozilla. increasing the dependencies on external software is bloat. The 
> tradeoff of outloading bloat is that you get a more elegent project by 
> depending on someone elses. I dont think it's worth depending on glade 
> to do the gui compared to just doing it by hand.
> 
> 
> > 
> >>2. Glade code is not fun to work with.  It also wouldn't look the same 
> >>as the rest of the code as it would be generated by a program. 
> >>Maintaining such code gets to be very annoying.
> >>
> > 
> > Agreed, but I was suggesting using libglade from the getgo.   It
> > really works well for me.
> 
> except i'm not going to be held back from maintaining code because the 
> program that wrote it is not working correctly or a version has features 
> mine doesn't so it doesn't understand it or there are bugs in so and so 
> version so the code it produced is bad too.
> 

Both star office and evolution use libglade.  I don't think it's going
away anytime soon.  In fact, if it had been used before it would
be a no brainer to get to gtk2 today.

(Continue reading)

Ed Sweetman | 4 Oct 01:17

Re: upcoming changes

Kristian G. Kvilekval wrote:
> On Thu, 2002-10-03 at 15:01, Ed Sweetman wrote:
> 
>    <snipped>
> 
>>I have over 150 processes open 24/7.  None use libglade. that includes 
>>mozilla. increasing the dependencies on external software is bloat. The 
>>tradeoff of outloading bloat is that you get a more elegent project by 
>>depending on someone elses. I dont think it's worth depending on glade 
>>to do the gui compared to just doing it by hand.
>>
>>
>>
>>>>2. Glade code is not fun to work with.  It also wouldn't look the same 
>>>>as the rest of the code as it would be generated by a program. 
>>>>Maintaining such code gets to be very annoying.
>>>>
>>>
>>>Agreed, but I was suggesting using libglade from the getgo.   It
>>>really works well for me.
>>
>>except i'm not going to be held back from maintaining code because the 
>>program that wrote it is not working correctly or a version has features 
>>mine doesn't so it doesn't understand it or there are bugs in so and so 
>>version so the code it produced is bad too.
>>
> 
> 
> Both star office and evolution use libglade.  I don't think it's going
> away anytime soon.  In fact, if it had been used before it would

(Continue reading)

Andreas Rottmann | 3 Oct 23:08

Picon

Picon

Re: upcoming changes

"Kristian G. Kvilekval" <kris <at> cs.ucsb.edu> writes:

> On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
> > 
> > > Finally, alsaplayer has some really nice plugins, works well 
> > > with alsa 0.9x, and has other cool features.  Might want to take
> > > a look if you are planing on redoing some internal interfaces
> > > of zinf.   
> > 
> > Plugins are not one of the features we plan on adding.  Zinf is an audio 
> > player.  That is all it plans on being.  We're not changing how zinf 
> > works yet.  We're specifying how zinf should work and fixing the code so 
> > that it does work that way. As for looking at alsaplayer's code.  Where 
> > do you think the cooperative software volume mixer came from?
> > 
> 
ZINF in fact already has plugins. I'd suggest (yes, this is a
shameless self-plug) the use of a plugin managment library,
however. My own Yehia framework provides exactly this, and moreover,
if you want it, also scripting abilities (currently python, soon
python and guile scheme). Visit http://ucxx.sourceforge.net for more
information.

Regards, Andy
--

-- 
Andreas Rottmann         | Dru <at> ICQ        | 118634484 <at> ICQ | a.rottmann <at> gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

-------------------------------------------------------

(Continue reading)

Ed Sweetman | 3 Oct 23:47

Re: upcoming changes

Andreas Rottmann wrote:
> "Kristian G. Kvilekval" <kris <at> cs.ucsb.edu> writes:
> 
> 
>>On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
>>
>>>>Finally, alsaplayer has some really nice plugins, works well 
>>>>with alsa 0.9x, and has other cool features.  Might want to take
>>>>a look if you are planing on redoing some internal interfaces
>>>>of zinf.   
>>>
>>>Plugins are not one of the features we plan on adding.  Zinf is an audio 
>>>player.  That is all it plans on being.  We're not changing how zinf 
>>>works yet.  We're specifying how zinf should work and fixing the code so 
>>>that it does work that way. As for looking at alsaplayer's code.  Where 
>>>do you think the cooperative software volume mixer came from?
>>>
>>
> ZINF in fact already has plugins. I'd suggest (yes, this is a
> shameless self-plug) the use of a plugin managment library,
> however. My own Yehia framework provides exactly this, and moreover,
> if you want it, also scripting abilities (currently python, soon
> python and guile scheme). Visit http://ucxx.sourceforge.net for more
> information.
> 
> Regards, Andy

you  mistaken plugins that are functional to eyecandy plugins. Multiple 
plugins of any of the kind that are currently plugins cannot be loaded. 
  Loading one will unload the other.  No management is necessary.

(Continue reading)

Andreas Rottmann | 4 Oct 11:27

Picon

Picon

Re: upcoming changes

Ed Sweetman <ed.sweetman <at> wmich.edu> writes:

> Andreas Rottmann wrote:
> > "Kristian G. Kvilekval" <kris <at> cs.ucsb.edu> writes:
> >
> >>On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
> >>
> >>>> Finally, alsaplayer has some really nice plugins, works well with
> >>>> alsa 0.9x, and has other cool features.  Might want to take
> >>>>a look if you are planing on redoing some internal interfaces
> >>>> of zinf.
> >>>
> >>> Plugins are not one of the features we plan on adding.  Zinf is an
> >>> audio player.  That is all it plans on being.  We're not changing
> >>> how zinf works yet.  We're specifying how zinf should work and
> >>> fixing the code so that it does work that way. As for looking at
> >>> alsaplayer's code.  Where do you think the cooperative software
> >>> volume mixer came from?
> >>>
> >>
> > ZINF in fact already has plugins. I'd suggest (yes, this is a
> > shameless self-plug) the use of a plugin managment library,
> > however. My own Yehia framework provides exactly this, and moreover,
> > if you want it, also scripting abilities (currently python, soon
> > python and guile scheme). Visit http://ucxx.sourceforge.net for more
> > information.
> > Regards, Andy
> 
> 
> you  mistaken plugins that are functional to eyecandy

(Continue reading)

Ed Sweetman | 4 Oct 18:32

Re: upcoming changes

Andreas Rottmann wrote:
> Ed Sweetman <ed.sweetman <at> wmich.edu> writes:
> 
> 
>>Andreas Rottmann wrote:
>>
>>>"Kristian G. Kvilekval" <kris <at> cs.ucsb.edu> writes:
>>>
>>>
>>>>On Thu, 2002-10-03 at 13:17, Ed Sweetman wrote:
>>>>
>>>>
>>>>>>Finally, alsaplayer has some really nice plugins, works well with
>>>>>>alsa 0.9x, and has other cool features.  Might want to take
>>>>>>a look if you are planing on redoing some internal interfaces
>>>>>>of zinf.
>>>>>
>>>>>Plugins are not one of the features we plan on adding.  Zinf is an
>>>>>audio player.  That is all it plans on being.  We're not changing
>>>>>how zinf works yet.  We're specifying how zinf should work and
>>>>>fixing the code so that it does work that way. As for looking at
>>>>>alsaplayer's code.  Where do you think the cooperative software
>>>>>volume mixer came from?
>>>>>
>>>>
>>>ZINF in fact already has plugins. I'd suggest (yes, this is a
>>>shameless self-plug) the use of a plugin managment library,
>>>however. My own Yehia framework provides exactly this, and moreover,
>>>if you want it, also scripting abilities (currently python, soon
>>>python and guile scheme). Visit http://ucxx.sourceforge.net for more

(Continue reading)

Return

Return to gmane.comp.audio.zinf.devel.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane