LCD-Skins umstellen - Grundsatzdiskussionen zu Displayskins

Nachricht

#1

@Papi2000

Danke für die Blumen, aber es hat mir auch viel Freude bereitet und ich sehe mehr und mehr was ich alles noch lernen kann! Was mir aber im Rahmen der Anpassungen aufgefallen ist und evtl. eine Anregung zu Verbesserung von OpenATV sein könnte:

OpenATV hat sich irgendwann entschieden, die Bildschirmskins (z.B. MetrixHD) und die Gerätedisplayskins zusammenzulegen. Das TB-Image trennt hier beispielsweise zwischen Bildschirmskins und Gerätedisplayskins. Dies hat den Vorteil, daß man überhaupt kombinieren kann. Die aktuellen Bildschirmskins bedienen ja die Gerätedisplays quasi "nebenbei" mit. Hier habe ich aber keine Chance mehr, neben meinem Lieblings-Bildschirmskin (z.B. MetrixHD) separat einen anderen Gerätedisplayskin (z.B. die AnalogClock) einzustellen.

Vielleicht läßt sich sowas wieder trennen (wie beim TB-Image), falls von eurer Seite aus Interesse besteht und auch jemand Zeit und Muße dafür hat?
Wenn ich wüßte wo ich da eingreifen müßte, dann würde ich mir das zumindest mal anschauen. Müßte dann halt sehr viel lernen, sprich lesen... :read:

Gruß......Mr.Servo

#2

Nein, siehst du falsch. Jeder GUI-Skin, der das Display mitskinnt, gehört verbannt. Der Metrix-atv skinnt eben nicht das Display.
Ein ebenfalls positiver Kandidat ist der Kraven-Skin in jeglichen Derivaten. Da hatte ich das mit ihm schon strickt getrennt. Die Truppe macht ja ohne ihn weiter - hoffentlich ohne Display-Skinanteil.
Aber es gibt noch haufenweise alter GUI-Skins, bei denen das Display leider noch mitgeskinnt wurde. Die gehören ausgebeint, und gleich überarbeitet (gab massig Änderungen an den Fontnamen, Ordner-Deklarationen, Screen-Namen, etc...). Wenn man die anpackt, könnte man so manches Schätzchen wiederbeleben.

#3

Papi2000 hat geschrieben:Nein, siehst du falsch.

Du hast (mal wieder) Recht! Bitte um Entschuldigung, ich hätte nicht so kurz vor der Primetime (20:15 Uhr) nochwas schreiben sollen, ich habe was komplett verwechselt. Sorry dafür!!! :sorry2:

Ich möchte nochmal neu anfangen: Was ich eigentlich meinte ist: Alleine der Gerätedisplayskins gehört eigentlich aufgeteilt in...
...den Teil, der während des Betriebs der Box anzeigt, z.B. der "OE-A_LCDSkin_10"
.. und in den Teil, der während des Standbys der Box werkelt: z.B. eine der Analoguhren wie "GB_220_Analog" .

[Edit/Nachklapp] Im TB-Image wird so im Frontdisplay-Menü getrennt: Skin / Uhr / LED. Das finde ich perfekt so!

Es war Blödsinn von mir die Bildschirmskins überhaupt zu erwähnen. Diese passen nun wirklich nicht in den Zusammenhang, sorry for that.

Der Code für die Standby-Analoguhr beschränkt sich dann daher auf folgenden Code (also recht kurz & knapp):

Code: Alles auswählen

