260 replies to this topic

[BuGless]

I'm currently working on a new skin, with the following features:
- Based on PLi-HD 3.0.
- Full HD (1920x1080).
- Configurable (overscan)margins.
- Configurable font sizes.
- Easily adjustable/editable layout due to dynamic screen content.
- Automatically resizing widgets due to changes in margins, font sizes or content.

I have four questions:
a. If anyone wants to take a glance at the work in progress, I'd be happy to post it, but I don't know how to create an ipk file yet (so any hints there would be welcome).
b. Does anyone know about a skin widget which allows one to display just the ECM time or just the provider name?
c. In some other skin I see reference to a Picon2 widget, which does not seem to work in standard OpenPLi; do I need a plugin installed for that?
d. I read somewhere that one can add supporting .py files to a skin; does anyone have an example or documentation on how this is to be accomplished?

[Rob van der Does]

I'll be happy to make an ipk out of your package.
Same applies to adding .py's, as long as you tell me where they should go and if there are any dependency's.

[BuGless]

I'll be happy to make an ipk out of your package.
Same applies to adding .py's, as long as you tell me where they should go and if there are any dependency's.

Many thanks for the offer.

However, I'm here to learn, so I'd prefer a pointer to some documentation or example that allows me to infer on how to do it myself.
Besides, my motto always is, if it can be scripted, it should be.

[pieterg]

there's only one proper way to create ipk's, make a bitbake recipe and let bitbake build and create the package.
Any other way is just emulating bitbake, and will eventually result in incompatible formats.

[BuGless]

One more question to add to the ones in the original posting:

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?
They appear to fulfill the same function, yet are not defined at the same time (if one is filled, the other is empy, and vice versa it seems).

[littlesat]

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?

Welcome to the world of enigma2..... due to the coders this is not made consequent... and when we change it a lot of skins will not be compatible anymore.... I discovered it when using templates in our standard OpenPLi-HD skin.......

[Rob van der Does]

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?

There are even more variations to this theme..........

[BuGless]

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?

..... due to the coders this is not made consequent...

Sigh. I see, so things like this mark the difference between a coder and a programmer... ;-)

I discovered it when using templates in our standard OpenPLi-HD skin.......

Well, the good news is, I found a solution for it (using a single template for both).

[BuGless]

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?

There are even more variations to this theme..........

Anything specific you can recall?
I mean, I'm converting everything into templates, so I'm bound to encounter them somewhere along the line, but since "discovering and learning" here sadly always involves a restart of enigma, any insights you can offer will help.

[Rob van der Does]

Is there a reason why e.g. there is a widget called "blue" *and* another widget called "key_blue" ?

There are even more variations to this theme..........

Anything specific you can recall?
I mean, I'm converting everything into templates, so I'm bound to encounter them somewhere along the line, but since "discovering and learning" here sadly always involves a restart of enigma, any insights you can offer will help.

Yes, instead of 'key_red' etc. one also finds (with and without capital(s)):
name="cancel"
name="OK"
name="Save"
name="buttonred", name="buttongreen" etc.
name="languagetext" (quite exeptional)
name="ButtonBluetext"
name="stationmenu"
name="key_r"
name="key_g"
name="key_y"
name="key_b"
source="red" etc.

And sometimes no label at all is available, so the skin could add something like '< eLabel text="Exit"........>'

The above is an exhaustive list of what I found so far, but I'm pretty sure there's more out there......

Could I make a test-ride with your skin? Manually implanting files/py's is no problem.

Edited by SatKiekerd, 16 October 2012 - 11:42.

[BuGless]

Yes, instead of 'key_red' etc. one also finds (with and without capital(s)):
name="cancel"
...

The above is an exhaustive list of what I found so far, but I'm pretty sure there's more out there......

Aargh... And to add insult to injury, I just found: <widget name="title" /> and <widget name="Title" />.
This sadly proves that programming and skin design is something that should be left to real programmers, or, at the very least, a real programmer should check any code a coder produces before committing it. But, I realise, like any community effort, there always is a shortage of resources (time), so we'll have to do with what everyone is offering.

Could I make a test-ride with your skin? Manually implanting files/py's is no problem.

Sure. Take note, it's very much a work in progress. I started with the PLi-HD skin, and am slowly transmogrifying it. There is still plenty of old skin left, it's all being replaced by brand new code.
Most notably, I've been working on ChannelSelection, InfoBar, SecondInfoBar, About, ServiceInfo and generic Menus.

The idea is that once the design is finished, it is easily tweaked by changing (at best) one value/width/height/fontsize whatever, and everything else will scale accordingly. Case in point: the infobars, I moved the infobar to the top (to get it out of the hair of subtitles); but if anyone wants to move it back down, it's easy, it just consists of blocks which can be moved, reordered, etc. without the need to recalculate any coordinates whatsoever.
The reason I sometimes cannot easily get away with changing just one value is because there is no provision for generic text-macros with parameters.

To assist in calibrating font sizes, I included some visible strings which are present in the About page, which allow you to calibrate the font width/height dimensions (in case someone changes the font sizes).

Anyway, the following skin currently consists of only one file (skin.xml), just place it in a subdirectory (current working name for the skin is BuGless on my machine).
There needs to be a PLi-HD skin on the same machine, otherwise it will miss a *lot* of images.

