Verletzung der Plugin-Schnittstelle

Hier haben Plugin-Entwickler die Möglichkeit, sich auszutauschen.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

Aber warum "Meta"? Das sind doch keine Meta-Daten, sondern ganz normale Daten...

Also ich sehe das eher so wie Bodo: So einfach wie möglich. Ich würde sogar noch etwas weiter gehen und nur Strings zulassen.

Man könnte z.B. die Plugin-Schnittstelle um folgende Methoden erweitern:

Code: Alles auswählen

void setProgramCookie(Program prog, String key, String value);
String getProgramCookie(Program prog, String key);
Mit der Konvention, dass der Key immer mit dem Klassennamen des Plugins anfängt. Z.B. "tvraterplugin.TVRaterPlugin.rating". Man könnte das auch erzwingen. Soll heißen: Wenn ein Wert gesetzt wird, dann muss er mit dem Klassennamen des Plugins beginnen...

Der Name "Cookie" ist nur ein Vorschlag. vielleicht fällt euch ja was besseres ein.

Statt nur Strings könnte man auch ein festes Set von Primitiven erlauben (Z.B. String, Integer, Double). Aber Beans fände ich etwas übertrieben.

Außerdem sollte TV-Browser das Speichern dieser Werte übernehmen. Ist ja unsinnig, dass das jedes Plugin für sich implementieren muss. Da wäre es wieder vorteilhaft, wenn die Werte nur Primitive sind.

@pck: Sag doch mal bitte ein konkretes Szenario, wie du das ganze einsetzen würdest. Was machst du beispielsweise mit den Bewertungen von Bodo?
Benutzeravatar
bodo
Site Admin
Beiträge: 19635
Registriert: 03 Dez 2003, 19:37
Wohnort: Köln
Kontaktdaten:

Beitrag von bodo »

Stimmt, der TV-Browser sollte das speichern übernehmen. Ansonsten rennen ziemlich viele Plugins beim Start durch alle Daten und fügen ihre Meta/Cookies ein, und das dauert ;)
pumpkin
Gold Member
Beiträge: 236
Registriert: 29 Dez 2004, 10:52
Wohnort: Vichten/Luxemburg
Kontaktdaten:

Beitrag von pumpkin »

Ob du das Ding Cookie oder Meta taufst ist mir natürlich wurscht.

Nur Primitive bringt ein kleines Problem: wenn ein Plugin Bilder reinstellen möchte gibts byte[] oder URL. Aber damit kann man durchaus leben. (Lieber nur Primitive als gar nix...)

Also auf die toDo-Liste von 1.2 ?
Martin
Site Admin
Beiträge: 2357
Registriert: 03 Dez 2003, 21:45
Kontaktdaten:

Beitrag von Martin »

Etwas ganz ähnliches gibt es schon in der 1.1 für den Baum:
Plugins können ihre Sendungen in einer Baumstruktur ablegen - die Speicherung übernimmt TV-Browser. Außerdem können zu jedem Knoten Properties gespeichert werden. Da sind allerdings nur Strings (für key und value) möglich. Das wird vom neuen Reminder verwendet.

Allerdings war das nicht plugin-übergreifend gedacht.
Benutzeravatar
bodo
Site Admin
Beiträge: 19635
Registriert: 03 Dez 2003, 19:37
Wohnort: Köln
Kontaktdaten:

Beitrag von bodo »

Im Tree werden die Daten für was anderes gebraucht. Das kann/sollte man nich so umfrickeln, das es für Programme auch benutzt wird, oder?!

Dann lieber eine neue Funktion in den Program die die Daten speichern kann.

Aber vielleicht kann man ja einen Daten-Container schaffen der in beiden benutzt wird...

program.getMetaContainer().getIntValue("tvrater.overallrating")

Das spart arbeit und man kann überall das zeug gleich benutzen
Martin
Site Admin
Beiträge: 2357
Registriert: 03 Dez 2003, 21:45
Kontaktdaten:

Beitrag von Martin »

bodo hat geschrieben:Im Tree werden die Daten für was anderes gebraucht. Das kann/sollte man nich so umfrickeln, das es für Programme auch benutzt wird, oder?!
Der Tree enthält pro Knoten Programm-Id und Properties dazu.

