Hello,
So, I've been off this list for quite a while, now.
Grepping the archive, I see I was addressed once or twice and never
responded. So:
Diego:
> I have two suggestions, though.
> 1) Could you add an option like "open fullscreen" to the context menu?
> I think this would be a nice goodie.
I'll add it to my list. The next time I release a (beta) package, then
this will be there.
> 2) Could you compile the package with --with-codecsdir=codecs and add a
> codecs subdirectory to dir where MPlayer gets installed? This way I
> could easily drop codecs into that directory (or you might even provide
> them with your package) and MPlayer could also play QT and Real files.
> These file types should be added to the file type dialog on installation
> then.
Yeah, this is something I've been aware of. Some of my packages so far
have done exactly this. In fact, I was even hacking at get_path to get
the path to the codecs folder relative to the mplayer executable. I
think my latest packages have a much more solid solution, though. I'll
get back to this.
S. Smith:
> I might have a bugreport for this (cvs), I have not been able to use
> [-fs|-vm|-zoom] without a sig11 as yet. Switching works fine, tho.
This is because of a patch I added. This behavior does not happen in
normal cygwin mplayer. Here's the issue for me:
This package is intended to be used without any command line.
So, in theory, you'd only ever have one movie running, perhaps on loop.
(My latest hacks have optional playlist associations, though...)
If you're looping a file, and during loop 1 you toggle fullscreen,
then when loop 2 begins, it goes back to windowed mode. My solution:
comment out "fs = options & 1" from vo_directx. This is _awful_ and
I'll fix it before my next release. It would be much better to have the
first call to config set fs, then subsequent calls should leave it
alone. Or, even more correct would be if the caller of config took the
time to check vo_fs state and pass that. In any case, it all diverges
from standard mplayer's way of doing things. And since I'm working on
packages for a special case, isn't a cheap hack okay in the short run?
Bah. I'm trying to make more and more of my package's patches portable
and commitable, but there's just an awful lot of changes that only apply
to the case where I'm packaging. Not to cygwin or even mingw mplayer.
As for the codec path stuff, my newest packages have most of the
package-specific/windows-specific code in a seperate file, to minimize
the drastic changes to mplayer core. A patch to mplayer.c that adds one
line to call an initialize function will probably apply even after big
changes to mplayer.c in CVS. However, my old way of cramming lots of
code where it doesn't belong left me re-writing my patches every week.
But, one of the things I'm doing now is renaming get_path to
normal_get_path and using my own package-specific version to find things
like codecs, fonts, config files, etc. Then I have a bit of code in the
init function (called at the top of main) that sets the env. var PATH to
include codec path. I still need to get around to testing the binary
codecs stuff, but I've just not had the time. Four more weeks of
school, then I can put in a lot more time on mplayer.
To wrap up, I am seeking comments and suggestions from you folks about
what I can do better/different in my next round of packages. For one
thing, I plan on putting up an actual webpage devoted to this vein of
development, rather than just a index of installer files. So, yes, tell
me what you'd like to see.
--Joey
--
All philosophy is naive.
