[MPlayer-dev-eng] Re: [PATCH] win32 codec path

[Joey Parrish]

On Tue, Aug 12, 2003 at 09:45:28AM +0200, Alban Bedel wrote:
> But if you can manage to add REALCODECS_PATH too add to the lib search
> path that's perhaps better. No big deal anyway.

Yes, that's what the patch I sent earlier in this thread does.
Both paths (if defined) should be put in the PATH env var.

> This empty config file creation can be removed from cvs without fear,
> it's really just useless crap. But imho we should have a define for single
> user os like win9x. So on such OS we only search config files in one
> place, ignore $HOME, etc. There may even be some unix users how like
> such config ;)

Yeah, that's what I do, see the other patches on my website.
They aren't good to commit to main, but they do just that.
To commit them to main, we all have to agree on "the right place" for
all these files to be installed, change install behavior on win32, etc.
Then we have to worry about a traditional cygwin system, with unix-like
behavior, and the whole thing is a headache.

> I just looked at your patch and vo_directx.c again. A few things must
> be changed a bit in the event handeling func.

> static LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
> {
> 	switch (message)
>     {
>  ....
>         case WM_CLOSE:
> 		{
> 			mplayer_put_key('q');
> 			return 0;
> 		}
> That's not guarented to work all the time as the user can attach
> any command to 'q' key. Instead something like this must be done:
>         case WM_CLOSE:
> 		{
> 			mp_input_queue_cmd(mp_input_parse_cmd("quit"));
> 		}

I agree.  That's not my code, however.
I'll certainly change that in my patchset, and that bit should certainly
be committed to main cvs.

> In your patch you also add some new special case in this function.
> This is bad. vo should not handle keyevent and such on their own.
> You must insted add some new key codes and pass them with
> mplayer_put_key() like other keystrokes. To handle the alt+enter case
> the best is if you can pass up/down event for all keys. Then the input
> layer can handle everything. Otherwise just make an ALT_ENTER key code.

IMHO, I found adding an ALT_ENTER code difficult.  I tried this first,
and it was discussed on this list.  If you can figure this out, please
help with that.

> Also note that mouse click can alredy be passed (see input/mouse.h),
> fell free to add new codes for double click.

Easier said than done.  What should I do, time the distance between two
identical mouse events to see if it's a valid double-click?  I don't
know the best way to add double-click codes to mouse.h, and besides,
this patch is just for the sake of my packages.  I don't expect most of
it to be committed to main.  Config stuff, win-specific behavior, these
things are IMHO okay to change in a package like mine.  But to change
them in main cvs is much more difficult.  Again, everybody have to agree
on the behavior, and it has to be portable and generic.  I don't have
time right now to do most of these things in such a way.  My win32 patch
set will be taken apart and submitted for approval one issue/change at a
time, once I work out the best way.  In the mean time, I'm very happy to
have others help me with some of these things the right way.  I just
started a new job, and school is about to start again, so I'm very short
on time.

> BTW i also noticed that on win98 the status line display eat up a
> lot of ressources (very choppy playback even on Ghz box) if the dos box
> doesn't have the focus (and hence need to bo on the front with this
> retarded wm ;) Using -quiet solve that.

I just get rid of terminal altogether.  See silentrun.tgz for the app I
use to launch mplayer in this manner.  This app will disappear once I am
able to change mplayer's main function into a windows-style WinMain.
But that's a long way off.  Including windows.h in mplayer.c causes so
many conflicts, it's overwhelming.

--Joey