Hi, On 8/24/05, Nicolas Plourde <nicolas.plourde@gmail.com> wrote:

On 23-Aug-05, at 8:53 PM, Micah Gideon Modell wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Has the MPlayer OS X project been merged back in with this one? It appears that the works available on this site are more recent than those on the MPlayer OS X site and everyone I've heard from there seems to think the project there is dead. I'd like to add AppleScript support to the application, but I'd rather like to do it on a currently active variant of the project.

Thanks for all your help!

Yes the project at mplayerhq is more recent and is merging eith the project at sourceforge. You can get the latest source from cvs;

cvs -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer login cvs -z3 -d:pserver:anonymous@mplayerhq.hu:/cvsroot/mplayer co -P mplayerosx

to build the project you will need to setup something like this;

/mplayer (source dir) /mplayer/main (mplayer cvs source) /mplayer/main_noaltivec (mplayer cvs source configured with --disable- altivec) /mplayer/mplayerosx (mplayerosx cvs source)

configure and build mplayer in main and main_noaltivec go to the mplayerosx dir and do make or make dist to create a .dmg of mplayerosx you can also use the xcode 2.1 project the old one is not working.

From your explanations, it seems mplayerosx is pretty much a wrapper around vanilla mplayer, so maybe mplayerosx will live like this for

Wouldn't this be worth being put on the XML doc, or do you plan to nuke mplayerosx in a short time? (when all the code is properly merged into mplayer) the whole foreseeable future. Guillaume -- Live fast, die old, and make very sure everyone knows you were there. -- Alan Cox

On Thursday 25 August 2005 00:19, Nicolas Plourde wrote:

Unless someone came up with a unified interface for all platform supported by mplayer. I dont think its a good idea to add osx specific ui code inside mplayer it would be better to extend the slave mode.

I totally agree. I'll send a bottle of coke (for enjoyment offcourse :) ) to the person who dares to completely remove the GUI code from MPlayer. Then we could either adopt an existing front-end as the official gui, or write a new one ourself from scratch or based on the current GTK+ code. If there's stuff that can be done with the current gui and is impossible through slave mode, it should be made possible :) I would vote for a GUI front-end from scratch with a toolkit that's as multiplatform as possible. Maybe wxWindows. That would give us a unified GUI for Linux, Windows, Mac OS, *BSD, Solaris, Irix, etc... with the same codebase. Hmm, maybe we should reverse the order. First write a decent official GUI front-end that can compete with the current intertwined GUI code and then ditch the gtk+ code :-) --Ivo

On Thursday 25 August 2005 03:11, Luca Barbato wrote:

Ivo wrote:

...

Hmm, maybe we should reverse the order. First write a decent official GUI front-end that can compete with the current intertwined GUI code and then ditch the gtk+ code :-)

wxWidgets is a btw the worst UI toolkit coding and support wise:

C++ mfclike APIs quite a pain about libs (on X11 you have gtk gtk2 and unicode that got mapped in different libs and are a _bit_ painful to get)

Argh, I though wxWindows was clean C. I was probably thinking of another toolkit. No C++ for me. Should have checked the website myself before posting and not rely on (wrong) memory.

I'll be involved in exams till the end of september so I could do anything on my own to support my idea of using efl (evas+ecore alone or the full ewl).

How cross-platform is that? I suppose it's X11 only? --Ivo

On 24-Aug-05, at 9:30 PM, Ivo wrote:

On Thursday 25 August 2005 03:18, Ivo wrote:

...

I was probably thinking of another toolkit.

I was, although I'm not that sure anymore if I'll vote for that as the basis of a multi-platform unified GUI.

It was WideStudio I was thinking of. That's a Gui builder and widget set for Windows, Linux, Solaris, Mac OS and FreeBSD. I have no experience with it, other than having compiled a Hello World example on windows and linux with the same code and it worked :) There is a C (read: non-C++) API binding though.

I was not thinking of using a specific UI kit. Maybe more like a layer to plug the gui to mplayer. Think of integrated slave mode. Also Creating a GUI guideline doc to make sure all gui provide the same user experience. ==== Nicolas Plourde <nicolas.plourde@gmail.com>

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nicholas and Ivo, you seem to be most active on this portion of the project: OK, so where might I fit into all of this? I have some ideas of things I'd like to do in the long run, but I don't know the code yet at all. I'd love to help accomplish some task(s) related to the GUI which will help the project (bugs/features/docs) but I need a bit of direction. What would help you most right now? I'd really like to contribute primarily in the form of documented code, but if straight documentation is what you need and it'll help me get familiar - let me know. Just please give me a discreet and manageable task. Cheers! Micah Gideon Modell - - -- http://www.csh.rit.edu/~micah http://www.LiveJournal.com/users/micah_gideon AIM: Micah Modell Get in a good mood. How hard is it just to decide to be in a good mood and then be in a good mood? (Lloyd Dobbler) Thus spake Ivo on Aug 25, 2005, at 11:01 AM:

On Thursday 25 August 2005 03:46, Nicolas Plourde wrote:

...