Attached Files

•  skin.xml   269.68KB   58 downloads

Edited by BuGless, 16 October 2012 - 12:20.

[Rob van der Does]

Thanks.

[BuGless]

Skin geupdate, GraphMultiEPG aangepast en getweaked, nog niet helemaal klaar, maar werkt al tien keer beter dan voorheen (je kunt nu GraphMultiEPG doen met 20 regels bijv., en naar onder/boven scrollen is nu van het DWIM concept).

De GraphMultiEpg.py file moet de huidige geinstalleerde overschrijven ("opkg flag hold enigma2-plugin-extensions-graphmultiepg" als je niet wilt dat updates de wijzigingen overschrijven).

P.S. Waarom verbiedt dit (development!) forum me een .py file te uploaden?

Attached Files

•  BuGless.zip   41.25KB   40 downloads

[littlesat]

De GraphMultiEpg.py file moet de huidige geinstalleerde overschrijven

Dit is natuurlijk een vette note done...!!! Een skin hoort geen py files te overschrijven!!! Dat is heel erg foei en verklaart meteen je P.S.....

En het is nu ook al mogelijk om de GME volledig met 20 zenders of zo te laten zien. In feite kun je twee screens toekennen... om te schakelen via de gele toets...

Maar wat heb je dan aangepast in GME (kun je een diff maken?).... misschien als het heel goed is kan het standaard worden??? Maar wij moeten dan ook weer rekening houden dat het met elke skin kan werken..... en dan loop je weer tegen bepaalde grenzen aan.

Maar nu kun je ook al door kanalen heen scrollen... dus onder de streep denk ik dat het goed is zoals het nu al is... alleen heb je niet geweten dat er een tweede scherm al mogelijk was.

Edited by littlesat, 17 October 2012 - 13:48.

[BuGless]

Excuse the Dutch in the previous post, BTW.

De GraphMultiEpg.py file moet de huidige geinstalleerde overschrijven

Dit is natuurlijk een vette note done...!!! Een skin hoort geen py files te overschrijven!!! Dat is heel erg foei en verklaart meteen je P.S.....

The skin doesn't require it. It's just in tweaking the GraphMultiEPG skin layout I found that the skin doesn't offer enough options to influence the behaviour. The GraphMultiEpg.py changes will not be part of the skin (eventually), but will (preferably) flow into the standard GraphMultiEPG package.

As such, if I want to discuss changes in py files, it is rather silly to forbid uploading of py files in this forum.

En het is nu ook al mogelijk om de GME volledig met 20 zenders of zo te laten zien. In feite kun je twee screens toekennen... om te schakelen via de gele toets...

I know. But I have a 2m wide HD screen with all pixels visible, and the current max. numbers don't cut it. Too much wasted space.

Maar wat heb je dan aangepast in GME (kun je een diff maken?).... misschien als het heel goed is kan het standaard worden??? Maar wij moeten dan ook weer rekening houden dat het met elke skin kan werken..... en dan loop je weer tegen bepaalde grenzen aan.

I'll provide a diff, eventually, it's not finished yet though; and yes, the changes will be compatible with all other skins (as the skinning of my cat progresses and the mist starts to clear up, I'm gradually becoming aware of the crosscompatibility mess enigma is in).

Maar nu kun je ook al door kanalen heen scrollen... dus onder de streep denk ik dat het goed is zoals het nu al is... alleen heb je niet geweten dat er een tweede scherm al mogelijk was.

Well, besides the wasted space (in my skin, margins are much smaller, so there is more screen real-estate to fill, the current GraphMultiEPG has an IMHO *very* erratic behaviour when pushing the up and down arrows. Also, centering the eventname makes it difficult to visually find the start of the program; and allowing wraparound in eventnames gets messy because the display sometimes shows partial letters if a complete second or third line does not fit anymore.

Edited by BuGless, 17 October 2012 - 14:05.

[littlesat]

So I was hooked to dutch too

[BuGless]

In looking for variations on the GraphMultiEPG I encounter various "mods" (BetterGraphMultiEPG, Coolguide, etc.) that basically all do the same thing, they are slight variations on the original theme, and fix some of the rough edges, but what I wonder about is: *Why* do these mods even exist? Why didn't they just contribute to the master source and fix the original?

The concept of Open Source normally is not just that you can fork it, the general idea is to contribute back instead; is there a reason why people in the enigma environment often seem to forget the second part?

[pieterg]

The concept of Open Source normally is not just that you can fork it, the general idea is to contribute back instead; is there a reason why people in the enigma environment often seem to forget the second part?

because most e2 'developers' are script kiddies?

[BuGless]

The concept of Open Source normally is not just that you can fork it, the general idea is to contribute back instead; is there a reason why people in the enigma environment often seem to forget the second part?

because most e2 'developers' are script kiddies?

Well, spank them!

[WanWizard]

because most e2 'developers' are script kiddies?

And don't forget the smaller the kiddy, the bigger the ego. They all want to show how great they are, even if they stole most of it from someone else.

It also contributes to a lot of this stuff being closed-source. Otherwise the stealing would be very obvious...