Suche Patches für VDR 1.7.21

Zitat

Das ein Patch her muss ist ja kein Geheimnis. Aber Wareagleicon wurde von Klaus abgelehnt. Es muss also etwas her, was von Klaus akzeptiert wird.

Bloss nicht.. ich will kein LCARS Menue

DER Thread gefällt mir

Das skinElchi hat den Würgaround übrigens von skinenigma 0.0.5 gekla... äh, ausgeliehen und erweitert (nur damit die geistigen Eigentumsverhältnisse klar sind ;D)

kls sagt (zu Recht), dass für die Darstellung die Skins verantwortlich sind, deshalb sollte nicht zu viel von der Darstellung in den core-VDR rein. Der VDR übergibt aber mit SetItem() nur einen mit Tabs getrennten String, den die Skins darstellen sollen.
Wenn das Skin jetzt "mehr" möchte wie z.B. einen aktiven Timer mit einem Symbol kennzeichnen, dann muss das Skin raten, dass der SetItem-String einen Timer-Eintrag darstellt und dann z.B. an Stelle des 'T' ein Symbol anzeigen. Was bei Timer oder Aufzeichnungen (new-Symbol) noch mit Parsen recht gut zu erraten ist, versagt komplett bei den Kanälen: WarEagle stellt da ein Symbol für TV, PayTV und Radio dar, aber ein Skin kann nicht mit vertretbaren Aufwand feststellen, welche Eigenschaften der Kanal hat, denn mit einem Namen den passenden Eintrag in der Kanalliste zu suchen ist schlicht Overkill und nicht die Aufgabe eines Skins. Dafür müsste das Skin die Info vom VDR bekommen was wieder auf Parsen, zusätzliche Tags oder Übergabe der darzustellenden Kanalobjekte hinausläuft. Letzteres wäre aber wieder ein ganz anders Interface. Genauso ein Ordner-Symbol vor Aufnahmeverzeichnissen. Da stellt sich aber die generell Frage, ob soviel graphischer Schnickschnack überhaupt gewollt ist.
Ohne die Infos vom VDR (als Patch oder als Interface-Erweiterung) sind die Skins da aber hilflos.
Und ich bin schon mal gespannt wann skinElchi das erste mal eine Aufzeichnung mit VPS-Symbol darstellt weil der Parser versagt hat

Moin!

Das Skin-Interface müsste um neue Methoden erweitert werden, die abgesehen von den Texten auch Bedeutungen der Texte mitgeben (z.B. eine Liste von Objekten mit 'nem enum und 'nem string, nagelt mich nicht darauf fest).
Der vdr selbst benutzt das neue Interface.
Die Default-Implementierung nimmt die neuen Daten und baut daraus den alten Tab-Text zusammen und füttert damit das alte Interface.

Ungeänderte Plugins funktionieren wie bisher, angepasste können die neue Schnittstelle benutzen. Das wäre der richtige Weg.

Lars.

Ich habe gestern versucht, den Parser vom SkinElchi auszutricksen und eine Aufnahme so zu benennen, dass ein Symbol draus wird. Es ist mir nicht gelungen.

Was durch den Parser schonmal sehr gut gezeigt wird, ist, welche Infos ein Skin-Entwickler braucht, um seine Symbole zu platzieren. Wenn es jemals eine API dafür gibt, dann müsste man nur den Parser ersetzen, bzw. durch bedingte Kompilierung für die neue VDR-Version ausklammern.

Ich habe ohnehin geplant, einige Änderungen am Text2Skin-Plugin zu machen. Wenn ich mit meinen noch anstehenden VDR-Projekten fertig bin, dann versuche ich einmal den Code von Firefly für text2skin zu adaptieren.

