Feodor2
Новый редактор параметров about:config
Наконец дошли руки перепилить под Mypal понравившийся народу редактор параметров.
Оригинал был, естественно, на XUL, и перенести его в Mypal можно было довольно легко - там, по сути, нужно только поменять имя файла из LangPack, содержащего нужные названия полей и кнопок, - но решить выпендриться и сделать полностью на HTML.
Эта процедура попила крови изрядно, и получилось чуток хуже, чем на XUL:
- Поле для ввода текстовых значений при растягивании окошка растягивается только по горизонтали, а вертикальный размер не меняется.
- Окошко можно уменьшить до такого размера, что оно становится меньше своего содержимого, и появляются полосы прокрутки.
Но даже такой вариант куда лучше, чем штатный способ редактирования. (И, может, кто владеющий HTML-ем получше меня, сможет дополировать.)
Для этой реализации пришлось полностью переписать две функции в https://github.com/Feodor2/Mypal68/blob/main/toolkit/components/viewconfig/content/config.js - NewPref() и ModifyPref().
Новый код намного меньше и проще исходного мозилловского, и при этом совместим с ним по входным параметрам и возвращаемым результатам работы - на случай, если кому-то взбредёт в голову вызывать эти функции программно.
PullRequest вот: https://github.com/Feodor2/Mypal68/pull/655
Окошко как раз одно-единственное (вместо кучи разных, которые всю жизнь Firefox использовал). Просто здесь я Фотошопом собрал в одну картинку все варианты его внешнего вида, которые оно имеет в разных ситуациях (создание нового параметра или редактирование существующего, а также тип параметра (string/integer/boolean)).
Видов на картинке потому и пять, что редактирование boolean в браузере не предусмотрено - вместо него сразу идёт переключение ("Toggle").
Вот ссылка на расширение для Iceape: http://yup.lh1.in/AddOns/NewPrefEditor/index.ru.html - там показаны все виды по-отдельности и описание приятных возможностей, которые я тут не упомянул.
Mypal can’t find the file at /mypal68/dist/bin/chrome/toolkit/content/global/NewPref.xhtml. шото не работает, может забыл его прописать в каких-нибудь jar.mn.
Думаю не обязательно выводить в отдельный файл, если всё всунуть в старые файлы то этой проблем не должно быть
шото не работает, может забыл его прописать в каких-нибудь jar.mn.
Ну как забыл... Я же с системой сборки Mypal незнаком совершенно. Работаю по живому - распаковал omni.js, поправил, запаковал, проверил. Ещё поправил, запаковал, проверил. Ещё поправил, запаковал, проверил... И так по кругу.
Сейчас вписал два эти файла в ближайший по дереву jar.mn, в котором нашлись config.xhtml и config.js, - "по образцу и подобию". Дальше вверх по дереву эти файлы уже нигде не упоминались. Pull Request нажал, проверь, что получилось.
Думаю не обязательно выводить в отдельный файл, если всё всунуть в старые файлы то этой проблем не должно быть
Если бы можно было всунуть в старые, я бы так не пыхтел над этими. Знаешь, почему штатная процедура создания/редактирования параметров так ужасно выглядит? От лени мозилловцев.
У Firefox есть стандартные функции alert() (показывает сообщение), prompt() (показывает сообщение, под которым нужно что-то вписать в строку ввода) и select() (показывает сообщение, под которым нужно что-то выбрать из предлагаемого списка).
Вот с использованием этих функций они всё редактирование и сделали.
Трогать (менять) окошки, показываемые этими функциями, нельзя - они же в уйме мест используются. Остаётся только собственное создавать.
Зато я его сделал без единого своего слова - задействовал исключительно те названия и фразы, которые у Mypal уже имеются.
Я прописал их в jar.mn. Всё замечательно кроме одного, редактирование boolean, что там редактировать? По моему это лишнее действие, верни перключалку.
Давным-давно возвращено. Вот commit соответствующий:https://github.com/Feodor2/Mypal68/pull/655/commits/b529ecf8f466ecd5c4908c37ebe0b008a992d7e7
И в pull request этот commit стоит вторым по списку.
Вот страничка расширения: http://yup.lh1.in/AddOns/NewPrefEditor/index.ru.html Там все достоинства расписаны.
а если многострочтное то до в оригинале предлагают править километр текста через щелку по моиму
в оригинале предлагают править километр текста через щелку по моиму
Во-во. Именно это и побудило. А идея позволить вставлять из буфера "имя;значение" пришла в голову уже потом, в процессе работы.
а на тему хотелок бесит автосортировка встиле вин15 когда ты сортируешь по status чтоб найти отличное от дефолтного потом меняешь чтото на дефолтное (например случайно) и тут час этот пункт улетает хрен знает куда на 10000 пунктов вниз и больше его никогда не найти если утя не фотографическая память...
и нехватает возможностей коментировать настройки типо там где что то поменял указывать для чего эт на тему может там что то такое есть из коробки? типо как вы там упоминали в закладках что поле с комантарием есть но не отображаетсо после очередного обновления со времен ФФ22...
бесит автосортировка встиле вин15
Это не "встиле вин15". Оно всегда так было, с самого первого Firefox.
и больше его никогда не найти если утя не фотографическая память...
Ну, допустим, что-то в потрохах браузера изменили, и строчки перестали улетать. Всё равно ведь для того, чтобы вернуть параметру (если он не логический) его прежнее значение, фотографическая память понадобится.
Undo - вот чего здесь не хватает. А это и реализовать намного проще, чем отмену автосортировки.
и нехватает возможностей коментировать настройки типо там где что то поменял указывать для чего эт на тему может там что то такое есть из коробки?
Нет, конечно. И никогда не было. Были одно или два расширения - справочники по параметрам about:config, но то давно было - во времена до FF 57. А начиная с FF 57 у Firefox остались только WebExtensions, которым такая функциональность в принципе недоступна.
В принципе, если задаться целью и как следует перекорёжить нынешний механизм отображения about:config, то комментарии к параметрам прикрутить можно. Но можно поступить проще и сразу: изменённые (да и не изменённые) параметры записывать в файл user.js, а в нём комментариев можно писать сколько угодно. Заодно и защита от случайного сброса значения 😄
Undo - вот чего здесь не хватает. А это и реализовать намного проще, чем отмену автосортировки.
ну или так
В принципе, если задаться целью
ну оно то не особо часто и надо
а вот щас зайти и чтото похерить без возможности исправить или отменить это очень легко
Ну, допустим, что-то в потрохах браузера изменили, и строчки перестали улетать. Всё равно ведь для того, чтобы вернуть параметру (если он не логический) его прежнее значение, фотографическая память понадобится
вангую что эти потроха это закоментить одну строчку которая вызывает переосортировку при любом изменении
а так ты открой посортируй по status или по value и даблкликни по чем то, что меняетсо от даблклика и все занудства утя отпадут тем более даблкликается по всей площади прямоугольника и даблкликатсо вполне может случайно особенно когда бразуер буксует
И в pull request этот commit стоит вторым по списку.
А остальные что?
Я буду в коде добавлять всё одним махом. Я вот это не люблю отдельно коамит на исправление каждой строки.
А остальные что?
Самый первый - изначально сделанный вполне рабочий вариант.
Потом я обнаружил то самое безобразие с пропавшей переключалкой значения булевских переменных и быстренько восстановил её (я просто не ожидал, что пункт меню с названием "Toggle" для такой простой задачи будет вызывать аж целую функцию ModifyPref() вместо того, чтобы всё сделать самостоятельно).
Заодно сделал результат, который ModifyPref() возвращает вызывающему коду в разных экзотических ситуациях, более точно воспроизводящим результат оригинальной функции ModifyPref().
(Вроде бы этот результат никому не нужен, кроме моей же функции NewPref(), а для неё эти экзотические ситуации значения не имеют, но на всякий случай...)
А потом решил, что двум моим новым файлам стоит дать более подходящее имя - и все остальные коммиты связаны именно с этим.
Я вот это не люблю отдельно коамит на исправление каждой строки.
Я тоже не люблю. Но я же правлю через браузер, а при этом на каждый отредактированный или даже просто переименованный файл новый коммит создаётся.
Функцию Undo сделать?
У странички about:config есть хитрый JS-объект - её собственный кеш всех параметров браузера. Этот кеш порождает некоторые неприятные нюансы в процессе работы с пользовательскими параметрами. Зато Undo реализовать на нём можно довольно легко - аж само просится.
Я уже добавил одним разом, вроде всё отлично.
Функцию Undo сделать
Так если неприятные нюансы в процессе работы.
Так если неприятные нюансы в процессе работы.
Эти неприятности имеются в оригинальном коде. Их функциональную часть я в своих функциях поборол, и теперь всё хорошо. Осталась визуальная часть, а это уже сущие мелочи - никто даже не поймёт, что тут что-то не так. (Можно было и визуальную часть побороть, но не стал в целях совместимости 😄 .)
Кстати, раньше когда на GitHub-е переписывался и собеседник отправлял новое сообщение, то оно у меня сразу отображалось (и когда он редактировал уже отправленное сообщение, оно и у меня на экране изменялось).
А сейчас чтобы увидеть любые изменения, нужно руками страничку обновлять.
Это на GitHub-е что-то изменилось, или причина в новых версиях Mypal?
Не понимаю, чётко скажи есть проблема или нету, если есть тогда не надо.
За сам github не скажу не обращал внимание
Берёшь браузер без моих правок. Создаёшь новый параметр числового или логического типа. После того, как этот параметр сохранён с каким-то значением, сбрасываешь его ("Reset"). Теперь у тебя на экране у этого параметра тип изменился на string, а значения никакого нет (точнее, там "" - пустая строка). И в кеше странички ровно то же самое. Но если запросить у браузера полный список его параметров, то там этого твоего сброшенного параметра нет вообще.
То есть, имеем рассогласование используемого страничкой кеша и его первоисточника.
А теперь опять попытайся создать параметр числового или логического типа с тем же именем, что и в прошлый раз. В окошке, где нужно вводить имя параметра, в заголовке будет написан правильный тип - тот, что ты запросил. Но в следующем окошке, где нужно вводить значение, в заголовке будет написано "string", и сохранённый по итогу параметр будет строковым.
Вот это и есть та проблема, о которой я говорил. Чтобы создать повторно параметр нужного типа, требуется или обновить страничку about:config, или повторно открыть её (что, в общем-то, одно и то же). При этом перечитывании кеш создастся заново, и в нём уже не будет остатков параметра от прошлой попытки.
А в моём варианте кода на экране после сброса всё остаётся как и было до меня - тип "string" и пустая строка в качестве значения - но при повторном создании параметра он сохранится именно с запрошенным тобой типом.
Я мог бы внести изменения ещё и в функцию сброса, чтобы она удаляла параметр из кеша и с экрана, но не стал, ибо его наличие там теперь уже ни на что не влияет.
А к возможности реализации Undo это всё какого-то особого отношения не имеет, потому что в любом случае объект с кешем параметров у странички имеется, и задействовать его для своих нужд можно.
В связи с реализацией Undo есть два вопроса. (Ответы на них предполагаются бинарные - "да" или "нет".)
- Традиционно под Undo понимается откат внесённых изменений, который выполняется в порядке, обратном порядку внесения этих изменений. Но в одном из моих любимых редакторов Undo работает по-другому - там можно каждую изменённую строчку возвращать в предыдущее состояние индивидуально, независимо от того, когда именно её изменили. Именно такой вариант я изначально и намеревался реализовать. Но тут @NS-Clone начал плакаться, что у него из-за выбранного режима сортировки изменённые параметры улетают далеко-далеко, и он их потом найти не может. А в такой ситуации помочь может только традиционный вариант Undo. Но я могу реализовать оба варианта сразу: Undo будет работать традиционно, по списку изменений, а, скажем, Restore будет откатывать изменения конкретного параметра.
Вопрос: если пользователь вызвал для какого-то параметра операцию Restore, вносить это действие в список для отката по Undo или нет?
- Страничка
about:config"живая" - если её открыли во вкладке, а в другой вкладке открыли настройки браузера и там что-то изменили, или сам браузер что-то в параметрах изменил по личной инициативе, то новые значения немедленно показываются во вкладке сabout:config.
Вопрос: такие "внешние" изменения в список Undo вносить или нет?
Традиционно под Undo понимается откат
традиционно для настроек есть ОК и ПРИМЕНИТЬ инет никакого ундо почему в каком то ведре сделали мгновенное применение не есно и почему все и вся начали этому уг подражать хотя в ФФ мы уже к этому привыкли
(Ответы на них предполагаются бинарные - "да" или "нет".)
ололо тогда раз у настам ожидают ГРАБЛИ может сделать/назвать это типо "откат настроек" и подписать на какое время оно будет откатывать
и тода не забыть притулить потверждение этому действию
хотя откат подразумевает более долговреенное это если бы каждый запуск настройки бекапились вот тогда можно было бы так обозвать а с таким автобекапом вылезут все те же глюко кривые проблемы что и с востановлением сессии щас
Страничка about:config "живая" - если её открыли во вкладке, а в другой вкладке открыли настройки браузера и там что-то изменили, или сам браузер что-то в параметрах изменил по личной инициативе, то новые значения немедленно показываются во вкладке с about:config.
ну окошка настроек ужо давно нет так что ССЗБ хотя это может быть и для клацнуть и посмотреть что изменитсо в about:config (но я так никогда не делол например) и тогда...
тобешь я сторонник идеи что текущие изменения из about:config более приоритетные но это большая палка с двумя концами особенно если плагины захотят срать в настройки в это время
с другой стороны если пользователь жмет отмену ОН ОЖИДАЕТ что отменитсо то что он щас натыкал ИМЕННО ТУТ а не отменить все изменения сделанные плагинами и настройками скорей всего более логично отменять изменения только about:config-а
Вопрос: такие "внешние" изменения в список Undo вносить или нет?
видимо не вносить но вот если изменения сделали извне после возможно нужно из undo этот пункт убирать? если такая возможность конечно есть
с другой стороны если пользователь жмет отмену ОН ОЖИДАЕТ что отменитсо то что он щас натыкал ИМЕННО ТУТ а не отменить все изменения сделанные плагинами и настройками
Вот те вопрос на засыпку: Числовой параметр имел значение 1; какой-то внешний код изменил его на 2; потом пользователь изменил его на 3; а ещё более потом этот же пользователь нажал Undo. Какое значение должно оказаться у параметра в итоге - 1 или 2?
но вот если изменения сделали извне возможно нужно из undo этот пункт убирать? если такая возможность конечно есть
Если внешние изменения в список для отката не вносить, то и убирать ничего не понадобится. Мой вопрос именно так и был сформулирован: вносить в список или нет?
Вот те вопрос на засыпку:
день назад ты предлагал брутить 10К файлов перебирая номерок имени
седня ты впадаешь в другую крайность по типу "а что если юзыр припаял проц мгтф-ом и у него отвалилсо проводок?" которую нельзя корректно обработать
Вот те вопрос на засыпку: Числовой параметр имел значение 1; какой-то внешний код изменил его на 2; потом пользователь изменил его на 3; а ещё более потом этот же пользователь нажал Undo. Какое значение должно оказаться у параметра в итоге - 1 или 2?
ЮЗЫР видел 1 и поменял его на 3
отменив он ожидает увидеть 1 опять а не погоду на сатурне
но ВОТ для надежностей лучшо чтоб было то чего поставил адон уже после ИБО он мог продублировать тоже значение в своих переменных и сохранить их дето в другом месте в итоге ты пападешь на то что плагин откажется менять настройку ссылаясь на то что она и так уже в таком состоянии
А я не просто так спрашиваю. Мне действительно удобнее игнорировать внешние изменения и включать в список только то, что пользователь изменил сам во вкладке about:config. Но озвученный нюанс лучше обсудить заранее, чтобы потом не предъявляли претензии и не требовали переделать логику.
А я не просто так спрашиваю.
ну на любую хотелку вылазит много подфодных камней обышно
но вот одни делают
а другие находят 10К причин чтоб за 20 лет не сделать вложенные коменты /* /* */*/ :)
Но озвученный нюанс
с третей стороны в about:config не так часто надо может просто нужно иногда делать его бекапы на автомате?
хотя вот даже я например не знаю/не помню где он в файлах а чего говорить про простого юысра тем более с профилем хрен знает где
или прикрутить базовую менюшку с возможностью загрузить один из предыдущих бекапов
ЮЗЫР видел 1 и поменял его на 3
отменив он ожидает увидеть 1 опять а не погоду на сатурне
Ты невнимательно читал то, что я написал в вопросах. Перечитай ещё раз с места "Страничка about:config живая".
Когда пользователь открыл about:config у него было 1. Но когда что-то внешнее изменило эту настройку на 2, то и на страничке about:config стало написано 2. То есть, пользователь видел новое состояние.
Или не видел, если это изменение произошло, когда у него было открыто окошко редактирования этого параметра и закрывало собой кусок странички.
Проблема элементарно решается выдачей при сохранении сообщения: "Ой, за время редактирования значение изменилось", но я старательно пытаюсь избежать добавления в Mypal своих сообщений, а готового такого там нет.
Что же до установленных расширений и их параметров, то для них хорошим тоном считается отслеживать внешние изменения и учитывать их. Во всяком случае, во всех моих расширениях это сделано: если открыты настройки расширения, и параллельно что-то изменить в них через about:config, то это изменение немедленно отобразится в диалоге настроек.
И во время работы расширения всё это тоже отслеживается и учитывается.
стало написано 2. То есть, пользователь видел новое состояние
в абоутконфиг 15К строчек с афтопересортировкой юыср ниче не видел