Aber wie gesagt, das ist nicht pluginübergreifend. Dh jedes Plugin hat seinen eigenen Teilbaum.
Dann lieber eine neue Funktion in den Program die die Daten speichern kann.
hä?
Benutzeravatar
bodo
Site Admin
Beiträge: 19635
Registriert: 03 Dez 2003, 19:37
Wohnort: Köln
Kontaktdaten:

Beitrag von bodo »

Im Progam-Interface meinte ich. Ich will nich die Daten für jedes Programm im Tree speichern müssen...dann wäre der Baum bei meinem Bewerter-Plugin rieeesig groß
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

War mir ja fast klar das keine konkreten Gegenvorschläge für TVB1.0.1-kompatible Plugins kommen. Nur noch mehr vom allgemeinen Gemecker.
bodo hat geschrieben:wenn du an der Plugin-Schnittstelle vorbei arbeitest, dann können wir dir nicht garantieren das dein Plugin in der nächsten Version läuft. Das heißt du hast erhöhten Pflege-Aufwand.
Du meinst im Gegensatz zu "wenn du nur offizielle Funktionen nutzt garantieren wir auch nichts"?

Oder im Gegensatz zu "wenn du's auf dem offiziellen Weg nicht programmieren kannst, spar dir dir Mühe und schreib einfach kein Plugin".
bodo hat geschrieben:Und wenn ein Autofahrer sagt das er den Blinker nich findet, baut der Hersteller doch nich noch einen 2. Knopf ein der auch noch den Blinker betätigt, oder ;) ? Dann positioniert er den Blinker anders.
Wenn ein Zulieferer die Blinkersteuerung über den Kofferraum anbietet sollte der Autobauer auf einen Blinker am Lenker verzichten, bis der Zulieferer 2007 andere Teile liefern kann? Bullshit.

Aber schauen wir mal, wie sich andere Plugins an die "tvbrowser.* nicht in Plugins" Regel halten ...

Code: Alles auswählen

CapturePlugin, Bodo Tasche / troggan / bodum: tvbrowser.core.Settings
FavoritesPlugin, Til Schneider / darras: tvbrowser.core.filters.FilterList
ListViewPlugin, Bodo Tasche / troggan / bodo: tvbrowser.core.Settings
ReminderPlugin, Martin Oberhauser / darras: tvbrowser.core.plugin.PluginProxy
Echt super, dass die größten Nörgler bei mir andere Maßstäbe ansetzen als bei sich selber. Und im Gegensatz zu mir können die alle die Plugin-Schnittstelle erweitern. :-(

Wenn ihr wirklich Kompatibilität mit der Zukunft wollt ...
... haltet euch an die Empfehlung, jede JComponent Accessible zu machen.
(Vielleicht bringt's nichts in Bezug auf die aktuellen Mac-Probleme, aber sauberer ist's dennoch.)
... haltet euch beim Überladen an den DesignContract.
(programpanel.getHeight() != programpanel.getSize().height)
... meidet reservierte Schlüsselworte als Variablennamen.
("Enumeration enum" verursacht aus gutem Grund seit Jahren eine Warnung.)
... nutzt evtl. WebStart anstelle eines plattformabhängigien Installers.

Und wenn ihr Pluginprogrammierer nicht vergraulen wollt macht EINMAL einen KONKRETEN Vorschlag wie es besser geht anstatt wiederholt allgemeine Kritik zu äußern.

(So, hab mich hiermit erforgreich an die "wenn du dich ärgerst antworte erst am nächsten Tag"-Regel gehalten. :-))
Martin
Site Admin
Beiträge: 2357
Registriert: 03 Dez 2003, 21:45
Kontaktdaten:

Beitrag von Martin »

pck hat geschrieben:War mir ja fast klar das keine konkreten Gegenvorschläge für TVB1.0.1-kompatible Plugins kommen. Nur noch mehr vom allgemeinen Gemecker.
Wer meckert hier? Til und Bodo sind auf der Suche nach einer Lösung wie du siehst.
Oder im Gegensatz zu "wenn du's auf dem offiziellen Weg nicht programmieren kannst, spar dir dir Mühe und schreib einfach kein Plugin".
Merkwürdig. Ich kann sowas aus keinem Posting herauslesen.

Code: Alles auswählen

