108 replies to this topic

[Erik Slagter]

I doubt people are interested in a new, cleaner and maybe better way - because it is right now simply very difficult to replace the existing, working but "bad" implementation in their images.
In addition i allready noticed some problems we allready had 2 years ago in your new approach.
Sorry for offtopic - we should not move this to unicable ii discussion.

???

 

Surely I have no clue what you are talking about.

 

Users always say they don't care about proper, clean implementations, but in the end, when (not if!) it doesn't work, they blame use and we can go fix it. That is not a statement from me, that is what history proves.

 

Anyway, there are enough images that don't care about code quality, I suggest that users already have the choice.

[Erik Slagter]

I think the remark is that the entire code could have been in kHz, in an integer, and just add a dot in the middle for display purposes.

 

That perhaps would have been simpler, but would require entry in kHz, always, so entering 6 instead of 3 digits for most people. Alternative would be to enter in Mhz as a float, and then directly convert it to integer after input. But that makes the input different from the processing, and isn't exactly clear either.

 

I think I agree with littlesat that although this is more work, it gives a cleaner end result.

Exactly.

 

Most users will never need to enter six digits, for them three digits is sufficient. So that's why I came up with the compromise of introducing a decimal point, so the majority of the users can still enter three digits like they're used to and the small minority, that needs a fraction, can enter that as well. Conceptually very clean and also user friendly.

 

I am missing some abstraction in the view in this thread. If we make the config value a float, that doesn't mean the value is carried as a float through enigma, it can be just a input tool and nothing more! Similarly, we could use a string, just to be able to enter a decimal point, if it turns out a float can't work. The argument that a float isn't precise enough doesn't stick, though, because the resolution of a double is way larger than you'll ever need for a proper tuning. For a "neat" display, it could be rounded, it doesn't impact operation.

[Erik Slagter]

All this stress just to display an unnecessary dot in the user interface.

We are now quite aware of your opinion now, please stop trolling. You're not the only user.

[Huevos]

Erik you are missing the point. Whether the dot is there or not it is still a six digit field. In both cases the user can just enter the first 3 digits if that is what they choose.

[littlesat]

The digits are the same, you do not need to fill in additional 3 digits and you can stop mentioning the freq is in KHz which is weird. The impact in code is currently less then changing it in KHz and it is now not more complicated by adding the floatint property, so add the end all changes are win-win...

P.s. I did never saw DVD-t or c frequencies mentioned in KHz - so now it is corrected as it should be from the beginning.... I suggest those who made it from the beginning understood the need for the KHz but were not aware of ConfigFloat

Edited by littlesat, 12 October 2016 - 17:30.

[arn354]

???
 
Surely I have no clue what you are talking about.
 
Users always say they don't care about proper, clean implementations, but in the end, when (not if!) it doesn't work, they blame use and we can go fix it. That is not a statement from me, that is what history proves.
 
Anyway, there are enough images that don't care about code quality, I suggest that users already have the choice.

Holy Eric - The only thing i say is that other images will have a hard approach IF they want to implement YOUR way of JESS - because you didn't accept the initial patch and improve TOGETHER from that point on.
Clean or not - it was and is a working implementation in other images for more then 1,5 years. Anyways, i keep my mouth closed in future.

Edited by arn354, 12 October 2016 - 18:21.

[Abu Baniaz]

No need to keep mouth closed. If there is no discussion, there is no improvement. It is healthy and beneficial to see other people's point of view/ideas even if you do not agree with them.

However, when discussions end up being more about who thinks they are better and how everyone else is poor, this is a hindrance.

By the way, E2 does not honour the Net ID for the UK. Nor does it recognise the provider name. Should I start a new topic?

[dAF2000]

By the way, E2 does not honour the Net ID for the UK. Nor does it recognise the provider name. Should I start a new topic?

 

Yes, please. Just to keep the topics clear.

[Erik Slagter]

 

???
 
Surely I have no clue what you are talking about.
 
Users always say they don't care about proper, clean implementations, but in the end, when (not if!) it doesn't work, they blame use and we can go fix it. That is not a statement from me, that is what history proves.
 
Anyway, there are enough images that don't care about code quality, I suggest that users already have the choice.

Holy Eric - The only thing i say is that other images will have a hard approach IF they want to implement YOUR way of JESS - because you didn't accept the initial patch and improve TOGETHER from that point on.
Clean or not - it was and is a working implementation in other images for more then 1,5 years. Anyways, i keep my mouth closed in future.

You're missing the point.

 

In the first place, let me state this clear, we're not to please other images' developers. They can cherry-pick anything from our code they like, but we're not going to take that in consideration beforehand.

 

Secondly, I can actually live with someone else's implementation of something, that's completely not the point. See the piles of contributions from external developers. It's not about "my stuff is better than yours". If it were that way, I wouldn't have spent three fulltime days trying to get the dvbadenin stuff both working AND neatly included in our repo. While doing that, I got less and less convinced this would ever work in an acceptable way, but still I continued until the end.

 

Lastly, who is going to be held resposible for bugs appearing in Enigma, especially in parts that have nothing to do with JESS, so not just the 0.01 % of the userbase, but ALL users will be affected?
 

And that is why it is unacceptable that a piece of code that has been "evolved" this way, in whatsoever no structured way, changes and adds code in enigma at lots of locations that have NOTHING to do with either Unicable or JESS would be applied. Moreover, we all agree that it's way too complex and complexity creates bugs. Support for JESS only needs a few additional lines of code in Enigma, plus maybe a few hundred lines of python. So why dvbadenin needs thousounds of lines if completely a mystery.

 

This is the last thing I am going to say about this. Remember, the ones that do the work get to make the decisions.