Тема закрыта
PreferencesCleaner при установке расширения парсит его файлы из defaults\prefs, и записывает имена настроек в свою базу - соответственно, при удалении расширения смотрит в базу, и по найденному там сбрасывает оставшиеся настройки. А с настройками, созданными на рантайме, поделать ничего нельзя - их нужно привязывать к расширению рукам, т.к. в defaults\prefs их нет.
Что такое "настройки, созданные в рантайме"?
Это примерно как заставить всех разработчиков именовать переменные в яваскрипт-коде строго в соответствии с венгерской нотацией.
глупости какие-то пишешь. Я говорю про разграничение встроенных префов от префов созданных дополнениями, часто не понятно кто создал какой преф, а так и проблемы бы такой не возникло.
mzfx
Отсутствует
Что такое "настройки, созданные в рантайме"?
Настройки, созданные не от того, что прописано в defaults\prefs, а динамически прямо в яваскрипт-коде. Такие настройки не имеют значения по умолчанию, и исчезают при сбросе настройки на дефолтное значение.
глупости какие-то пишешь.
Спасибо.
Я говорю про разграничение встроенных префов от префов созданных дополнениями, часто не понятно кто создал какой преф, а так и проблемы бы такой не возникло.
Разграничение по формальному критерию никогда не будет работать, и никого ни к чему не обяжет, т.к. его невыполнение не чревато ничем - настройку можно обозвать хоть Ya Vasya Pupkin - система это вполне позволяет, и это никак не скажется на её работоспособности.
Отсутствует
а динамически прямо в яваскрипт-коде
я правильно понял, что они имеют динамические имена?
или ты имел в виду, что они просто прописаны где то в толще скрипта? тогда их можно, наверное, найти по какой-нибудь js функции типа "создать преф".
Спасибо.
не обижайся, я просто не люблю когда люди строят якобы аналогию к позиции оппонента, доказывают абсурдность этой якобы аналогии и потом считают, что тем самым доказали и абсурдность позиции оппонента по предмету спора.
Разграничение по формальному критерию никогда не будет работать, и никого ни к чему не обяжет, т.к. его невыполнение не чревато ничем
Почему это? если ограничить права дополнениям, что они просто не смогут создавать префы не по нотации - это бы решило проблему. Назови причины почему этого делать не стоит.
mzfx
Отсутствует
если ограничить права дополнениям
Это очень-очень большое "если". Я в свое время достаточно глубоко закопался в эту проблему (в результате чего, собственно, и был сделан этот Preferences Cleaner). Основная проблема как раз в том и заключается, что вообще и никак, в т.ч. программно, нельзя определить автора настройки, вплоть до разделения, была эта настройка от FF, или от дополнения (настройки которых, кстати, обычно именуют как extensions.[chrome_package_name].[preference_name] - но у самого расширения даже в свойствах объекта, представляющего расширение, нет этого chrome_package_name).
И если с настройками, объявленными в defaults\prefs, еще что-то можно было придумать, то с создаваемыми динамически - в общем случае ничего.
можно, наверное, найти по какой-нибудь js функции типа "создать преф"
Ага. Например:
setMyPref: function(prefName, prefVal) { Services.prefs.setCharPref(prefName, prefVal); }
Стек вызова этого метода может быть очень длинным, и отследить каким-нибудь тестом, что же приходит в переменной (правильное имя настройки, или неправильное) - нереально.
доказывают абсурдность этой якобы аналогии и потом считают
Мне, наверное, надо было просто выбрать аналогию поближе. Вот, например, на этом форуме не рекомендуется писать по-русски безграмотно - вполне понятный и полезный пункт правил. Однако речи о том, чтобы заставить всех неукоснительно соблюдать правила языка, и сразу банить за нарушения грамматики, не идет. Потому что это не даст никакого положительного результата. Вот так и с этими именами настроек.
Отредактировано hydrolizer (21-03-2012 19:52:11)
Отсутствует
Я в свое время достаточно глубоко закопался в эту проблему (в результате чего, собственно, и был сделан этот Preferences Cleaner).
Т.е. ты автор этого дополнения?
Однако речи о том, чтобы заставить всех неукоснительно соблюдать правила языка, и сразу банить за нарушения грамматики, не идет.
Так в том то всё и дело, что в отличие от форума - на АМО каждая версия каждого дополнения сначала проходит рецензию, прежде чем её допускают к публикации. А на форуме проводить предмодерацию каждого сообщения каждого пользователя - просто рехнёшься.
Более того, всё равно ведь преф создаётся в лисе какой-то функцией - так можно просто её так исправить, чтобы любой создаваемый ей преф создавался уже в виде extensions.имя_дополнения.имя_префа и я не вижу в этом ничего плохого, а результат будет в прозрачности работы каждого дополнения.
mzfx
Отсутствует
iDev.Pi
Более того, всё равно ведь преф создаётся в лисе какой-то функцией - так можно просто её так исправить, чтобы любой создаваемый ей преф создавался уже в виде extensions.имя_дополнения.имя_префа и я не вижу в этом ничего плохого, а результат будет в прозрачности работы каждого дополнения.
А что делать с теми кучами настроек, которые уже насоздавали расширения до сегодняшнего дня? Ликвидировать вместе с самими расширениями?
Иначе говоря — как решать проблему обратной совместимости? По-доцлеровски, методом вивисекции?
Отсутствует
Иначе говоря — как решать проблему обратной совместимости? По-доцлеровски, методом вивисекции?
а проблемы, в общем-то и не будет: будет как с переходом от статус-бара к аддон-бару: сначала будут новые версии дополнений выходить, которые добавят новые префы (можно даже им значения выставить из существующих старых префов). Старые дополнения - будут использовать старые префы, но рано или поздно к ним же выйдут обновления - а значит и они мигрируют на новые префы. Ну будет кучка дополнений, которая за год не выпустит обновления - такие дополнения чаще всего уже давно не разрабатываются и потенциально уже мертвы, просто пока ещё работают.
а через 2 года вообще взять и насильно удалить все префы старого формата и всё.
Если 2 года у дополнения не было обновлений - ему самое место в анналах истории.
Отредактировано iDev.Pi (22-03-2012 00:53:58)
mzfx
Отсутствует
Т.е. ты автор этого дополнения?
Да.
на АМО каждая версия каждого дополнения сначала проходит рецензию
Эммм... да, проходит. Только вот степень тщательности рецензирования здесь бывает очень разной. Например, на моей памяти пару раз аппрувили просто неработающие версии расширения.
Более того, всё равно ведь преф создаётся в лисе какой-то функцией - так можно просто её так исправить, чтобы любой создаваемый ей преф создавался уже в виде extensions.имя_дополнения.имя_префа
Я же выше писал, что 1) невозможно определить автора вызова функции, с точки зрения вызовов в chrome-контексте все эти вызовы анонимны; 2) и у дополнения даже нет этого параметра "имя_дополнения" (т.е. имя пакета дополнения).
Решать все эти проблемы в совокупности исключительно ради читабельности имен настроек никто не будет - система настроек работает, некорректно заданные имена сбоев не вызывают, и поэтому корявые имена - ну, просто как признак небрежности в оформлении, не более того.
Отсутствует
Да.
Оок, спасибо за дополнение, оно полезное.
У меня есть несколько вопросов по нему, здесь это уже оффтопик, может создашь новую тему "Preferences Cleaner" в разделе "Обсуждение расширений"?
2) и у дополнения даже нет этого параметра "имя_дополнения" (т.е. имя пакета дополнения).
ну, я имел в виду GUID/UID...
1) невозможно определить автора вызова функции, с точки зрения вызовов в chrome-контексте все эти вызовы анонимны;
интересно, почему они сделали все вызовы анонимными..?
mzfx
Отсутствует
может создашь новую тему "Preferences Cleaner" в разделе "Обсуждение расширений"?
Отсутствует
.gozer пишет: Правда я бы на АМО в правила рецензирования ввёл бы изменения: чтоб дополнения создавали свои настройки только в таком виде: "extensions.UID_этого_дополнения.имя_настройки".
Это примерно как заставить всех разработчиков именовать переменные в яваскрипт-коде строго в соответствии с венгерской нотацией.
Хм... на это есть Exception fault
Note. Прошу прощения за тормоз ответа и долю юморного... оффтопа
PreferencesCleaner при установке расширения парсит его файлы из defaults\prefs, и записывает имена настроек в свою базу - соответственно, при удалении расширения смотрит в базу, и по найденному там сбрасывает оставшиеся настройки. А с настройками, созданными на рантайме, поделать ничего нельзя - их нужно привязывать к расширению рукам, т.к. в defaults\prefs их нет.
Должно быть оттого что нет протокола взаимодействия приложений и оболочки. Был бы изначально продуманный протокол, была бы возможность "чистого" удаления приложений... ИМХО.
P.S. помнится, еще в 90х по аналогичной ситуёвине в Винде были нехилые дебаты... увы если тот "гигант" не смог (не захотел?) унифицировать это и в своей собственной епрархии, то что сказать об этом частном случае. А жаль.
С "богами"-разрабами общаются на английском языке. Но не факт, что они тебя услышат... как и всякие боги... (с) // Голая Лиса не лучше Ишака. Вся сила в шубке! ;) //
Отсутствует
Lexx77
ПКМ по параметру → Сбросить. И перезапустить .
Или вручную открыть prefs.js.
Отредактировано littleleshy (05-11-2013 17:24:54)
Отсутствует
Тема закрыта