CapturePlugin, Bodo Tasche / troggan / bodum: tvbrowser.core.Settings
FavoritesPlugin, Til Schneider / darras: tvbrowser.core.filters.FilterList
ListViewPlugin, Bodo Tasche / troggan / bodo: tvbrowser.core.Settings
ReminderPlugin, Martin Oberhauser / darras: tvbrowser.core.plugin.PluginProxy
Da hast du recht - diese Abhängigkeiten müssen weg.

Wenn du über die Pluginschnittstelle hinweg programmierst, mußt du einfach damit rechnen, daß das Plugin in einer späteren TV-Browser-Version nicht mehr funktioniert. Das ist dir sicher klar. Wenn du das ingnorierst, ist das deine Sache.
Änderungen an der Schnittstelle hingegen geben wir frühzeitig bekannt bzw. wir markieren die Methoden als @deprecated.
Und wenn ihr Pluginprogrammierer nicht vergraulen wollt macht EINMAL einen KONKRETEN Vorschlag wie es besser geht anstatt wiederholt allgemeine Kritik zu äußern.
Nur Geduld - dieser Thread ist dazu da, um eine gute Lösung zu finden. Warte doch erstmal ab.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

@pck: Es gibt keinen Grund, sich zu ärgern. Das ist hier keine wir-gegen-dich- oder wir-haben-Recht-und-du-nicht-Sache. Es ist eine sachliche Diskussion. Also bitte nimm das nicht persönlich. Wir sind gerne bereit, auf alle Vorschläge einzugehen. Aber du musst auch akzeptieren, wenn andere eine andere Meinung haben.
pck hat geschrieben:Wie erfährt man ohne Settings von wann bis wann ein Tag läuft?
Das geht in der Tat noch nicht. Wenn du das brauchst, dann müssen wir den PluginManager erweitern.
pck hat geschrieben:Wie informiere ich ProgramChangeListener, dass sich meine Icons verändert haben?
Da gibt es einen Workaround: Rufe beim betroffenen Program mark und gleich wieder unmark auf, dann wird es neu gezeichnet.
pck hat geschrieben:Wie deaktiviert sich ein Plugin bei 1.0.1 ohne internes Wissen?
Ein Plugin sollte sich nicht selbst deaktivieren. Warum brauchst du das?
pck hat geschrieben:
Til hat geschrieben:Wir können die Icon-Einstellung ja so ändern, wie wir es auch bei den Plugins gemacht haben: Standardmäßig sind alle eingeschalten.
Dann hätte LocalImdb ja dieselben "Rechte" wie die mitgelieferten Plugins. :roll: Bleibt aber Bodos berechtigter Einwand: "Wenn du einfach magisch Icons anmachst, weiß ja keiner wo man die aus macht und die Reihenfolge ändert."
So, wie es im Moment ist, ist es natürlich nicht gut: Der Benutzer installiert ein Plugin und muss dann TV-Browser gut genug kennen, um zu wissen, dass er zusätzlich die Icons aktivieren muss, damit er was sieht. Da denkt natürlich keiner dran. Zuerst denkt man, dass die Installation des Plugins nicht geklappt hat. Ergo sucht man an der falschen Stelle.

Ich fände es trotzdem am besten, wenn Icons standardmäßig angeschlten sind. Man kann davon ausgehen, dass der Anwender alle Icons will. Wie du bereits gesagt hast: Viele Plugins haben ohne Icons gar keinen Sinn.

Wenn er eines explizit nicht will, dann muss er halt die Einstellungsseite finden. Dann sucht er aber auch nach der richtigen Funktion. Und "Aussehen/Sendungsanzeige" ist doch eigentlich passend.
pck hat geschrieben:Wie wäre es wenn ihr mich einfach mal machen lasst, und nach paar Monaten "Erfahrung sammeln" reden wir darüber ob Plugins wie bei Such-Panels auch bei PluginIcon-Panels einen offiziellen Funktionsaufruf kriegen.
Such-Panels sind etwas anderes. Da geht es nicht um ein und die selbe Funktion. Ob ich eine Lieblingssendung einstelle, einen Filter zusammenbaue oder ob ich jetzt eine Suche durchführen will, sind verschiedene Funktionen.
pck hat geschrieben:Es wäre schon sehr arm, wenn man in einem OpenSource™ Projekt die Features beschränkt, nur weil etwas nicht von den Schöpfern vorgesehen ist.
Das hat nichts mit Open-Source oder nicht-Open-Source zu tun. Es geht nur darum, dass eine wachsende Software beherrschbar bleibt. Um das zu ermöglichen gibt es gewisse Techniken, die wir einhalten wollen.
pck hat geschrieben:War mir ja fast klar das keine konkreten Gegenvorschläge für TVB1.0.1-kompatible Plugins kommen. Nur noch mehr vom allgemeinen Gemecker.
Tschuldigung, dass ich jetzt erst genau auf deine Punkte eingangen bin. Ich dachte, die Antworten von pumpkin wären deine gewesen. Hab ich übersehen...
pck hat geschrieben:
bodo hat geschrieben:wenn du an der Plugin-Schnittstelle vorbei arbeitest, dann können wir dir nicht garantieren das dein Plugin in der nächsten Version läuft. Das heißt du hast erhöhten Pflege-Aufwand.
Du meinst im Gegensatz zu "wenn du nur offizielle Funktionen nutzt garantieren wir auch nichts"?