mini73: Volle Zustimmung. So in etwa sollte es gelöst werden. Allerdings sind da gleich einige Fragen offen. So ist für jedes Menü andere Info relevant. Zudem wäre nicht ganz falsch, wenn auch andere Plugins ihre Menüs hier bekannt machen könnten. AFAIK kennt C++ keine dynamischen Objekte. Man müsste also an die Funktion erstmal einen Identifier übergeben um das Menü zu bezeichnen. Als zweiten Wert dann einen Pointer. Das Skin muss abhängig vom Menü dann aus dem übergebenen Pointer via Typumwandlung selber die richtige Struktur machen. Wenn ein vom Skin nicht bekannter Identifier übergeben wird, dann sollte das Skin einen im dritten Argument übergebenen String verwenden um wieder eine Plain-Text-Liste bauen zu können (Fallback).

Und wenn noch jemand ein Argument gegen UTF-8 braucht: Vor nicht allzulanger Zeit hat kls geschrieben, dass er auch seinen VDR ohne UTF-8 laufen hat.

Was extrecmenu angeht: Wenn es selber die entsprechenden Zeichen generiert (was, soweit ich weiß, der Fall ist), dann braucht es keinen Wareagle-Patch sondern lediglich den richtigen Font. Würde sich extrecmenu ähnlich verhalten wie das Original-Aufnzeichnungs-Menü, dann würde Skinelchi sogar direkt damit klarkommen. Hier zeigt sich aber wieder, wo möglicherweise die Grenzen einer Skin-API sind. Extrecmenu ist ein klarer Fall bei dem ein Plugin eine Information an den Skin übergeben müsste. Ein "nicht-VDR-Menü" für das man eventuell zumindest optional ein "Verschönern" durch den Skin zulassen will.

Zitat von Mreimer

Würde sich extrecmenu ähnlich verhalten wie das Original-Aufnzeichnungs-Menü, dann würde Skinelchi sogar direkt damit klarkommen.

extrecmenu hat aber komplett andere Symbole als das orginale Aufzeichnungsmenü, ferner kann hier der User selber Symbole ins Menu mappen oder die Zeilen umgstalten. Die Skinelchi Methode kann hier also niemals funktionieren.

cu

Keine_Ahnung: ich denke wir sind da auf einer Wellenlänge, mein Kommentar ging eher in die andere Richtung. Lieber gar keine Lsg und etwas später eine zukunftsträchtige. Frickelei gibts rund um den VDR wahrlich genug.

Lars: klingt gut. Das würde evtl auch eine grafische Aufbereitung des Menüpunktes erlauben (Icon oder andere Visualisierung) welche das Skin dann leisten kann.

@Mreimer: Das einzigen Argumente gegen UTF-8 sind und waren immer gewesen: "Hatten wir noch nie" bzw. "Neumodischer Kram, der macht nur alles kaputt" Das sind Argumente aus dem letzten Jahrhundert. Und ja das sind genauso Totschlagargumente wie die gegen UTF-8
"dann braucht es keinen Wareagle-Patch sondern lediglich den richtigen Font. " -> gapatchter Font klingt scheisse, gibts da nichts besseres ? Wenn wir Symbole wollen, sollten das Icons sein.

Zitat von steffen_b

"dann braucht es keinen Wareagle-Patch sondern lediglich den richtigen Font. " -> gapatchter Font klingt scheisse, gibts da nichts besseres ? Wenn wir Symbole wollen, sollten das Icons sein.

Aber genau so ist es aktuell im extrecmenu gelöst. Der einzige Weg um zwischen Plugin und Skin einen Eintrag zu übertragen führt aktuell über einen durch Tabs getrennten String. Viele andere Lösungen als String parsen und Sonderfont verwenden bleiben da aktuell nicht.

Moin!

Zitat von Mreimer

Aber genau so ist es aktuell im extrecmenu gelöst. Der einzige Weg um zwischen Plugin und Skin einen Eintrag zu übertragen führt aktuell über einen durch Tabs getrennten String. Viele andere Lösungen als String parsen und Sonderfont verwenden bleiben da aktuell nicht.

Das ist was für das Pflichtenheft den neuen Skin-Schnittstelle.
Wenn erst mal die Usecases bekannt sind, lässt sich auch eine API entwickeln.

