[vlc-devel] VLC.framework Changes/Modifications

Pierre d'Herbemont pdherbemont at free.fr
Sun Oct 7 16:29:37 CEST 2007


On Oct 7, 2007, at 2:39 PM, Enrique Osuna wrote:

> I did neglect to modify the Makefile for this build.  I'll be sure  
> to update it.

Not really needed if we go Xcode... I'll appriciate though.

> With VLCMediaControl, I was trying to follow the MediaControlAPI  
> Architecture ( http://wiki.videolan.org/MediaControlAPI ).   
> Although the class implementation doesn't actually use any of the  
> mediacontrol APIs.  It does try to mimic the way it works.

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?

> 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.

I was a bit lost with the MediaControl thing.

Tell me if I am wrong?

Model is VLCMedia
View is VLCVideoView
Control is VLCMediaPlayer

In libvlc we do have:
Model libvlc_media_t
View libvlc_drawable_t
Control libvlc_media_instance_t

> 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. centerstageproject.com)  
> 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.

True enough. Isn't

[aMediaPlayer initWithMedia: aMedia];
[aMediaPlayer setVideoView: aVideoView];
[aMediaPlayer play];

Simple enough?

> > 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.

it should STOP the input (close the vout and such...), not pause...  
Not a big deal though.

> 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.

I like MediaList better too.

>
> > -VLCLibrary
> > 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.

Yeah, I would like to depreciate that playlist singleton in libvlc  
and core.

> 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.

The notification seem fine to me. We could also have some kind of  
delegate method for the VLCLibrary object...

> > do we need all this classes?
>
> 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.

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.

VLCMediaListPlayer would be a subclass of the VLCMediaPlayer;

[aMediaListPlayer initWithMediaList: aMediaList];
[aMediaListPlayer setVideoView: aVideoView];
[aMediaPlayer play];

> > I would suggest you to send (small) patches with your modification.
> I'll work on that this afternoon and resubmit.
>
> 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

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.

Pierre.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20071007/1ef8d538/attachment.html>


More information about the vlc-devel mailing list