> > I've made some modifications and changes to your VLC.framework.  Some<br>> > are apparent and not so apparent.  One of the first things I did was<br>> > build out the VLC.framework using an Xcode project versus a Makefile.

> > No big advantage, except it was easier for debugging and modifying the > > framework. >  > That's a choice... ;) We could go all Xcode if it is really wanted. > As I think I would be the only one to complain, patch are welcomed.

I did neglect to modify the Makefile for this build.  I'll be sure to update it. > A diff would have been appreciated to easily see the changes. Will provide one after I make a few modifications based on your comments.

<br><br>> So far I have listed:<br>> - VLCMediaControl:<br>>      At first it seemed to be the missing class in Model-View-Control<br>> to me for the Media object.<br>> Now, I understand that this is kind of a media_list_player. However

<br>> it is still confuse in my mind.<br><br>With VLCMediaControl, I was trying to follow the MediaControlAPI Architecture (<a href="http://wiki.videolan.org/MediaControlAPI" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://wiki.videolan.org/MediaControlAPI</a>

).  Although the class implementation doesn't actually use any of the mediacontrol APIs.  It does try to mimic the way it works. Your comment about MVC, I'm not sure if I quite understand.  I thought I was implementing the class in an MVC fashion, can you point out a clearer example so that it may help me out.

> - VLCAudio: Nice. We need to add support in libvlc for per- > media_instance sounds controlling. >  > - VLCMediaPlayer: > I understand that this object is the close to the media_instance_t.

<br>> To me it should be merged with MediaControl.<br><br>My initial thoughts were to do that, however, I wanted to create a mechanism that allowed for other programmers to use this framework and use the VLCMediaPlayer instance for playback strictly.  I know there are a few projects out there (

e.g. <a href="http://centerstageproject.com">centerstageproject.com</a>) that have their own playlist manager if you will and would want to use VLC just as a playback engine versus a playlist manipulation one. > libvlc_media_instance_stop should be implemented in core.

It should but what would it do?  Other than pausing the playback and setting it's state to STOPPED. > - VLCMediaList: > This is basically the media_list. This is a nice renaming of the > VLCPlaylist. But then we don't need VLCPlaylist, do we?

I really don't think we need VLCPlaylist I just put it there so that there were one-to-one class bindings from libvlc to VLC.framework.  Based on your comment below, we can easily get rid of this class.  This VLCMediaList can be renamed to VLCPlaylist -- although I think MediaList is more appropriate.

<br><br>> -VLCLibrary<br>> There have been some addition to the class that seems to me

> inappropriate: We don't really want to keep one playlist object tied > to the VLCLibrary. Once we get rid of VLCPlaylist object we don't need this one playlist singleton.  I included it to follow the core's way of handling playlists.  The core has one playlist singleton for every libvlc instance.

<br><br>> About raising a terminal log, with the exception, it is not ok.<br>> Either we handle it or ignore it of appropriate instead of

> quit_on_exception. I really prefer a dialog box for the user, so that > he can understand that something went wrong, and can report to us. I do agree with handling errors, however, there needs to be a better way of reporting those errors up.  quit_on_exception just kills the application.  We should at least let the framework report back to the main application that there was an error and let the main application handle the error as most appropriate.  Maybe creating a Notification based off on NSError?  Or generating an Exception for the main application to catch and handle.  Although, I've read some where (can't remember where exactly) on Apple's website that mentioned that Exceptions shouldn't be used as internal error handling.

<br><br>> I am not sure we really want to implement the Framework as a direct

<br>> bindings on libvlc. We may not need all this classes. So the question<br>> is, do we need all this classes?<br><br>No, I don't think we need all the classes.  However, I wanted to try to stay true to your original implementation.  

We can get rid of things like VLCPlaylist.  I think the core implementation, such as Library, MediaList, MediaInstance and MediaDescriptors are a definite. > I would suggest you to send (small) patches with your modification.

<br>I'll work on that this afternoon and resubmit.<br><br>One of the major changes that I did make was a structural change to how the headers are stored in the framework.  Instead of VLC.framework/Headers/VLC/VLC*.h  it's 

VLC.framework/Headers/VLC*.h > Thanks!

<br><br>Thanks for the feedback and getting the framework started. 