Oder im Gegensatz zu "wenn du's auf dem offiziellen Weg nicht programmieren kannst, spar dir dir Mühe und schreib einfach kein Plugin".
Was soll denn das jetzt? Ist das eine Anspielung auf die Änderung der Plugin-Schnittstelle in Version 1.1?

Genau diese Änderung ist wie ich finde der beste Beweis, wie wichtig die Schnittstelle ist. Bei dem Umbau habe ich extrem darauf geachtet, dass alte Plugins trotzdem noch laufen. Bei einer klar definierten Schnittstelle kann man bei Änderungen die alten Sachen als deprecated deklarieren und sie so umschreiben, dass sie immer noch funktionieren. Dann kann man auch einen Wiki-Artikel schreiben, in dem man genau erklärt, was sich verändert hat, so dass der Aufwand für beide Seiten minimiert werden kann.

Wenn du einfach auf TV-Browser-Interna zugreifst, dann kann alles mögliche passieren. Es kann sein, dass es die Klassen/Methoden gar nicht mehr gibt. Es kann sein, dass sie bestimmte andere Vorbedingungen erwarten. Es wird also ein elendes Chaos.
pck hat geschrieben:
bodo hat geschrieben:Und wenn ein Autofahrer sagt das er den Blinker nich findet, baut der Hersteller doch nich noch einen 2. Knopf ein der auch noch den Blinker betätigt, oder ;) ? Dann positioniert er den Blinker anders.
Wenn ein Zulieferer die Blinkersteuerung über den Kofferraum anbietet sollte der Autobauer auf einen Blinker am Lenker verzichten, bis der Zulieferer 2007 andere Teile liefern kann? Bullshit.
Wenn du findest, dass sich die Icon-Einstellungen "im Kofferraum" befinden, dann sag uns einen besseren Platz. Wenn ein Blinkerhebel im Kofferraum ist, dann macht keinen zweiten dazu, sondern man packt den Hebel aus dem Kofferraum wo anders hin...
pck hat geschrieben:Aber schauen wir mal, wie sich andere Plugins an die "tvbrowser.* nicht in Plugins" Regel halten ...

Code: Alles auswählen

