rodocop
Advanced Member | Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Цитата:| А как можно при старте КМ запустить какой-нибудь макрос ? |
здесь два вопроса в одном, которые стоит пояснить:
1) макросом в КМ именуется не столько kmm-файл, сколько отдельная "функция" внутри макроса, структурная единица макроязыка:
Цитата:
Код: aboutaddons{
macroinfo=_("Addons Manager");
$OpenURL="about:addons";&OpenURL_InNew;
} |
|
вот это я привел макрос по имени aboutaddons
2) при старте макрофайлы (kmm) подгружаются все (т.е. с ними может работать КМ в ходе данной сессии).
А автоматическое выполнение того или иного МАКРОСА (т.е. отдельной функции) прописывается при помощи событий:
Код: Events
The Macro Extension Plugin provides a variety of events.
Event Is triggered
OnActivateWindow When a window gets the focus.
OnCloseGroup When a multi-layered window is closed.
OnCloseTab When a tab is closed.
OnCloseWindow When a window/layer is closed.
OnInit When the Default Configuration Files have been parsed.
OnLoad When a document finished loading.
OnOpenTab When a tab is opened.
OnOpenWindow When a window/layer is opened.
OnQuit When the macro plugin (the browser) is being closed.
OnSetup When the User Configuration Files have been parsed.
OnStartup When the first window is opened.
OnWMAppExit When ID_APP_EXIT is called to terminate the application. |
В main.kmm отпределены соответствующие переменные вида $OnEvent, c помощью которых в остальных макрорасширениях и прописываются МАКРОСЫ, запускаемые в тот или иной момент.
Так, во всех kmm, которые создают какие-либо пункты меню, есть подобная строка:
Код:| $OnInit=$OnInit."_aboutpages_BuildMenu;"; |
Она означает, что по событию Init (инициация браузера) выполняется обозначенный макрос, интегрирующий кастомный пункт в нужное место в меню.
(Если заглянуть в menus.cfg и разобраться в его синтаксисе, то обнаружится, что там прописаны далеко не все имеющиеся в итоге менюшки - недостающую часть как раз и формируют макросы)
**продолжение**
таким образом, при сохранении подобной структуры макрофайла у вас автоматом будет выполняться та функция, которая прописана на одно из событий запуска.
Идут они в таком порядке:
OnInit - этап инициализации, на котором подгружаются все настройки по умолчанию
OnSetup - следующий этап, где подгружаются установки пользователя (перекрывают дефолтные, если есть разночтения)
OnStartup - в момент создания первого окна
OnOpenTab - в момент открытия первой вкладки
OnLoad - по окончании загрузки документа
3 первых события одноразовые на сессию, остальные 2 происходят каждый раз с открытием вкладки или загрузкой в нее нового документа.
Цитата:| И да, возможно здесь не место для таких вопросов, где лучше о подобном вопрошать ? |
еще как место!
Цитата:| При переключении скинов кнопки едут. |
угу, едут.
Проблема в том, что в КМ изначально открытая архитектура, в которой единственная забота разработчика - не сломать сделанное до него. Для чего служат определенные конвенции написания макросов (ссылку дам, когда сайт вернется на место).
А вот для написания тулбаров конвенций нет. Поэтому каждый автор скинов волен формировать тулбары по-своему (до определенной степени).
Иными словами, я могу создать произвольное число тулбаров и раскидать кнопки по ним произвольным образом.
Когда вы меняете скин одного автора на скин другого, может случиться коллизия такого рода, что тулбары имеют разные названия и, что еще хуже, одинаковые названия, но разный состав и порядок кнопок.
Вот тогда все и разваливается, ибо КМ помнит параметры настройки тулбаров kmeleon.toolband.ИмяПанели.ххххх, но они конфликтуют с настройками toolbars.cfg из скина.
Как решать проблему?
1) во-первых, можно попробовать использовать ТОЛЬКО унифицированные тулбары, благо они существуют - Русская команда еще в старые времена проделала эту неблагодарную работу (думаю, что это Quicksilver tears постарался) для той подборки скинов, что выложена на нашем сайте.
В них по возможности полно синхронизирован контент тулбаров и у них почти идентичные toolbars.cfg.
При смене одного такого скина на другой развал будет минимален, а для скинов с одинаковым размером кнопок - и вовсе будет отсутствовать.
Но надо понимать, что разница в размерах кнопок вносит некоторую сумятицу, ибо далеко не все панели "резиновые" (только URLbar, tabbar, закладки да фавориты - они занимают по умолчанию все доступное место в панели, а при необходимости ужимаются). И их резиновость небезгранична. Минимальный размер остальных панелей жестко определен прописанными к отображению кнопками.
2) Частично проблема решена в новом КМ: дело в том, что в папке скина иногда лежит файл skin.js - это собственно файл, хранящий настроенные автором параметры kmeleon.toolband.ИмяПанели.ххххх.
Просто в более ранних версиях была недоработка, и этот файл игнорировался.
Сейчас он читается и работает точно так же, как все js-файлы настроек из папки browser\defaults\preferences.
Это значит, что панели в худшем случае будут отображены, как это настроил автор, а не в полном беспорядке.
Проблемы здесь вот какие: во-первых, если в другом скине были иначе названные тулбары, то их настройки останутся в prefs.js и могут вызывать не то чтобы конфликты, но ненужное влияние на настройку.
Дело в том, что один из 4 параметров kmeleon.toolband.ххххххххххх для каждой панели - это kmeleon.toolband.ИмяПанели.break, отвечающий за то, начинает ли эта панель новую "строку" или прилепляется справа к предыдущей по порядковому номеру.
А порядковый номер задает kmeleon.toolband.ИмяПанели.index. Ну и "левые" панели от бывшего скина могут в эту нумерацию внести путаницу, понятное дело.
Во-вторых, мы пока не умеем сохранять пользовательские настройки скина обратно в skin.js кроме как вручную (скопировать по окончании работы из prefs.js в skin.js).
А заранее подогнать стандартную настройку скина для нужд всех пользователей нереально - мало того, что каждый юзер хочет иметь свои кнопки и панели видимыми, да еще в своем порядке - это как раз понятно и ожидаемо; но главное - автор настраивает панели для своего размера окна браузера, а у всех юзеров оно разное по ширине.
Ну и вот.
Но есть и хорошие новости. Наличие данного файла (подгружаемого поверх дефолтных настроек, как и user.js из профиля) позволяет привязать к конкретному скину те или иные настройки браузера в целом.
Ну самый очевидный пример - это когда хромоподобный скин, сделанный Дорианом (ссылку позже дам) автоматом выключает виндовый заголовок окна КМ (ну тот, где кнопки "свернуть", "развернуть" и "закрыть"). Чтобы было "как в Хроме" 
Менее очевидные примеры - любые, на какие хватит фантазии. Скажем, с одним скином браузер настроен на производительность и удобство, а с другим - на максимальную безопасность. Удобно и наглядно: посмотрел на шкуру - и сразу ясно, какие настройки стоят.
3) Последний способ - это расширение от JamesD, которое сохраняет всю совокупность toolband-настроек в файл, привязанный к своему скину.
И каждый раз, когда идет переключение на этот скин, настройки "впрыскиваются" обратно в КМ.
Написано это расширение для КМ 1.6, но и сейчас должно работать.
Проблема в том, что оно не всегда корректно отрабатывает и сохраняет порой не все нужные префки.
Ссылка - опять же позже. Хотя вроде бы в последнем Твине эта шняга встроена...
Добавлено:
Цитата:| Использовать сторонний софт вроде nnCron не хочется. Писать на AHK лишний экзешник тоже. Есть что-нибудь встроенное, или макрос с подобным функционалом, не подскажете ? |
Хотите совершенно сумасшедший скриншот?
На всякий случай - даю наводку: это K-Meleon 74+1 |
Всего записей: 1614 | Зарегистр. 21-12-2005 | Отправлено: 21:09 20-07-2015 | Исправлено: rodocop, 21:59 20-07-2015 |
|
