Публикации с меткой «wxPython»

Здравствуй хабрхабр!

В данной статье я хотел бы рассказать, сформулировать свои мысли по поводу такой замечательной библиотеки как wxPython. Под катом вы найдете небольшую теорию, описание форм, разбор свойств форм, различных контролов и всё что касается wxPython.
Welcome to wxPython.

Доброго времени суток!

Введение

Когда-то я вам уже рассказывал о связке Ruby/Tk. Сегодня я собираюсь продолжить знакомство с «быстрыми интерфейсами». На этот раз я расскажу вам о wxPython, а писать мы будем на Python.
На самом деле, wxPython является лишь обёрткой для библиотеки wxWidgets, который в свою очередь представляет графический тулкит, который позволяет писать кроссплатформенные приложения.

Кратко об анимации в wxPython

Дяденька делает анимацию на wxPython

1. wx.animate.Animation - инкапсулирует параметры анимации, а также поддерживает загрузку анимации из файла. Поддерживает Gif и Ani форматы анимаций.
2. wx.animate.GifAnimationCtrl - Контрол для отрисовки проигрывания Gif-анимации в графическом интерфейсе приложения.

При написании программ на Python, используя при этом графический интерфейс иногда приходится запускать различные долгие обработки каких либо данных, при этом в большинстве случаев будет блокироваться интерфейс и пользователь увидит программу замороженной. Чтобы этого избежать необходимо нашу задачу запустить в параллельном потоке или процессе. В данной статье мы рассмотрим, как это сделать в wxPython с помощью модуля Threading.

Потокобезопасные методы wxPython

В wxPython существуют три метода для работы с потоками. Если ими не пользоваться, то при обновлении интерфейса программы Python могут подвиснуть. Чтобы этого избежать, необходимо использовать потокобезопасные методы: wx.PostEvent, wx.CallAfter и wx.CallLater. По словам Robin Dunn (создатель wxPython) wx.CallAfter использует wx.PostEvent для отправки события на объект приложения. Приложение будет иметь обработчик этого события и будет реагировать на него соответственно заложенному алгоритму. На сколько я понимаю wx.CallLater вызывает wx.CallAfter с заданным параметром времени, чтобы он знал сколько ему ждать перед отправкой события.

Robin Dunn также отметил, что Global Interpreter Lock (GIL) не допустит одновременного выполнения более одного потока, что может ограничить количество используемых ядер процессора. С другой стороны, он также сказал, что wxPython освобождается от GIL вызывая API функции библиотеки wx, поэтому другие потоки могут работать одновременно. Другими словами быстродействие может изменяться при использовании потоков на многоядерных машинах. Обсуждение этого вопроса может быть интересным и не понятным…
Прим. перев. — для более полного знакомства с GIL прошу сюда.

Наши три метода можно разделить на уровни абстракции, wx.CallLater находится на самом верху, далее идет wx.CallAfter, а wx.PostEvent находится на самом низком уровне. В следующих примерах вы увидите, как использовать wx.CallAfter и wx.PostEvent в программах WxPython.

Предисловие

Необходимые знания
Первое - конструктор wx.App

Второе - перенаправление потоков вывода

Третье - предупреждения
Собираем все вместе
То, что уже было сказано

import sys
import warnings
...
warnings.simplefilter('ignore')
...
sys.stdout = open(logs_dir.decode('cp1251') + '\\my_stdout.log'.decode('cp1251'), 'w')
sys.stderr = open(logs_dir.decode('cp1251') + '\\my_stderr.log'.decode('cp1251'), 'w')
...
app = MyApp(redirect=0)
...

Небольшие проблемы с правами

import os
home_dir = os.path.expanduser('~')

В эту папку уже любой пользователь сможет спокойно записывать все, что ему нужно.

Очень интересный эффект, а точнее ошибка, получилась у меня при отрисовке на форме (wx.Frame) с помощью wx.PaintDC. Вот код события wx.EVT_PAINT, который использовался сначала:

def on_paint(self, evt):
   self.dc = wx.PaintDC(self)
   self.dc.DrawBitmap(self.background, 0,0, True)

Как вы уже, наверное догадались данные манипуляции ведутся с целью отрисовки фона окна, а точнее само окно в форме картинки. Пример можно подсмотреть в wx.Demo -> Miscellaneous -> ShapedWindow. Так вот, такой код приводит к тому, что, если деактивировать окно (произойдет событие ex.EVT_ACTIVATE), и потом опять активировать (это же событие), то контролы внутри окна не отрисуются. Теперь посмотрим на код, который работает правильно:

def on_paint(self, evt):
   dc = wx.PaintDC(self)
   dc.DrawBitmap(self.background, 0,0, True)

Как видите, проблема решилась тем, что мы не делаем контекст атрибутом окна. Почему так? Хороший вопрос, и ответ на него пока не знаю, не углублялся, так как особо нет времени. Но если кто знает ответ на этот вопрос, милости прошу в комментарии.

Представим себе окно (wx.Frame), которое нужно разместить на екране согласно некторому алгоритму, например, отцентрировать. Что мы делаем?

class MyFrame(wx.Frame):
...
    def __init__(self):
        ...
        ds = wx.DisplaySize()
        self.SetPosition((ds[0] / 2 - self.Size[0] / 2, 
                          ds[1] / 2 - self.Size[1] / 2))
        ...

Предположим, что метод __init__ содержит еще массу программного кода дял инициализации окна. В таком случае, логично предположить, что вышеописанная операция должна быть описана после всех манипуляций с размерами окна.

Часто такие операции происходят неявно, и, следственно, окно позиционируется совершенно неправильно, и об этом следует всегда помнить. Примером такой неявной смены размеров окна может быть, скажем установка сайзера (wx.Sizer):

self.SetSizer(self.main_sizer)
self.Fit()

В этом случае окно "подтянет" свои размеры под сайзер и, соответственно, позиционирование пройдет неправильно.