49 replies to this topic

[luisteraar]

Het lukt me nog niet grafische dingen op het lcd scherm te laten zien.

 

Denk dat probleem de juiste source en render naam opgave is.

 

<widget source="parent.Service" render="LcdPicon" ................. </widget> werkt niet

 

ook bij render Pixmap.

 

Wie heeft de juiste entry's bij openpli enigma2 ?

 

 

[Jork]

Heb je al dit geprobeerd? "LcdPicon" wijzigen in "Picon"

[luisteraar]

"Picon" al geprobeerd dat wil ook niet

[luisteraar]

Ben probleem op het spoor.

In openpli enigma2 is geen renderer LcdPicon.py in lib/python/Components/Renderer.

Is er een oplossing voor ?

[Jork]

Heb je een Gb4kquad? Dan mag je deze renderer eens proberen. Wel met Picon te selecteren. Deze is getest en werkt zonder uitzondering.

Attached Files

•  Picon.py   4.98KB   6 downloads

[luisteraar]

Ja heb ook een gbquad4k .

 

In openpli enigma2 zit al een Picon.py is dat een andere ?

[Jork]

Ja vast. Herstart wel Enigma helemaal want L4L wil de gbquad4k lcd driver wel eens in de weg zitten.

Edited by Jork, 21 November 2021 - 17:08.

[luisteraar]

bedankt , lukt vandaag niet mee (eten tv kijken) morgen als eerste testen.

[Jork]

Ik had ook liever een betere gdi ondersteuning gezien voor de gb modellen voor dit type hardware. o.a pixmap32 resolutie support. Maar ja dan kun je dit lenen van teamblue. Misschien dat je dit in je build van Pli kunt toevoegen. lcd.cpp en bijbehorende lcd.h. Ik heb er overigens niets op tegen dat het OpenPli team hun image zo clean zoals nu is blijft houden. Ik zie dit eerder als een voordeel dan als een belemmering.

Edited by Jork, 21 November 2021 - 17:26.

[luisteraar]

Precies ga morgen ook testen met de renderer files van teamblue ,die zitten in OE-alliance.

Ben al blij dat ik (jij al eerder) weet waar het lcd probleem zit.

Kan ook testen op een gbue4k.

[Jork]

Heb jij onder Pli al een mooi analoog klokje werkend buiten L4L om natuurlijk? Ik heb hem zo goed als werkend op dit moment. Uurwerkaanwijzers werken en alles op de juiste positie, breedte en lengte aanwijzers en schaling. Aleen nog wat meer nodig voor de 32 bpp kleurondersteuning en eventueel voor de selectie van meerdere clockskins. Zodra ik helemaal tevreden ga ik dit wel delen met je. Onder teamblue werkt dit wel maar door wat beperking kon ik dit tot dusver niet voor elkaar krijgen in Pli.

Edited by Jork, 21 November 2021 - 17:36.

[luisteraar]

Zover ben ik nog helemaal niet met klokje  ,zag wel in enigma2 van openatv een clock renderer

[Jork]

Helaas gaan die clockrender en ook clock converters niet werken voor de Gigablue/OpenPli combinatie. Dit komt o.a door de beperkingen in GDI van OpenPli voor de GigaBlue hardware. Maar dit is wel oplosbaar.

Edited by Jork, 21 November 2021 - 17:46.

[WanWizard]

Ik had ook liever een betere gdi ondersteuning gezien voor de gb modellen voor dit type hardware. o.a pixmap32 resolutie support. Maar ja dan kun je dit lenen van teamblue. Misschien dat je dit in je build van Pli kunt toevoegen. lcd.cpp en bijbehorende lcd.h. Ik heb er overigens niets op tegen dat het OpenPli team hun image zo clean zoals nu is blijft houden. Ik zie dit eerder als een voordeel dan als een belemmering.

 

Eigenlijk zijn dit dingen die in een BSP horen te zitten, want ze zijn hardware specifiek.

 

Waar je dan met dit soort dingen tegen aan loopt is dat er weleenswaar een object oriented taal gebruikt wordt. maar er procedureel geprogrammeerd is, waarbij classes vaak gewoon verzamelingen methods zijn, die static en als singleton gebruikt worden. En dat maakt het overloaden of extenden van basis functies erg lastig (en de code een berg spaghetti).

[luisteraar]

Object georienteerd programmeren is niet zalig makend en standaard programmeren is niet automatisch spagetti.

Zo is oa de linux kernel en libc in plain C geschreven dus niet object georienteerd en die werken toch

goed dacht ik en geen spagetti.

Ben nu bezig met de grafische lcd render zodat die op elke box hardware werk tmet een box schermpje.

[WanWizard]

Dat zeg ik ook niet.

 

In dit geval is het wel spaghetti, en zit het vol met classes niet niet op een OO manier gebruikt worden, en barst het van de globals. En derhalve gaat je vergelijking met de linux kernel mank.

 

Veel problemen hadden voorkomen kunnen worden door abstracties en class overloads toe te passen, in plaats van de code vol te stoppen met "if box then" of "if hardware then", vaak ook nog in een try/cache constructie, onder het motto "als het een niet lukt, dan proberen we het andere wel".

 

Je zult met zulke code bij Linus aan komen....

[luisteraar]

If (boxtype == xxxx) then is niet zo abnormaal alleen een slimme manier vinden om alles

in 1 keer goed te krijgen zoals MACHINE_FEATUES colorlcd220 colorlcd400 .......

Dan krijg je wel in de build enviroment een boom van if's is niet wenselijk.

Maar als je een product(enigma2) hebt die voor tig verschillende boxen moet werken ontkom je

er vaak niet aan om alles te ondersteunen van een box.

Is iets leuks om op te lossen ,houd je van de straat in de kroeg mag niet meer 

Edited by luisteraar, 22 November 2021 - 14:09.

[luisteraar]

mbt linus de kernel build config file zit vol met if's voor diverse hardware enz.

[WanWizard]

Dan zijn we het fundamenteel oneens.

 

Dit is allemaal prima, en clean, oplosbaar via hardware abstractie en class overloading en inheritance...

 

In PHP zou ik (even uit de losse pols) doen:

// creer storage voor generieke objecten 
$registry = new StdClass();

// top level class voor alle hardware
abstract class Hardware {
    // generieke data en code voor alle hardware hier...

    // method definitie voor het aan/af zetten van het opname led
    abstract protected function recording_led {bool status): bool;
}

En per ondersteunde box:

class et9x00Hardware extends Hardware {
    // specieke et9x00 initialisatie, data en code

    protected function recording_led(bool: status) {
        // specifieke functie voor de et9x00
    }
}

// maak een instantie aan voor de de registry
$registry->hardware = new et9x00Hardware();

En in de code

// zet de opname led aan
$registry->hardware->recording_led(true);

Hierdoor hoeft de code niet te weten op welke box het draait, en hoeft deze het ook niet uit te zoeken. Ook uitvissen of de feature ondersteund is, en zo ja, hoe het te implementeren is dan volledig weg uit de enigma code.

 

Hiermee kun je alle platform specifieke zaken uit de code filteren, en ook af van de SystemInfo global.

[WanWizard]

mbt linus de kernel build config file zit vol met if's voor diverse hardware enz.

 

Dat is wat anders dan in de code.

 

In builld config heb ik daar niet zo'n moeite mee, die moet nu juist alle zaken nodig voor een build bij elkaar harken. Voor ons zou dat het build recipe zijn, en daar worden dingen als MACHINE en MACHINE_FEATURES ook continue gebruikt.