Hi all, second try with this patch. Hopefully it'll get a bit more review and testing this time :) I already explained what this patch is about but for those too lazy to search the archives here is the whole story again. This patch try to implement a simple API to set and more importantly query the state of various things in MPlayer (like the current volume, name of the demuxer used, whatever). With the commands it is only possible to set things, so to query it is a no go for the internal ui (OSD menu and GUI). In the end the GUI use ugly hacks, the OSD menu have no preference menu, and the frontends are stuck with a couple get_* commands. This imho called for a new API: m_property Basically m_property is just a simple extension of m_option. Instead of using pointers to variables like in m_config, it use pointers to ioctl like functions. The function is then used to set/get the property. Currently the following operations exists: get, set, step up / down, print (to show a more approriate form for human) and parse (to eventually read back that human form). Many of the current commands must then be moved to properties to avoid useless code duplication. For this i implemented a command to property bridge. It can handle most commands automatically by setting the corresponding property and then querying it to display its state on the OSD (via msg and/or bar). In the end this patch have some side effect which are imho desirable things: * Move code from the big switch handeling commands to smaller functions. Not only easier to understand but also finnaly easily re-usable. * "Standardize" all commands going through the bridge. * Put an end to the get_* commands proliferation, everything can be handeled via the get_property command. As an extra (and a way to test the querying properties and the string expansion function i plan to use for the OSD menus) i added a command line option (-playing-msg) that will print a string at the start of the main loop. Before printing the string is expanded allowing to print the state of any property. The following expansion are supported: * \e \n \r \t \xNN : expand to escape, new line, etc * ${NAME} : expand to the value of the property NAME * ?(NAME:TEXT) : print TEXT only if property NAME is available A useful application is to get the currently played file in the title bar of your terminal. For example in an xterm: "\e]0;MPlayer - ${filename}?(length: - ${length})\x07" would set the title to something like: "MPlayer - mymovie.avi - 1:20:02" if the length is available and "MPlayer - mymovie.avi" if not. Please test. In particular subtitle switching and EDL as i can't really test those (not much subs around and i have never used EDL). I know this patch is big, probably too big already, but pls take a bit of time and consider that if this patch had 3 properties it wouldn't be very useful. I tried to resist the temptation of converting too many commands, but if this patch is to be accepted i plan to add more things like tv, etc. Albeu
On Tue, 14 Mar 2006 00:34:33 +0100 Alban Bedel <albeu@free.fr> wrote:
Hi all,
second try with this patch. Hopefully it'll get a bit more review and testing this time :) I already explained what this patch is about but for those too lazy to search the archives here is the whole story again.
This patch try to implement a simple API to set and more importantly query the state of various things in MPlayer (like the current volume, name of the demuxer used, whatever). With the commands it is only possible to set things, so to query it is a no go for the internal ui (OSD menu and GUI). In the end the GUI use ugly hacks, the OSD menu have no preference menu, and the frontends are stuck with a couple get_* commands. This imho called for a new API: m_property
Basically m_property is just a simple extension of m_option. Instead of using pointers to variables like in m_config, it use pointers to ioctl like functions. The function is then used to set/get the property. Currently the following operations exists: get, set, step up / down, print (to show a more approriate form for human) and parse (to eventually read back that human form).
Many of the current commands must then be moved to properties to avoid useless code duplication. For this i implemented a command to property bridge. It can handle most commands automatically by setting the corresponding property and then querying it to display its state on the OSD (via msg and/or bar).
In the end this patch have some side effect which are imho desirable things: * Move code from the big switch handeling commands to smaller functions. Not only easier to understand but also finnaly easily re-usable. * "Standardize" all commands going through the bridge. * Put an end to the get_* commands proliferation, everything can be handeled via the get_property command.
As an extra (and a way to test the querying properties and the string expansion function i plan to use for the OSD menus) i added a command line option (-playing-msg) that will print a string at the start of the main loop. Before printing the string is expanded allowing to print the state of any property. The following expansion are supported: * \e \n \r \t \xNN : expand to escape, new line, etc * ${NAME} : expand to the value of the property NAME * ?(NAME:TEXT) : print TEXT only if property NAME is available
A useful application is to get the currently played file in the title bar of your terminal. For example in an xterm: "\e]0;MPlayer - ${filename}?(length: - ${length})\x07" would set the title to something like: "MPlayer - mymovie.avi - 1:20:02" if the length is available and "MPlayer - mymovie.avi" if not.
Please test. In particular subtitle switching and EDL as i can't really test those (not much subs around and i have never used EDL).
Third try, same patch as above but stripped down to a couple properties. Albeu
Hi, On Fri, Mar 17, 2006 at 06:13:45PM +0100, Alban Bedel wrote:
second try with this patch. Hopefully it'll get a bit more review and testing this time :) I already explained what this patch is about but for those too lazy to search the archives here is the whole story again.
This patch try to implement a simple API to set and more importantly query the state of various things in MPlayer (like the current volume, [...]
Just for the record: I think this was applied... Greetings, Reimar Döffinger
Reimar Döffinger wrote:
Hi, On Fri, Mar 17, 2006 at 06:13:45PM +0100, Alban Bedel wrote:
second try with this patch. Hopefully it'll get a bit more review and testing this time :) I already explained what this patch is about but for those too lazy to search the archives here is the whole story again.
This patch try to implement a simple API to set and more importantly query the state of various things in MPlayer (like the current volume,
[...]
Just for the record: I think this was applied...
Some version of it certainly was; the new file (m_property.c) exists in the source tree. Thank you for noting that. (I'm a little behind sometimes - understatement of the month, at least...) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
participants (3)
-
Alban Bedel -
Reimar Döffinger -
The Wanderer