Спасибо!
А разве «Хабракодер» из хабраштучек не имел такой возможности? Сейчас он просто не обновляется, а старый firefox из-за этого ставить не хотелось :)
Спасибо, сам полез искать плагины для Хабра
в духе ХАБРАТУЛЗ все (по дефолту) устареышие.
PS если есть у кого желание обновите пожалуйста, я могу кому помочь с модуля под друпал…
да действительно удобно, теперь не так лениво будет форматировать собственные коменты, бо в большеносые случаем люди забивали на этом (только избранные пытались выделится)
при нажатии на определенную кнопку в форме с обеих сторон текста появлялись соответствующие теги
(честно говоря я не помню смотрел ли я пред просмотр)
ну а после самой публикации получилось так (http://habrahabr.ru/blogs/firefox/60668/#comment_1657656)
Да, не заметил галочку.
Собственно посмотреть я его хотел дабы убедиться в верности своих предположений, что никакой это не плагин а обыкновенный userJS, обернутый не понятно за чем в плагин. Помимо очевидных минусов не кросплатформенности, такой подход создает еще и излишнюю нагрузка, ведь скрипт выполняется для каждой загружаемой странцы и сам проверяет домен. При использовании UserJS проверка домена выполняется до выполнения скрипта.
Не понимаю, зачем мне писать тоже самое, когда нужно просто автору существующего указать на его ошибку. Или вы предлагаете каждому, кто хочет исправить глюк в опенсорс проектах делать свой собственный форк?
«Помимо очевидных минусов не кросплатформенности»
интересно каких? Тестил на iceweasel 3.0.6, firefox 3.0.10 Mac, firefox 3.0.10 Win, firefox 3.5b4 Debian.
«При использовании UserJS проверка домена выполняется до выполнения скрипта.»
вероятно, но проверка домена не занимает особо времени и ресурсов, а остальной код не выполняется, пока домен не совпадет.
Повторюсь, что это мой первый опыт написания чего-либо под firefox (помимо opensearc'ей), и может я где-то не совсем рационально сделал. В любом случае — спасибо за критику! :)
> интересно каких? Я тестировал в фаерфоксе, в фаерфоксе и в фаерфоксе.
Я здесь вижу только один браузер :) А вообще UserJS поддерживает опера и теоретически нет никаких препятствий поддерживать его любым браузером. Для этого не нужны никакие платформо-зависимые компоненты, вроде XUL.
> вероятно, но проверка домена не занимает особо времени и ресурсов
Уверен, точно также думают все разработчики остальных сорока плагинов, установленных у среднестатистического пользователя ФФ :)
А мне кажется, что немного усилий и будет лучше перенести в «I ♥ Habrahabr». Как я уже сказал выше, не вижу ни одной причины делать скрипт не кросплатформенным плагином.
Это как бы не плагин для движка хабрахабра, а плагин для браузера, который добавляет кнопки к элементу.
Но Вы всегда можете сами вытащить нужный код из скрипта плагина (ведь это обычный Javascript) :)
Для ВП полно разных плагов для вставки хтмл-кнопок (к сожалению, визуальных редактров типа TinyMCE меньше, чем в 50кБ не видел — максимум, что можно сделать, использовать gzip-версию). Штуки с использованием JQuery можно отметать сразу (из-за размера опять), а два-три хороших со вставкой тегов — есть.
Вот, как раз хотел спросить, не будет ли рациональнее написать такое в виде скрипта. Я не очень разбираюсь, но это ведь лучше для производительности, чем отдельный плагин (учитывая, что GM уже стоит)? Или я не прав? Там ведь всего пара кнопок.
GreaseMonkey также, в любом случае, является расширением, так что в производительности разницы особой нет между расширением, написанным с нуля, и связкой GreaseMonkey + Userscript.
Чем больше расширений, тем меньше заметно падение производительности при добавлении еще одного. Тем более не все так критично с производительностью и даже конфигурации с 50+ расширениями прекрасно работают без тормозов.
Давайте попробуем посмотреть на то, что происходит внутри браузера.
Каждое расширение должно зарегистрировать объект, который будет прослушивать запросы браузера. При появлении нового запроса (и последующей загрузке данных с удалённой страницы), расширению будет многократно передан объект документа, ассоциированный с данным запросом. После этого можно обратиться к свойству документа, отвечающему за хранение текущего URI. Это свойство обычно заполняется сразу после того, как браузер начал свою работу по выполнению запроса, потому что URI удалённой страницы заранее известен. После того, как получен URI, можно проводить его проверку на соответствие нужному. Обычно это производится с помощью регулярного выражения.
Из этого можно сделать вывод, что основной урон производительности наносит не сама проверка адресов, а регистрация большого количества прослушивающих объектов, каждому из которых нужно будет передавать инициализированный объект документа (иногда даже не один раз, а несколько: на каждом этапе загрузки удалённой страницы необходимо обновлять соответствующий ей документ [такая загрузка есть инкрементальная загрузка]). В случае же с GreaseMonkey регистрируется один такой слушатель (в лучшем случае, если у нас только он и установлен), и он реализует проверку соответствия URI текущего загружаемого документа и зарегистрированных.
GreaseMonkey выгоднее для производительности, но если установлены другие расширения, то эта выгода сходит на нет.
>Каждое расширение должно зарегистрировать объект, который будет прослушивать запросы браузера.
…
В случае же с GreaseMonkey регистрируется один такой слушатель…
Спасибо, Вы прекрасно озвучили мою же мысль %)
Я как раз о том и говорю, что лепить расширение там, где достаточно скрипта — неразумно. Одно такое расширение, второе, третье, пятое, десятое… и в результате у нас вместо одного слушателя (GM) — десять. А если стоит ещё десяток других расширений, то вместо десяти — двадцать.
А уж рассуждения вроде «плюс-минус одно, когда их и так много» (не Ваше, а выше) — это вообще из разряда «нафига я буду оптимизировать свою программу, если на фоне тормознутости ОСи её тормоза никто не заметит». Кому как — а мне, как программисту, такой подход просто отвратителен.
Полностью согласен с тем, что описано выше. Но пользовательским скриптом можно пользоваться пока нет тесной взаимосвязи с браузером (да, в моем случае можно было обойтись только им). А чтобы добавить хранение настроек в конфиге, локализацию, вызов локальных картинок из плагина и пр., то тогда без упаковки это в плагин не обойтись. Верно я понимаю?
Все эти FCKEditor — незаменимы, когда надо давать чтото редактировать неподготовленному юзеру(«секретарша»), но пока достаточно тяжелы для сайтов. Мы у себя FCK юзаем только в админке.
а также напоминалка разным «программистам» в комментариях, что код надо выделять в пре — чтобы его не сжирал хабраДжувикс (он, кстати, ведет себя необычно — в pre, как и code экранируются угловые скобочки, так что надо ставить один пре, если нужен много строчник). Да и те же ссылки проще ставить кнопками.
Вместе с установкой этого аддона появляется возможность вывести куда-нибудь кнопку (через настройки вида), позволяющую показать/скрыть этот тулбар. Либо можно делать это через менюшку тулзов. Так что постоянно он мешаться не будет.
Правда, обнаружил там багу кнопки смены цвета, но ее можно временно (пока не пофиксят) заменить самописной, которая делается проще простого.
Расширение для Firefox :: Хабра-редактор комментариев