nach den Diskussionen in den letzten Tagen habe ich mich noch einmal hingesetzt und meine TAPCOM-Bibliothek weitergestrickt. Dank der Anregungen von FireBird konnte ich hier noch etwas optimieren. Hier also die Veröffentlichung der Version 0.12!
Im Prinzip können TAPs jetzt (vorausgesetzt das Ganze klappt auch im wirklichen TAP-Leben) kooperieren und sich gegenseitig Dienste anbieten. Sinnvolle Szenarien dafür gibt es aus meiner Sicht genügend:
- Filer könnte seinen Löschen-mit-oder-ohne-Papierkorb-Dialog für andere TAPs zur Verfügung stellen. Dieses Szenario habe ich als Beispiel näher beschrieben (s. u.).
- Nicedisplay könnte für andere TAPs eine Schnittstelle bereitstellen, über die diese beliebigen Text im Display anzeigen lassen können (z. B. im Wechsel mit den Standard-Nicedisplay-Anzeigen). Im Zusammenhang mit dem RadioText-TAP kam glaube ich genau ein solcher Wunsch auf.
- Quicktimer könnte seinen Timer-Änderungs-Dialog als Dienst anbieten. Andere TAPs, die Timer anlegen (z. B. Improbox), könnten bei entsprechendem Wunsch des Nutzers direkt nach Anlegen des Timers den Quicktimer-Dialog aufrufen, damit der Benutzer den Timer anpassen kann (Vorlauf/Nachlauf/Dateiname).
- Immer wieder wünschen sich die Benutzer bei den TAPs, die Texteingaben verlangen, das TAP x möge doch bitte die gleiche virtuelle Tastatur wie TAP y anbieten. Alle TAP-Entwickler könnten ihre verschiedenen Tastaturen in ein eigenes Eingabe-Service-TAP zusammenschmeißen, das dann Eingaben über die verschiedenen Tastaturen als Services anbietet. So wäre mit wenig Aufwand aus jedem TAP jede gewünschte Tastatur erreichbar.
- Viele TAPs haben teilweise ähnliche Einstellungen. Beispielsweise bieten Improbox, die EPG-TAPs, QuickTimer und auch Filer Einstellungen für Vor- und Nachlauf mit gleicher bzw. verwandter Semantik. Mit TAPCOM könnten die TAPs untereinander diese Einstellungen erfragen, den Benutzer ggf. auf Konflikte hinweisen bzw. eine einheitliche Einstellung verwenden.
- Bei mehreren gleichzeitig laufenden TAPs wird es auf der Tastatur bald relativ eng, was bei einigen TAPs schon zu sehr originellen Lösungen geführt hat (z. B. QuickTimer-Aktivierung über ganze Tastenfolge). Würde ein TAP seine Aktivierung zusätzlich zu einer Taste auch über einen TAPCOM-Service anbieten, so ließe sich ein "TAP-Schnellstartmenu"-TAP schreiben oder in Filer integrieren. Bestimmte, seltener benutzte TAPs könnten dann vom Benutzer nur über dieses Schnellstartmenu aktiviert werden und müssten keine Original-Tasten "verdrängen". So etwas habe ich mir (basierend auf der TAPCOM-Idee und mit etwas Gehacke) mal für QuickTimer, MediaManager und MP3-Jukebox geschrieben, die ich alle eher selten brauche.
- ...
mfg
asrael
PS:
Das Ganze ist natürlich noch sehr Beta. Die beiden mitgelieferten Beispielanwendungen sollten hoffentlich auf jeder Hardware/Firmware-Kombination laufen. Für Rückmeldungen bin ich dankbar. Vielleicht hat ja auch der ein oder andere TAP-Guru mal Lust, TAPCOM mit seinem TAP zu testen und bestimmte Dienste seines TAPs über TAPCOM anzubieten. Ein Test-Client dürfte auf der Basis der anliegenden Beispiele schnell geschrieben sein. Der Vorteil einer solchen einheitlichen Schnittstelle ist es auch, dass sich nicht mehrere
Speziallösungen, die den gleichen Weg benutzen, ins Gehege kommen.
PPS:
Da Tastatur-Ereignisse benutzt werden, wird die Benutzung von TAPCOM dazu führen, dass sich der Topf nach einem automatischen Einschalten nicht mehr ausschaltet (siehe vorausgegangener Thread). Bei den meisten Szenarien, die ich mir so vorstellen kann, geht aber dem Aufruf eines RPCs über TAPCOM eine Interaktion des Benutzers voraus, so dass dies hier nicht schlimm ist. Der Aufruf von RPCs über TAPCOM ohne vorhergehende Interaktion des Nutzers ist aber entsprechend vorsichtig vorzunehmen. Eine sicherere Lösung hierfür ist aber anzustreben, für Hinweise bin ich dankbar.
PPPS:
@tapworld:
This is an library for TAP programmers. Please don't publish this at the moment. If there is some interest from the german TAP programmers in this library and if it proves to work stable and efficiently, I will write an english documentation and will ask you to publish the library.
PPPPS:
Auszug aus der anliegenden liesmich.txt:
Im Verzeichnis TAPCOM befindet sich die TAPCOM-API (Header und Object-Datei), im Verzeichnis Example1 und Example2 befinden sich zwei Nutzungsbeispiele.
Zweck der TAPCOM-API ist es, TAP-Programmierer mit der Möglichkeit auszustatten, ihre TAPs auf einfache Art und Weise untereinander kommunizieren lassen zu können. Dies geschieht mit RPCs (remote procedure calls), d. h. ein TAP kann also bestimmte Dienste zur Verfügung stellen, die dann von anderen TAPs aufgerufen werden können.
Sinn und Funktionsweise lassen sich am besten an einem konkreten Beispiel erklären:
Filer bietet schon jetzt Einstellungen an, mit denen der Benutzer entscheiden kann, ob beim
Löschen von Dateien diese im Papierkorb landen sollen oder physisch gelöscht werden und ob eine Sicherheitsabfrage erfolgen soll. Demnächst kann Filer vielleicht (Spekulation) je nach Benutzereinstellung beim Löschen einer Datei diese in den Papierkorb legen und gleichzeitig vormerken, dass sie nach xx Tagen Aufenthalt im Papierkorb automatisch gelöscht werden soll.
Andere Programme (z. B. Improbox oder SmartEPG) können auch Dateien löschen, bieten teilweise einen Papierkorb (aber zumindest in Zukunft mit anderer Logik als Filer), teilweise auch keinen an. Ob aber Improbox den Papierkorb benutzt oder nicht, muss hier z. B. erneut (und unabhängig von Filer) eingestellt werden.
Würde nun Filer einen Dienst zum Löschen von Dateien anbieten, den andere TAPs nutzen können, so würden alle Papierkorb-, Abfrage- und Autolösch-Funktionen von Filer für die anderen TAPs ohne großen Aufwand nutzbar. Der Benutzer müsste im wesentlichen seine Einstellungen (Papierkorb ja/nein, Sicherheitsabfrage ja/nein, Autolöschen ja/nein (und wann) etc.) nur einmal in Filer tätigen. Improbox bzw. SmartEPG müssten nur jeweils eine Einstellung "Löschen über Filer (ja/nein)" bieten.
Der Aufwand für das anbietende TAP (Filer) und für das nutzende TAP (Improbox) wäre aus meiner Sicht vergleichsweise gering.
In Filer müsste etwa folgender Code stehen:
// eine Zusatzzeile in TAP_Main:
int TAP_Main(void) {
TAPCOM_Identify(TAPCOM_App_Filer);
...
}
// Ergänzung in TAP_EventHandler:
dword TAP_EventHandler(word event, dword param1, dword param2) {
byte caller, serviceId;
void* parameter;
TAPCOM_ProcessEvent(&event, param1, &caller, &serviceId, ¶meter);
// diese Zeilen sind nötig, um TAPCOM-Ereignis zu erkennen
if (event == EVT_TAPCOM) {
// RPC von einem Client
switch (serviceId) {
// was will der Client von mir
case 1: // ID für Filer-Service "Delete"
// Hier könnte Filer eine Header-Datei "filer_tapcom_services.h" anbieten, die etwa
// enthält:
// #define Filer_TAPCOM_Delete 1
// Dann könnte man diese Konstante verwenden und schreiben:
// case Filer_TAPCOM_Delete:
if (caller == TAPCOM_App_Improbox) {
// und ggf. weitere
char *filename = (char*) parameter;
FILER_delete(filename);
// Hier wird der (ja irgendwo schon vorhandene) Code für das Löschen aufgerufen.
// nur Prinzipskizze, wird wohl eher während EVT_IDLE gemacht werden
}
break;
// ggf. weitere Services, die Filer anbietet
}
return RKEY_NoUse;
} else
// weitere Events verarbeiten wie bisher
Außerdem muss in der Datei oder den Dateien, die TAP_Main bzw. TAP_EventHandler enthalten, tapcom.h inkludiert werden und die Datei tapcom.o zum Filer-TAP gelinkt werden.
In Improbox müsste im Prinzip nur folgender Code stehen:
// eine Zusatzzeile in TAP_Main:
int TAP_Main(void) {
TAPCOM_Identify(TAPCOM_App_Improbox);
// Nur nötig, falls Filer den Service auf bestimmte TAPs beschränkt oder falls Improbox
// selbst Services anbieten möchte.
...
}
// an der Stelle, wo normalerweise die Datei von Improbox selbst gelöscht würde:
TAPCOM_RPC(TAPCOM_App_Filer, 1, filename);
// Voraussetzung: filename ist ein char-Pointer, der auf einen Speicherbereich zeigt, der den
// Dateinamen enthält.
// Noch eleganter (nach Inkludieren von "filer_tapcom_services.h"):
// TAPCOM_RPC(TAPCOM_App_Filer, Filer_TAPCOM_Delete, filename);
Auch hier muss tapcom.h inkludiert werden und die Datei tapcom.o zum Filer-TAP gelinkt werden.
Im Verzeichnis TAPCOM befindet sich die Datei tapcom.h, die in eigene Quelltexte eingebunden werden muss, und die Datei tapcom.o, die beim Linken der Anwendungen benötigt wird. Die Datei build.bat der mitgelieferten Beispielanwendung demonstriert den Übersetzungsvorgang (Pfade bitte ggf. anpassen).
Die Beispielanwendung in Example1 enthält drei TAPs: eines, das als Server fungiert und zwei Client-TAPs. Alle drei sollten für den Test gestartet werden. Beim Drücken der UHF-Taste ruft Client1 einen Service des Server-TAPs auf. Dieses erzeugt dann eine Ausgabe. Analog ruft Client1 nach Drücken der Taste TV/SAT einen anderen Service des Servers auf, der eine andere Ausgabe erzeugt. Client2 reagiert auf das Drücken von Sleep mit dem Aufruf eines Services des Servers, der auch hier eine Ausgabe erzeugt.
Nach dem Test können die drei TAPs mit 1, 2 und 3 beendet werden.
Alle sechs beschriebenen Tasten sollten beim Test möglichst nicht durch andere TAPs abgefangen werden (am besten ohne andere TAPs testen).
Die Beispielanwendung in Example2 enthält zwei TAPs: einen Server und einen Client. Beim Drücken der Mute-Taste ruft der Client einen Service des Server-TAPs auf. Im Gegensatz zu Example1 wird hier vom Server eine Rückmeldung an den Client erzeugt. Zufällig erzeugt der Server eine Erfolgs- oder Misserfolgsmeldung, die vom Client ausgewertet wird. Nach dem Test können durch Drücken von 4 beide TAPs beendet werden. Hierzu bietet der Server einen entsprechenden Dienst an, mit dem ein Client ihn zum Beenden auffordern kann.
Alle fünf TAPs können auch gemeinsam gestartet werden, um das Zusammenwirken unterschiedlicher Clients und Server zu demonstrieren.
Einziger Zweck der Beispiel-TAPs ist es, die Funktionen und die Benutzung der TAPCOM-API zu demonstrieren. Ihr Quellcode enthält weitere Details zur Nutzung der TAPCOM-API.
keine weiteren Katastrophen passieren. 
: , da den verwendeten Mechanismus ja im Prinzip jeder benutzen kann. Es ist aber zumindest gewährleistet, das nur das für ein TAPCOM-Ereignis gehalten wird, was auch (mit annähernd 100 Prozent Wahrscheinlichkeit) eines ist.
)