Lars.

Zitat von Mreimer

Aber genau so ist es aktuell im extrecmenu gelöst. Der einzige Weg um zwischen Plugin und Skin einen Eintrag zu übertragen führt aktuell über einen durch Tabs getrennten String. Viele andere Lösungen als String parsen und Sonderfont verwenden bleiben da aktuell nicht.

Doch, man nimmt für die Icons ein Sonderzeichen (um die INFORMATION "hier ICON_1 einfügen" (also sowas wie der IMG Tag in HTML) zu transportieren) was im normalen Text garantiert nicht vorkommt. Nach "*" zu suchen ums durch ein Icon zu ersetzen ist hier z.B. extrem ungünstig weils auch im ganz normalen Text vokommen kann.
Besser man nimmt anstelle von "*" z.B. das Zeichen 0xE010, das kommt garantiert nur an Postionenen vor an dem es wirklich durch das entsprechende New Icon ersetzt werden soll (Weil Zeichen Nummer 0xE010 ist in Unicode für genau solche Zwecke reserviert).
D.h. hier sind keine Fehlinterpretationen möglich und das parsen ist wesendlich einfacher (beim parsen nach "*" muss man ja auch den Kontext berücksichtigen (weil sonst erden alle "*" durch Icons ersetzt). Und DAS machts kompleziert (was passiert wenn ich per OSDserver nen Menü aufrufe und das "*" Icon anzeigne will?) und fehleranfällig).

cu

Irgendwelche Sonderzeichen durch die API zu senden ist keine Lösung sondern ein weiterer Workaround.

Alles, was nie den Weg direkt in den VDR finden wird, ist verschwendete Zeit, weil es wieder ein externer Patch ist und auch immer bleiben wird.

Wenn schon, dann sollte man gleich eine *richtige* Lösung implementieren oder es so lassen wie es ist. Aktuell geht ja zumindest String-Matching relativ ordentlich und zwar ohne den VDR zu patchen.

Zudem wird nicht einfach auf einen "*" gematcht (in der Skinelchi-Lösung) sondern auf einen Stern, der auf ganz bestimmte String-Muster folgt.

Und an der Stelle wäre es vermutlich Zeit mal kls auf den Thread zu verweisen?

Zitat von Mreimer

Irgendwelche Sonderzeichen durch die API zu senden ist keine Lösung sondern ein weiterer Workaround.

Das Problem ist das es immer irgendeine Art von Datenstruktur (und damit Steuerzeichen) geben muss wenn man eine Formatierung wünscht. Sei es HTML, RTF oder irgendwelche Office XML Formate. Mit plain ASCII bekommt man halt keine Formatierungen hin. Der old-Style Mailweg mit *fett* oder /kursiv/ ist nicht eindeutig maschinenlesbar und damit in diesem Fall unbrauchbar.

Zitat von Mreimer

Wenn schon, dann sollte man gleich eine *richtige* Lösung implementieren oder es so lassen wie es ist. Aktuell geht ja zumindest String-Matching relativ ordentlich und zwar ohne den VDR zu patchen.

Wobei ich den Sinn hier nicht wirklich sehe, den VDRSymbols Font braucht man eh für epgsearch, music, extrecmenu, systeminfo usw. Also hat man nix gewonnen ausser einigen Symbolen weniger und einen (von vielen) VDR Patchen weniger.

cu

Moin!

Wenn man sich skins.h ansieht, ist das Problem doch cSkinDisplayMenu:: SetItem. Ein wenig darunter gibt es schon einen Kommentar, der andere SetItem-Methoden vorschlägt. Als Parameter gibt's dann cEvent, cRecording, cTimer und cChannel. Dann müssen keine Sonderzeichen usw. herumgereicht werden, sondern das Skin kann direkt auf die Infos der anzuzeigenden Elemente zugreifen.