<screen name="StandbySummary" position="0,0" size="220,176" zPosition="0" flags="wfNoBorder">
      <ePixmap pixmap="analog.png" position="0,0" size="220,176" zPosition="0" />
   <widget source="global.CurrentTime" render="EtAnalogClockLCD" position="center,center" size="220,176" hColor="white" positionwidth="218" positionheight="176" linewidth="5" linesize="35" zPosition="4" alphatest="on">
      <convert type="EtAnalogClock">Hours</convert>
   </widget>
   <widget source="global.CurrentTime" render="EtAnalogClockLCD" position="center,center" size="220,176" mColor="white"  positionwidth="218" positionheight="176" linewidth="4" linesize="75" zPosition="3" alphatest="on">
      <convert type="EtAnalogClock">Minutes</convert>
   </widget>
   <widget source="global.CurrentTime" render="EtAnalogClockLCD" position="center,center" size="220,176" sColor="red"  positionwidth="218" positionheight="176" linewidth="3" linesize="85" zPosition="2" alphatest="on">
      <convert type="EtAnalogClock">Seconds</convert>
   </widget>
   <widget source="session.RecordState" render="Pixmap" pixmap="analog_rec.png" position="0,0" size="220,176" zPosition="1" transparent="1" alphatest="on" >
      <convert type="ConditionalShowHide">Blink</convert>
   </widget>
</screen>

...also keinen Code für den Betriebsmodus, nur der reine Standby-Code. Ich hoffe ich habe es verständlich ausgedrückt?

Papi2000 hat geschrieben:Aber es gibt noch haufenweise alter GUI-Skins, bei denen das Display leider noch mitgeskinnt wurde. Die gehören ausgebeint, und gleich überarbeitet (gab massig Änderungen an den Fontnamen, Ordner-Deklarationen, Screen-Namen, etc...). Wenn man die anpackt, könnte man so manches Schätzchen wiederbeleben.

Vielleicht ist die neue Version OpenATV 6.5 der richtige Zeitpunkt für das Bereinigen des gesamten Systems? Irgendwann muß man ja mal die Reißleine ziehen...

Off-Topic: OpenATV muß nicht die eierlegende Wollmilchsau sein (YouTube & Co.). Das können aktuelle Smart-TVs viel besser. Die STB hat andere Aufgaben und vor Allem: Stärken!... Manchmal ist weniger mehr.

(ist aber nur (m)eine Meinung)

Und genau wie bei irgendwelchen veralterten Boxen mit 750MHz-Prozessor (im schlimmsten Fall sogar noch ohne Support): Die müssen auch nicht mehr zwingend bei v6.5 mitgenommen werden. Im Zweifel müssen sich die Anwender eben mal eine aktuelle Box für >90 Emmchen schießen. Irgendwann ist Schluß und dann muß eben eine "alte" Version <v6.5 für die Oldies reichen. Peng! Das Team würde für die Entlastung sicherlich dankbar sein. (ist aber nur (m)eine Meinung)

Gruß....Mr.Servo

#4

Mr.Servo hat geschrieben:Ich möchte nochmal neu anfangen: Was ich eigentlich meinte ist: Alleine der Gerätedisplayskins gehört eigentlich aufgeteilt in...
...den Teil, der während des Betriebs der Box anzeigt, z.B. der "OE-A_LCDSkin_10"
.. und in den Teil, der während des Standbys der Box werkelt: z.B. eine der Analoguhren wie "GB_220_Analog" .

Der Code für die Standby-Analoguhr beschränkt sich dann daher auf folgenden Code (also recht kurz & knapp)

Man wird es nie allen recht machen können, ist eben der allgemeine display_skin.

Der nächste will dann zB im EMC oder MC eine andere Ansicht...
wer extrawünsche hat muss eben einfach selber Hand anlegen.

#5

hihi, war nicht bös gemeint.
Ja, da gebe ich dir völlig Recht. Ich habe in meinen HD75hd-Displayskin die Digitaluhr des OpenMips reingefringelt, weil mir die am besten gefällt, und keine graphischen Anforderungen stellt. Die Analoguhren hatten ein Wiele massiv Proc.-Power beansprucht. Da wurden die Boxen im Standby wärmer, als im Betrieb. Das ist im Treiber inzwischen bereinigt.

Für mich wäre der Einstieg mit oATV6.4 jetzt sofort richtiger. Damit ist die Python2, wie auch die Python3 Kompatitbilität abgedeckt. Das, was in beiden Images geht, wäre das sauberste Egebnis.

