Определение типа виджета из программы (на Pyhron-е)

[VAK_53]

Никак не найду, как определить тип/класс виджета из программы (на Pyhron-е).
Получаю набор объектов интерфейса из builder и надо отфильтровать и поменять наклейки (label) у кнопок.

Заранее спасибо за внимание.

[RingOV]

https://github.com/RingOV/gis-weather/blob/master/utils/localization.py#L37
Вот тут можно подсмотреть

[VAK_53]

Спасибо, добрый человек за оперативный ответ. Пример из ГИСа достаточно убедителен, чтобы использовать в своей работе, но на рабочем месте окажусь только в понедельник... Главное, чтобы работало.
Но остается какой-то осадок и сомнение в  строгости метода. Вот что мы должны принять во внимание согласно PyGTK 2.0 Tutorial by John Finlay:
18.4. Widget Name Methods
The following widget methods set and get the name of a widget:
widget.set_name(name)
name = widget.get_name()
name is the string that will be associated with the widget. This is useful for specifying styles to be used with specific
widgets within an application. The name of the widget can be used to narrow the application of the style as opposed
to using the widget’s class.
Последнее предложение Гугл перевел так (машинный перевод использую, чтобы придерживаться стандартной лексики):
 Название виджета может быть использовано, чтобы сузить применение стиля в отличие от использования класса виджета
Значит виджеты все-таки имеют классы, но почему они нам не доступны?
Повторюсь за Володей Высоцким:
"Ну,а завтра спросят дети,
Навещая нас с утра:
Папы, что сказали эти
Кандидаты в доктора?
Мы откроем нашим чадам
Правду - им не все равно:
Удивительное рядом,
Но оно запрешено."
Ну это конечно шутка...
Хочется дойти до истины, если она есть.

[Sly_tom_cat]

  а зачем так сложно  или я чего-то не понимаю

Если имена лейблам сразу задавать как _('бла-бла') и грузить объект gettext (gettext.translation(....., fallback=True).install() ) то оно само все будет меняться. Зачем мудрить с ручной заменой лейблов? \\

Если же лейблы нужно менять динамически, то можно их объявлять как переменные объекта и делать им .set_label('бла-бла'), но лучше .set_label(_('бла-бла')) если там текст который нужно локализовать.

[RingOV]

Вот что мы должны принять во внимание согласно PyGTK 2.0 Tutorial by John Finlay:

Важное уточнение - в gis-weather Gtk3

Sly_tom_cat,
Там даже не надо _() задавать. Они по умолчанию в Glade "переводимые". Проблема в том, что перевод осуществляется только при запуске программы. А если хочется перевод "на лету", то нужно мудрить с ручной заменой.

[Sly_tom_cat]

  а для чего перевод на лету то?

Как по мне так если приложение и должно работать в локали системы то на ходу оно меняться в принципе не должно. В системе локаль только в рамках сессии поменять можно. Программа это (в моем понимании) объект атомарный с точки зрения локали - т.е. если с одной запустился то с ней пусть и работает. Надо в другую локаль переключится - пере запусти просто приложение - в чем вопрос то?

[RingOV]

Sly_tom_cat,
освежил я память. Закомментировал функцию перевода glade формы. И увидел, что glade форма не переводится. Из-за этого был сделан весь этот велосипед с переводом, и только потом он был прикручен для "на лету".

Но автору темы, возможно, не для перевода это нужно.

[Sly_tom_cat]

RingOV, вот поэтому я стараюсь всегда детально описать ситуацию, когда "костыль к коду изолентой приматываю" Без таких комментариев потом хрен вспонишь - зачем тот костыль был прикручен и костыль ли это или нормальный кейс .