CapturePlugin, Bodo Tasche / troggan / bodum: tvbrowser.core.Settings
FavoritesPlugin, Til Schneider / darras: tvbrowser.core.filters.FilterList
ListViewPlugin, Bodo Tasche / troggan / bodo: tvbrowser.core.Settings
ReminderPlugin, Martin Oberhauser / darras: tvbrowser.core.plugin.PluginProxy
Echt super, dass die größten Nörgler bei mir andere Maßstäbe ansetzen als bei sich selber. Und im Gegensatz zu mir können die alle die Plugin-Schnittstelle erweitern. :-(
Natürlich gelten die Regeln genauso auch für uns. Stimmt. Wir haben vereinzelt (und es ist wirklich vereinzelt) auch auf das tvbrowser-Package zugegriffen. Aber glaube mir, wenn ich dir sage, dass das aus Versehen passiert ist.

Wir werden das umgehend ändern.
pck hat geschrieben:Wenn ihr wirklich Kompatibilität mit der Zukunft wollt ...
... haltet euch an die Empfehlung, jede JComponent Accessible zu machen.
(Vielleicht bringt's nichts in Bezug auf die aktuellen Mac-Probleme, aber sauberer ist's dennoch.)
... haltet euch beim Überladen an den DesignContract.
(programpanel.getHeight() != programpanel.getSize().height)
... meidet reservierte Schlüsselworte als Variablennamen.
("Enumeration enum" verursacht aus gutem Grund seit Jahren eine Warnung.)
... nutzt evtl. WebStart anstelle eines plattformabhängigien Installers.
Mann mann, jetzt gräbst du aber Sachen aus... Wir haben nie behauptet, dass wir perfekt sind. Wir haben auch nie behauptet, dass wir in irgend einer Weise besser als Du oder jemand anderes sind. Also bitte reiss dich mal am Riemen und verstehe, dass das hier kein persönlicher Angriff ist...

Es gibt überhaupt keinen Grund derart emotional zu reagieren. Wir haben eine bestimmte Meinung, die wir sachlich erklären. Wenn du anderer Meinung bist, dann schreibe sie uns. Aber akzeptiere, dass es andere Meinungen gibt und gehe nicht gleich in die Luft...
pck hat geschrieben:Und wenn ihr Pluginprogrammierer nicht vergraulen wollt macht EINMAL einen KONKRETEN Vorschlag wie es besser geht anstatt wiederholt allgemeine Kritik zu äußern.
Jemanden zu vergraulen wäre das letzte, was wir wollen. IMHO war unsere Kritik auch durchaus konstruktiv...

Wir sind der Überzeugung, dass das Design-Prinzip mit der Plugin-Schnittstelle wichtig ist, wenn TV-Browser in absehbarer Zeit noch stabil laufen soll. Das heißt nunmal, dass sich Plugins an die Schnittstelle halten sollen.

Im Umkehrschluss heißt das: Wenn ein Plugin eine Funktionalität braucht, die die Plugin-Schnittstelle nicht hergibt, dann muss von unserer Seite eine offizielle Möglichkeit dafür geschaffen werden.

Alles andere würde dazu führen, dass die Software innerhalb kürzester Zeit nicht mehr beherrschbar wird. Dann treten die typischen Symptome von verrotteter Software auf: Man ändert etwas an einer Stelle und an einer völlig anderen Stelle kracht es. Und kein Mensch ist mehr in der Lage das undurchschaubare Dickicht von Abhängigkeiten zu verstehen. Der Aufwand für Änderungen steigt ins unermessliche und keiner hat mehr Lust, irgend etwas zu machen, weil er Angst hat, er macht mehr kaputt als besser.
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

Til hat geschrieben:
pck hat geschrieben:Wie erfährt man ohne Settings von wann bis wann ein Tag läuft?
Das geht in der Tat noch nicht. Wenn du das brauchst, dann müssen wir den PluginManager erweitern.
Ja, ich nutze das bereits in TVB1.0.1 und fremde Plugins nutzen auch die Settings daher ... (*edit* ... sollte man das tun und es gleich für alle bisherigen Zwecke einheitlich lösen.)
Til hat geschrieben:
pck hat geschrieben:Wie informiere ich ProgramChangeListener, dass sich meine Icons verändert haben?
Da gibt es einen Workaround: Rufe beim betroffenen Program mark und gleich wieder unmark auf, dann wird es neu gezeichnet.
Okay, ist ineffizienter aber könnte schnell genug sein ... muss das mal testen.
Til hat geschrieben:
pck hat geschrieben:Wie deaktiviert sich ein Plugin bei 1.0.1 ohne internes Wissen?
Ein Plugin sollte sich nicht selbst deaktivieren. Warum brauchst du das?
Angeblich kann Benutzern von meinem QuickScroll-Plugin schlecht werden. ;) Die wollen dann sehr wohl dass sich das Plugin deaktiviert. TVB1.0.1 stellt zwar einen "Deaktivieren" Button zur Verfügung, Plugins werden aber erst in TVB1.1 von dem Button in Kenntniss gesetzt, daher nutze ich da einen Workaround.
Til hat geschrieben:Ich fände es trotzdem am besten, wenn Icons standardmäßig angeschlten sind. Man kann davon ausgehen, dass der Anwender alle Icons will. Wie du bereits gesagt hast: Viele Plugins haben ohne Icons gar keinen Sinn.
Prima. Wenn eine stabile Version vom TV-Browser das mal unterstützt werde ich LocalImdb umbauen müssen. Ganz egal welche Zwischenlösung ich ich nun realisiere.
Til hat geschrieben:Was soll denn das jetzt? Ist das eine Anspielung auf die Änderung der Plugin-Schnittstelle in Version 1.1?

