Hi,
this patch allows plugins to replace the VDR mainmenus "Schedule", "Channels", "Timers" and "Recordings" by a different implementation.
There are already a few plugins around which do something like that, using their own idea of a patch. So Tobias Grimm, Martin Prochnow, Christian Wieninger and me made an effort to find a common solution for the problem. The patch is based on a suggestion of Christian Wieninger back in March 2006 (http://www.linuxtv.org/pipermail/vdr/2006-March/008234.html). It is meant to be an interim solution for VDR 1.4 until (maybe) VDR 1.5 introduces an official API for this purpose.
Please note that no plugin supports this patch yet. We wanted to introduce it to the list first. Maybe there are some additional requirements we didn't think of.
You will find more detailed information in the patch file.
Enjoy, Frank
Frank Schmirler wrote:
this patch allows plugins to replace the VDR mainmenus "Schedule", "Channels", "Timers" and "Recordings" by a different implementation.
There are already a few plugins around which do something like that, using their own idea of a patch. So Tobias Grimm, Martin Prochnow, Christian Wieninger and me made an effort to find a common solution for the problem. The patch is based on a suggestion of Christian Wieninger back in March 2006 (http://www.linuxtv.org/pipermail/vdr/2006-March/008234.html). It is meant to be an interim solution for VDR 1.4 until (maybe) VDR 1.5 introduces an official API for this purpose.
After taking a short look at the patch, I think that this could be done in a more elegant way.
- case osSchedule:
if (!cPluginManager::CallFirstService("MainMenuHooksPatch-v1.0::osSchedule", &menu))menu = new cMenuSchedule;elsestate = osContinue;break;
The service functions are meant to be a solution for plugin-to-plugin communication, since in that case there's no access to the other's symbol space. In this case however, the VDR headers can easily be extended, so there's enough room to do a normal interface.
For the menu hooks, I would suggest to implement a common base class, that a plugin must derive a copy of, to register a new handler. Basically, the same way it already works for cStatus, or other things like devices and skins.
Basically, I think its worth considering such an interface to allow to replace standard dialogs. However, the user should always have the choice whether he wants to keep the originals or use the replacements.
Cheers,
Udo
On Mon, 26 Feb 2007 21:41:28 +0100, Udo Richter wrote
The service functions are meant to be a solution for plugin-to- plugin communication, since in that case there's no access to the other's symbol space. In this case however, the VDR headers can easily be extended, so there's enough room to do a normal interface.
Right, we've been discussing that but opted against an API change. With just an interim solution in mind we've been looking for the least invasive way to get what we want. And no need to recompile all plugins.
For the menu hooks, I would suggest to implement a common base class, that a plugin must derive a copy of, to register a new handler. Basically, the same way it already works for cStatus, or other things like devices and skins.
That would be the cleanest solution. But IMHO a little bit oversized if it were only about replacing the four mainmenu entries. A new API should rather give plugins a chance to modify both, contents and behaviour of the standard menus. That way even multiple plugins could modify the contents of the same (original) menu, something a dumb "replace whole submenu" feature would not support.
My upcoming remotetimers plugin should give an excellent example. Currently it's a copy of the original timers and schedule menu code with some lines added here and there just to fill in the remote entries. With an appropriate new API I could simply append the remote timers to the original timers list and my additional options to cMenuEditTimer. In the schedules menu, I need to tag remote timer matches and catch the add timer actions. If there were some well defined hooks, that would not keep anyone from using one of the alternative schedule implementations. Finally on a pure streaming client it would be nice to redirect instant recordings to the server by overriding the red button action in the main menu. However as it should also be informed whenever the record key is pressed this is rather a candidate for an other API.
I stop cherishing my illusions here. Such an API would require thorough analysis of the current plugins and major rewrites of VDR and plugins. Still in the end it won't suit everyone. But maybe Klaus could share his opinion with us? Perhaps it's worth a try.
Basically, I think its worth considering such an interface to allow to replace standard dialogs. However, the user should always have the choice whether he wants to keep the originals or use the replacements.
Agreed. That's why in the patch instructions we ask plugin developers to provide a setup option for this which defaults to "off".
Cheers, Frank
-
Frank Schmirler -
Udo Richter