465 replies to this topic

[littlesat]

I get issue with GMEPG, ServiceList.... as it seems there the skin attribute list become empty....

 

It might indeed be better to create a new object e.g. TextLabel for the skin... that does all functionality of Label, Button and StaticText and then in the skin itself we can swap to TextLabel... Just to keep one clean new thing and keep the old for backwards compatebility....

Edited by littlesat, 9 June 2018 - 09:22.

[prl]

I'm taking a step back from this, then. I don't think it's either desirable or feasible to make objects that implement full correct behaviour in both a name= and source= skin widget environment. I'm not even sure what "correct" means in that environment.

 

If this is to be done for Button, Label and StaticText, why stop there? Why not make it the design for every Component?

 

Does anyone even know what the additional functionality of Button/eButton over Label/eLabel is supposed to achieve?

[prl]

Littlesat, here is the original commit, committed by you in 2012.

https://github.com/O...3d0886a5241e010

 

So now, 6 years later, skinners expect this behaviour.

 

PRL's commit just reverses this behaviour (except it doesn't actually reverse the original commit).

 

 

No, prl's commit doesn't reverse that behaviour, it encapsulates it in the class DummySource, along with some other behaviour to make those methods do what they appear to be intended to do.

[IanSav]

Hi Prl,

 

Can you please explain your reservations.

 

From my perspective I was simply looking for a way to separate what code Python coders write from how skin developers use the available skin variables.  If there is text to be displayed then the skin author should be able to decide to display it as a simple "name=" widget or, if more manipulation is desired, a "source=" widget with all the converters available to that type of display object (conditional display, text mutation, image substitutions, etc).

 

Regards,

Ian.

[littlesat]

My issue is the gsod I get with channelslist gmepg etc... due to attribute lists being None...

[Huevos]

To PRL, your commit blocks Button() and Label() writing to "source". The commit by Littlesat 6 years ago was to get Button() and Label() to write to "source".

Why would you now want to stop that behaviour and break any skin that currently uses the feature?

[Huevos]

Also if the original feature is no longer required why is it not reverted? Why do we need new code to turn the old code into dead code? No wonder enigma is such a mess.

[betacentauri]

I'm really a noob regarding this. Can someone explain in a few sentences why there are name and source widgets. Is there an advantage using name or source?
Can’t you just declare one of them as deprecated and write big warning messages when a skinner still uses it?

[IanSav]

Hi Betacentauri,

 

A "name=" widget simply takes its source data and renders it on screen.  The is no ability within the skin to manipulate the data.  A "source=" widget also takes its source data and renders it on screen.  The difference is that "source=" widgets are able to pass the data through a linked list of converters to manipulate or conditionally display the data in various alternate ways.

 

How did I do? 

 

Regards,

Ian.

[betacentauri]

Very good . Thanks for the short explanation!

[Rob van der Does]

This raises the question why a "name=" widget is required at all.

[littlesat]

Rob... you hit a point...

[IanSav]

Hi Rob,

 

I would use "name=" when there is a simple display need.  It is a shorter syntax to type in. 

 

I would happily to loose "name=" if it meant that the code could be simplified and made faster and more efficient.  It would reduce complication for both Python coders and skin developers.  (As mentioned before, synonyms could be created to keep legacy code and skins running.)

 

Regards,

Ian.

[Huevos]

This raises the question why a "name=" widget is required at all.

It is not, but it would take a huge amount of editing python code and skins to drop it. And there are already skinners moaning about the few small changes we have made so far.

[Huevos]

Hi Rob,

 

I would use "name=" when there is a simple display need.  It is a shorter syntax to type in. 

 

I would happily to loose "name=" if it meant that the code could be simplified and made faster and more efficient.  It would reduce complication for both Python coders and skin developers.  (As mentioned before, synonyms could be created to keep legacy code and skins running.)

 

Regards,

Ian.

Still doesn't cure the problem though because you can't update the "source" text on the fly when the object is Button or Label.

 

And what about the "show/hide" methods? These don't exist in StaticText.

 

Also the other disadvantage of "name" is it can only be used once per screen. Whereas it is possible to have multiple "source" widgets that use the same label.

[littlesat]

You have also label in skins to put some text somewhere without having am’key’ in python...

[prl]

Hi Prl,

 

Can you please explain your reservations.

 

From my perspective I was simply looking for a way to separate what code Python coders write from how skin developers use the available skin variables.  If there is text to be displayed then the skin author should be able to decide to display it as a simple "name=" widget or, if more manipulation is desired, a "source=" widget with all the converters available to that type of display object (conditional display, text mutation, image substitutions, etc).

 

 

My reservations are simple - it would require that the Button/Label/StaticText implementations would need to be completely different from their present ones. For example, if a StaticText source appeared only in a "name=" skin widget, what would be its renderer? What would be its converters?

 

My view of the complexity of actually doing this seems to be supported by the fact that the idea seems to have strong support as an idea, but no-one seems to be stepping forward to implement it, or even with ideas about how it might be implemented.

 

If Button/Label/StaticText are to be re-arranged in this way, then it seems that all Components/Sources should be re-arranged in the same way, and that looks like quite a big undertaking.

[IanSav]

Hi Huevos,

 

 

Hi Rob,

 

I would use "name=" when there is a simple display need.  It is a shorter syntax to type in. 

 

I would happily to loose "name=" if it meant that the code could be simplified and made faster and more efficient.  It would reduce complication for both Python coders and skin developers.  (As mentioned before, synonyms could be created to keep legacy code and skins running.)

 

Regards,

Ian.

Still doesn't cure the problem though because you can't update the "source" text on the fly when the object is Button or Label.

 

And what about the "show/hide" methods? These don't exist in StaticText.

 

Also the other disadvantage of "name" is it can only be used once per screen. Whereas it is possible to have multiple "source" widgets that use the same label.

 

 

My comment was not to simply drop "name=" as it is now but to only have a "source=" display mechanism *IF* a new display type was to be developed that does everything done previously by Button(), Label() and StaticText().

 

Regards,

Ian.

[IanSav]

Hi Prl,
 

My reservations are simple - it would require that the Button/Label/StaticText implementations would need to be completely different from their present ones. For example, if a StaticText source appeared only in a "name=" skin widget, what would be its renderer? What would be its converters?

Without understanding all the issues going through your mind I would suggest that no converters would be required or allowed in this simplified display case. The rendered could probably default to Label.
 

My view of the complexity of actually doing this seems to be supported by the fact that the idea seems to have strong support as an idea, but no-one seems to be stepping forward to implement it, or even with ideas about how it might be implemented.
 
If Button/Label/StaticText are to be re-arranged in this way, then it seems that all Components/Sources should be re-arranged in the same way, and that looks like quite a big undertaking.

 

I have lots of enthusiasm for the task but, unfortunately, I lack the skills to complete it.

 

Regards,
Ian.

[Rob van der Does]

This raises the question why a "name=" widget is required at all.

It is not, but it would take a huge amount of editing python code and skins to drop it. And there are already skinners moaning about the few small changes we have made so far.

And 'moaning skinners' are all that's required to stop any form of progress? I can't believe that!
If the moan and don't update their skin, their skins get lost, simple as that.
And you don't have to drop them all at once in E2; this can be an ongoing process over some time.

My comment was not to simply drop "name=" .....

No, but it just happens to pop up now as a side-discussion in this thread.

Edited by Rob van der Does, 11 June 2018 - 03:40.