Genau diese Änderung ist wie ich finde der beste Beweis, wie wichtig die Schnittstelle ist. Bei dem Umbau habe ich extrem darauf geachtet, dass alte Plugins trotzdem noch laufen.
Mein Plugin wird eine aktuelle Konfigurationsoption wahrscheinlich verlieren, da Schnittstellen die in 1.0.1 nichteinmal deprecated waren in 1.1 gänzlich fehlen. LocalImdb läuft zwar mit 1.1, muss aber hierdurch zur Zeit gegen 1.0.1 kompiliert werden. Vielleicht könnte man Methodenaufrufe per Reflection in Zukunft irgendwie zulassen? Dann könnten Plugins die Features aus verschiedenen TV-Browser-Versionen parallel anbieten.

Ich finde es trotzdem gut was ihr im CVS macht. Ich werde mir aber nicht jetzt schon den Kopf wegen 1.2+-Kompatibilität zerbrechen.
til hat geschrieben:Wenn du findest, dass sich die Icon-Einstellungen "im Kofferraum" befinden, dann sag uns einen besseren Platz.
Mein aktueller Ansatz ist die Option zusammen mit den anderen Plugin-Relevanten Optionen zu zeigen. Eventuell finde ich die Idee in einem Monat selber scheiße ... fragt mich dann. :-)

Eine Alternative wäre, als Text anzuzeigen ob die Icons aktiv sind oder nicht. Und ein Button könnte bei Betätigung das korrekte Panel öffnen.
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

"mark und gleich wieder unmark" läuft super.
Benutzeravatar
Til
Site Admin
Beiträge: 1498
Registriert: 04 Dez 2003, 11:21
Wohnort: Karlsruhe
Kontaktdaten:

Beitrag von Til »

pck hat geschrieben:
Til hat geschrieben:
pck hat geschrieben:Wie erfährt man ohne Settings von wann bis wann ein Tag läuft?
Das geht in der Tat noch nicht. Wenn du das brauchst, dann müssen wir den PluginManager erweitern.
Ja, ich nutze das bereits in TVB1.0.1 und fremde Plugins nutzen auch die Settings daher ...
Bei so einer Kleinigkeit ist das ja als Übergangslösung OK. Du greifst ja nicht tief in die TV-Browser-Interna ein und das nur lesend.

Aber bitte sag uns bei sowas Bescheid, damit wir die Plugin-Schnittstelle erweitern können, so dass du als Plugin-Entwickler sauber arbeiten kannst.

Ich werden den PluginManager erweitern, so dass du den Tagesanfang und -start auslesen kannst. Nebenbei gefragt: Wozu brauchst du das denn?
pck hat geschrieben:Angeblich kann Benutzern von meinem QuickScroll-Plugin schlecht werden. ;) Die wollen dann sehr wohl dass sich das Plugin deaktiviert. TVB1.0.1 stellt zwar einen "Deaktivieren" Button zur Verfügung, Plugins werden aber erst in TVB1.1 von dem Button in Kenntniss gesetzt, daher nutze ich da einen Workaround.
Das kapier ich jetzt nicht ganz. Wenn ein Benutzer ein Plugin nicht mehr will, dann kann er es doch in den Einstellungen deaktivieren. Warum muss das das Plugin machen?
pck hat geschrieben:
Til hat geschrieben:Ich fände es trotzdem am besten, wenn Icons standardmäßig angeschalten sind. (...)
Prima. Wenn eine stabile Version vom TV-Browser das mal unterstützt werde ich LocalImdb umbauen müssen. Ganz egal welche Zwischenlösung ich ich nun realisiere.
OK. Damit kann ich leben. Von mir aus kannst du bis dahin deine Icons "magisch" aktivieren. Das entspricht dann dem späteren Verhalten.
pck hat geschrieben:Mein Plugin wird eine aktuelle Konfigurationsoption wahrscheinlich verlieren, da Schnittstellen die in 1.0.1 nichteinmal deprecated waren in 1.1 gänzlich fehlen. LocalImdb läuft zwar mit 1.1, muss aber hierdurch zur Zeit gegen 1.0.1 kompiliert werden. Vielleicht könnte man Methodenaufrufe per Reflection in Zukunft irgendwie zulassen? Dann könnten Plugins die Features aus verschiedenen TV-Browser-Versionen parallel anbieten.
Welche Schnittstellen meinst du denn? Und welche Methoden gibt es jetzt nicht mehr?

