Давненько я не писал программерских статей на сайт. Написать эту статью меня подтолкнул перевод OutWiker на wxPython 4.2.0, когда оказалось, что в PyPi уже нет бинарных сборок под 32-разрядные Windows, а я пока не вижу причин отказываться от поддержки 32-битных операционок.

На самом деле сам процесс компиляции wxPython достаточно неплохо описан в документации, но есть некоторые моменты, связанные со сторонним софтом, который используется при сборке. И к тому же я попытался описать, что происходит на каждом шаге сборки, который нужно выполнить вручную, а также, что за библиотеки и софт требуется и зачем.

Ссылка на саму статью вот — Сборка библиотеки wxPython под Windows.

В промежутках между работой и сном постепенно доделываю OutWiker, очередную версию которого собираюсь в скором времени выложить. Одним из изменений в этой версии будет то, что теперь можно будет перетаскивать прикрепленные файлы из окна OutWiker’а в другие приложения. Но когда я только начинал добавлять эту возможность, то не думал, что потрачу на нее столько сил и нервов, и все из-за одной мерзопакостной ошибки в wxWidgets.

Началось все хорошо. Сидя под Windows, реализация возможности перетаскивать файлы в другие приложения заняла считанные строки:

def onBeginDrag(self, event):
	"""
	Начало перетаскивания файлов
	"""
	data = wx.FileDataObject()

	for fname in self.getSelectedFiles():
		# Добавляем вложенные файлы в список.
		data.AddFile (fname)

	dragSource = wx.DropSource (self)
	dragSource.SetData(data)

	result = dragSource.DoDragDrop ()

Читать далее ‘wxPython и Drag’n’Drop файлов в Linux’ »

На днях столкнулся со странным глюком, найденным в OutWiker‘е, на исправление которого вместе с поимкой виновника ушло два вечера.

Не буду долго описывать то, как я наткнулся на этот глюк, лучше перейдем сразу к его сути. А суть состоит в том, что для хранения и парсинга настроек страниц в программе используется стандартный класс ConfigParser (с некоторой тонкой оболочкой над ним, но в данном случае это не важно) — очень уж в нем удобно разбирать строки вида xxx = yyy. Так вот, неожиданно оказалось, что если yyy кончается на русскую букву «Р», то при преобразовании yyy в unicode бросается исключение о том, что кодек utf8 не может преобразовать строку, так как данные неожиданно закончились (‘utf8’ codec can’t decode byte 0xd0 in position __: unexpected end of data). Причем, в середине строки буква «Р» нормально преобразовывалась. Добавление пробела к концу строки, которая кончалась на «Р», ничего не дало, зато навело на мысль, что дело может быть в обрезании строки при выкидывания начальных и концевых пробелов, переводов строк и т.п. При этом все остальные русские буквы на конце обрабатывались без проблем.

Читать далее ‘История одного глюка или дело о букве «Р»’ »

Хоть мне и нравится библиотека wxPython для создания интерфейса питоновских программ, но есть в ней одна неприятная особенность. Дело в том, что часто поведение одного и того же кода в разных операционках у библотеки отличается. В таких случаях приходится плясать с бубном и что-то подправлять таким образом, чтобы, с одной стороны, поведение программы в одной ОС осталось таким каким же, как оно было задумано и как уже работает, а, с другой стороны, чтобы в других ОС работало точно так же.

Иногда эти шаманства связаны с махинациями сайзерами, а вот вчера я столкнулся с очень неприятным поведением класса wx.Image, от которого не ждал никакого подвоха.

Итак, предыстория. Сижу под Windows, делаю OutWiker (скоро выложу новую версию). Все крупные изменения уже сделаны, под Windows все нормально, пришло время проверить их под Linux. Запускаю VirtualBox с Ubuntu 10.04, запускаю там OutWiker и… все работает. Не веря своему счастью, запускаю юнит-тесты, надеясь, что, раз внешне все нормально, то запуск этих тестов станет простой формальностью.

Читать далее ‘wxPython. Windows vs. Linux’ »

Где-то года полтора назад (в конце 2008 года) я выкладывал обзор дизайнеров интерфейса для wxPython. На днях решил посмотреть что же изменилось за это время. Прошелся по упомянутым в обзоре сайтам и, честно говоря, удивился, что за это время из всех программ обновлялась только wxGlade. Беглый поиск по гуглу тоже не дал никаких новых IDE или дизайнеров.

Жаль, что такие полезные программы не развиваются. Правда, есть парочка платных софтин для построения интерфейса на wxPython/wxWidgets, которые обновлялись не так давно, но мы их считать не будем. 😛

Немного настораживает ситуация с обновлением самой библиотеки wxPython. Последняя версия (2.8.10.1) вышла 14 мая прошлого года, осенью прошлого года вышла версия 2.9 wxWidgets, на основе которой построена wxPython, но библиотека wxPython до сих пор не обновилась. Правда, покопавшись в рассылке wxPython обнаружилось, что версия 2.9 должна скоро выйти, вроде бы уже есть предварительные сборки.

Еще жаль, что wxPython не поддерживает Python 3.x, и когда начнется работа по портированию на него не понятно. Все в той же рассылке писали, что разработчики обсуждали, а не начать ли работу по портированию в этом году, чем все это закончилось я так и не понял, до этого писали, что портирование на Python 3.x имеет у разработчиков низкий приоритет.

Если честно, то очень расстраивает то, что такая замечательная библиотека как wxPython так медленно развивается. С точки зрения пользователя мне намного больше нравятся проги, написанный под wxPython, чем под pyGTK. Все-таки wxPython/wxWidgets для отображения интерфейса использует API той среды, где программа запускается. Поэтому, например, в винде все диалоги открытия/сохранения окон будут выглядеть привычно для пользователя, в отличие от того же pyGTK.