Forums

Hello.

 

Few time ago @WanWizzard stated that we need more flexible way to use formatted strings in skins.

So i thought about it and i think i found a solution. so i post this as a discussion here so to discuss what can be done and everybody to give suggestions before to post a PR for that.

 

So, finally i came up to this possible definition in the skin

<convert type="EventTime">F',{StartTime:%H:%M} - {EndTime:%H:%M}  •  {DurationSign}{Duration:d} min</convert>

Let me explain the parts of the convert text definition...

 

The text/type is a comma separated list with first element " F' ". That stands for to notify the convertor that we have a format string template as a second element.

So the second element is obviously the format string.

{StartTime:%H:%M} - {EndTime:%H:%M}  •  {DurationSign}{Duration:d} min

Here you can specify what you want to render and also you can specify the format of the elements in it. For example StartTime of the event:

{StartTime:%H:%M} - %H:%M formatted as 24h time

In this way you can construct whatever sequence you want with separators of your choice or without them.

 

 

So to work all this ofcource the convertor itself have to be adapted. For example above the code in the convertor can look like this:

begin = event.getBeginTime()
end = begin + event.getDuration()
now = int(time())
duration_sign = ""
if begin <= now <= end:
   duration = end - now
   duration_sign = "+"
else:
   duration = event.getDuration()

d = {"StartTime":datetime.fromtimestamp(begin), "EndTime":datetime.fromtimestamp(end), "Duration": duration//60, "DurationSign": duration_sign}
res_str =  self.parts[1].format(**d)

The requirements is the values to be formattable and to provide in the dictionary all possible values that you may use in the format string.

 

So any thoughts?

I am OK with adding new convertors/components if you agree with it.

Edited by DimitarCC, 20 October 2023 - 12:34.

res_str = self.parts[1].format(**d)

And using "format" means the format string doesn't have to correspond with the field list, i.e. no duration.

<convert type="EventTime">{StartTime:%H:%M} - {EndTime:%H:%M}</convert>

 

I got it. But there will be some difficulties....

As i said above the values provided have to be formattable.

For example time struct in python can not ever be formatted using the .format function. So it must be converted to datetime by using datetime.fromtimestamp(..)

Also current converters produce formatted values (fixed format) as string which will not be suitable for that new component/convertor.

In my opinion existing convertors have to be modified so to expose functions which will provide raw formattable values suitable for use with format string template.

So it will require a bit redesign of the idea of convertors in enigma2, but also since have to be kept backward compatibility it still have to be possible to provide same type of values like it is now.

Also in a matter of localization all labels used have to be translatable and in my opinion a values have to be provided for all standard labels like "min", "MB", "KB" and so on.

Edited by DimitarCC, 20 October 2023 - 13:52.

my 2ct's:

 

I'd say leave the old converters / renderers alone, and mark them "deprecated", and create new ones with the new / extended functionality.

 

This way every skin designer can make the swap in her / his own time, without breaking backward compatibility.

 

And the skin load logic needs to be adapted so that converts / renderers can be loaded from the skin directory too, instead of hardcoded only from /usr/lib/enigma2/python, so that skin designers are no longer forced to copy their specials to the system directory.

 

This directory should have precedence, which would allow a skin designer to replace a core component without touching that core component, avoiding issues if a user switches skin to one that depends on the original component.

WanWizard I think you are missing the spirit of enigma2 with a comment like this.
I'm sure, You, and many others, don't know about projects like Neutrino or similar, where someone wanted to create a perfect GUI, but ignored the existing reality.

Therefore, there is no need to mark anything as "deprecated". 

You need to effectively use existing opportunities and create new ones, if necessary.

I don't understand what your problem is.

 

The only thing I wrote is, "don't break backward compatibiltity"?  "Deprecated" only means "may be removed in the future, from now on use this better replacement"? Which is a normal thing to do if you want to keep the code bloat due to legacy code under control?

my 2ct's: And the skin load logic needs to be adapted so that converts / renderers can be loaded from the skin directory too, instead of hardcoded only from /usr/lib/enigma2/python, so that skin designers are no longer forced to copy their specials to the system directory.

Are you really suggesting running python code from the skin folder? How are you going to import that? The python root folder for enigma is /usr/lib/enigma2/python. In the current system the converters are loaded into the convert folder by the skin package and opkg makes sure there are no conflicts. Converters and Renderers have been packaged like this with skins for years, so why this new idea now.? It actually makes enigma more complicated compared to now with zero added value.

Are you really suggesting running python code from the skin folder?

You can use your own converters, which are named with the skin prefix or something individually.
But I don't see any reason for that if everyone uses the same.

Edited by Taapat, 20 October 2023 - 19:05.

That was my suggestion, yes. From an architectural and design point of view the only logical solution.

 

How is that going to work, if at all? I don't know, I'm not a python expert, nor have I looked into it. It could very well be it is not feasable from the technical point of view.

 

It is a deviation of "how it was always done". Yeah, and? 10000 lemmings and all that...

 

Given the number of issues with both plugins and skins overwriting core files, I think it is safe to say opkg (if used at all, a lot is installed manually, from zips or source) doesn't safeguard you against that at all.

You can use your own converters, which are named with the skin prefix or something individually.

But I don't see any reason for that if everyone uses the same.

 

That is a work-around to prevent collisions, yes. But not all plugins and skins do that.

I don't understand what your problem is.

 

The only thing I wrote is, "don't break backward compatibiltity"?  "Deprecated" only means "may be removed in the future, from now on use this better replacement"? Which is a normal thing to do if you want to keep the code bloat due to legacy code under control?

 

The reasoning behind it was that new functionality replaces the old. 100%. Obviously, if that is not the case it is a different story ( but then the new code should be revisited ).

 

The point is that you don't want two sets of code that do exactly the same thing. That is code rot and created technical debt, which will bite you in the future.

 

And there is absolutely no reason for a forced removal, deprecate just means "will be removed in the future, use is not advised". But yes, eventually it has to be removed, for the reasons previously stated.

 

Leaving code with duplicate functionality in the codebase is just handy for lazy users of the code, not for maintainers of that code.

That was my suggestion, yes. From an architectural and design point of view the only logical solution.

 

How is that going to work, if at all? I don't know, I'm not a python expert, nor have I looked into it. It could very well be it is not feasable from the technical point of view.

 

It is a deviation of "how it was always done". Yeah, and? 10000 lemmings and all that...

 

Given the number of issues with both plugins and skins overwriting core files, I think it is safe to say opkg (if used at all, a lot is installed manually, from zips or source) doesn't safeguard you against that at all.

We build complete images and compatible packages from the feeds. If people are installing stuff from zips and suchlike, and breaking things, that is not our problem.

Maybe we can make solution in the middle...
We can introduce several new convertors (separated by the source type) which will contain the new way of constructing the string. And keep the old convertors for backward compatability.
After some time old type convertors will be removed (or at least duplicated part).
In this way we will have new possibilities and at same time not break current skins.

That was exactly what I suggested, but what appearently was misunderstood.

We build complete images and compatible packages from the feeds. If people are installing stuff from zips and suchlike, and breaking things, that is not our problem.

 

You may have a point, as long as they don't pop in here and ask for support. And we're send on a wild goose chase, because we don't know some py has been overwritten...

 

Maybe something crude like "opkg install enigma2 --force-reinstall" in enigma2.sh if e2 is in a crash loop, plus a fallback to the emergency skin? Then at least we know e2 is in a known state?