Wenn andere Plugins hier besondere Strukturen durchreichen wollen, die sie selbst definieren, dann gibt es natürlich ein Problem, denn dann müsste das Skin ja auch irgendwie einen Header aus dem anderen inkludieren, um die Daten interpretieren zu können. Das ist spätestens beim Paketbau schwierig, weil dann nur die Sourcen des Skins und die Header des vdr verfügbar sind. Es müsste dann wieder ein Patch für den vdr her, aber da würde eine neue Header-Datei reichen, das ist nicht schwierig.
Oder man muss das irgendwie serialisieren (z.B. XML o.ä.).

Da ich extrecmenu nicht kenne: Was könnten das für Daten-Strukturen sein? Gibt es andere Plugins, die besondere Daten an das Skin liefern müssten?

Formatierungen sind dabei nicht wichtig, darum muss sich das Menu-benutzende Plugin nicht kümmern. Es liefert nur Daten mit Semantik (neu, läuft gerade usw.), das Skin kümmert sich um die Formatierung. Fettdruck usw. muss also nicht übergeben werden.

Lars.

Das Problem mit dem Header ist schonmal gelöst worden. Und zwar bei der Kommunikation zwischen Plugins. Hier sendet der aufrufende eine Version mit. Das gerufene Plugin weiß dadurch welche Version der Struktur im Ziel-Plugin einkompiliert ist. Das gerufene Plugin kann dann entweder eine passende Struktur füllen und zurücksenden oder eben die Anfrage ablehnen.

Vorteil: Man kann die .h aus dem Plugin, welches man im Skin unterstützen will, in den eigenen Source kopieren.

Zitat von mini73

Oder man muss das irgendwie serialisieren (z.B. XML o.ä.).

Wobei XML hier wirklich overkill ist. Deswegenen die Idee eines leichten Formats indem einfach nur bestimmte reservierte Bytefolgen ein Bitmap representieren. Das schliest ja nicht aus das es dazu später auch komplexere Lösungen geben kann.

Zitat von mini73

Da ich extrecmenu nicht kenne: Was könnten das für Daten-Strukturen sein?

Witzigerweise ALLE Extrecmenu ist da ja extrem frei konfigurierbar. Man kann dort z.B. auch eine Filmwertung (Reihe von 5 Sternen, mehr oder weniger gefüllt) anhand der EPG Metadaten (TVMovie Filmwertung) anzeigen lassen. Oder man hat ne Anzeige des Sternbitmap bei allen Filmen die mit B Anfangen, es ist halt alles möglich. Der Inhalt von Spalten kann nämlich der stdout eines Shelscriptes sein.

Zitat von mini73

Gibt es andere Plugins, die besondere Daten an das Skin liefern müssten?

Im Prinzip gibts hier erstmal das osdserver plugin und das systeminfo Plugin wo die Daten absolut nicht vorhersagbar sind.

Wobei die Progressbar als erstes genormt werden sollte, weil die nutzen ja extrem viele Plugins, entweder als ASCII Art ("[|||| ]") oder per speziellen Symbolfont direkt. Der Rest, ja viele Plugins nutzen irgendwelche Symbole aus dem VDRSymbols Font. Wobei das nicht genormt ist (da gibt ja keine offizielle Liste wo sich Plugins registrieren müssen, das erschwert sowas ja), bei mir nutzt z.B. das PIN Plugin die Checkbox aus dem VDRSymbols Font (die letzte Release Version läuft nicht unter uft-8, also gibts hier Patchwildwuchs).

Zitat von mini73

Formatierungen sind dabei nicht wichtig, darum muss sich das Menu-benutzende Plugin nicht kümmern. Es liefert nur Daten mit Semantik (neu, läuft gerade usw.), das Skin kümmert sich um die Formatierung. Fettdruck usw. muss also nicht übergeben werden.

