<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On Oct 7, 2007, at 2:39 PM, Enrique Osuna wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">I did neglect to modify the Makefile for this build.  I'll be sure to update it.<BR class="khtml-block-placeholder"></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Not really needed if we go Xcode... I'll appriciate though.</DIV><DIV><BR><BLOCKQUOTE type="cite">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.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Ok. I don't really like the fact of being able to do the same thing using a different API. What about some shortcut in existing classes?</DIV><BR><BLOCKQUOTE type="cite">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. <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I was a bit lost with the MediaControl thing.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Tell me if I am wrong?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Model is VLCMedia</DIV><DIV>View is VLCVideoView</DIV><DIV>Control is VLCMediaPlayer</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In libvlc we do have:</DIV><DIV>Model libvlc_media_t</DIV><DIV>View libvlc_drawable_t</DIV><DIV>Control libvlc_media_instance_t</DIV><BR><BLOCKQUOTE type="cite">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.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>True enough. Isn't</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>[aMediaPlayer initWithMedia: aMedia];</DIV><DIV>[aMediaPlayer setVideoView: aVideoView];</DIV><DIV>[aMediaPlayer play];</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Simple enough?</DIV><BR><BLOCKQUOTE type="cite">> libvlc_media_instance_stop should be implemented in core. <BR><BR>It should but what would it do?  Other than pausing the playback and setting it's state to STOPPED.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>it should STOP the input (close the vout and such...), not pause... Not a big deal though.</DIV><BR><BLOCKQUOTE type="cite">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></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I like MediaList better too.</DIV><BR><BLOCKQUOTE type="cite"><BR>> -VLCLibrary<BR>> There have been some addition to the class that seems to me <BR>> inappropriate: We don't really want to keep one playlist object tied<BR>> to the VLCLibrary.<BR><BR>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></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yeah, I would like to depreciate that playlist singleton in libvlc and core.</DIV><BR><BLOCKQUOTE type="cite">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></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The notification seem fine to me. We could also have some kind of delegate method for the VLCLibrary object...</DIV><BR><BLOCKQUOTE type="cite">> 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.  <BR><BR>We can get rid of things like VLCPlaylist.  I think the core implementation, such as Library, MediaList, MediaInstance and MediaDescriptors are a definite.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Ok. I got your point. I was a bit septical about introducing too much complexity in the framework, but it seems to work fine. Yet we now need the VLCMediaListPlayer class.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>VLCMediaListPlayer would be a subclass of the VLCMediaPlayer;</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>[aMediaListPlayer initWithMediaList: aMediaList];</DIV><DIV>[aMediaListPlayer setVideoView: aVideoView];</DIV><DIV>[aMediaPlayer play];</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite">> 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<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I missed that one... Headers/VLC/*.h are the exported headers. Header in Headers/*.h are the private one. So I think this one is not valid.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Pierre.</DIV><BR></DIV><BR></BODY></HTML>