"Kleinere Boxen" wie eine UE_Plus selbst als V2 mit 256MB Flash und Dualcore 750MHz sind für oATV6.5 vermutlich nicht mehr geeignet. Für die ganzen Boxen wird auch von keinem Hersteller ein neuer Treiber kommen. Bei den Gigas ist mit der Quad_Plus afaik die Unterkante der Unterstützung definiert. Die Quad mit dem etwas kleineren Prozessor und nur Software Transcoding könnte noch mitlaufen, weil gleicher Treiber. Aber viel wird am Treiber nicht mehr gemacht - eher fleigen die auch raus.

Boxen mit 220x176 Display gibt es dennoch einige. Daher wäre der Python2 Ansatz schon richtig. Dann könnte man die Displayskins nämlich auch weiterhin für die mit anbieten.

Weiteres Thema sind weitere Displaytypen:
96x64 DM800se
128x32 ET10000
132x64 DM800hd, DM8000, DM7020hd
220x176 Gigablue HD Quad / 800UE / 800UEplus / Ultra UE / UE 4K UHD -> hier behandelt, und erledigt
255x64 Vu+ Ultimo, Mutant HD 2400, Atemio Nemesis
400x240 DM internes Grautec-LCD, Gigablue Quad Plus / Quad 4K UHD -> wäre aus meiner Sicht ein weiterer Zweig, der lohnen könnte
480x320 Vu+ Solo4k -> sicher einige User, aber müssen sich hinten anstellen
720x405 ET8500(Spezial) -> leider totaler Exot, und schwer nebenher abzudecken

Mit der Gewichtung würde ich ins Rennen gehen. Der Aufwand für die beiden Mayor-Types hält sich in Grenzen, und ~80% der Boxen hier im Board wären damit insgesamt abgedeckt.
Wenn du da mitgehen kannst, unterstütze ich gerne (ab Weihnachten frühestens wieder @home).

#6

Hi Papi2000,

vielleicht wäre es nicht klug ab Post #3 ein neues Thema (z.B. LCD-Skins umstellen") aufzumachen, denn dieses ist ja sogar gepinnt. Es läuft gerade etwas off-tipc, finde ich.

Danke & Gruß.....Mr.Servo

#7

Done, und in den passenden Sektor geschoben.

#8

Danke Dir fürs Umziehen in einen neuen Thread!

Papi2000 hat geschrieben:Für mich wäre der Einstieg mit oATV6.4 jetzt sofort richtiger. Damit ist die Python2, wie auch die Python3 Kompatitbilität abgedeckt. Das, was in beiden Images geht, wäre das sauberste Egebnis. [...]

Boxen mit 220x176 Display gibt es dennoch einige. Daher wäre der Python2 Ansatz schon richtig. Dann könnte man die Displayskins nämlich auch weiterhin für die mit anbieten.

Weiteres Thema sind weitere Displaytypen:
96x64 DM800se
128x32 ET10000
132x64 DM800hd, DM8000, DM7020hd
220x176 Gigablue HD Quad / 800UE / 800UEplus / Ultra UE / UE 4K UHD -> hier behandelt, und erledigt
255x64 Vu+ Ultimo, Mutant HD 2400, Atemio Nemesis
400x240 DM internes Grautec-LCD, Gigablue Quad Plus / Quad 4K UHD -> wäre aus meiner Sicht ein weiterer Zweig, der lohnen könnte
480x320 Vu+ Solo4k -> sicher einige User, aber müssen sich hinten anstellen
720x405 ET8500(Spezial) -> leider totaler Exot, und schwer nebeher abzudecken

Mit der Gewichtung würde ich ins Rennen gehen. Der Aufwand für die beiden Mayor-Types hält sich in Grenzen, und ~80% der Boxen hier im Board wären damit insgesamt abgedeckt.
Wenn du da mitgehen kannst, unterstütze ich gerne (ab Weihnachten frühestens wieder @home).

Ja ich gehe gerne mit, denn das Thema ist zwar ein bissl Arbeit

Der Dateianhang arbeit-2.gif existiert nicht mehr.

