Wünsche Kanalsuche und Bouquetverwaltung
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
Wünsche Kanalsuche und Bouquetverwaltung
Hallo!
Wäre es möglich bei der Kanalsuche eine Option "hinzufügen" mit einzubauen?
Dann würden Kanäle bei einer Kanalsuche nicht gelöscht z.B. hinzugefügt Unterkanäle bei Direkt oder Sport.
In der Bouquetverwaltung wäre es schön wenn man Kanäle oder Bouquets ganz löschen könnte.
Es ist ja so, daß beim löschen eines Kanals dieser aus der bouquets.xml gelöscht wird
und dadurch ein neues Bouquet "Andere", das nicht gelöscht werden kann, angelegt wird.
Abhilfe wäre, wenn der Kanal oder das Bouquet nicht aus der bouquets.xml sondern gleich aus
der services.xml gelöscht würde.
Gruß Nachtvogel
Wäre es möglich bei der Kanalsuche eine Option "hinzufügen" mit einzubauen?
Dann würden Kanäle bei einer Kanalsuche nicht gelöscht z.B. hinzugefügt Unterkanäle bei Direkt oder Sport.
In der Bouquetverwaltung wäre es schön wenn man Kanäle oder Bouquets ganz löschen könnte.
Es ist ja so, daß beim löschen eines Kanals dieser aus der bouquets.xml gelöscht wird
und dadurch ein neues Bouquet "Andere", das nicht gelöscht werden kann, angelegt wird.
Abhilfe wäre, wenn der Kanal oder das Bouquet nicht aus der bouquets.xml sondern gleich aus
der services.xml gelöscht würde.
Gruß Nachtvogel
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Parse error. Was hat Kanalsuche mit Unterkanäle zu tun? Möglicherweise meinst du dass nicht (mehr) gefundene Kanäle nicht einfach von services.xml gelöscht sein soll, sondern irgendwie in einem "Papierkorb" (<junk><transponder>...</transponder></junk>) verschoben soll?Wäre es möglich bei der Kanalsuche eine Option "hinzufügen" mit einzubauen?
Dann würden Kanäle bei einer Kanalsuche nicht gelöscht z.B. hinzugefügt Unterkanäle bei Direkt oder Sport.
services.xml ist ein Datenbank über gefundene Services, hier (in Unterschied zu bouquets.xml) soll der User nicht rumfummeln (dürfen).
Ntürlich kannst du als "Poweruser" services.xml und bouquets.xml mit einem geeigneten Editor modifizieren. Dann aufpassen so dass zapit nicht beim Runterfahren deine Änderungen vernichtet.
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
Ja, genau so meinte ich das. Die Unterkanäle waren nur ein Beispiel.Barf hat geschrieben:Parse error. Was hat Kanalsuche mit Unterkanäle zu tun? Möglicherweise meinst du dass nicht (mehr) gefundene Kanäle nicht einfach von services.xml gelöscht sein soll...Wäre es möglich bei der Kanalsuche eine Option "hinzufügen" mit einzubauen?
Dann würden Kanäle bei einer Kanalsuche nicht gelöscht z.B. hinzugefügt Unterkanäle bei Direkt oder Sport.
Nein, sie sollten in der services.xml bleiben.Barf hat geschrieben:...sondern irgendwie in einem "Papierkorb" (<junk><transponder>...</transponder></junk>) verschoben soll?
Das wäre aber schön, wenn man das Bequem in der Bouquetverwaltung machen könnteBarf hat geschrieben:services.xml ist ein Datenbank über gefundene Services, hier (in Unterschied zu bouquets.xml) soll der User nicht rumfummeln (dürfen).
Gruß Nachtvogel
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
Halt so wie man bei der D-Box1 auch den Sclauf einstellen kann.
Da kann man die alte Senderliste ersetzen lassen oder die neuen an einer beliebigen Stelle "inserten" oder eben hinten dranhängen.
Wäre es denn möglich mit zwei service.xml bzw. bouquet.xml zu arbeiten? Als das man ganz normal auf beide zugriff hat aber beim Suchlauf immer nur die eine geändert wird?
Oder irgend ein Tool das mir die Feeds eben in die service.xml "rein operiert".
Das es mit einem externen Editor geht weis ich aber ich wills von der Box aus machen können. Der Tuxbox Commander ist dafür nicht geeignet weil viel zu langsam.
Gruß Gorcon
Da kann man die alte Senderliste ersetzen lassen oder die neuen an einer beliebigen Stelle "inserten" oder eben hinten dranhängen.
Wäre es denn möglich mit zwei service.xml bzw. bouquet.xml zu arbeiten? Als das man ganz normal auf beide zugriff hat aber beim Suchlauf immer nur die eine geändert wird?
Oder irgend ein Tool das mir die Feeds eben in die service.xml "rein operiert".
Das es mit einem externen Editor geht weis ich aber ich wills von der Box aus machen können. Der Tuxbox Commander ist dafür nicht geeignet weil viel zu langsam.
Gruß Gorcon
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
Ich habe mich verschrieben tüdelü
makeRemainingChannelsBouquet=false
bei der Frage warst du sogar persönlich dabei, es gibt da nen Thread von vor ca. 1/2 Jahr.
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=34317
Essenz:
makeRemainingChannelsBouquet=false
bei der Frage warst du sogar persönlich dabei, es gibt da nen Thread von vor ca. 1/2 Jahr.
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=34317
Essenz:
Dort hatte Gorcon dir sogar ne Lösung präsentiertthegoodguy hat geschrieben:Es gibt Vorurteile die einfach nicht auszurotten sind :in zapit.conf hilft seit ca. 2 Jahren, vgl. http://forum.tuxbox.org/forum/viewtopic ... uet+andereCode: Alles auswählen
makeRemainingChannelsBouquet
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Eigentlich haben wir hier zwei ganz getrennte Themen:
1. Behandlung von Services, die seit letzte Scan verschwunden sind,
2. Behandlung von ungewünschte Services (der Zapper soll sie nicht sehen)
Zu 1.: Die tote Services soll nicht in services.xml aufgenommen werden, weil dies wurde u.U. die Konsistenz von den dadrin erhaltene Daten gefährden wurde. Mann könnte hier die tote Services z.B. in einem Datei services_dead.xml scheiben. Aber dann sind wir schon bei sehr normalbenutzerentfernte Dinge, und der telnet-ende Benutzer kann dann genau so gerne ein Backup von services.xml machen. Der Nutzen ist zu Debugging und Geschichteschreiben beschränkt. Fazit: Keine Änderung erforderlich oder wünschenswert.
Zu 2.: Hier glaube ich das insbesonderes alle Postern auf dem Thema "Bouquet Anderes löschen" das Problem mit einer möglichen Lösung verwechselt. Das Grundproblem ist das Verstecken von ungewünschte Services von dem Zapper. Das Löschen in diverse Dateien ist (möglicherweise) eine (von mehre) (nicht notwendigerweise saubere) Lösung des Grundproblems.
Erstmals: "Anderes" ist kein Bouquet normalen Sinn, sondern die Software bildet aus alle Services, die nicht einem (richtigen) Bouquet gehören, den Pseudo-Bouquet "Anderes". Deswegen ist die Frage um Löschen von "Anderes" nicht sinnvoll. Das makeRemainingChannelsBouquet=false funktioniert so, dass "Anderes" nicht angezeigt wird.
Es gibt eine Möglichkeit einzelne Boquets zu verstecken (das "hidden"-Attribut in dem Bouquete-Element in bouquets.xml). Leider nicht von der Neutrino-GUI beeinflussbar, aber vom Web-Interface (oder durch händisches Editieren ). Also: Lege ein Junk-Bouquet an, verschiebe alle ungewünschte Services dahin, und markiere den als "hidden" mit Web-interface oder durch händisches Editieren.
Wünschenswert wäre, den Bouquet-Editor so zu erweitern, dass er verstecken könnte.
Ausserdem wandert die next-channel-taste problemlos in versteckte Bouquets rein, sollte mann vielleicht ändern.
1. Behandlung von Services, die seit letzte Scan verschwunden sind,
2. Behandlung von ungewünschte Services (der Zapper soll sie nicht sehen)
Zu 1.: Die tote Services soll nicht in services.xml aufgenommen werden, weil dies wurde u.U. die Konsistenz von den dadrin erhaltene Daten gefährden wurde. Mann könnte hier die tote Services z.B. in einem Datei services_dead.xml scheiben. Aber dann sind wir schon bei sehr normalbenutzerentfernte Dinge, und der telnet-ende Benutzer kann dann genau so gerne ein Backup von services.xml machen. Der Nutzen ist zu Debugging und Geschichteschreiben beschränkt. Fazit: Keine Änderung erforderlich oder wünschenswert.
Zu 2.: Hier glaube ich das insbesonderes alle Postern auf dem Thema "Bouquet Anderes löschen" das Problem mit einer möglichen Lösung verwechselt. Das Grundproblem ist das Verstecken von ungewünschte Services von dem Zapper. Das Löschen in diverse Dateien ist (möglicherweise) eine (von mehre) (nicht notwendigerweise saubere) Lösung des Grundproblems.
Erstmals: "Anderes" ist kein Bouquet normalen Sinn, sondern die Software bildet aus alle Services, die nicht einem (richtigen) Bouquet gehören, den Pseudo-Bouquet "Anderes". Deswegen ist die Frage um Löschen von "Anderes" nicht sinnvoll. Das makeRemainingChannelsBouquet=false funktioniert so, dass "Anderes" nicht angezeigt wird.
Es gibt eine Möglichkeit einzelne Boquets zu verstecken (das "hidden"-Attribut in dem Bouquete-Element in bouquets.xml). Leider nicht von der Neutrino-GUI beeinflussbar, aber vom Web-Interface (oder durch händisches Editieren ). Also: Lege ein Junk-Bouquet an, verschiebe alle ungewünschte Services dahin, und markiere den als "hidden" mit Web-interface oder durch händisches Editieren.
Wünschenswert wäre, den Bouquet-Editor so zu erweitern, dass er verstecken könnte.
Ausserdem wandert die next-channel-taste problemlos in versteckte Bouquets rein, sollte mann vielleicht ändern.
-
- Tuxboxer
- Beiträge: 5873
- Registriert: Samstag 23. Februar 2002, 22:46
Es ging hier aber nur um Punkt1.
Es geht auch nicht darum das "tote" Services in der Senderliste drinn bleiben sodern die von Hand eingepflegten Sender (zB. Premiere Direkt Feeds)
Es gab mal zu AlexW Zeiten Images die diee Sender beim normalen Suchlauf gefunden und eingetragen haben, warum klappt das eigentlich jetzt nicht mehr?
Gruß Gorcon
Es geht auch nicht darum das "tote" Services in der Senderliste drinn bleiben sodern die von Hand eingepflegten Sender (zB. Premiere Direkt Feeds)
Es gab mal zu AlexW Zeiten Images die diee Sender beim normalen Suchlauf gefunden und eingetragen haben, warum klappt das eigentlich jetzt nicht mehr?
Gruß Gorcon
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
Ich kann mich erinnern, hab das aber nie hin bekommen.hannebamb(el) hat geschrieben:Ich habe mich verschrieben tüdelü
makeRemainingChannelsBouquet=false
bei der Frage warst du sogar persönlich dabei, es gibt da nen Thread von vor ca. 1/2 Jahr.
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=34317
Essenz:Dort hatte Gorcon dir sogar ne Lösung präsentiertthegoodguy hat geschrieben:Es gibt Vorurteile die einfach nicht auszurotten sind :in zapit.conf hilft seit ca. 2 Jahren, vgl. http://forum.tuxbox.org/forum/viewtopic ... uet+andereCode: Alles auswählen
makeRemainingChannelsBouquet
Nach ein paar versuchen bin ich zur "von Hand lösch Methode" zurückgekehrt.
Es gibt seit neuesten die Möglichkeit nur Radio, nur TV oder alles suchen zu lassen. Da werden auch nur die Services in die Services.xml geschrieben die ich vorher ausgewählt habe.Barf hat geschrieben:Zu 1.: Die tote Services soll nicht in services.xml aufgenommen werden, weil dies wurde u.U. die Konsistenz von den dadrin erhaltene Daten gefährden wurde. Mann könnte hier die tote Services z.B. in einem Datei services_dead.xml scheiben. Aber dann sind wir schon bei sehr normalbenutzerentfernte Dinge, und der telnet-ende Benutzer kann dann genau so gerne ein Backup von services.xml machen. Der Nutzen ist zu Debugging und Geschichteschreiben beschränkt. Fazit: Keine Änderung erforderlich oder wünschenswert.
Und so nur anders herum müßte die Möglichkeit bestehen, der Box zu sagen "nur Sender hinzufügen, nicht löschen". Ich weiss der Vergleich ist nicht besonders gut
Das Bouquet Würde nicht erstellt, wenn man die Löschfunktion auf die services.xml anwenden würde.Barf hat geschrieben:Zu 2.: Hier glaube ich das insbesonderes alle Postern auf dem Thema "Bouquet Anderes löschen" das Problem mit einer möglichen Lösung verwechselt. Das Grundproblem ist das Verstecken von ungewünschte Services von dem Zapper. Das Löschen in diverse Dateien ist (möglicherweise) eine (von mehre) (nicht notwendigerweise saubere) Lösung des Grundproblems
Mit dem verstecken klappt das nicht, bei mir.
Es gibt da bestimmte Sender wie Erotik über die meine Kinder nicht stolpern sollen
Löschen soll löschen sein und nicht ein "Anderes" Bouquet erstellen.
Das wäre schon mal tollBarf hat geschrieben:Wünschenswert wäre, den Bouquet-Editor so zu erweitern, dass er verstecken könnte.
Ausserdem wandert die next-channel-taste problemlos in versteckte Bouquets rein, sollte mann vielleicht ändern.
Gruß Nachtvogel
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Aha. Endlich, in Beitrag #12 im Thread sagt ihr was ihr haben will.Es geht auch nicht darum das "tote" Services in der Senderliste drinn bleiben sodern die von Hand eingepflegten Sender (zB. Premiere Direkt Feeds)
Es handelt sich also um wie händisch zugefügte services die ein Scan überleben. Ich schlage folgendes vor:
-- services.xml gehört dem Programm zapit, enthält keine manuelle Änderungen, wird bei Scan neu geschrieben. Wie jetzt.
-- Es wird eine neue Datei abgelegt, myservices.xml, gleiche Syntax und Semantik, wo der Benutzer (der selbst für Semantik und Syntax veranworten muss) seine eigene Einträge machen kann. Die Datei wird von zapit gelesen, aber nie geschrieben.
Eventuell könnte mann später ein Warmduschereditor für myservices.xml basteln; nicht wirklich wichtig weil nur "Experten" sowieso damit rumfummeln.
Hier ist ein Patch für ...apps/dvb/zapit/src/getservices.cpp, der den Vorschlag implementiert. Testen. Es ist recht viel was schief laufen kann.
-
- Foren-Moderator
- Beiträge: 297
- Registriert: Montag 11. Oktober 2004, 14:51
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Und wie soll der Scan unterscheiden zwischen tote (böse) Services und selbstzugefügte (gute)? Es kann/wird zu einem Ansammlung von Serviceleichen führen. (Eine Möglichkeit wäre ein Attribut "manually_added" zuzufügen.) Die Lösung mit myservices.xml hat diesen Nachteil nicht.Und so nur anders herum müßte die Möglichkeit bestehen, der Box zu sagen "nur Sender hinzufügen, nicht löschen".
Finde ich eine legitime Anforderung. Lass uns versuchen, das Problem zu lösen, nicht das Problem mit Löschen in services.xmlEs gibt da bestimmte Sender wie Erotik über die meine Kinder nicht stolpern sollen
Das manuelle rausschmeissen in der machinell erzeuge Datenbank der services (services.xml) ist am höchstens eine Notlösung, wirklich nicht eine saubere Lösung, Das Verstechen von Bouquets scheint mir mehr versprechend. (Warum es nicht bei Nachtvogel funktioniert muss er herausfinden; entweder ist es ein Bedienfehler, oder ein Bug in sein Software. Bei mir läuft es.) Die Behandlung von versteckte Bouquents sollte mann eventuell verbessern: Wie in frühere Posting erwähnt, unterstützt der Neutrino Bouqueteditor das Verstecken nicht, next-channel wandert in versteckte Bouquets rein, mann kann mit channelnummer-eingabe reinkommen. Sollte mann dies ändern? Damit wird der Semantik von versteckte Bouquets etwas geändert, von "versteckt" zu "verboten". Vielleicht sollte die Kanäle in den versteckte Bouquets auch nicht bei Kanalnummerzuweisung berücksichtigt werden?
Meinungen?
-
- Tuxboxer
- Beiträge: 4391
- Registriert: Freitag 21. Mai 2004, 17:16
Hallo!
Deshalb hab ich mir ja auch gleichzeitig eine Löschfunktion gewünscht
Gruß Nachtvogel
Gar nicht.Barf hat geschrieben:Und wie soll der Scan unterscheiden zwischen tote (böse) Services und selbstzugefügte (gute)? Es kann/wird zu einem Ansammlung von Serviceleichen führen. (Eine Möglichkeit wäre ein Attribut "manually_added" zuzufügen.) Die Lösung mit myservices.xml hat diesen Nachteil nicht.Und so nur anders herum müßte die Möglichkeit bestehen, der Box zu sagen "nur Sender hinzufügen, nicht löschen".
Deshalb hab ich mir ja auch gleichzeitig eine Löschfunktion gewünscht
Da stimme ich Dir voll und ganz zu.Barf hat geschrieben:Finde ich eine legitime Anforderung. Lass uns versuchen, das Problem zu lösen, nicht das Problem mit Löschen in services.xmlEs gibt da bestimmte Sender wie Erotik über die meine Kinder nicht stolpern sollen
Das manuelle rausschmeissen in der machinell erzeuge Datenbank der services (services.xml) ist am höchstens eine Notlösung, wirklich nicht eine saubere Lösung,...
Ich denke mal, daß ich da einen Fehler gemacht hatte, hab's danach auch nie wieder ausprobiert.Barf hat geschrieben:Das Verstechen von Bouquets scheint mir mehr versprechend. (Warum es nicht bei Nachtvogel funktioniert muss er herausfinden; entweder ist es ein Bedienfehler, oder ein Bug in sein Software. Bei mir läuft es.)
Wenn das realisiert würde, würde ich mich riesig freuenBarf hat geschrieben:Die Behandlung von versteckte Bouquents sollte mann eventuell verbessern: Wie in frühere Posting erwähnt, unterstützt der Neutrino Bouqueteditor das Verstecken nicht, next-channel wandert in versteckte Bouquets rein, mann kann mit channelnummer-eingabe reinkommen. Sollte mann dies ändern? Damit wird der Semantik von versteckte Bouquets etwas geändert, von "versteckt" zu "verboten". Vielleicht sollte die Kanäle in den versteckte Bouquets auch nicht bei Kanalnummerzuweisung berücksichtigt werden?
Gruß Nachtvogel
-
- Erleuchteter
- Beiträge: 553
- Registriert: Freitag 27. Februar 2004, 14:30
Hi,
also die Problematik mit den manuell in "services.xml" eingefügten Kanälen könnte man doch durch einen "Include"-Mechanismus wie folgt lösen:
In die "services.xml" wird ein include-Statement zum Laden einer weiteren Datei eingefügt (und dann im Parser von zapit entsprechend ausgewertet).
Diese "included"-Datei (nennen wir sie z.B. mal "services.xml.local") ist im Auslieferungszustand leer, kann aber manuell mit gewünschten Serviceeinträgen erweitert werden.
Beim Sendersuchlauf wird dann die "services.xml" wie gehabt behandelt (Löschen, Hinzufügen usw.). Totzdem bleiben die "im eigenen Schweiße" erstellten manuellen Einträge aufgrund des Includes unangetastet erhalte ...
- GMo -
also die Problematik mit den manuell in "services.xml" eingefügten Kanälen könnte man doch durch einen "Include"-Mechanismus wie folgt lösen:
In die "services.xml" wird ein include-Statement zum Laden einer weiteren Datei eingefügt (und dann im Parser von zapit entsprechend ausgewertet).
Diese "included"-Datei (nennen wir sie z.B. mal "services.xml.local") ist im Auslieferungszustand leer, kann aber manuell mit gewünschten Serviceeinträgen erweitert werden.
Beim Sendersuchlauf wird dann die "services.xml" wie gehabt behandelt (Löschen, Hinzufügen usw.). Totzdem bleiben die "im eigenen Schweiße" erstellten manuellen Einträge aufgrund des Includes unangetastet erhalte ...
- GMo -
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
@gmo18t:
tja, das ist ja in alles Wesentliches das gleiche als mein Vorschag mit myservices.xml. (Ein name wie services.xml.local ist nicht besoderes gelungen für xml-editoren etc.) Die Vorteile hast du ja gut beschreiben .
Es gibt ein W3C-Empfehlung XML Includes (W3C sagen "Empfehlung" wo wir andere "Standard" sagen wurde). Unterstützt libxml2 xincludes? Falls ja, wäre es einfach zu implementieren.
Für den Benutzer ist es sicherlich egal, falls man xinclude, cpp (iggit!) oder m4 benutzt, oder (mein unsprunglicher Vorschlag) fest nach myservices.xml sucht.
tja, das ist ja in alles Wesentliches das gleiche als mein Vorschag mit myservices.xml. (Ein name wie services.xml.local ist nicht besoderes gelungen für xml-editoren etc.) Die Vorteile hast du ja gut beschreiben .
Es gibt ein W3C-Empfehlung XML Includes (W3C sagen "Empfehlung" wo wir andere "Standard" sagen wurde). Unterstützt libxml2 xincludes? Falls ja, wäre es einfach zu implementieren.
Für den Benutzer ist es sicherlich egal, falls man xinclude, cpp (iggit!) oder m4 benutzt, oder (mein unsprunglicher Vorschlag) fest nach myservices.xml sucht.
-
- Erleuchteter
- Beiträge: 553
- Registriert: Freitag 27. Februar 2004, 14:30
war ja nur'n Beispiel, irgenwas mußte ich ja schreibenBarf hat geschrieben: ...
(Ein name wie services.xml.local ist nicht besoderes gelungen für xml-editoren etc.)
...
genau an sowas hab ich gedacht, daß auf diese Art dann nur wenig geproggt werden müßte, kenne mich mit libxml2 aber leider nicht aus ...Unterstützt libxml2 xincludes? Falls ja, wäre es einfach zu implementieren.
- GMo -
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Hmm, just for the fun of it, habe ich die Möglichkeit für xinclude Unterstützung untersucht. Hmm, libxml (http://xmlsoft.org) unterstützt xinclude! Hmm, libxml2 wird mit --without-xinclude configuriert. Ändern. Hmm, kompiliert nicht, muss auch --with-xpt zufügen. Dann kompiliert libxml2 MIT xinclude-Üunterstützung. Dann getservices.cpp bearbeiten. "Normalerweise" sollte ein #include <libxml/xinclude.h> genügen. Es zeugt sich aber, dass Deklarationen für libxml wit ausschliesslich in xmlinterface.h gemacht wird. Diese Datei verletzt alle Regeln für eine strukturierte Verwendung von externe Bibliotheken. Warum schreiben die Bibliothekauthoren include-Files, wenn die Benutzer sowieso die Funktionsprototypen, die sie (z.Z) meinen sie brauchen, mit cut-n-past in ihre Code übernehmen? Mannomann Microsoft certified? Sowas aufzuräumen -- ich nicht. (In Neutrino findet manchmal die bizarrste Coding.)
tja... mein vorgeschlagene, implementierte(!) Lösung enthält genau 6 nichtleere Zeilen, eine davon ein printf.genau an sowas hab ich gedacht, daß auf diese Art dann nur wenig geproggt werden müßte,
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Hier ist eine Implementierung von 2. und 3. Patch für .../apps/tuxbox/neutrino/src/neutrino.cpp, ../apps/tuxbox/neutrino/src/gui/channellist.h und ../apps/tuxbox/neutrino/src/gui/channellist.cppDie Behandlung von versteckte Bouquents sollte mann eventuell verbessern: Wie in frühere Posting erwähnt, unterstützt der Neutrino Bouqueteditor das Verstecken nicht, next-channel wandert in versteckte Bouquets rein, mann kann mit channelnummer-eingabe reinkommen. Sollte mann dies ändern? Damit wird der Semantik von versteckte Bouquets etwas geändert, von "versteckt" zu "verboten". Vielleicht sollte die Kanäle in den versteckte Bouquets auch nicht bei Kanalnummerzuweisung berücksichtigt werden?
Was noch zu tun ist die Fehlermeldung zu lokalisieren, eventuell eine Konfigurierbarkeit. Falls ein Benutzer doof genug ist, alle Bouquets zu verstecken bekommt er eine Endlosschleife. Als Strafe
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11