Hast du mal den Artikel über das neue Pluginsystem gelesen? Siehe: http://wiki.tvbrowser.org/index.php/Das ... rowser_1.1

Das einzige, was nicht mehr rückwärtskompatibel ist, ist der Zugriff auf andere Plugins. Das konnten wir leider nicht retten, weil wir mit der Version 1.1 die Plugin hinter PluginProxies kapseln, so dass RuntimeExceptions abgefangen werden.
pck hat geschrieben:
til hat geschrieben:Wenn du findest, dass sich die Icon-Einstellungen "im Kofferraum" befinden, dann sag uns einen besseren Platz.
Mein aktueller Ansatz ist die Option zusammen mit den anderen Plugin-Relevanten Optionen zu zeigen. Eventuell finde ich die Idee in einem Monat selber scheiße ... fragt mich dann. :-)

Eine Alternative wäre, als Text anzuzeigen ob die Icons aktiv sind oder nicht. Und ein Button könnte bei Betätigung das korrekte Panel öffnen.
Also mir gefällt beides nicht. Dann mach die Icons lieber magisch an. Dein Plugin macht ohne Icons sowieso keinen Sinn. Wenn jemand deine Icons nicht will, dann muss er halt dein Plugin deaktivieren.

In der nächsten Version werden sie ja dann automatisch aktiviert, so dass du keinen "Hack" mehr machen musst.
Benutzeravatar
bodo
Site Admin
Beiträge: 19635
Registriert: 03 Dez 2003, 19:37
Wohnort: Köln
Kontaktdaten:

Beitrag von bodo »

Ich benutze die Settings-Klasse, aber ohne die kann man an den Stellen nich leben. Es macht also Sinn, die Settings-Klasse zu verschieben, so das die nich mehr im Core ist. Ein Plugin sollte alle Settings auslesen können, nicht nur Tages-Anfang/Ende, oder nich?

Ich brauch das um die Zeit-Knöpfe und das User-Verzeichniss auszulesen.
pck
Plugin-Developer
Beiträge: 108
Registriert: 26 Jan 2005, 08:59
Wohnort: Ilmenau
Kontaktdaten:

Beitrag von pck »

til hat geschrieben:Ich werden den PluginManager erweitern, so dass du den Tagesanfang und -start auslesen kannst. Nebenbei gefragt: Wozu brauchst du das denn?
Meine Übersichts-Dialoge sind recht nervig wenn sie Punkt Mitternacht aufhören. Und da der Benutzer ohnehin angibt was "seine" Tagesgrenzen sind sollte man die hier nutzen.
til hat geschrieben:
pck hat geschrieben:... TVB1.0.1 stellt zwar einen "Deaktivieren" Button zur Verfügung, Plugins werden aber erst in TVB1.1 von dem Button in Kenntniss gesetzt, ...
Das kapier ich jetzt nicht ganz. Wenn ein Benutzer ein Plugin nicht mehr will, dann kann er es doch in den Einstellungen deaktivieren. Warum muss das das Plugin machen?
Das Plugin muss die Deaktivierung manchmal mit zusätzlichem Code unterstützen. Ihr habt ja daher auch in 1.1 die "onDeactivate()" Funktion hinzugefügt.
til hat geschrieben:Das einzige, was nicht mehr rückwärtskompatibel ist, ist der Zugriff auf andere Plugins. Das konnten wir leider nicht retten, weil wir mit der Version 1.1 die Plugin hinter PluginProxies kapseln, so dass RuntimeExceptions abgefangen werden.
Genau, nur hätte man ja erstmal die Funktion deprecated belassen können und meinetwegen eine leere Pluginliste liefern können. Ansonsten haben Plugin-Programmierer nur unnötig Stress. Und ein Ersatzmechanismus, das Zugriff auf "ungebundene" Methoden anderer Plugins erlaubt ist noch nicht vorhanden. Und selbst wenn er vorhanden wäre könnte ich kein versionsunabhängiges Plugin schreiben, da Reflection hier nur eingeschränkt erlaubt ist.
Antworten