465 replies to this topic

[Huevos]

The way I see ir your templates are far too complicated. Why do your keys have multiple names. Why don't you use the same name everywhere?

[littlesat]

What so you mean?

Edited by littlesat, 20 January 2018 - 09:14.

[littlesat]

And now I see you added a key in screen...I stared at it yesterday and could not see it.... in addition you only need to retreive the key when the parameter is presents... having red and key_red is ugly history the same that timer and timer edit and a bit more is using ok cancel keys... and while fixing this we break all skins... so I’m really ‘scared’ this time to optimize it... what do you think? I think skins should adapt.... only some screens where you really benefit from it we could consider to change it for minimal impact. E.g. I like how network is performing... ???? and streaminginfi’o.... actually the screens that are adapted might miss some buttons and texts... cosmetic... but scary

Edited by littlesat, 20 January 2018 - 09:32.

[Huevos]

My personal opinion is if it is python and you are in control of it it should be updated. Then people need to update their skins. But that is not your problem.

 

If it is a plugin and you are not in control of it and it doesn't use the correct key names just delete it from your skin and let it use its own embedded skin.

[littlesat]

I'm afraid this does not work... 

 

https://github.com/O...99ac8ef3eddacc1

 

At least hear it doesn't correcty hide buttons.... (see FlashImage)

[Rob van der Does]

There do remain (unimportant?) issues when a key is present in the x.py, but not always active.
That means that the condition to show has been fulfilled (and hence the coloured key does show) even if the key is not active in a specific situation (but will become active once the user changes a condition)..

[littlesat]

Exactly that can be solved now when using StaticText instead of Label() or Button()... the the example in StreamingInfo.py, Hotkey.py, FlashImage.py and as it always was be in the Network setup...

[Huevos]

I think those hidden png's could be merged with your main template. I've thought of a way to do it. But right now you are going down the wrong route in the python file. Hard coding it like that is a bad mistake. More trouble in the future. Why don't people write reusable code so things can work automatically?

[littlesat]

Because I could not check yet if your latest change suggestions are working they are delayed and I only want to retrieve the key when required...

Edited by littlesat, 20 January 2018 - 17:15.

[Huevos]

The reason I didn't want the "objecttypes" depending on the "conditional" is because I want to use them independently on 2 different objects, In my button panel "objecttypes" is used on the individual widgets, whereas the "conditional" is used on the whole panel.

 

Here is my fullscreen automatic button panel. So far it is completely stable with no noted secondary effects.

https://github.com/O...tes.xml#L12-L41

[littlesat]

I fully agree...

[littlesat]

Your panels are not sufficient as the button png’s are not autohiden...and there are screens that have red green etc...’without key_ you do not use the class type check at all... it I think we’re now not on the same ‘frequency’...

Edited by littlesat, 20 January 2018 - 21:23.

[Huevos]

No, there is no autohide in there yet.

 

I do use the class check on the widgets.

 

My panels work fine on all conventional code, and they are simple.

 

When I add the autohide it won't be hard coded like Flashimage.py

[littlesat]

Here Autohide works with the source statictext method...

[Rob van der Does]

Here Autohide works with the source statictext method...

And chamges are only required for a few items.
Does VirtualKeyboard work fine this way in PLi?

I would suggest ViX to use the same (or at least compatible) method as PLi, as that makes merging much more easy.

Edited by Rob van der Does, 21 January 2018 - 04:55.

[Rob van der Does]

Would there be a similar way to show/hide other buttons, like Menu & Info?

[littlesat]

It depends... when in python the same keys are used for the same thing it is fine... but the menu buttons are most time just there because the skin says it... so without code change this is not possible... (in python we need a menu,
Info key etc....)
Actually it is a pitty that skins and python are so much depended from eachother.

Edited by littlesat, 21 January 2018 - 08:28.

[Huevos]

Littlesst can you point me to the bit of code that does the auto hide. What is using the statctext boolean method?

[Rob van der Does]

It depends... when in python the same keys are used for the same thing it is fine... but the menu buttons are most time just there because the skin says it... so without code change this is not possible... (in python we need a menu,
Info key etc....)

IMHO if it's only the skin/screen 'demanding' for a (Menu/Info)button, the code should indeed be changed. And as this means effectively be 'enhanced' that would even be a good thing and hence worth the effort.

Edited by Rob van der Does, 21 January 2018 - 11:33.

[littlesat]

The boolean property added in statictext and then conditionalshiwhide in the skin. Maybe this also might work with label and vitten when we add a boolean property to variabketext.py (sorry when I named py files slightly wrong). And that was exactly my purpose!