Im Prinzip vermischen sich hier zwei verschiedene Ideen, erstmal Metadaten und zweitens Textformatierungen (hier speziell Icons im Fliestext). Wobei der Wareagle Patch im Prinzip nur Textformatierungen (wenn man Icons zu den Formatierungen zählt) macht und in einigen Sonderfällen (Kanalliste) hier zusätzliche Metadaten über Formatierungen reinpackt.

Ich denke perfekt wäre eine Mischung aus beidem.
D.h. erstmal kann ein Plugin im Menü selber Icons einfügen (weil nur das Plugin weiss hier um die Bedeutung) oder sogar Sachen Fett, Ausgegraut usw. darstellen.
Aber eine Möglichkeit z.B. eine Spalte als Progressbar (mit den Atrributen VALUE=10;MAX_VALUE=100) zu taggen wäre natürlich auch sinnig damit der Skin sie dann selber rendern kann.

cu

Moin!

Zitat von Mreimer

Vorteil: Man kann die .h aus dem Plugin, welches man im Skin unterstützen will, in den eigenen Source kopieren.

Ok.

Keine_Ahnung:
Schau doch bitte mal in skins.h rein. Es gibt folgende Darstellungstypen, die ein Skin "rendern" muss:

• cSkinDisplayChannel: zeigt den aktuellen Kanal und evtl. EPG-Infos an, es bekommt cChannel- und cEvent-Objekte, hat also alle nötigen Daten.
• cSkinDisplayReplay: zeigt den Fortschritt einer Wiedergabe an und bekommt dafür Titel, Schnittmarken, Fortschritt, ob gespult wird, leider aber kein cRecordings-Objekt, das wäre vielleicht noch hilfreich
• cSkinDisplayVolume: zeigt die Lautstärke an und bekommt Current, Total, Mute - mehr braucht eine Lautstärkeanzeige nicht
• cSkinDisplayTracks: zeigt Daten vom verwendeten Audiokanal an
• cSkinDisplayMessage: zeigt einfach eine Nachricht an, bekommt dafür einen Nachrichtentyp und den Text

Und dann gibt es noch cSkinDisplayMenu (worum es hier eigentlich geht).
Es hat einen Titel, die Farbbuttons, eine einzeilige Nachricht und die "central area".
Im zentralen Bereich kann zum einen ein cEvent, cRecording oder Fließtext angezeigt werden.

Zum anderen kann dem Menü auch eine Liste mit "Items" übergeben werden, die momentan Tab-getrennt sind.
extrecmenu zeigt eigentlich nur Aufnahmen an, deshalb wäre eine Methode "SetItem" mit einem cRecording als Parameter völlig ausreichend. Eventuell noch ein SetItem, dass ein Aufnahme-(Unter-)Verzeichnis übergibt (Name + Anzahl der enthaltenen Aufnahmen?), ich weiß nicht, ob's da schon eine passende vdr-Klasse für gibt.
Jetzt gibt es die Aufnahmen, die z.B. aus dem DVD-Archiv kommen, wo dann ein anderes Symbol dargestellt werden soll. Das sollte nicht durch extrecmenu vorgegeben werden, sondern das Skin muss wissen, dass es eine spezielle Aufnahme ist, also z.B. eine von cRecording abgeleitete Klasse mit zusätzlichen Informationen aus der dvd.vdr (oder cRecording wird um eine Möglichkeit erweitert, spezielle Informationen während des Video-Directory-Scans durch ein Plugin im cRecording zu hinterlegen, eine einfache Key-Value-Liste müsste eigentlich reichen [so wie setup.conf mit Pluginname.Key=Value]).

Ein Plugin, dass ein Menü darstellt, sollte meiner Meinung nach keine Icons übergeben/anfordern können, sondern nur Informationen über die anzuzeigenden Objekte. Das Skin entscheidet dann, ob es an bestimmten Stellen ein Symbol darstellt. Es gibt nämlich auch Skins, die z.B. rein textbasiert arbeiten usw..
Und wenn es keine passende Klasse im vdr gibt, kann man es eben so machen, wie oben beschrieben - den passenden Header aus dem anderen Plugin zum Skin kopieren und benutzen. Dafür muss es dann z.B. eine SetItem-Methode geben, die wie bei der Service-Schnittstelle einen String mit Namen/Version des Objekts und ein Pointer übergibt, der dann per dynamic_cast<> umgewandelt werden kann.