, aber Du hast Recht: ist programmiertechnisch noch überschaubar. Ich muß mich noch an die Strukturen und Möglichkeiten von OpenATV gewöhnen, da fehlt es mir noch an Details. Aber das wird schon - und mit kleinen Hilfen trauen sich vielleicht auch andere an solche Themen oder haben wirder Lust was zu machen?

Okay, dann gehe ich die Sache mit dem "400x240 DM internes Grautec-LCD, Gigablue Quad Plus / Quad 4K UHD" mal an, aber wer könnte hier der Tester sein? Oder soll ich die zu testenden Skins hier reinstellen, ginge ja auch?

Gruß......Mr.Servo

#9

@Papi2000

Huch! Ich finde hier den 400er-Skin von HD75hd nicht. Der 400er "OE-A_LCDSkin_10" sieht anders aus als der 220er-"OE-A_LCDSkin_10".

Guggst Du:

: lcd220_OE-A_LCDSkin_10_prev.png (5.29 KiB) 1086 mal betrachtet

: lcd220_OE-A_LCDSkin_10_prev.png (5.29 KiB) 1086 mal betrachtet

220er OE-A_LCDSkin_10................vs.................400er OE-A_LCDSkin_10_prev

Auch wenn in der Preview das Aspektverhältnis komisch wirkt, im Code steht aber bei allen "Summaries" klar 400x240, also alles gut. Beispiel: <screen name="InfoBarSummary" size="400,240" position="0,0">

Da der LCD-Skin ja quasi der "Träger" für die Analogclocks ist, sollte der "Träger" auch weise gewählt sein. Kennst Du vielleicht das 400er Pendant vom 220er-"OE-A_LCDSkin_10"? Welcher Gerätedisplayskin sollte der "Träger" (Leitwolf) sein?

Gruß......Mr.Servo

#10

Ohje. Habe ich befürchtet.
Ich nutze auf der DM900 und Quad4K den angehängten.
Aber das ist ein Mod-Mod eines Mods vom Ursprungs-HD75hd für die 400x240 und acht Tuner plus die Digitaluhr des teamBlue.
Da ist auch noch seine Skinvorlage als "..-alt" drin.
Auf was der aber im Ursprung aufsetzte, weiß ich auch nicht.
Es fehlen auch viele Screens im Betrieb.

Ich hatte die Hoffnung, mit "fertigen Windows" zu arbeiten, die nur im Skin zu Beginn auf Größe skaliert werden. Geht zwar prinzipiell auch, aber bei den ganzen unterschiedlichen Aspekts der Displays sieht das bescheiden aus, und macht somit null Sinn. Daher habe ich auch den Displayskin nicht weiter mit Screens aus anderen Displayskins für Menüs oder Listenanzeigen befüllt, was ja theoretisch auch ginge.

#11

Tja und das nächste "Problem". Ich habe ja nur das 220er-Bullauge

, da kann ich den 400er Skin nicht sehen und anpassen.

Vorschlag#1: Vielleicht wäre HD75hd oder ein anderer so nett und könnte seinen 220er-"OE-A_LCDSkin_10" auf 440er Kurs bringen, falls die Hardware dafür vorhanden ist. Einen geeigneten LCD-Emulator gibts ja für solche Fälle wohl nicht?

Vorschlag#2: Keine Ahnung, aber könnte man im Image nicht wiefolgt umstellen (analog zum TB-Image): Unterscheidung im Frontdisplay-Menü zwischen Skin / Uhr
Die OpenATV-Gerätedisplayskins ja so gelagert, daß diese auch die Standby-Uhr mitbedienen. Da müßte man programmtechnisch reingrätschen und dann je nach Einstellung das XML-Tag "StandbySummary" mal vom aktuellen Gerätedisplayskin oder mal vom separaten XML-Code (also z.B. der AnalogClock) nehmen.

Bei der Uhr könnte man dann im Menü auswählen lassen: "Standby-Uhr" vom aktuellen Gerätedisplayskin oder Auswahl "Standby-Uhr-Skin", also die Auswahl zwischen "nimm das XML-Tag "StandbySummary" vom Gerätedisplayskin und -wie ein "table-override"- "würge dies ab und nimm dafür einen separaten Standby-Uhrenskin".

