Eclipse / EclipseSE/Eclipse Fire/EX FHD (pig)

AlexWilMac

Moderator
Right, sure.
And, anyway, all this is just to give a feedback, because it doesn't make sense to change a skin just for a personal use or purpose.
I'd like to "help" by just testing, although I'm sure our great MX does such tests by himself ;)
 

Matrix10

Administrator
Something goes wrong if I replace your text: probably there is some extra control characters taken by copying&pasting from here.
Can you please attach the skin.xml file edited by you? Although, it seems this is an overall problem, from the info I've got. It comes from some overall changes in the OE-A original code and its MessageBox part...

This problem is fixed only in the default skin,some time ago.
I don’t know why some coders change things that are almost irrelevant.
(Not OBH coders)
Especially not taking into account the existing skins.
That's an old problem.
I really have no intention of updating dozens of skins for such changes every time.
This is not just an coding problem but deleting all skins from the server and uploading new ones.

Okay I updated this skin for you.
You can test
But I stay on two lines in the list
because this panel is used in several places
in most cases with two lines.

Eclipse Fire skin
 

Attachments

  • skin.zip
    55.5 KB · Views: 11
Last edited:
Thanks and its allways best to get it from the source :) so thanks MX for cleaning up the mess i have done ;)

And totaly agree with you MX never ever are they consulting skinners when they do changes on coding
I know this first hand and special the OBH gets often hurt by this since its buillt on the OE Alliance core and not the Vu+ like Blackhole.
 

AlexWilMac

Moderator
First of all thanks to @Matrix10 for his extra effort.
What I'd like to underline is that this was not intended just and only to have a skin adjusted but to open a discussion about the opportunity to find a smart way to get over the bounds of the code.
I examined both the solution proposed by MX and Thomas. They differ for the fact of taking automatically into account how many lines are in the MessageBox or keeping the default of visible lines at the number of two.
The results are in the corresponded screengrabs attached (the first 3 from MX solution, the second three from the Thomas solution, as of their filenames).

I'm not into the skin coding field but, if I interpret correctly what Thomas did (you tell me, Thomas, if I'm wrong), this line of code
count = len(self.list)
is meant to adapt to the situation. So if we have two options, two lines wioll be shown; otherwise we'll have 3 or 4 (or probably more: I haven't found more than 4 options so far!).
However it was got, the result is modular.

But, again, the real problem is: is it a great deal to introduce similar piece of codes in every skins from now on just to "win" over the coders who, as MX said, don't care about skins and skin coders?
Because, it must be said, if coders don't show consideration for skins, they actually show no consideration for us users.
Skins, either the nice ones or the ugly ones, are the only way a user has got to interact with a code, and together they create a real software; otherwise we should do everything from the command line, as it was in CP/M, then in DOS and then in the first Linux releases, for everything.
GUIs and skins are a fundamental part of a software: we users cannot be all programmers and the success of an image, I believe, much depends also on them, not also on "pure" code.
 

Attachments

  • EclipseFire-Mbox1-2-options-MX.jpg
    EclipseFire-Mbox1-2-options-MX.jpg
    262.8 KB · Views: 26
  • EclipseFire-Mbox1-3-options-MX.jpg
    EclipseFire-Mbox1-3-options-MX.jpg
    311.3 KB · Views: 25
  • EclipseFire-Mbox1-4-options-MX.jpg
    EclipseFire-Mbox1-4-options-MX.jpg
    310.8 KB · Views: 24
  • EclipseFire-Mbox1-2-options-TH.jpg
    EclipseFire-Mbox1-2-options-TH.jpg
    306.5 KB · Views: 24
  • EclipseFire-Mbox1-3-options-TH.jpg
    EclipseFire-Mbox1-3-options-TH.jpg
    94.6 KB · Views: 24
  • EclipseFire-Mbox1-4-options-TH.jpg
    EclipseFire-Mbox1-4-options-TH.jpg
    276.1 KB · Views: 24

AlexWilMac

Moderator
P.S. obviously (it was tacit) I was not talking about our OBH or BH coders but about coders of the overall project.
Actually, as far as I know, our coders had already done an "extra" work to fix other coders' issues ;)
 

Matrix10

Administrator
First of all thanks to @Matrix10 for his extra effort.
What I'd like to underline is that this was not intended just and only to have a skin adjusted but to open a discussion about the opportunity to find a smart way to get over the bounds of the code.
I examined both the solution proposed by MX and Thomas. They differ for the fact of taking automatically into account how many lines are in the MessageBox or keeping the default of visible lines at the number of two.
The results are in the corresponded screengrabs attached (the first 3 from MX solution, the second three from the Thomas solution, as of their filenames).