Oder verstehe ich die Aufgabe eines Skins verkehrt?

Lars.

Zitat von mini73

Oder verstehe ich die Aufgabe eines Skins verkehrt?

Ich gaube du siehst das zu positiv Das wird niemand wirklich programieren und pflegen.

Nehmen wir man nen ganz simples Beispiel. Das Pin Plugin zeigt einfach eine Liste aller geperrten Sendungen, d.h. z.B. hat man dort ne Liste
----
Lindenstrasse
Big Brother
Tagesschau
----
willst du jetzt ne Klasse <sendungen> einführen und im Skin die Klasse <sendungen> fürs PIN Plugin berücksichtigen? Klar, hier könnte man ne generische Checklist Klasse einführen, aber dann zeige ich dir das nächste Beispiel was eine neue Anforderung bringt

Und hauptsächlich gehts ja bei der WarEagle/VDRSymbols Sache um solchen Kleinkram der auf viele Plugins verstreut ist.

cu

Zitat von mini73

Zum anderen kann dem Menü auch eine Liste mit "Items" übergeben werden, die momentan Tab-getrennt sind.
extrecmenu zeigt eigentlich nur Aufnahmen an, deshalb wäre eine Methode "SetItem" mit einem cRecording als Parameter völlig ausreichend. Eventuell noch ein SetItem, dass ein Aufnahme-(Unter-)Verzeichnis übergibt (Name + Anzahl der enthaltenen Aufnahmen?), ich weiß nicht, ob's da schon eine passende vdr-Klasse für gibt.

Problem ist hier, dass die Spalten der Anzeige im extrecmenu konfigurierbar sind. Und schon fällt die ganze Idee wie ein Kartenhaus zusammen...

Auch irgendwelche "Steuerzeichen" helfen garnicht, denn wenn ein Plugin ein Logo anfordert, dann muss immer auch das Skin ein passendes Logo haben. Wenn dieses fehlt, dann landet das Steuerzeichen entweder ungefiltert im OSD oder es fällt unter den Tisch, was dann Informationsverlust bedeutet.

Der Optimalfall wäre, dass das Plugin, welches das Menü aufbauen will, erstmal selber einen Satz Logos mitbringt und diese irgendwie in die Zeilen setzen kann. Das Skin sollte dabei die Chance haben, eben diese Logos zu übersteuern um ggf. zum Skin passende zu zeichnen.

Je länger ich darüber nachdenke um so attraktiver erscheint mir diese String-Parserei. Sie funktioniert jetzt schon. Sie benötigt keinen VDR-Patch und, wenn gut gemacht, ist sie auch zuverlässig. Das einzige, was ich mir hier noch wünschen würde, wäre ein eindeutiges Feedback zum Skin, in welchem Menü man sich befindet. So könnte man für das entsprechende Menü auch direkt passende Ersetzungen machen, ohne die Gefahr, dass eine Ersetzungsregel in einem anderen Menü unerwartete Nebeneffekte zeigt.

Man kann in die Doku schreiben "Wenn nach dem Datum ein Sternchen ist, dann ist die Aufnahme neu" oder man kann in ein Skin programmieren "Wenn der Inhalt eindeutig als Datum erkennbar ist und das Ding auf einen Stern endet, dann hau den Stern weg und male ein Icon".

Zitat von Keine_Ahnung

Nehmen wir man nen ganz simples Beispiel. Das Pin Plugin zeigt einfach eine Liste aller geperrten Sendungen, d.h. z.B. hat man dort ne Liste

