[vlc-devel] VLC.framework Changes/Modifications
pdherbemont at free.fr
Sun Oct 7 12:09:36 CEST 2007
First, thanks for your work, it's greatly appreciated.
On Oct 7, 2007, at 2:25 AM, Enrique Osuna wrote:
> I've made some modifications and changes to your VLC.framework. Some
> are apparent and not so apparent. One of the first things I did was
> build out the VLC.framework using an Xcode project versus a Makefile.
> No big advantage, except it was easier for debugging and modifying the
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.
> The second thing I did was make the framework use relative
> paths vs. absolute paths. I spent a few days trying to get the
> framework to work because it kept pointing to libraries in nonexistent
For this one, I have previously hit an ld bug: ld doesn't recognize
@loader_path properly. But if you managed, then cool!
> As far as the actually source code, I ended up moving things around
> and tried to organize things as logically as possible. The
> VLCMediaControl class tries to model the MediaControl API as much as
> possible, but I know there were a few area that I failed.
A diff would have been appreciated to easily see the changes.
So far I have listed:
At first it seemed to be the missing class in Model-View-Control
to me for the Media object.
Now, I understand that this is kind of a media_list_player. However
it is still confuse in my mind.
- VLCAudio: Nice. We need to add support in libvlc for per-
media_instance sounds controlling.
I understand that this object is the close to the media_instance_t.
To me it should be merged with MediaControl.
libvlc_media_instance_stop should be implemented in core.
This is basically the media_list. This is a nice renaming of the
VLCPlaylist. But then we don't need VLCPlaylist, do we?
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.
About raising a terminal log, with the exception, it is not ok.
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 am not sure we really want to implement the Framework as a direct
bindings on libvlc. We may not need all this classes. So the question
is, do we need all this classes?
I would suggest you to send (small) patches with your modification.
More information about the vlc-devel