Этот цикл посвящен теме создания апплетов для панели GNOME. Если
кратко, апплет - это маленькое приложение, которое встраивается в
панель и либо информирует о чем-либо (например, погоде, или о
состоянии батареи), либо выполняет какие-либо одноэтапные действия
(запускает поиск, изменяет громкость и т.д.).
Я буду создавать простой апплет для включения/выключения прокси в
GNOME.
Прежде чем начать, стоит упомянуть один документ, который описывает
создание апплета средствами Python и PyGTK: это GNOME applets with
Python. Однако, на мой взгляд, у него есть ряд недостатков, которые и
побудили меня осветить эту тему по-своему.
Итак, приступим.
В первой части я буду создавать скелет апплета и регистрировать его в
GNOME, во второй буду писать функциональную часть, а в третьей -
заниматься "полировкой" и украшательствами.
Скелет апплета
Перво-наперво, выделю то, что необходимо для функционирования любого
апплета, вне зависимости от его природы:
* некий виджет-контейнер (например, HBox)
* некий "полезный" виджет (у меня это будет Label)
* всплывающая подсказка
* некое действие по левой кнопки мыши
* контекстное меню
* возможность запуска как отдельного приложения (для отладки)
* регистрация в GNOME как апплета к панели
Прежде чем приступить к пояснениям, скажу о конвенции насчет имен
методов. Если имя метод начинается с двух подчеркиваний, то
перегружать (переопределять) такой метод нежелательно. Если же имя
метода начинается с буквы, то такой метод можно практически
безболезненно перегружать. Но все же, если Вы будете писать свой
апплет, то все же гляньте код соответствующего метода
GnomeAppletSkeleton прежде чем перегружать его.
Итак, первым делом инициализирую ключевые виджеты, без которых не
обойдется ни один апплет:
Поскольку апплет - безоконный виджет (у него нет окна), то для того,
чтобы была возможность реагировать на события, я помещаю EventBox в
него. А уж все дополнительные виджеты (в моем случае это будет только
Label) добавляются к ev_box.
Заметьте, что в XML-описании пункта меню "О программе" нет собственно
названия пункта, а лишь его StockID. Это сделано по той простой
причине, что пункт меню "О программе" стандартен для большинства
приложений и в случае указания StockID Вы получаете:
* стандартную иконку для данного пункта (причем, с изменением темы
оформления GNOME эта иконка может меняться)
* стандартное название пункта меню, причем автоматически
переведенное на нужный язык
Каждый пункт меню имеет "глагол"-действие, который ставится ему в
соответствие. self.ppmenu_verbs же задает соответствие между
"глаголом"-действием и callback-функцией.
Следующий шаг по созданию апплета - "соединение" callback-функций и
событий:
Еще раз отмечу, что апплет - безоконный виджет, поэтому все события
генерирует ev_box. В данном случае, я соединил события "нажатие на
кнопку" с callback-функцией self.on_button и событие "попадание
курсора в область виджета" с callback-функцией self.on_enter. Здесь же
при помощи словаря self.button_actions задал соответствие между
кнопками мыши и функциями-действиями. Стоит заметить, что
callback-функции, соединенные с событиями должны быть определенной
сигнатуры (об этом чуть позже), а функции-действия не должны принимать
ни один параметр.
Следующий по порядку вызов - это метод after_init. В скелете он
пустой, предназначен специально для переопределения в потомках.
С этапами создания апплета вроде завершил, остались
callback-функции... Я не буду пересказывать PyGTK reference, лишь
перечислю типы callback-функций и их сигнатуры, которые встречаются у
меня:
* callback-функция на события ev_box. Сигнатура function(widget,
event). Реализации - on_enter, on_button
* callback-функция на пункт меню. Сигнатура function(event,
data=None). Реализация - on_ppm_about
* функция-действие (мое название) на нажатие одной из кнопок мыши.
Сигнатура function(). Реализация - _show_ppmenu.
Содержимое callback-функции _cleanup не буду приводить - оно слишком
тривиально (удаляется объект self.applet) для того, чтобы занимать
место, а кому интересно - гляньте в полном исходном тексте апплета.
Что касается остальных callback-функций, я их приведу и
прокомментирую, поскольку они все же представляют интерес.
def on_button(self, widget, event):
"""Action on pressing button in applet"""
if event.type == gtk.gdk.BUTTON_PRESS:
self.button_actions[event.button]()
Callback-функция on_button вызывается при нажатии любой кнопки мыши
внутри виджета. И внутри этой функции я во-первых убеждаюсь, что
присоединили к правильному событию (нажатию на клавишу), а во-вторых
вызываю нужную функцию-действие, выбирая (в event.button хранится
номер кнопки, нажатие на которую и вызвало появление данного события)
из ранее описанного словаря self.button_actions. Для кнопок 1 и 2 у
меня пустые действия, для 3 - контекстное меню. Показ контекстного
меню - специальный метод класса Applet - setup_menu. Первый аргумент -
XML-описание меню, второй - "глаголы"-действия, третий -
пользовательские данные (передаются третьим параметром в
callback-функцию).
Что касается события "попадание курсора в область виджета", то на него
я реагировать буду так: показывать какую-нибудь простенькую подсказку,
ради разнообразия сделав ее динамической.
def on_enter(self, widget, event):
"""Action on entering"""
info = "Hey, it just skeletonnAnd on_enter event time is %d" %
event.time
self.tooltips.set_tip(self.ev_box, info)
И последняя callback-функция - на вызов пункта меню "О программе".
Здесь я воспользуюсь стандартным диалогом из модуля gnome.ui:
def on_ppm_about(self, event, data=None):
"""Action on choosing 'about' in popup menu"""
gnome.ui.About("GNOME Applet Skeleton", "0.1", "GNU General Public Licensev.2",
"Simple skeleton for Python powered GNOME applet",
["Pythy <the.pythy@gmail.com.>",]
).show()
Класс-костяк апплета написан, теперь нужно описать его "фабрику":
def main(args):
if len(args) == 2 and args[1] == "run-in-window":
run_in_window()
else:
run_in_panel()
if __name__ == '__main__':
main(sys.argv)
Небольшой комментарий по коду: если файл запускается как скрипт, то
выполняется функция main, в ней, в зависимости от того, передан ли
аргумент run-in-window, апплет запускается либо в окне (функция
run_in_window), либо в панели (run_in_panel). Про функцию run_in_panel
чуть ниже, а в run_in_window стоит обратить внимание на строчку
app.reparent(main_window). Этим собственно и достигается, что апплет
запускается в отдельном окне.
Как выглядит костяк апплета можно увидеть на скриншотах:
AppletSkeleton in windowed mode, with tooltips
AppletSkeleton in windowed mode, with popup menu
AppletSkeleton in windowed mode, with 'about' dialog
Регистрация апплета в панели GNOME
Если выше был обычный Python-код, с некоторой PyGTK-спецификой, то
сейчас будет сплошная магия ;) Это, кстати, одна из слабых сторон
GNOME-Python - отсутствие систематической документации (для
gnomeapplet вообще никакой документации нет, за исключением пары
примеров и вышеупомянутой "методички"). К примеру, в при регистрации
апплета вызывается функция applet_bonobo_factory, однако нигде не
упоминается, какие параметры в нее передаются. Чтобы узнать это, нужно
лезть в исходные тексты. Я, конечно, понимаю, что "Use code, Luke!",
но все же качество документации по PyGTK в целом хромает (например,
сплошь и рядом в документации рекомендуются методы, которые уже пару
версий назад как уже объявлены устаревшими).
Общая идеология регистрации апплета такова:
* описываем мета-информацию в специальном .server файле
это и есть вызов "специального интерфейса". Параметры такие: IID
(уникальный идентификатор сервиса в GNOME), тип (это остатки C-природы
GTK, тип GObject), имя, версия, callback-функция.
Теперь что касается "описания мета-информации". Пишем следующий XML
(он для всех апплетов будет идентичным, специфичные для моего апплета
данные я выделил полужирным):
Так, что тут: два раздела, фабрика и сам апплет. Для каждого
определены IID, у фабрики IID должен совпадать с тем, что указали в
вызове bonobo_factory в апплете. Дополнительно отмечу, что тут же
можно задавать переводы названия/описания апплета (в данном случае
будет на русском, если у Вас русская локаль и на английском во всех
остальных случаях). Называем этот файл GNOME_AppletSkeleton.server и
"скармливаем" его Bonobo Activation Server. Существует несколько
вариантов этого "действа":
1. Поместить .server в каталог /usr/lib/bonobo/servers
2. Изменить /etc/bonobo-activation/bonobo-activation-config.xml (там
есть несколько примеров), добавить нужный путь (скажем,
/usr/local/lib/bonobo/servers) и положить .server туда
3. В переменную BONOBO_ACTIVATION_PATH добавить каталог, где лежит
.server.
Мне наиболее правильным показался второй вариант, я его и использовал.
После этого скрещиваем пальцы и пытаемся добавить апплет на панель.
Если .server правильно "скормили", то апплет-скелет появляется в
списке кандидатов на добавление. Если и все остальное сделали верно,
то добавление пройдет гладко. И Вы получите примерно такой результат:
AppletSkeleton in paneled mode, add to toolbar dialog
AppletSkeleton in paneled mode, with tooltips
AppletSkeleton in paneled mode, with popup menu
Стоит отметить, что контекстное меню в "режиме окна" и в "режиме
панели" отличаются - для панели
Часть вторая
Продолжу рассказ о создании апплета к панели GNOME. В прошлый раз я
написал "костяк" апплета, который ничего не делает. Сегодня на его
основе напишу апплет, который уже чем-то будет полезен.
GConf
Напомню, что конечная цель - создание апплета для переключения прокси
(вкл/выкл). Для этих целей есть диалог "Параметры прокси-серверов"
(Система->Параметры->Сервис Прокси), но им не удобно пользоваться,
поскольку нужно совершать много лишних действий.
Сам диалог настройки ничего не делает, он лишь изменяет значение
соответствующего параметра в GConf (/system/proxy/mode), а
программы, использующие прокси, следят за значением этого параметра.
Поэтому, для того чтобы включить или выключить прокси, апплету
достаточно изменить нужное значение в GConf.
У GConf есть как положительные, так и отрицательные стороны. Из
положительных хочу отметить такие приятные вещи как:
* информирование всех "подписанных" на параметр программ об
изменении его значения (внешне это выглядит так: открываете диалог
"Параметры прокси-серверов", меняете при помощи Python значение
нужного параметра и переключатель в диалоге сам "прыгает" на
нужную позицию)
* глобальность изменения: не нужно думать о том, что нужно еще
проставить значение переменной http_proxy для wget - GConf делает
это автоматически. Ну а то, что все GNOME-программы берут
настройки о использовании/не использовании прокси из GConf, я
думаю, понятно без объяснений.
Из отрицательных я выделяю:
* gconfd "гадит" в журналы. Мне не нравится, что gconfd пишет в
общесистемный журнал (/var/log/messages) на русском языке.
* несогласованность настроек различных программ. Например, Gajim
и Firefox используют собственные настройки соединений. И если
для Gajim можно найти оправдание (поддержка нескольких аккаунтов),
то для Firefox я не вижу причин игнорировать GConf. Хотя для Gajim
адекватен был бы выбор между "использовать глобальные настройки
Gnome" и "использовать отдельные настройки для соединений".
* невозможность (или просто я не знаю о таком) изменить настройки
только для отдельных приложений
Прежде чем писать код, советую "поиграться" в интерактивной сессии (в
качестве индикатора о смене настроек можно использовать диалог
"Параметры прокси-сервера", либо редактор `gconf-editor`, но на мой
взгляд, диалог прокси более показателен)
Что происходит, если попытаться получить значение несуществующего
ключа, или извлечь значение не того типа, предлагаю изучить
самостоятельно, вооружившись gconf-editor и Python.
Что касается возможных значений ключа `/system/proxy/mode', то
допустимые значения здесь таковы: none, manual, auto. Если значение не
входит в список разрешенных, оно интерпретируется как none.
Последняя оговорка и можно приступать к написанию кода: для того,
чтобы GConf сообщал об изменении того или иного ключа, нужно
"подгрузить" одну из веток GConf для "прослушки" и добавить
callback-функцию на изменение нужного ключа.
В коде изложено всё вышесказанное:
class ProxyGconfClient(object):
"""Get/set proxy states"""
proxy_dir = "/system/proxy"
def __init__(self, callback=None):
"""
GConf client for getting/setting proxy states
@param callback: callback function. Executing
when proxy state changed. It calls with params:
* client - GConf client
* cnxn_id - connection ID
* entry - changed entry
* params - additional params
@type callback: callable
"""
if callback is None:
callback = lambda client, cnxn_id, entry, params: None
# make connection to GConfD
self.client = gconf.client_get_default()
# add proxy_dir for inspection, without preload
self.client.add_dir(self.proxy_dir,
gconf.CLIENT_PRELOAD_NONE)
# add callback for notifying about changes
self.client.notify_add(self.proxy_key,
callback)
def get_state(self):
"""Returns state of proxy"""
return self.client.get_string(self.proxy_key)
def set_state(self, value):
"""
Set state of proxy
@param value: state of proxy, may be
* 'none' - direct connection, proxy off
* 'manual' - manual settings, proxy on
* 'auto' - auto settings, proxy on
if value neither 'manual', no 'auto', it means
direct connection, i.e. proxy off.
@raise RuntimeError: cannot set value to GConf's key
"""
if not self.client.set_string(self.proxy_key,
value):
raise RuntimeError("Unable to change key %s" %
self.proxy_key)
def on(self):
"""Turn proxy on (i.e. set proxy mode 'manual')"""
self.set_state(self.on_state)
def switch_proxy(self):
if self.proxy.is_on():
self.proxy.off()
else:
self.proxy.on()
Поясняю написанное:
Во-первых, напоминаю, что after_init специально создавался в скелете
для переопределения в потомках, так что это правильное место для
добавления прокси-переключателя (атрибут proxy), определения действия
на левую кнопку мыши (button_actions) и установки начального текста
для label.
Во-вторых, в качестве callback-функции, которая выполняется при смене
состояния ключа GConf, я использую _cb_proxy_change (сигнатура этой
функции такова: GConf-клиент, идентификатор соединения, измененный
ключ, дополнительные параметры). По идее, идеологически более
правильно здесь использовать конструкцию
entry.get_value().get_string(), но мне не нравится такой стиль записи,
он не Pythonic. Поэтому я использую информацию от объекта
прокси-переключателя.
Далее, переопределенная callback-функция on_enter, теперь она
показывает состояние прокси, а не просто "Привет мир".
Ну и последний метод - switch_proxy - выполняется по нажатию левой
кнопки, переключает состояние прокси.
Действия по регистрации этого, уже работающего, апплета абсолютно
аналогичны таковым для скелета, так что я не описываю их. Рабочий код
можете взять отсюда.
Фактически, апплет уже функционирует, однако выглядит он не
притязательно. В следующей части буду "шлифовать" внешний вид.
Заключительная часть
Заканчиваем с апплетом к GNOME. В первых двух частях работали
над структурой апплета и его наполнением, сегодня завершающий этап:
"отшлифовка" внешнего вида и подготовка к многоязычному окружению.
Внешний вид
Общая структура апплета аналогична таковой во второй части:
наследуемся от ProxyGnomeApplet:
class ProxySwitcherGnomeApplet(ProxyGnomeApplet)
И переопределяем нужные методы. Во-первых, роль главного виджета
играет gtk.Image, а не gtk.Label как в "модельном" апплете.
gtk.Image это некий "контейнер" изображения. Его можно "заполнить"
данными из различных источников, мы будем использовать пиксельный
буфер (pixbuf). Само изображение (как пиксельный буфер) будем брать из
значка "Прокси" текущей темы. Если в текущей теме не будет такой
иконки - будем использовать тему Tango.
def _init_pixbufs(self):
"""Init pixbufs from current theme, or from Tango, if 'proxy' icon not in current theme"""
self.pixbufs = {}
self.theme = self._get_theme()
try:
self._reload_pixbufs()
except gobject.GError:
self.theme = self._get_theme('Tango')
self._reload_pixbufs()
Мы будем использовать словарь pixbufs для хранения пиксельных буферов
для включенного и выключенного состояния прокси. В первой строке мы
инициализируем этот словарь. Во второй - получаем текущую тему. Потом
пробуем подгрузить значок "Прокси" из текущей темы
(self._reload_pixbufs()), если такого значка нет (исключение
gobject.GError), то используем тему Tango и уже с нее загружаем
значок.
Название текущей темы берем из GConf, ключ
/desktop/gnome/interface/icon_theme:
def _get_theme(self, name=None):
"""Return a theme by name, or current one if name is None"""
if name is None:
name = gconf.client_get_default().get_string('/desktop/gnome/interface/icon_theme')
theme = gtk.IconTheme()
theme.set_custom_theme(name)
return theme
В методе _reload_pixbufs мы решаем сразу несколько задач:
* подгружаем значок для включенного прокси (как пиксельный буфер) из
текущей темы
* на основе полученного изображения формируем пиксельный буфер для
выключенного прокси
def _reload_pixbufs(self, size=None):
"""Reload pixbufs from current theme for specified size, or for panel'ssize if size is None"""
if size is None:
size = self.applet.get_size()
pixbuf = self.theme.load_icon('proxy', size, gtk.ICON_LOOKUP_FORCE_SVG)
faded_pixbuf = gtk.gdk.Pixbuf(pixbuf.get_colorspace(),
pixbuf.get_has_alpha(),
pixbuf.get_bits_per_sample(),
pixbuf.get_width(),
pixbuf.get_height())
pixbuf.saturate_and_pixelate(faded_pixbuf, 1, True)
self.pixbufs[True] = pixbuf
self.pixbufs[False] = faded_pixbuf
И вот в этом коде четко проявляется, что PyGTK - лишь "прослойка"
между Python и C-библиотекой GTK: для того чтобы получить
"затемненный" пиксельный буфер (faded_pixbuf) нужно воспользоваться
методом saturate_and_pixelate объекта gtk.gdk.Pixbuf, причем метод
ничего не возвращает, а "затемненный" пиксельный буфер должен быть
передан первым параметром. Что еще более не типично для Python - он
обязательно должен быть типа gtk.gdk.Pixbuf. Т.е. нельзя, скажем,
инициализировав новый пиксельный буфер значением None, передать его
методу saturate_and_pixelate - будет ошибка несовпадения типов. Еще
один момент - объект gtk.gdk.Pixbuf не получиться скопировать при
помощи copy.deepcopy() - опять таки по причине C-природы GTK. Поэтому
приходится абсолютно неестественно для Python создавать новый
пиксельный буфер, передавая конструктору gtk.gdk.Pixbuf параметры
исходного пиксельного буфера. И уже этот, новый пиксельный буфер,
"отдавать" saturate_and_pixelate.
Все остальное в этом методе достаточно просто: в самом начале, если не
передан параметр size, то берем размер панели, на которую помещается
данный апплет (self.applet.get_size()); а в самом конце сохраняем
полученные пиксельные буферы в словарь pixbufs.
Теперь нужно переопределить методы after_init где инициализируется
начальное состояние апплета и callback-функции _cb_proxy_change на
переключение прокси и on_enter на попадание курсора мыши внутрь
апплета. Ну и неплохо было бы изменить диалог "О программе",
переопределив on_ppm_about.
Метод after_init повторяет таковой у класса ProxyGnomeApplet за
небольшими изменениями: дополнительно в атрибут proxy_is_on записываем
данные, включен ли прокси; визуальное состояние апплета
устанавливается методом set_visual_state.
def set_visual_state(self, state, is_on):
"""Set overall visual state for corresponding proxy's state"""
msg_on_state = u"Proxy is on"
msg_off_state = u"Proxy is off"
mode = u"mode: %s" % state
variant = (is_on and msg_on_state) or msg_off_state
self.info = u"%s (%s)" % (variant, mode)
self._set_image(is_on)
def _set_image(self, kind):
"""Set image for specified state"""
self.image.set_from_pixbuf(self.pixbufs[kind])
Здесь код незамысловат: в начале формируются строки всплывающей
подсказки, в зависимости от значения параметра is_on выбирается текст
"Proxy is on" или "Proxy is off". Дополнительно, в скобках
отображается режим (параметр state). Последняя строка - установка
соответствующего значка (метод _set_image). Ну а в методе _set_image -
заполнение контейнера gtk.Image данными из пиксельного буфера. Какой
пиксельный буфер (из двух, что хранятся в self.pixbufs) использовать
определяет переданный параметр kind.
Следующая пара методов, который нужно переопределить, это
_cb_proxy_change и on_enter - callback-функции на переключение прокси
и на попадание указателя мыши в апплет. Тут очень просто и понятно:
def _cb_proxy_change(self, client, cnxn_id, entry, params):
"""Callback for changing proxy, change visual state of applet"""
self.proxy_state = self.proxy.get_state()
self.proxy_is_on = self.proxy.is_on()
self.set_visual_state(self.proxy_state, self.proxy_is_on)
def on_enter(self, widget, event):
"""Callback for 'on-enter' event, show tooltip"""
self.tooltips.set_tip(self.ev_box, self.info)
И последний метод, это показ диалога "О программе". Здесь мы
используем стандартный виджет gnome.ui.About. Параметры конструктора у
него такие: имя приложения, версия, лицензия, краткое описание, список
авторов, список авторов документации, переводчики, логотип. Версия,
лицензия и автор у нас указаны в начале файла, в "магических"
переменных __version__, __license__ и __author__. В качестве логотипа
используем все тот же значок "Прокси" из текущей темы, только бОльшего
размера (80 пикселов). Все остальное понятно из кода:
def on_ppm_about(self, event, data=None):
"""Callback for pop-up menu item 'About', show About dialog"""
pixbuf_logo = self.theme.load_icon('proxy', 80, gtk.ICON_LOOKUP_FORCE_SVG)
msg_applet_name = u"Proxy switcher"
msg_applet_description = u"Applet for turning proxy on/off"
gnome.ui.About(msg_applet_name, __version__, __license__,
msg_applet_description,
[__author__,], # programming
None, # documentation
None, # translating
pixbuf_logo,
).show()
С внешним видом вроде бы все.
Здесь я намеренно опустил некоторые вещи, чтобы не перегружать код
непринципиальными моментами:
* Реакция апплета на изменение ориентации панели - сигнал
change-orient
* Реакция апплета на изменение размера панели - сигнал change-size
* Реакция апплета на изменение фона панели - сигнал
change-background
Примеры callback-функций на эти сигналы (а они идентичны у
большинства апплетов) можно найти при помощи Google Codesearch:
например, для change-orient.
Многоязычное окружение
Для "апплета на коленке" допустимо, чтобы он работал только на языке
создателя. Если же есть желание показать апплет хотя бы одному другу,
то резонно задуматься о работе в многоязычном окружении. Стандартный
инструмент для таких вещей - GNU gettext. В Python есть его
поддержка. Во время разработки программы особо ничего не меняется,
лишь у каждой строки, которую нужно перевести, появляется "обертка"
_().
В нашем случае, нужно переводить: всплывающие подсказки (в методе
set_visual_state) и название программы, ее описание (в методе
on_ppm_about). Делаем:
Первым параметром в gettext.install идет название домена переводов -
обычно совпадает с именем программы.
Отмечу один момент: в случае использования подстановок в строки стоит
избегать конструкций _(u"some string %s with subst" % value) по той
причине, что при извлечении строк для перевода, будет извлечена строка
u"some string %s with subst", а во время работы программы будет
искаться перевод для строки с уже подставленным значением value,
поэтому лучше вынести операцию подстановки значения "за скобки", т.е.
_(u"some string %s with subs") % value.
Теперь нужно извлечь строки, которые нужно перевести. И здесь есть
некоторая неопределенность. В том смысле, что нет только одного
способа выполнить эту операцию. Можно использовать "канонические"
инструменты GNU gettext, можно использовать инструменты Python. Я
приведу пример использования Python-инструментов - не только в силу
специфики блога, но и по причине лучшей переносимости. Итак, делаем:
pythy@axcel:~/blog/gnome-applet/gnomeapplet_03$ pygettext -v -o po/proxyswitcher.pot proxyswitcher.py
Working on proxyswitcher.py
pot-файл - это шаблон, так что копируем его в файл перевода po:
Теперь редактируем параметры перевода (в файле перевода есть "рыба") и
собственно сам перевод. Далее, "компилируем" в mo-файл. В качестве
"компилятора" msgfmt.py (для Debian и Ubuntu он доступен в пакете
python2.4-doc):
"Инструментальный" этап завершен. Теперь появляется резонный вопрос:
как использовать данный перевод? И здесь опять неоднозначность: Python
по умолчанию ищет переводы в /usr/share/locale, однако есть
возможность указать другое место, где искать переводы - передать имя
каталога вторым параметром в gettext.install:
в данном примере переводы ищутся в той же директории, где и
располагается программа. Однако стоит предостеречь о том, что в данном
каталоге нужно положить файл перевода не просто так, а по соглашению
<targetdir>/<lang>/LC_MESSAGES/<domain>.mo, где <targetdir> - каталог,
где ищутся переводы (текущий каталог), <lang> - двухбуквенный код
языка (ru), <domain> - домен перевода (proxyswitcher). И вот по вот
этому соглашению, кладем файл proxyswitcher.mo в каталог
ru/LC_MESSAGES/proxyswitcher.mo. Еще один момент, на который стоит
обратить внимание - все строки unicode, и в gettext.install тоже
указываем опцию unicode, иначе строка будет подставлена "как есть",
без перекодировки (т.е. если я создавал файл перевода в коировке
UTF-8, а пользователь запустит программу в KOI8-R окружении, то
подставлены будут переведенные строки в UTF-8).
Результат
Пробуем собрать всё воедино и посмотреть, что получилось. Если я нигде
не ошибся и вы нигде не опечатались, то результат должен быть таков:
Dialog 'add to panel'
Applet inside panel, tooltip, proxy is on
Applet inside panel, tooltip, proxy is off
'About' dialog
Что дальше
Дальше встает вопрос о распространении апплета. Напомню, какие файлы
нужны для работы апплета:
* GNOME_ProxySwitcher.server - описание нашего апплета для Bonobo,
должен лежать либо в /usr/lib/bonobo/servers, либо в одном из
каталогов, упомянутых в
/etc/bonobo-activation/bonobo-activation-config.xml (по умолчанию
всё закомментировано).
* applet_skeleton.py, applet_example.py, proxyswitcher.py -
собственно код апплета, исполняемый файл (proxyswitcher.py) должен
лежать в месте, указанном в GNOME_ProxySwitcher.server; остальные
- в PYTHONPATH (наиболее простой вариант - в том же месте, что и
proxyswitcher.py)
* файлы переводов proxyswitcher.mo в каталоге /usr/share/locale,
либо указанном в proxyswitcher.py
Если апплет пакетировать в deb/rpm, то проблем не возникает -
Bonobo-файл и файл переводов кладутся в нужные места, а код апплета,
скажем, в /usr/lib/gnome-applets/proxyswitcher. Если не пакетировать,
то ситуация такая: пользовательское ПО по стандарту FHS должно
помещаться либо в /opt, либо в /usr/local. В /opt обычно ставят ПО
сторонних вендоров, так что правильное место для нашего апплета - это
/usr/local. Так что нужно: написать шаблоны Bonobo-файла и
proxyswitcher.py и в зависимости от переданного значения ключа
--prefix при установке заполнять шаблоны необходимыми данными.
Еще один момент, который требует доработки - это обработка ошибок.
Дело в том, что если при старте апплета возникает какая-либо ошибка,
то GNOME об этом ничего не скажет, а молча не запустит апплет. Так что
было бы здорово, если при возникновении исключительной ситуации,
апплет сообщал о ней.
Думаю, что решению этих вопросов будет посвящена еще одна статья. Код,
описанный в статье, как всегда, можно получить на code.google.com
Vova
