Print Page - Значение Text как формат для полей с биндами на числовые данные

Есть такие бинды как dialogs.*.value.duration, dialogs.*.value.position и подобные. Мне допустим в своем скине очень хочется видеть их данные в отличном от стандартного форматировании, например длительность с нулем впереди и без дробной части, но сейчас адекватными способами этого никак не добиться.

Предложение в том, чтобы сделать поддержку форматирования подобным числовым биндам через значение свойства Text(PlaylistItem-у и подобным его надобно будет добавить). Есть встроенные методы форматирования времени, но они обычно тянут за собой i18n что не очень то и нужно + не позволят гибко управлять округлением.

Посему набросал что хочу видеть; при грамотной реализаии она потребуется всего лишь один раз и сможет использоваться для форматирования любых числовых данных

Для времён хотелось бы видеть литералы h, m, s, f.
синтаксис выражений
- разрешена только одна группа литералов каждого типа, все последующие должны восприниматься как пользовательский текст
- концом группы является символ, отличный от литерала текущей группы. Здесь же начало следующей группы.
- символ, следующий за backslash(\) или не являющийся литералом - пользовательский текст и выводится как есть
- если представлен только один тип литерала - отображать все значение в его мере
- для всех литералов в конце формата различать нижний и верхний регистры, кроме случаев когда f единственный использованный тип
- если регистр литералов в пределах группы разный - использовать регистр последнего символа
- литерал в нижнем регистре - отбрасываем(обрезаем) дробную часть, в верхнем - округляем по общим правилам (>= 5 -> +1)
- литерал f обозначает дробную часть меры литерала предыдущего типа и разрешен только в конце, иначе игнорировать
- если литерал f единственный использованный - выводить значение в наименьшей мере(милисекундах для времён)
- литерал f может следовать только за секундами(комбинироваться), иначе игнорировать (или в редакторе конвертить в следующую по убыванию меру с сохранением регистра)

пример, значение 217467 ms

формат	вывод	примечание
f	217467	-
m	3	-
mM	04	округляем минуты целиком т.к. последний литерал в верхнем регистре
mm:ss	03:37	литералы секунд в нижнем регистре - отбрасываем дробную часть, а не округляем секунды
MM:ss	03:37	округление минут игнорируется т.к. литерал минут не в конце
MM:SS	03:38	игнорим минуты, но не секунды - они в конце и округляются, 37.467, 7 >= 5 -> 37.47, 7 >= 5 -> 37.5, 5 >= 5 -> 38
mm:SS.FF	03:37.47	здесь игнорятся секунды а дробная часть округляется до двух знаков
mm.fff	03.037	если делать конвертацию, то редактор должен сконвертить это в mm.sss

Опционально, для размеров, частот и прочих кило/мега/гига числовых данных литералы g, m, k, f, синтаксис тот же что и для времен, за исключением комбинирования f - оно разрешено с любым литералом

как пример размер файла и значение 5256974 bytes
допустим такой странный формат m\M\B k.F\K\B
результат будет таким 5MB 13.7KB

ну ееесли так ленииииИъиво то можно и простой DisplayLeadingZero добавить)

Quote from: Xaker_Two on September 11, 2023, 22:03:25

округляем по общим правилам (>= 5 -> +1)

Quote from: Xaker_Two on September 11, 2023, 22:03:25

секунды - они в конце и округляются, 37.467, 7 >= 5 -> 37.47, 7 >= 5 -> 37.5, 5 >= 5 -> 38

37.467 по общим правилам округляется до 37, зачем использовать алгоритм с накоплением ошибки и получать неправильный результат?

Вы описали общепринятый мат. метод, который смотрит на знак N + 1, где N нужная точность. Я же про округление с хвоста(точнее с первого числа меньше 4)
Но у нас вроде не финансовая тематика и накопление ошибки такого плана допустимо + оно позволит избежать вопросов пользователей типа
"А вот в одном месте мне время пишется 37.5, а в другом 37 ровно, хотя по правилам округления должно быть 38"
и придется объяснять, что за кулисами число намного длиннее чем видит пользователь, ссылаться на истинную длину трека, слать на вики на статью округления... Проще накапливать допустимую ошибку, а она максимум 0.(5)
В любом случае это лучше чем сейчас 37.001 апается до 38 ровно =)

А так, это своего рода идеал, но если очень запарно будет в реализации то можно и мат. метод + его проще реализовать(он сам уже реализован)

AIMP Forum

AIMP for Android => Skin Editor, Skin Engine => Предложения / Suggestions => Topic started by: Xaker_Two on September 11, 2023, 22:03:25