Thema: LCD-Skins umstellen - Grundsatzdiskussionen zu Displayskins

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.

Zitat von Papi2000

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!!!

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:

<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?

Zitat von Papi2000

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

Zitat von Mr.Servo

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.

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).

Done, und in den passenden Sektor geschoben.

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.