I was not thinking of using a specific UI kit. Maybe more like a layer to plug the gui to mplayer. Think of integrated slave mode. Also Creating a GUI guideline doc to make sure all gui provide the same user experience.

Yes. In principle, a GUI API layer in MPlayer would be very good and have all platform/toolkit-specific gui's use that API to communicate to MPlayer. But in reality, I fear people won't extend that api-layer if something can't be done (yet), but read/write global variables or do other hacks to get it done easily/fast (but ugly). Not in the beginning, but after a while I think it will start to happen. We could offcourse just don't accept such code, but I think plain slave-mode is easier, because it enforces the gui programmer to use a certain 'api' and extend that api if it does not suffice. If slave mode is properly handled in MPlayer, I don't think it will be much slower, if at all.

--Ivo

_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng I'm interested in trying out a translation into either Korean and/or Hebrew. I'm fluent in neither and I've never done a localisation before, but I'd really like to try it. Basically, don't count on my success, but let me give it a shot if you don't mind.

Cheers! Micah Gideon Modell - -- http://www.csh.rit.edu/~micah http://www.LiveJournal.com/users/micah_gideon AIM: Micah Modell Learning is not compulsory... neither is survival. (W. Edwards Deming) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDDTGzjyQxogoGtswRAmyAAKDyaZYUnjpsTB9gdTaEl534qpFJZACg9fHc SBrBHjw3qLMSLM9m8i45e9E= =Kd08 -----END PGP SIGNATURE-----

Hi, On 8/25/05, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:

Hi, On Thu, Aug 25, 2005 at 11:49:22AM +0900, Micah Gideon Modell wrote:

...

OK, so where might I fit into all of this? I have some ideas of things I'd like to do in the long run, but I don't know the code yet at all. I'd love to help accomplish some task(s) related to the GUI which will help the project (bugs/features/docs) but I need a bit of direction. What would help you most right now? I'd really like to contribute primarily in the form of documented code, but if straight documentation is what you need and it'll help me get familiar - let me know. Just please give me a discreet and manageable task.

I guess it would be very interesting to know what slave mode commands the people who already made GUIs missed/are missing most. The next step would then be implementing them in a clean way. Also the switch-case in mplayer.c that handles the commands probably should be cleaned up a bit, like putting the biggest blocks in seperate functions etc. - preferably even in a seperate file. Though I should warn anyone attempting this: It will be difficult to get into CVS because it is mostly cosmetic and has quite a risk of breaking things.

I can think of at least one command that I tried to implement at some point (but didn't succeed because time schedule issues) was the "online chapter seeking", which means that sending a command like "chapter 5" in slave mode will seek to chapter 5, and a command such as "nextchapter" will seek to next chapter, if it exists, and son long.... Apparently, this would have to be done at demuxer level (like the online audio track switching code), and would have to be done for each container that supports chapters: mkv and mpeg from the top of my head. Too bad we didn't benefit from Google's "summer of code" :-( Guillaume -- Reading doesn't hurt, really! -- Dominik 'Rathann' Mierzejewski

On 24-Aug-05, at 10:49 PM, Micah Gideon Modell wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Nicholas and Ivo, you seem to be most active on this portion of the project:

OK, so where might I fit into all of this? I have some ideas of things I'd like to do in the long run, but I don't know the code yet at all. I'd love to help accomplish some task(s) related to the GUI which will help the project (bugs/features/docs) but I need a bit of direction. What would help you most right now? I'd really like to contribute primarily in the form of documented code, but if straight documentation is what you need and it'll help me get familiar - let me know. Just please give me a discreet and manageable task.

For starter you can try to build the mplayer and mplayerosx source and create a distribution. The mplayerosx portion of the project need to be documented for user and developer. mplayerosx also need testing and feature suggestion. I will try to make available the latest build of mplayer osx available on the web. ==== Nicolas Plourde <nicolas.plourde@gmail.com>

On 25-Aug-05, at 10:26 AM, Micah Gideon Modell wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

OK, I'll work on building the player - which modules will I need for that? I've currently got mplayerosx and that's all. Do I need any others? Additionally, what do you need in a distribution? Is it more than the .app folder?

Look at one of the first post of this thread where i was explaining how to put it together. Building mplayerosx is not trivial for newbie. You will need mplayerosx module, main module and a copy of main module named main_noaltivec mplayerosx is the gui frontend, main is mplayer and main_noaltivec is mplayer build without altivec support. MPlayer_Source directory | |--->main | |--->main_noaltivec | |--->mplayerosx You first need to build main and main_noaltivec. to configure and build the main module you need to export export MACOSX_DEPLOYMENT_TARGET=10.3 and configure ./configure --with-termcaplib=ncurses.5 --disable-gl --disable-x11 make for the g3 build ./configure --with-termcaplib=ncurses.5 --disable-gl --disable-x11 -- disable-altivec (you need to edit config.mak and change the -mcpu and -mtune from 74XX to G3) im not sure if this is really needed make then go to the mplayerosx directory and and type make dist this will create a compressed archive with the binary ready to use. these instruction should be put in some doc Good luck ==== Nicolas Plourde <nicolas.plourde@gmail.com>