Jump to content


Photo

Proposal for flexible formatted strings in convertors

Skin Convertor Format

  • Please log in to reply
18 replies to this topic

#1 DimitarCC

  • PLi® Contributor
  • 1,584 posts

+71
Good

Posted 20 October 2023 - 08:19

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?


Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, 2xPulse4K, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & 2xTriax 78 (39E)


Re: Proposal for flexible formatted strings in convertors #2 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 20 October 2023 - 12:23

I think that for this possibility we need to introduce additional components, instead of correcting the existing ones.
If such a component uses information from existing components, you will be able to use any information.
If you correct the existing ones, it will be the same as with ServiceName, where you add information that is already in another converter.


Re: Proposal for flexible formatted strings in convertors #3 DimitarCC

  • PLi® Contributor
  • 1,584 posts

+71
Good

Posted 20 October 2023 - 12:33

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


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

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, 2xPulse4K, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & 2xTriax 78 (39E)


Re: Proposal for flexible formatted strings in convertors #4 Huevos

  • PLi® Contributor
  • 4,756 posts

+167
Excellent

Posted 20 October 2023 - 12:41

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>

 



Re: Proposal for flexible formatted strings in convertors #5 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 20 October 2023 - 12:44

I hope you got my idea.
Create one component that combines information from other existing ones.
But that's just my opinion, maybe others see it differently.


Re: Proposal for flexible formatted strings in convertors #6 DimitarCC

  • PLi® Contributor
  • 1,584 posts

+71
Good

Posted 20 October 2023 - 13:45

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.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, 2xPulse4K, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & 2xTriax 78 (39E)


Re: Proposal for flexible formatted strings in convertors #7 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 20 October 2023 - 14:32

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #8 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 20 October 2023 - 16:38

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.



Re: Proposal for flexible formatted strings in convertors #9 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 20 October 2023 - 17:04

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?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #10 Huevos

  • PLi® Contributor
  • 4,756 posts

+167
Excellent

Posted 20 October 2023 - 18:49

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.



Re: Proposal for flexible formatted strings in convertors #11 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 20 October 2023 - 19:05

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.


Re: Proposal for flexible formatted strings in convertors #12 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 20 October 2023 - 19:06

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #13 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 20 October 2023 - 19:11

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #14 Taapat

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 20 October 2023 - 19:12

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?

 

In my experience, if you call something "Deprecated" there is a well-thought-out reason for it, and that means it won't be used in the next release.
If you mark something as "Deprecated" and it doesn't change in future releases, then the question is why do you mark it that way if its usage doesn't change?


Re: Proposal for flexible formatted strings in convertors #15 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 20 October 2023 - 19:17

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.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #16 Huevos

  • PLi® Contributor
  • 4,756 posts

+167
Excellent

Posted 20 October 2023 - 19:47

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.



Re: Proposal for flexible formatted strings in convertors #17 DimitarCC

  • PLi® Contributor
  • 1,584 posts

+71
Good

Posted 21 October 2023 - 07:25

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.

Vu+DUO4KSE, DM920UHD, Vu+Uno4KSE, SF8008Mini, 2xPulse4K, Vu+Solo2, Dreambox DM500HD, Triax 78 (7E,9E,13E,19.2E,23.5E) & 2xTriax 78 (39E)


Re: Proposal for flexible formatted strings in convertors #18 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 21 October 2023 - 14:44

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


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Proposal for flexible formatted strings in convertors #19 WanWizard

  • PLi® Core member
  • 70,834 posts

+1,832
Excellent

Posted 21 October 2023 - 14:48

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?


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.




Also tagged with one or more of these keywords: Skin, Convertor, Format

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users