Man baue eine Alternative dazu, die mit Ascii auskommt (z.B. Sternchen ist gewählt und kein Sternchen ist abgewählt). Hätte man nun zum Skin hin ein Feedback der Form "das ist das pinplugin-Menü", dann könnte man einfach das erste Feld separieren und bei Sternchen ein angehaktes und andernfalls ein nicht angehaktes Kästchen zeichnen. Bei einem Skin ohne Support für diese Ersetzung ist aber dennoch mit jedem Font eine brauchbare Ansicht verfügbar.

Ich glaube den Gedanken, dass es sinnvoll ist, das Wissen über das aktuelle Menü um Skin zu haben, gehe ich jetzt mal an kls. Das scheint mir das absolute Minimum zu sein, um vom Skin aus sinnvoll Logos ins OSD zu bekommen.

Moin!

Genau solche Beispiele brauchen wir, damit wir überhaupt mal einen Überblick bekommen, danke!
Gib mir mehr...

Ich betreibe meinen vdr eigentlich nur als Aufnahmeserver, die Aufnahmen sehe ich mir meistens direkt per USB am TV an, da ich noch keine HD-Ausgabe habe. Deshalb kenne ich fast keine "Oberflächen-affine" Plugins bzw. kenne nur das, was sich von Live aus steuern lässt. Aber das soll sich ja auch irgendwann mal ändern...

Wenn man erst mal ein kleines Bündel an Grundklassen hat, wird man sehen, wie sich das entwickelt. Denn dann werden die anderen Plugin-Entwickler auch anfangen, diese Teile zu benutzen. Und dann stellt man schnell fest, was noch so fehlt...

Lars.
(hach, ist das schön, mal wieder vernünftig zu diskutieren... Ich bin gespannt auf das Ergebnis )

Zitat von Mreimer

Auch irgendwelche "Steuerzeichen" helfen garnicht, denn wenn ein Plugin ein Logo anfordert, dann muss immer auch das Skin ein passendes Logo haben.

Es gibt doch eine offizielle Liste aller VDR OSD Symbole. Will ein Plugin ein neues Symbol haben muss es das dort registrieren, das funktioniert rein praktisch seit Jahren einwandfrei.

Zitat von Mreimer

Man kann in die Doku schreiben "Wenn nach dem Datum ein Sternchen ist, dann ist die Aufnahme neu" oder man kann in ein Skin programmieren "Wenn der Inhalt eindeutig als Datum erkennbar ist und das Ding auf einen Stern endet, dann hau den Stern weg und male ein Icon".

Nur der Skin liest keine Diokus von irgendwelchen Plugins die beim User installiert sind

Es geht ja auch darum das sowas praktisch funktionieren muss. Und nicht nur in der Therorie wo der Skin Author nix besserer zu tun hatals den Plugins hinterherzusuchen

Zitat von Mreimer

Man baue eine Alternative dazu, die mit Ascii auskommt (z.B. Sternchen ist gewählt und kein Sternchen ist abgewählt).

2011 darf man gerne etwas anspruchsvoller sein Und Symbole sind gewünscht, deswegen gibts den WarEagle Patch.

Zitat von Mreimer

Hätte man nun zum Skin hin ein Feedback der Form "das ist das pinplugin-Menü", dann könnte man einfach das erste Feld separieren und bei Sternchen ein angehaktes und andernfalls ein nicht angehaktes Kästchen zeichnen.

Oder man nutzt einfach den angeharkte Käststchen im String. Dann ist es egal wo der String herkommt.

Zitat von Mreimer

Bei einem Skin ohne Support für diese Ersetzung ist aber dennoch mit jedem Font eine brauchbare Ansicht verfügbar.

Ein Skin ohne Symbolsupport (Symbolsuppurt meint für die Symbolbytes im String die PNB Symbole darstellen) ersetzt einfach die max. 20 Symbole durch ihre ASCII Entsprechung. Da kann man einfach eine generische Funktion in den VDR einbauen die Zeichenweise durch den übergebenen String geht und alle speziellen Symbolbytes durch ihre ASCII Entsprechungen ersetzt.

cu