[vlc-devel] Re: To OSX developers - Some questions, and my currentstatus
hartman at videolan.org
Thu Mar 11 15:24:32 CET 2004
On 11 mrt 2004, at 13:18, ozone at algorithm.com.au wrote:
> On 11/03/2004, at 9:44 AM, Bob Maguire wrote:
>> A few days ago, I installed subversion and grabbed the latest source
>> VLC and had a go at building it. Monday night I finally got it to
>> after some jiggery-pokery, and have tried tinkering a bit with the
>> OSX gui
>> module. My first goal was to fix the shortcoming of needing the
>> window to have the focus for any of the hotkeys to work beyond just
>> basic ones.
> Hmm, while we're all talking about Mac OS X and the GUI ...
> I've made a pretty significant number of changes to modules/gui/macosx
> as part of an internal project to make a "media browser". It's in the
> middle of development right now, but I've posted a screenshot here:
> <http://www.algorithm.com.au/gallery/screenshots/VLC_Browser>. As you
> can see, it changes the VLC interface quite significantly, to include
> web-browser style back/forward controls, URLs, and hyperlinks into the
> media playing interface. I intend to merge the media browsing
> capability into VLC at some point in the future, but right now the
> changes are far too intrusive to consider for the trunk. I do have
> some contributions I could make to the current Mac OS X interface,
I kinda like it, but it's too much browser, too little player for me
personally. I also don't like to have the video in the controller for
instance. It just doesn't work that well for me with movies. it works
with shorter clips though. i can see that. (Ergo, it should be
optional, which is what VLC is all about in the end).
> 1. In my own tree, I've refactored the modules/gui/macosx
> directory, so now there's one file per class, i.e.
> 23:08 .../gui/macosx % ls *.[cmh]
> AJRInstallClipView.h VLCControllerWindow.m intf.h
> AJRInstallClipView.m VLCGLView.h intf.m
> AJRInstallScrollView.h VLCGLView.m macosx.m
> AJRInstallScrollView.m VLCMain.h misc.h
> MPSlider.h VLCMain.m misc.m
> MPSlider.m VLCQTView.h nskeys_to_vlckeys.h
> MPSliderCell.h VLCQTView.m open.h
> MPSliderCell.m VLCVout.h open.m
> NSTextViewWithLinks.h VLCVout.m output.h
> NSTextViewWithLinks.m VLCWindow.h output.m
> VLBrushedMetalImageView.h VLCWindow.m playlist.h
> VLBrushedMetalImageView.m about.h playlist.m
> VLCApplication.h about.m prefs.h
> VLCApplication.m applescript.h prefs.m
> VLCBrowserController.h applescript.m prefs_widgets.h
> VLCBrowserController.m controls.h prefs_widgets.m
> VLCControllerView.h controls.m vout.h
> VLCControllerView.m info.h vout.m
> VLCControllerWindow.h info.m
> I don't know if this is a good idea and should be considered for
> the main VLC trunk, but it certainly makes code much easier to manage
> for me. However, this may be just because of how I organise my
> workflow; perhaps other Mac OS X developers abhor the
> one-file-per-class concept. What do you guys think?
I don't really see the use for it, i know my way around :), but there
is no big reason why it cannot be done.
Especially now with subversion, we can quite easily 'split' files,
without losing too much information.
However, i'm really against splitting extended UI elements into
separate files, you end up with a woodwork of files. Only the
prefs_widgets for instance contain somewhere around 15 classes. to
start splitting those up would be idiotic. They are all similar and
having them in one file is way easier.
> 2. At the moment, to work on the media browser, I'm keeping two
> directories for the Mac OS X GUI: modules/gui/macosx-browser, and
> modules/gui/macosx-original, and renaming each one to
> modules/gui/macosx as appropriate depending on which one I need to
> develop with. It would be really cool if the build system for Mac OS
> X could somehow be restructured to support generating multiple VLC
> applications, e.g. "VLC.app" and "VLC Browser.app", so that you can
> generate different UIs.
Theoretically possible. Add new macosx targets in the Makefiles.
/Makefile.am has a VLC.app target for instance. This could be copied to
create a VLC Browser.app (BTW be careful with spaces in names, this can
be a bit tricky).
> Of course, I'd be even happier if the browser-style interface could be
> merged into the main VLC trunk at some point, so that we don't need
> this type of build system :), but I think that people who experiment
> with VLC for internal projects who need to customise their GUI
> front-end would really appreciate this. (e.g. a custom UI for
> home-LAN DVD streaming, camera surveillance, etc.)
> I'm happy to do the heavy lifting required for this sort of stuff if
> people want these sorts of changes to happen, by the way.
It's a slamdunk thing. not difficult at all. you just need to know your
way around VLC's buildsystem :)
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>
More information about the vlc-devel