Hi Klaus,
meanwhile there are many plugins, that could be used as a replacement for some of VDR's main menu entries, like "schedule" or "channels". Please don't get me wrong, you've done a great job, but some plugin authors too ;-) And if the user likes to use a plugin instead of the builtin function, why not? A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
... cPlugin *p = NULL; switch (State) { case osSchedule: p = CallFirstService("schedule"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuSchedule); break; case osChannels: p = CallFirstService("channels"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuChannels); break; case osTimers: p = CallFirstService("timers"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuTimers); break; case osRecordings: p = CallFirstService("recordings"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuRecordings(NULL, 0, true)); break; ...
a plugin could implement a service like "schedule" that only signals that it offers this functionality. If so, VDR would call this plugin instead of the builtin menus.
Christian
Christian Wieninger wrote:
Hi Klaus,
meanwhile there are many plugins, that could be used as a replacement for some of VDR's main menu entries, like "schedule" or "channels". Please don't get me wrong, you've done a great job, but some plugin authors too ;-) And if the user likes to use a plugin instead of the builtin function, why not? A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
... cPlugin *p = NULL; switch (State) { case osSchedule: p = CallFirstService("schedule"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuSchedule); break; case osChannels: p = CallFirstService("channels"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuChannels); break; case osTimers: p = CallFirstService("timers"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuTimers); break; case osRecordings: p = CallFirstService("recordings"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuRecordings(NULL, 0, true)); break; ...
a plugin could implement a service like "schedule" that only signals that it offers this functionality. If so, VDR would call this plugin instead of the builtin menus.
Christian
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I just want to say that it would be a great idea. I use epgsearch instead of the build in EPG-view and patched VDR.
Regards Peter
Christian Wieninger wrote:
Hi Klaus,
meanwhile there are many plugins, that could be used as a replacement for some of VDR's main menu entries, like "schedule" or "channels". Please don't get me wrong, you've done a great job, but some plugin authors too ;-) And if the user likes to use a plugin instead of the builtin function, why not? A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
... cPlugin *p = NULL; switch (State) { case osSchedule: p = CallFirstService("schedule"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuSchedule); break; case osChannels: p = CallFirstService("channels"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuChannels); break; case osTimers: p = CallFirstService("timers"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuTimers); break; case osRecordings: p = CallFirstService("recordings"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuRecordings(NULL, 0, true)); break; ...
a plugin could implement a service like "schedule" that only signals that it offers this functionality. If so, VDR would call this plugin instead of the builtin menus.
Christian
Basically I don't mind doing this.
However, originally I was trying to get a first release candidate for version 1.4 ready this weekend, but with every new patch that people want to get in, things are, of course, going to be delayed.
Well, since a few unexpected things came up for this weekend, anyway, I guess I'll have to abandon that deadline altogether. Which means that I might as well take a few more weeks and get some more patches in...
Klaus
Klaus Schmidinger schrieb:
Basically I don't mind doing this.
great!
However, originally I was trying to get a first release candidate for version 1.4 ready this weekend, but with every new patch that people want to get in, things are, of course, going to be delayed.
Well, since a few unexpected things came up for this weekend, anyway, I guess I'll have to abandon that deadline altogether. Which means that I might as well take a few more weeks and get some more patches in...
ok, I can understand you. If it's not part of 1.4, I'll wait for 1.5, although it would be nice to get rid of another patch. (yes, I know it's another patch for you ;-) )
Christian
Christian Wieninger wrote:
A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
... cPlugin *p = NULL; switch (State) { case osSchedule: p = CallFirstService("schedule"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuSchedule); break;
The Service() interface is probably the wrong interface for such things. VDR shouldn't rely on this interface, its primarily for non-standard communication.
Also, your suggestion will call MainMenuAction for each menu entry, how should the plugin know which one was called?
On the other hand, the current menu scheme needs an overhaul anyway, as the main menu is flooded with plugin entries. Such a customized main menu could easily hide the schedule/channels/timers/recordings menu, or move the default entries somewhere else. Plugin main menu entries could take over their place.
What about this one: Add an interface that allows a plugin to catch this:
Menu = new cMenuMain;
... and either create an own main menu, or modify the existing one. (several plugins should be able to do some modifications one after the other)
Cheers,
Udo
Udo Richter schrieb:
The Service() interface is probably the wrong interface for such things. VDR shouldn't rely on this interface, its primarily for non-standard communication.
I think this is one possible solution. If there would be a special api function for this purpose, I don't mind ;-) But since there is no 'communication' here, but only a lookup for the service, why not use it anyway?
Also, your suggestion will call MainMenuAction for each menu entry, how should the plugin know which one was called?
This is only true, if a plugin would handle more than one main menu entry. Can't imagine a plugin like that.
Christian
Christian Wieninger wrote:
Also, your suggestion will call MainMenuAction for each menu entry, how should the plugin know which one was called?
This is only true, if a plugin would handle more than one main menu entry. Can't imagine a plugin like that.
Really? And I thought that an epgsearch-enhanced timer menu would be obvious. ;)
(At least I would love to be able to delete all these epgsearch-added timers that I don't need - right now I have to disable them, so they continue to fill up the timers list.)
Cheers,
Udo
Hi,
Udo Richter schrieb:
Really? And I thought that an epgsearch-enhanced timer menu would be obvious. ;)
I already thought about this ;-) But if so, it would be a new plugin. But I know atleast one guy, who is currently working on a plugin like that.
(At least I would love to be able to delete all these epgsearch-added timers that I don't need - right now I have to disable them, so they continue to fill up the timers list.)
yes, that also bothers me. I'll change this in one of the next releases. Sorry for OT ;-)
Christian
Am Freitag, 3. März 2006 14:22 schrieb Christian Wieninger:
Also, your suggestion will call MainMenuAction for each menu entry, how should the plugin know which one was called?
This is only true, if a plugin would handle more than one main menu entry. Can't imagine a plugin like that.
well, I could: epgsearch ;)
it would be easy to also use it as replacement for the channellist if you set "show channels without EPG" to yes with a special call or flag. Further on, I wish i could jump directly to the search function of epgsearch without having to call the epg. And finally the "Edit timer" function is also more powerfull as you can set every weekday separately.
so there are at least four functions epgsearch could replace and therefore the original idea of a plugin providing one _or multiple_ services was not such a bad idea (imho) :)
But I also like Udo's idea of being able to create the menu "dynamically", currently i personally use the menu-patch from the setup-plugin to create my own menu structure and sort and group all the plugins and functions (no this is not a suggestion, just an example).
cheers, Thiemo
Hi!
Udo Richter schrieb:
Christian Wieninger wrote:
A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
... cPlugin *p = NULL; switch (State) { case osSchedule: p = CallFirstService("schedule"); AddSubMenu(p?(cOsdMenu *)p->MainMenuAction():new cMenuSchedule); break;
The Service() interface is probably the wrong interface for such things. VDR shouldn't rely on this interface, its primarily for non-standard communication.
Also, your suggestion will call MainMenuAction for each menu entry, how should the plugin know which one was called?
On the other hand, the current menu scheme needs an overhaul anyway, as the main menu is flooded with plugin entries. Such a customized main menu could easily hide the schedule/channels/timers/recordings menu, or move the default entries somewhere else. Plugin main menu entries could take over their place.
What about this one: Add an interface that allows a plugin to catch this:
Menu = new cMenuMain;
... and either create an own main menu, or modify the existing one. (several plugins should be able to do some modifications one after the other)
A customizable menu would be the nicest feature for that, but I think an easy solution would be to search plugins with the name "schedule", "timers", "recordings" and so on and if it exists it should replace the main-menu-entry vdr provides.
Just my 2ct. Bye, Andreas Brugger
Christian Wieninger schrieb:
Hi Klaus,
meanwhile there are many plugins, that could be used as a replacement for some of VDR's main menu entries, like "schedule" or "channels". Please don't get me wrong, you've done a great job, but some plugin authors too ;-) And if the user likes to use a plugin instead of the builtin function, why not? A real replacement currently can only be done when patching VDR, so what do you think about the following change of the MenuMain constructor in menu.c? :
Wouldn't it be enough to hide the original Menu entries?
An another way could be that the Plugin returns not the MAINMENUENTRY: virtual const char *MainMenuEntry(void) { return MAINMENUENTRY; }
It could return the Name of the Plugin it would like to replace. virtual const char *MainMenuEntry(void) { return "Timers"; }
I have some patches and Idears for the OSD and Menu usibility but I will wait for 1.4 befor I will post them.
Best regards, Patrick Fischer
-
Andreas Brugger -
Christian Wieninger -
Klaus Schmidinger -
Patrick Fischer -
Peter Juszack -
Thiemo -
Udo Richter