I'm not into the skin coding field but, if I interpret correctly what Thomas did (you tell me, Thomas, if I'm wrong), this line of code
count = len(self.list)
is meant to adapt to the situation. So if we have two options, two lines wioll be shown; otherwise we'll have 3 or 4 (or probably more: I haven't found more than 4 options so far!).
However it was got, the result is modular.

But, again, the real problem is: is it a great deal to introduce similar piece of codes in every skins from now on just to "win" over the coders who, as MX said, don't care about skins and skin coders?
Because, it must be said, if coders don't show consideration for skins, they actually show no consideration for us users.
Skins, either the nice ones or the ugly ones, are the only way a user has got to interact with a code, and together they create a real software; otherwise we should do everything from the command line, as it was in CP/M, then in DOS and then in the first Linux releases, for everything.
GUIs and skins are a fundamental part of a software: we users cannot be all programmers and the success of an image, I believe, much depends also on them, not also on "pure" code.

Neither of coding is ideal.
One coding has automatic changes
by height and the other by width.
It would be best to have a coding that automatically changes both panel height and width.
 
You are correct Alex and same are you Matrix10
So therfore i have re written the applet code for MessageBox and MessageBoxSimple.
It can still probably be tweaked a little bit better but this is as close i get.

<applet type="onLayoutFinish">from enigma import getDesktop, eSize, ePoint
count = len(self.list)
if not self['text'].text:
textsize = (780, 0)
listsize = (780, 35 * count)
if self.picon:
self['list'].instance.move(ePoint(80, 0))
wsizex = textsize[0] + 80
else:
self['list'].instance.move(ePoint(0, 0))
wsizex = textsize[0]
self['list'].instance.resize(eSize(*listsize))
else:
textsize = self['text'].getSize()
if textsize[0] &lt; textsize[1]:
textsize = (textsize[1], textsize[0] + 10)
if textsize[0] &lt; 780:
textsize = (textsize[0], textsize[1] + 35)
else:
textsize = (780, textsize[1] + 35)
listsize = (textsize[0], 35 * count)
self['text'].instance.resize(eSize(*textsize))
if self.picon:
self['text'].instance.move(ePoint(80, 0))
self['list'].instance.move(ePoint(80, textsize[1]))
wsizex = textsize[0] + 80
else:
self['text'].instance.move(ePoint(10, 10))
self['list'].instance.move(ePoint(0, textsize[1]))
wsizex = textsize[0]
self['list'].instance.resize(eSize(*listsize))
wsizey = textsize[1] + listsize[1]
self.instance.resize(eSize(*(wsizex, wsizey)))
self.instance.move(ePoint((getDesktop(0).size().width() - wsizex) / 2, (getDesktop(0).size().height() - wsizey) / 2))
</applet>
 

Attachments

  • skin.zip
    54.6 KB · Views: 6

Matrix10

Administrator
Thomas,

Is it possible for the list to go from left to right
with a distance of ten to the left and the same number to the right.
Is it possible that the list does not go all the way to the bottom
let's say ten lines above the end of the panel / line.
 

Matrix10

Administrator
OK
I changed our old coding a bit
i am not an image coder
I learned a little from all of you :D
Test please

If it is good then we can use this coding.

It is also possible to use the / bar button in the list
which was used by Thomas
 

Attachments

  • skin.zip
    55.5 KB · Views: 1
Have tested and did some minor tweaks to move the list up closer to the text
Otherwise nice workaround MX :)

Try and see what you think about this??
 

Attachments

  • skin.zip
    54.6 KB · Views: 6

Matrix10

Administrator
EclipseFire update

test pls

Language Selection panel
Skin Selector
Lcd SkinSelector
Auto Bouquets Maker_Setup
Thanks to @nunigaia for earlier fix in skin default Black Shadow skin.
 

Attachments

  • skin.zip
    55.6 KB · Views: 4

Matrix10

Administrator
EclipseFire Skin UPDATE

All Updates:

Massagebox
Language Selection panel
Skin Selector
Lcd SkinSelector
Auto Bouquets Maker_Setup
HistoryZapSelector
IMDB
ext infobar CryptoBar added VM
EPGRefreshConfiguration
EPGRefreshServiceEditor
ChoiceBox
 

Attachments

  • skin.zip
    55.8 KB · Views: 7
Last edited:

AlexWilMac

Moderator
I'm sorry I couldn't test it, also, because of a couple of really bad days...
But I'm sure Thomas was a great tester, better than me with his knowledge of skin coding. I would be just a user ;)
 
Top