[MPlayer-dev-eng] MPlayer OS X

Micah Gideon Modell micah at csh.rit.edu
Thu Aug 25 04:49:22 CEST 2005


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




More information about the MPlayer-dev-eng mailing list