Compiled 0.2.92 for Mac OS X

[Christophe Massiot]

Dear Stéphane,

At 20:58 +0100 21/01/02, Stéphane Sudre wrote :

>  > I know that the standard for Objective-C is .m. But I couldn't get the vlc
>  > build system to work with ".m" files, so I changed the extension to ".c".
>
>I don't understand since below you're saying you're using pbxbuild.

Once again, vlc is originally a UNIX application, and as such the 
build system is based on standard GNU make. I'm no specialist, but 
AFAIK pbxbuild is only used in the final stage of the build, after 
the vlc binary has been created by GNU make.

You may think it would have been better to use pbxbuild for 
everything, but it is not practical. Things are moving very quickly, 
files are created, files are removed, and having only one centralized 
Makefile to build binaries on all architectures is a lot easier to 
maintain.

BTW, you could have guessed all this by yourself by just looking at 
vlc.app in Makefile.

>  > Well, NSQuickDrawView seems to be meant for cases where you need 
>a QuickDraw
>  > Port (qdport). Since quicktime needs a qdport to draw to, I believe
>  > NSQuickDrawView is the right widget to use. Why the hell should I
>  > reimplement the functionality of NSQuickDrawView if it's already there.
>
>Will check if there's no way to draw into a buffer.

The point isn't to draw RGB pixels into a buffer. I know it's 
feasible, but we don't want that. What we want to use is the 
"overlay" feature of the video board (ie. hardware YUV conversion and 
scaling), and the only way we have found (in the _very_ poor Apple 
documentation) to do it is to use QuickTime. It isn't easy to work 
with such a bad API documentation, and I'm grateful to Florian for 
digging up this information.

The YUV-thing is _very_ important for us, and if you know of a way to 
do it without using QuickTime, your help would be much appreciated.

>This is a very surprising because a lazy extern developer (like me) is
>certainly going to compile the player with PB and the .pbproj "file".

Then we'd probably need to write it down to an as-yet-unwritten 
README.MacOSX. BTW we would welcome such a contribution. We would 
also welcome a gdb backtrace ; since you're saying vlc keeps 
crashing, it shouldn't be hard to get one.

MacOS X isn't our primary platform of development, and that explains 
why vlc-X isn't as stable and well-written as its Linux counterpart 
(if someone wants to give me a PB G4, it may change :-)). Florian and 
Eugenio are running out of time, so we definitely need external 
contributions, but you don't appear to be willing to help on this. 
Just the facts, as you say, so far your contribution has only 
resulted in a flame war with Florian ("my coding standards are better 
than yours", or something like that), and I can't see any 
constructive suggestion helping either to document vlc, or to debug 
it.

I do not know what your intentions are, what you intend to do with 
vlc (I don't reckon you've said it somewhere). We are definitely not 
interested in flame wars. Yet, if your goal is to help improve the 
project in a non-controversial, non-arrogant, non-judgemental way, 
your contributions will be more than welcome.

It's up to you to tell us what you want to do.

Greetings,


-- 
Christophe Massiot.

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html