-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Klaus! Some class declarations, for example the class cMenuRecording are declared in the sourcefile. So plugin developers cannot use them easily. Why don't you move this declarations to the headerfiles? There are also most class members declared as private. So plugin developers have to implement most things themself. Why aren't they protected? Maybe you have a good reason for that. As a plugin newbie I have to copy all the vdr classes I wanna use, instead of easily deriving it. An example of this would be cMenuRecordingItem or cRecording. But there are many other classes, which could be used in plugins.
Thomas
- -- gpg-id: D31AAEEA http://www.setho.org/people
On 05.09.2013 13:07, Thomas Maass wrote:
... Some class declarations, for example the class cMenuRecording are declared in the sourcefile. So plugin developers cannot use them easily. Why don't you move this declarations to the headerfiles? There are also most class members declared as private. So plugin developers have to implement most things themself. Why aren't they protected? Maybe you have a good reason for that. As a plugin newbie I have to copy all the vdr classes I wanna use, instead of easily deriving it. An example of this would be cMenuRecordingItem or cRecording. But there are many other classes, which could be used in plugins.
These classes were never meant to be "derived from". If I make, e.g., cMenuRecordingItem a virtual base class, there would also have to be a way of having a derived cMenuRecordings create instances of the derived cMenuRecordingItem instead of its own. I'm afraid this would make things unnecessarily complex. These are VDR's own menu implementations, and if somebody doesn't like them, there's always things like "extrecmenu" etc. In the core VDR I'd like to keep things simple and basic.
In one of the upcoming develoepr versions I plan to implement a way to freely configure the menu of VDR, and even use plugin provided replacements of the standard menus. Maybe this will help...
Klaus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I wanna write a recmenu plugin similar to extrecmenu. And when I look into the code of extrecmenu, the developer had to implement everything himself, even calling a recording's info screen. Also functions as play, rewind, delete etc.
I want to implement the hdd-archive, renaming and moving functions. First I wrote a patch for VDR, which adds these functions to VDR's original recmenu. But I don't want to fix the patch with every upcoming VDR version. I posted the first version of the patch last week.
So I decided to start a recmenu Plugin with archive-hdd support. As I use mostly original functions, I always have to copy the whole original recmenu code and make some small changes to it.
It it impossible to simply add a "bool cRecording::IsArchive()" method. By now, I implemented my own cRecordings and cRecordingItem class, and added the method there. The rest is a copy of VDR's original class.
What about the few class declarations you made in the sourcefiles?
Thomas
- -- gpg-id: D31AAEEA http://www.setho.org/people
-
Klaus Schmidinger -
Thomas Maass