Greetings, I was directed to post this here from the mplayer-cygwin list, so here goes. This is a heavily heavily modified version of Sascha Sommer's original win32 gui for win32. I began modifying it quite a while ago, with the help of Gianluigi Tiesi who has been kind enough to host binaries and fix my bugs. It's always been available on his site (http://oss.netfarm.it/mplayer-win32.php) which is also linked to from the mplayer homepage under related projects. It uses standard win32 api calls to emulate the current linux gui, so it works in both cygwin and mingw. The goal was to try and handle everything that we possibly could within the gui source, and to stay out of the external mplayer source tree as much as possible. It takes advantage of the gui code that is currently in place within the source tree, so only very minor patching is necessary. Only 3 files require patching, configure, Gui/Makefile, and mplayer.c. The former 2 are self explanitory, but i'll briefly explain the mplayer.c changes. Basically it works the opposite in windows as it does in linux (go figure huh?). The gui is enabled by default, however it is disabled when called via slave, so this still allows it to be used by any frontends around that call mplayer's slave functions. Secondly, i've added a COPYDATA struct which allows for IPC which is handled within gui.c. Lastly, since the sub window is fairly new, and is handled differently than the linux gui, a small 3-liner to allow the sub window to correctly adjust to new aspects when using runtime aspect switching. Some screenshots can be viewed here: http://vayne.fdns.net/mplayer/shot1.png http://vayne.fdns.net/mplayer/shot2.png http://vayne.fdns.net/mplayer/shot3.png Some features: IPC with WM_COPYDATA (as stated above) Fully skinnable with any supported mplayer skin. Playlist loading/saving/shuffling. Full drag&drop support (including playlists) DVD/vcd/cd support (the latter with libcdio) Aspect switching support, whether with -aspect on the cmdline or via runtime aspect switching. DVD title/chapter switching dialog. Preferences dialog. Skin browser. Support for loading external subtitle files. Systray support. Console toggle for stdout/stderr debug info. The sub window takes advantage of WinID when using vo directx, but will hide when using other vo's. And as well, the sub window should automatically hide when a file is audio only and only pop back up when we have video. Also included is an optional (to be applied last) patch for DVD menu's for use with Atvos Attila's dvd menu patches. Questions? comments? Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, On 3/22/06, Erik Lunchpail <erik_27can@yahoo.com> wrote:
Questions? comments?
Congrats for such an achievement! I don't have a computer with windows anymore, so I won't be able to test it, but I'll go though your patch to see how I can help the reviewing process to have it eventually merged before -pre8. One quick question though: does your patch adds some new dependencies (like a windows sdk)? I'd think that you need something to draw windows and everything... Cheers, Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
Congrats for such an achievement! I don't have a computer with windows anymore, so I won't be able to test it, but I'll go though your patch to see how I can help the reviewing process to have it eventually merged before -pre8.
Well, couldn't have done it without Sascha Sommer's original code, and Gianluigi's help as well, so as we Canadians say, kudos to them as well. Here's an updated version. This fixes a few minor bugs for loading dialogs from input commands that was reported on the cygwin list.
One quick question though: does your patch adds some new dependencies (like a windows sdk)? I'd think that you need something to draw windows and everything...
Nope, uses all standard win32 api calls. So only the win32 api package from mingw/cygwin is needed (it's needed anyways to even compile mplayer for windows.) Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
well. Here's an updated version. This fixes a few minor bugs for loading dialogs from input commands that was reported on the cygwin list.
Sorry, screwed that last one up, here's the latest. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
well. Here's an updated version. This fixes a few minor bugs for loading dialogs from input commands that was reported on the cygwin list.
Another small update. Fixes a problem when using -playlist and/or -shuffle on the cmdline. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Another small update. Fixes a problem when using -playlist and/or -shuffle on the cmdline.
Updated to current CVS. The debug console will now show the cpu extensions mplayer was compiled with, and to be consistent, i've changed the "Skin" directory to "skins". Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Updated to current CVS. The debug console will now show the cpu extensions mplayer was compiled with, and to be consistent, i've changed the "Skin" directory to "skins".
New patch. Added a new preferences setting to enable/disable using the sub window as WinID. Should allow people to still use directx if they prefer not to have the sub window using WinID (although it's still recommended, especially if using dvd menu's because it tracks dvdnav mouse events.) Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, On 4/2/06, Erik Lunchpail <erik_27can@yahoo.com> wrote:
Updated to current CVS. The debug console will now show the cpu extensions mplayer was compiled with, and to be consistent, i've changed the "Skin" directory to "skins".
New patch. Added a new preferences setting to enable/disable using the sub window as WinID. Should allow people to still use directx if they prefer not to have the sub window using WinID (although it's still recommended, especially if using dvd menu's because it tracks dvdnav mouse events.)
I've had a look at the code, and the very good point is that your patches are very clean, which makes reviewing easy. Now, I can't test, and I'm not one of MPlayer's coders, so I can't comment on many other things. All I can say is that I'd very much like to see that patch merged _if you're willing to stick around to maintain it_. One of MPlayer's greatest weak point is that current gui is unmaintained, and isn't that great, so it would really be a shame to commit some more code if I was to follow the same tragic path... Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
All I can say is that I'd very much like to see that patch merged _if you're willing to stick around to maintain it_.
One of MPlayer's greatest weak point is that current gui is unmaintained, and isn't that great, so it would really be a shame to commit some more code if I was to follow the same tragic path...
Yes of course. It was suggested that I post it here, and I don't mind if it's kept separate. I'm all for a good platform-independant one, so if one comes along more power to it, I don't mind if the whole current gui code gets removed to make way for a better one. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sun, Apr 02, 2006 at 01:01:31AM -0500, Erik Lunchpail wrote:
Updated to current CVS. The debug console will now show the cpu extensions mplayer was compiled with, and to be consistent, i've changed the "Skin" directory to "skins".
New patch. Added a new preferences setting to enable/disable using the sub window as WinID. Should allow people to still use directx if they prefer not to have the sub window using WinID (although it's still recommended, especially if using dvd menu's because it tracks dvdnav mouse events.)
Well, patch looks genereally OK. A merely cosmetic issue, could you not use the ugly windows typedefs in mplayer.c? LPCSTR is 'char*', and HWND is 'void*'. Also I don't quite like the invocation of the gui. -slave really does have a use, and your patch makes it impossible for ex. to play an audio file with keybinds without gui. Is there any way to fake argv[0] in windows?... - ods15
Well, patch looks genereally OK. A merely cosmetic issue, could you not use the ugly windows typedefs in mplayer.c? LPCSTR is 'char*', and HWND is 'void*'.
No prob, changed.
Also I don't quite like the invocation of the gui. -slave really does have a use, and your patch makes it impossible for ex. to play an audio file with keybinds without gui. Is there any way to fake argv[0] in windows?...
It's a PITA I know. One option could be to remove the whole GetCommandLine() check, but the binary would have to be named gmplayer.exe and started with a .bat file. This way mplayer will by default NOT use the gui, however there's no argv[0] check against the .exe exension, so it would have to be called from a .bat file from within the same directory by omitting the file extension (eg. START gmplayer) and users could shortcut to the bat file. Does this sound like a better solution? It would certainly remove part of the mplayer.c patching. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
It's a PITA I know. One option could be to remove the whole GetCommandLine() check, but the binary would have to be named gmplayer.exe and started with a .bat file. This way mplayer will by default NOT use the gui, however there's no argv[0] check against the .exe exension, so it would have to be called from a .bat file from within the same directory by omitting the file extension (eg. START gmplayer) and users could shortcut to the bat file. Does this sound like a better solution? It would certainly remove part of the mplayer.c patching.
Actually no, that pretty much defeats the whole purpose of the IPC, not to mention if people wanted to use it with other frontends, they'd have to rename it back to mplayer.exe. Basically I think it has to use the gui by default and only disabling it if calling it via slave, or by adding a new cfg option. Using CommandLineToArvW will split up the args and I could check each arg, but it's easier (and less code) to just check the entire called commandline. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
to rename it back to mplayer.exe. Basically I think it has to use the gui by default and only disabling it if calling it via slave, or by adding a new cfg option. Using CommandLineToArvW will split up the
New patch. Changed those windows typedefs and cleaned up a bit of code. Also fixes a small crash bug I was experiencing. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
New patch. Changed those windows typedefs and cleaned up a bit of code. Also fixes a small crash bug I was experiencing.
Sorry, fixed an issue with the IPC and long pathnames. New patch attached. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Sorry, fixed an issue with the IPC and long pathnames. New patch attached.
Fixed a small issue I introduced with the last patch. Files were being appended to the playlist instead of opened right away with IPC and drag&drop. Works fine now. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Fixed a small issue I introduced with the last patch. Files were being appended to the playlist instead of opened right away with IPC and drag&drop. Works fine now.
New patch. Minor fixups and an updated dvdnav patch to apply to Otvos Atilla's latest. Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Saturday 08 April 2006 03:38, Erik Lunchpail wrote:
Fixed a small issue I introduced with the last patch. Files were being appended to the playlist instead of opened right away with IPC and drag&drop. Works fine now.
New patch. Minor fixups and an updated dvdnav patch to apply to Otvos Atilla's latest.
MPlayer developers what is your opinion about this patch? I think we should give the author cvs access so he can apply and maintain it himself. What do you think? Regards Sascha
Hi, On 4/8/06, Sascha Sommer <saschasommer@freenet.de> wrote:
On Saturday 08 April 2006 03:38, Erik Lunchpail wrote:
Fixed a small issue I introduced with the last patch. Files were being appended to the playlist instead of opened right away with IPC and drag&drop. Works fine now.
New patch. Minor fixups and an updated dvdnav patch to apply to Otvos Atilla's latest.
MPlayer developers what is your opinion about this patch? I think we should give the author cvs access so he can apply and maintain it himself. What do you think?
I think it would be a good idea. Few devs proved to be interested in reviewing it (mostly because they don't use Windows I guess), and I've looked at the patch, and it doesn't seem invasive, so it can't really break the whole source tree. So he's got my vote, provided that he plans to stick around to maintain his code. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
On Sat, Apr 08, 2006 at 10:37:18AM +0200, Guillaume POIRIER wrote:
On 4/8/06, Sascha Sommer <saschasommer@freenet.de> wrote:
On Saturday 08 April 2006 03:38, Erik Lunchpail wrote:
Fixed a small issue I introduced with the last patch. Files were being appended to the playlist instead of opened right away with IPC and drag&drop. Works fine now.
New patch. Minor fixups and an updated dvdnav patch to apply to Otvos Atilla's latest.
MPlayer developers what is your opinion about this patch? I think we should give the author cvs access so he can apply and maintain it himself. What do you think?
I think it would be a good idea. Few devs proved to be interested in reviewing it (mostly because they don't use Windows I guess), and I've looked at the patch, and it doesn't seem invasive, so it can't really break the whole source tree.
So he's got my vote, provided that he plans to stick around to maintain his code.
Yes, if he is willing to maintain the stuff, I'm all for it. Diego
I think it would be a good idea. Few devs proved to be interested in reviewing it (mostly because they don't use Windows I guess), and I've looked at the patch, and it doesn't seem invasive, so it can't really break the whole source tree.
So he's got my vote, provided that he plans to stick around to maintain his code.
Yes, if he is willing to maintain the stuff, I'm all for it.
Up to you guys, i've hacked away at it off and on for over a year now, and continue to do so fairly regularly, so I don't plan on up-and-dropping it anytime soon. Attached is the latest. Fixed a minor crash bug, and fixed a major FS switching bug when using WinID (It wasn't being reset between normal and fullscreen). Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, On 4/14/06, Erik Lunchpail <erik_27can@yahoo.com> wrote:
I think it would be a good idea. Few devs proved to be interested in reviewing it (mostly because they don't use Windows I guess), and I've looked at the patch, and it doesn't seem invasive, so it can't really break the whole source tree.
So he's got my vote, provided that he plans to stick around to maintain his code.
Yes, if he is willing to maintain the stuff, I'm all for it.
Up to you guys, i've hacked away at it off and on for over a year now, and continue to do so fairly regularly, so I don't plan on up-and-dropping it anytime soon.
Attached is the latest. Fixed a minor crash bug, and fixed a major FS switching bug when using WinID (It wasn't being reset between normal and fullscreen).
Okay, very good then. Please send a username and an initial password for CVS access to Diego. Once you receive it, you can start comitting your code... :-) If possible, please give a step-by-step guide to enable Windows GUI support if it's different from the way it's done on unix. If I recall correctly, you said there were no extra dependencies, so no need to document "extra dependencies" part ;) Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
On Fri, Apr 14, 2006 at 10:44:44AM +0200, Guillaume POIRIER wrote:
Okay, very good then. Please send a username and an initial password for CVS access to Diego. Once you receive it, you can start comitting your code... :-)
I've created an account for Erik, please welcome a new dev aboard.. Diego
Diego Biurrun wrote:
On Fri, Apr 14, 2006 at 10:44:44AM +0200, Guillaume POIRIER wrote:
Okay, very good then. Please send a username and an initial password for CVS access to Diego. Once you receive it, you can start comitting your code... :-)
I've created an account for Erik, please welcome a new dev aboard..
Hi Erik. :) -Corey
On Tue, Apr 18, 2006 at 09:24:25AM -0700, Corey Hickey wrote:
Diego Biurrun wrote:
On Fri, Apr 14, 2006 at 10:44:44AM +0200, Guillaume POIRIER wrote:
Okay, very good then. Please send a username and an initial password for CVS access to Diego. Once you receive it, you can start comitting your code... :-)
I've created an account for Erik, please welcome a new dev aboard..
Hi Erik. :)
-Corey
Welcome Eric, may the force be with you, new cola-jedi ;) Reynaldo
--- "Reynaldo H. Verdejo Pinochet" <reynaldo@opendot.cl> wrote:
On Tue, Apr 18, 2006 at 09:24:25AM -0700, Corey Hickey wrote:
Diego Biurrun wrote:
On Fri, Apr 14, 2006 at 10:44:44AM +0200, Guillaume POIRIER wrote:
Okay, very good then. Please send a username and an initial password for CVS access to Diego. Once you receive it, you can start comitting your code... :-)
I've created an account for Erik, please welcome a new dev aboard..
Hi Erik. :)
-Corey
Welcome Eric, may the force be with you, new cola-jedi ;)
Reynaldo
Thx guys :) Regards, Erik __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, On 4/14/06, Erik Lunchpail <erik_27can@yahoo.com> wrote:
Attached is the latest. Fixed a minor crash bug, and fixed a major FS switching bug when using WinID (It wasn't being reset between normal and fullscreen).
I've tested mplayer-gui-rtm-cvs-20060323.7z, and found a bug: when activating "always on top" from the keys (key 'T'), it always print 'Stay on top: disabled', and doesn't stay on top at all. CVS version doesn't suffer from that bug. Guillaume -- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about. -- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
I've tested mplayer-gui-rtm-cvs-20060323.7z, and found a bug: when activating "always on top" from the keys (key 'T'), it always print 'Stay on top: disabled', and doesn't stay on top at all. CVS version doesn't suffer from that bug.
That's quite an old version, the gui has had many major bugfixes since then. The lastest i've sent to Gianluigi and as well, on the list is quite stable. I checked it out, that seems to be related to using WinID (which is what the sub window uses) and i'm not sure if that's intentional or not. Nonetheless, disabling the use of the sub window (in preferences) works around the problem for now. It could very well be an issue within vo_directx.c related to the use of WinID. The latest is on my homepage (http://vayne.fdns.net) but it includes Otvos Atilla's dvdnav patch and the gui dvdnav patch, and is therefore experimental. Furthermore, using -geometry when using WinID won't work either (and should probably be disabled). The vo layer is placing the output in one place (with geometry) and the external prog may be placing the window in another place (SetWindowPos(), SetWindowPlacement()). The option to disable the sub window as WinID I believe I added after 20060323, so check a binary on my homepage if you can. It should always have the ability to fall back to a standard mplayer vo. Regards, Erik
-- I am disillusioned enough to know that no man's opinion on any subject is worth a damn unless backed up with enough genuine information to make him really know what he's talking about.
-- H. P. Lovecraft (about the flamewars on FFmpeg and MPlayer-dev mailing lists) http://www.brainyquote.com/quotes/quotes/h/hplovecr278144.html
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hi, Erik Lunchpail wrote:
I've tested mplayer-gui-rtm-cvs-20060323.7z, and found a bug: when activating "always on top" from the keys (key 'T'), it always print 'Stay on top: disabled', and doesn't stay on top at all. CVS version doesn't suffer from that bug.
That's quite an old version, the gui has had many major bugfixes since then.
Ok, my bad.
The lastest i've sent to Gianluigi and as well, on the list is quite stable. I checked it out, that seems to be related to using WinID (which is what the sub window uses) and i'm not sure if that's intentional or not. Nonetheless, disabling the use of the sub window (in preferences) works around the problem for now. It could very well be an issue within vo_directx.c related to the use of WinID. The latest is on my homepage (http://vayne.fdns.net) but it includes Otvos Atilla's dvdnav patch and the gui dvdnav patch, and is therefore experimental.
Ok, I'll test your version. I usually don't watch DVDs with MPlayer (I prefer my comfy chair in front of the DVD player on the living room), so it hopefully shouldn't matter.
Furthermore, using -geometry when using WinID won't work either (and should probably be disabled). The vo layer is placing the output in one place (with geometry) and the external prog may be placing the window in another place (SetWindowPos(), SetWindowPlacement()).
The option to disable the sub window as WinID I believe I added after 20060323, so check a binary on my homepage if you can. It should always have the ability to fall back to a standard mplayer vo.
Okay, will do. Anyway, so far, so good, even though there is this problem and probably others, it doesn't crash, which is really nice when testing experimental stuff. Keep up the good work, Guillaume
participants (8)
-
Corey Hickey -
Diego Biurrun -
Erik Lunchpail -
Guillaume POIRIER -
Guillaume Poirier -
Oded Shimon -
Reynaldo H. Verdejo Pinochet -
Sascha Sommer