Wäre sowas denkbar / machbar? Dann könnte der User sich seinen Gerätedisplayskin raussuchen und bei Bedarf einen separaten Standby-Uhr-Skin zu- und wieder wegschalten.

Gruß.....Mr.Servo

#12

Ja, die Standby-Uhr quasi als Skinpart. Das hätte was.
Ich kann momentan von hier nur nichts ausrichten.
Sonst hätte ich schon sowas angeleiert. Liegt ja auf deiner Linie.
Weiß jetzt nicht, wer vom Team ausser @Apachi70 so nah an den Skins ist, und mitmachen könnte.
Ich hau ihn mal an...

#13

Papi2000 hat geschrieben:Ja, die Standby-Uhr quasi als Skinpart. Das hätte was.
Ich kann momentan von hier nur nichts ausrichten.
Sonst hätte ich schon sowas angeleiert. Liegt ja auf deiner Linie.
Weiß jetzt nicht, wer vom Team ausser @Apachi70 so nah an den Skins ist, und mitmachen könnte.
Ich hau ihn mal an...

ja klar kann ich machen

#14

Hi Apachi70!
klasse daß Du mitmachst. Da ich die Strukturen im Hintergrund (noch) nicht so detailiert kenne, schlage ich vor daß Du das Konzept vorgibst und ich dann die einzelnen Unterfunktionen übernehme. Wäre das OK für Dich? Danke schon mal!
Gruß......Mr.Servo

#15

Also quasi im teamBlue spickeln, wie dort die Trennung angesteuert wird, und die Skinparts zur aktuellen Nutzung definiert und zusammengeführt werden?
Also wo die Definitions getroffen werden, wo welcher Import stattfindet, und wie das zur Anzeige im Display geregelt ist?
Das wären die Einstiegsschritte, die ich mir vorstellen könnte.

#16

Ja, so mache ich das auch gerne: Erst Spielregeln lernen - dann spielen. Das unterscheidet einen Player vom Gambler

Ich schaue mir das bei TB mal näher an, aber erst ab heute spätnachmittag.

Gruß....Mr.Servo

#17

@Apachi70,

Habe mal ein wenig versucht da durchzusteigen am Beispiel "lcd_skin220", aber es ist noch mager, weil ich die aufrufende TB-Struktur (noch) nicht verstehe.

Ein Standby-Clockskinpart (Beispiel "clock_lcd_analog.xml") ist ja noch sehr simpel aufgebaut, aber wo könnte die Einbindung stattfinden?

Es gibt da eine wahrscheinlich übergeordnete "skin_lcd_default.xml", die dann eine "common.xml" included. Aber ich finde nirgends einen Bezug auf eine <screen name="StandbySummary"...> oder auf den Standby-Clockskinpart, z.B. auf "clock_lcd_analog.xml"

Kannst Du mal bitte mit Deinem Kennerblick drüberschauen, Dir springt doch bestimmt spontan schon gleich was ins Auge...?

Danke & Gruß......Mr.Servo

#18

Hallo Zusammen,

wollte mich mal erkundigen, wie es mit unserem Projekt "Display-Splitskins" weiter geht. Habe ja inzwischen durch das Modifizieren der "plugin.py" von LCD4Linux (lese ab hier und hier) einiges dazugelernt. Aber ich mag mit dem Dazulernen nicht aufhören.

Gruß......Mr.Servo

#19

Hi Zusammen,

Ich hänge gerade im Projekt "LCD4Linux" und warte auf eine Rückmeldung, aber von mir aus können wir hier nun durchstarten. Wie siehts aus?

Gruß.....Mr.Servo

#20

Bin auf der Suche nach einer Vorlage auf diesen Thread gestoßen,
echt traurig, dass das hier untergegangen ist.
HDF hat Display-Skins und Standby Skins getrennt.
Ich glaube, das war auch das ursprüngliche Anliegen,
von @Mr.Servo.
Schade das es nicht umgesetzt wird.