[vlc-devel] VLC.framework Changes/Modifications
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:
> 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];
> > 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
> 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];
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel