371 replies to this topic

[Pr2]

Plugin SlowZap is not yet Python3 compatible:

[Skin] Processing screen 'MessageBox', position=(0, 0), size=(1920 x 1080) for module 'MessageBox'.


[Screen] Warning: Skin is missing element 'autoresize' in <class 'Screens.MessageBox.MessageBox'>(Certains plugins ne sont pas disponibles:
SystemPlugins/SlowZap (Missing parentheses in call to 'print'. Did you mean print("[newPlayService] Failed to start", currentlyServiceReference)? (plugin.py, line 214))
).


[Skin] Parsing embedded skin '<embedded-in-SimpleSummary>'.
[Skin] Processing screen '<embedded-in-SimpleSummary>' from list 'MessageBox_summary, SimpleSummary', position=(0, 0), size=(132 x 64) for module 'SimpleSummary'.
[Screen] Showing screen '['MessageBox_summary', 'SimpleSummary']'.

[Dimitrij]

Plugin SlowZap is not yet Python3 compatible

 

todo

[midoo]

sorry for posting this here but i couldn't find any place else

i'm building teamblue (openpli fork) for sf8008 and image booted ok but still minor issue related to full hd skin 
 


like in picture the listhight is not working properly

my source code repo is here

https://github.com/a...ree/python3-old

Edited by midoo, 30 April 2022 - 01:06.

[Huevos]

Probably "ChoiceList" alias missing from skin.

 

https://github.com/O...ty/skin.xml#L20

[midoo]

Probably "ChoiceList" alias missing from skin.

hello @Huevos this is my skin used for hotkey for example :

 
github.com/ahmedmoselhi/enigma2/blob/python3-old/lib/python/Screens/Hotkey.py#L262

my skin.xml in attachments

Attached Files

•  skin.xml   1.42MB   6 downloads

[Huevos]

It is not even present in your skin.xml file.

[midoo]

It is not even present in your skin.xml file.

it's there in line 385 :

<alias name="ChoiceList" font="Regular" size="32" height="45" />

[midoo]

@Huevos thank you for help , was fixed by updating skin_default xml from pli

 

https://github.com/a...701bfa95d4133e2

[Huevos]

In python3 branch there is a commit that has not been rebased properly.

 

In python3 branch there is this: https://github.com/O...ries.py#L79-L81

 

But the rest of the commit is missing: https://github.com/O...ededa617da51570

[dreamce]

Openpli pyt.3 openpli 8.2 zgemma h9 twin
where???

[WanWizard]

You need to build it yourself, we only build test images for people working on the project.

[WanWizard]

In python3 branch there is a commit that has not been rebased properly.

 

In python3 branch there is this: https://github.com/O...ries.py#L79-L81

 

But the rest of the commit is missing: https://github.com/O...ededa617da51570

 

That is not going to be easy, looks like a lot of refactoring took place after that date.

elif scope in (SCOPE_CURRENT_SKIN, SCOPE_ACTIVE_SKIN):

this entire section doesn't exist anymore.

 

The other "elseif's" are there, but the code is refactored (still looks quite similar though).

[Huevos]

 

In python3 branch there is a commit that has not been rebased properly.

 

In python3 branch there is this: https://github.com/O...ries.py#L79-L81

 

But the rest of the commit is missing: https://github.com/O...ededa617da51570

 

That is not going to be easy, looks like a lot of refactoring took place after that date.

elif scope in (SCOPE_CURRENT_SKIN, SCOPE_ACTIVE_SKIN):

this entire section doesn't exist anymore.

 

The other "elseif's" are there, but the code is refactored (still looks quite similar though).

 

Ok, I'll do this.

 

But, any time there are new commits in Develop, Python 3 branch should be rebased on top. If you do this as you go along it is so little work.

[littlesat]

Personally I prefer to freeze develop and go for py3 to avoid the merge conflict workload. but in between py3 is currently somehow on hold (again)

[Huevos]

By the way the real problem is that the branch started as a python 3 feature branch and then someone started to add commits completely unrelated to the python 3 conversion. i.e. use it as their playground. This can be seen if you do a diff of the 2 branches. Things added not related to the conversion, and partial commits.

[littlesat]

That is even more terrible indeed…

[Huevos]

That is even more terrible indeed…

Yes, it is true... like changing all the SCOPE names to the "better" IanSav versions.

[littlesat]

Iansav has good intended suggestions… but it means it breaks thinks cross image and offers a lot of extra work for all devs… without adding real added technical value… we can better accept that enigma2 has crap parts and live with it and only improve parts of them when you try to add value/features and it is required or helpfull… but not at random… so the projects starts into fixing what the good intended stuff did break instead of add value… We should think more effective. An not spend our time on stuff that gains even more work…

Indeed the scope stuff should not be included in py3…

Edited by littlesat, 21 May 2022 - 11:33.

[WanWizard]

Personally I prefer to freeze develop and go for py3 to avoid the merge conflict workload. but in between py3 is currently somehow on hold (again)

 
That can only work if there is a firm commitment to work on it, and to finish it, because while develop is no updates are possible, and frozen nothing can be fixed either. So the frozen period needs to be as short as possible. And I haven't seen that commitment.
 

But, any time there are new commits in Develop, Python 3 branch should be rebased on top. If you do this as you go along it is so little work.

 
Agreed, the longer you wait with a rebase, the more complex it will be.
 

By the way the real problem is that the branch started as a python 3 feature branch and then someone started to add commits completely unrelated to the python 3 conversion. i.e. use it as their playground. This can be seen if you do a diff of the 2 branches. Things added not related to the conversion, and partial commits.

I'm not sure that is the case, it more looks like code that was already converted to python3 was taken from elsewhere (my guess: OpenVision), and with that came Ian's changes. I don't think it is intentional.
 

we can better accept that enigma2 has crap parts and live with it and only improve parts of them when you try to add value/features and it is required or helpfull

 

I strongly disagree, if only because refactoring improves the quality of the code. So it is always helpful, and a good idea.

 

The root cause of this issue is not doing a daily rebase, not the fact the code was optimized along the way...

[littlesat]

I strongly disagree, if only because refactoring improves the quality of the code. So it is always helpful, and a good idea.
->
When it indeed does improves without breaking other stuff I agree…. But when it breaks other stuff and just add new work in cascade I do not agree.