Микроблог про wxWidgets

Ну вот и мое имя внесено в анналы истории 🙂 Страна должна знать своих героев 🙂

Продолжая тему с потерей конфига. Кратко напомню суть проблемы – периодически при загрузки компа конфиг файлы программы – “плохие”. Либа выдает ошибку конвертации в юникод и данных нет. Как показали эксперименты, файл есть, примерно нужного размера но заполнен нулевыми символами (???). Причем конфига у меня два, первый открыт все время работы программы и закрывается при выходе\получении сообщения о выключении компа. Второй открывается локально при выходе\завершении и тут же закрывается. Проблема с обоими.

Я тут повозился полдня, подебажил сорцы, по перезагружался много раз – результаты такие.

Версия Сергея:

Теоретически, при любом сбое файл настроек должен ведь сохраниться. Я вижу пока только одну возможность – в момент flush когда он уже пометил старый файл пустым и не успел записать данные.

Неправильная, там внутрях используется wxTempFile, который обрабатывает это дело умно – пишет данные в временный файл, убивает оригинал, переименовывает временный в оригинал.

Eсли просто выключать комп все ок.

Если инициировать процесс выключения (в обработчике я пишу в конфиг и удаляю его), и сразу же нажать рессет. То в 60% случаев – проблема проявляется. Причем устойчивое появление проблемы мне удалось наблюдать только если программа стоит в автозагрузке, если же нет – то вроде все ок (это мне вообще мозг ломает…).

Сорцы смотрел, дебажил, эксперементировал. Почему такое может быть понять не могу – в мою картину мира не вписывается, то что трабла происходит только при ресете  – ну что может там такого происходить???  Судя по сорцам – все просто и правильно. А то что мне не удается это поймать когда запускаю руками программу, а не из автозагрузки – вообще путает все карты.

Уже не знаю что и думать. Наверное буду писать систему дублирования 🙁

Почему я стал программировать на wxWidgets

Пока я потихоньку, потихоньку пробую тройку (собрал для себя прогу на ней, добавил несколько багов в трекер, жду), народ активно знакомится, исследует и пишет офигенные обзоры новшеств wxWidgets 3. Почитал, узнал много нового, все больше и больше хочу перевести продакшен разработку на тройку:)

Недавно я жаловался на большой размер ехе в wxWidgets 3.0, все на что меня хватило это пожаловаться в блоге, спросить на форуме и уйти назад на 2.8. Но есть более цепкие люди, они нашли в чем было дело, теперь все стало легче, екзешник похудел на 2+ мегабайта. Но все равно прибавил 0.7 по сравнению с 2.8 веткой (2.8 вместо 2.1M).

Сейчас как раз сижу перевожу свой notes manager на trunk c 2.8.10. Что радует без проблем скомпилился databaselayer и с небольшими доработками сама программа, теперь вот отлавливаю и правлю различия в логике…

И как раз в этот момент приходит радостная новость wxWidgets 2.9 выпущена в виде официального релиза!

We are pleased to announce the first release in the 2.9 development series. wxWidgets 2.9.0 gives a flavour of what will be provided in the stable wxWidgets 3.0 version next year, and we are interested in your feedback. Enhancements in 2.9 include the removal of the distinction between ANSI and Unicode builds, and a reworked Mac OS X architecture, supporting both 32-bit Carbon and 32-bit/64-bit Cocoa variants (wxOSX/Cocoa at alpha stage). You can get wxWidgets 2.9.0 from the download page.

Или вот по-русски из другого источника

Вышел первый релиз новой экспериментальной ветки кроссплатформенного C++ тулкита для построения графических интерфейсов wxWidgets 2.9.0. В новой ветке:

1. Прекращено разделение ANSI и Unicode сборок;
2. Переработан код для поддержки платформы Mac OS X, который теперь поддерживает как 32-bit Carbon, так и 32-bit/64-bit Cocoa API;
3. Добавлены дополнительные свойства для grid-классов;
4. Улучшены средства для отображения данных, которые теперь поддерживают комбинированный вывод через списки и деревья;
5. Переработана документация.
6. Добавлена поддержка промежуточного сохранения состояния объектов (persistent objects).
7. Улучшены не связанные с построением GUI интерфейса возможности, такие как циклы обработки событий, таймеры и сокеты;
8. События теперь могут быть привязаны к любой операции, не обязательно, как раньше, к методу производного от wxEvtHandler класса;

Так что не за горами уже и сама wxWidgets 3.0.  2.9 это просто название для нестабильной ветви, радуемся товарищи.

Вот вам почитать для вдохновения  The Wonderful World of wxWidgets 3.0  лично мне сразу после этого хочется бросить и перейти на 3.0 🙂

А я пока пойду писать в trac чем я недоволен 🙂

Тут в комментариях к посту о wxWidgets 3.0 возник вопрос, о том как теперь писать строковые литералы. Вопрос интересные, изменения там существенные и я до сих пор до конца не понимаю, как все таки правильно, поэтому  решил сегодня немного поэкспериментировать с этим вопросом:

wxMessageBox(“тест test”);

Это работает, но это получается ANSI строка, можно использовать только символы текущей локали(ну и конечно первые 127). Добавив реально юникодный текст

wxMessageBox(“öffnen вікно привет Donnée rápido test”);

Получаем несколько warningов C4566 и кривой текст на экране.

В общем что бы работало надо писать одно из трех L””, _T(“”), wxT(“”) – это все сводится к L””. Если нужна локализация тогда так

wxMessageBox(_(L”öffnen вікно привет Donnée rápido test”));

Что не очень удобно, может введут новый макрос который будет делать сразу два дела… Или может он уже есть но я не знаю.

В итоге, если я правильно понимаю, картина такая – если у нас в литерале только английские буквы – пишем просто “text” или _(“text”), в противном случае L”text” или _(L”text”)(вместо L можно использовать любой из двух старых макросов _T()\wxT()). Весь старый код использующий wxT() будет отлично работать.

Вернее конечно еще не саму 3.0, а то, что ей скоро станет – текущее состояние сорцов из транка. Выкачал из репозитория, собрал библиотеку, собрал свою программу. Теперь у меня есть две новости – плохая и хорошая 🙂

Есть у меня программа которая не делает ничего супер специфического, но поддерживает достаточно много базовых, для любой нормальной программы, вещей. Вопреки ожиданиям, удалось достаточно быстро ее скопмилироват. Нашлось только одно место где у функции поменялись параметры и пришлось переделывать код и всего два места, в которых используются deprecated function. В общем ничего серьозного, за 20 минут скомпилил программу даже с выключенным режимом совместимости. Это радует.

Теперь то, что огорчает – размер ехешника вырос почти в два раза с 1.8М до 3.4 в релизе, и до 7M в дебаг версии. Minimal sampe из поставки wxWidgets компилируется в 4.5М кода в релизе (!). С такими делами уже и на QT можно переходить:(
Настройки для сборки wxWidgets я использую стандартные, с одним исключением – меню динамическую сборку на статическую – (/MD(d) -> /MT(d)). Статическую сборку я использую всегда для уменьшения проблем у пользователей.

Спросил на wxForum – все молчат. Но что-то такой располневший exe мне совсем не нравится…

Kirix, компания которая подарила на wxAUI, делает новый подарок – wxWebConnect Web Browser Control Library. wx обертку над  Mozilla Foundation’s Gecko engine (XULRunner). Встраиваемый веб-броузер контрол, взаимодействие с DOM, пост запросы. Вообщем теперь вполне можно написать броузер. Типа как файрфокс только побыстрее:)

Конечно я незнаю насколько библиотека полная, хорошая, безглючная – не пробывал, но Kirix, если я правильно понимаю использует ее в продакшене, так что все должно быть ок.

Незнаю, как у вас – а у меня уже руки чешутся.. это же сколько всего что хотелось можно теперь написать 🙂

P.S. интересно когда она  в wxPython’e появится?

По ошибке использовал русскую букву “c”  в идентификаторе события, VS 2008 проглотила без проблем, но gcc под маком не проведешь..:)

Тяжела и не казисть,

жизнь простого программиста(с)

Чего только не приходится делать на работе. Первое нехорошее предчувствие подленько кольнуло меня когда я узнал что придется активно работать с видео, в принципе ничего особенного просто показывать его, но уже тогда я догадывался что хорошего будет мало. Дальше я узнал что еще надо будет писать movie maker (хотя тут основную часть писал не я) и Webcam manager.

1. И понеслось сначало надо было написать грид видео плееров, один из которых настоящий, остальные  рисованные все это на wxScrolledWindow – cо скроллингом, переключением етс.
2. Потом оказалось что один и тот-же wxMediaCtrl необходимо шарить между несколькими окнами, поддерживать 3 режима Fit to window, One to One  и FullScreen – куча работы по написанию,  и главное внедрению всего этого в чужую запутанную архитектуру  и тестингу.
3. wxMediaCtrl использует АктивХ под винду, а у этого АтивХ есть свое собственное поведение которое зависит от бекенда (под винду два родных) и не доступно для регулирования с наружи, что разумеется не устраивало – пришлось грязным хаком подменять оконную процедуру плеера и вмешиватся в обработку событий.
4. Под маком все было еще веселее – там с wxMediaCtrl вообще печально. Во-первых он принципиально не может отрисовывать под другими контролами – то есть если видео играет на wxScrolledWindow и мы скроллим его – то видео отрисовывается поверх всего что есть в нашей программе. Во-вторых, Quike Time самостоятельно реагирует на нажатия мыши – останавливается, запускается не уведомляя об этом нас, в результате наши контролы управления получаются в рассогласованном состоянии. Короче под маком пришлось писать свой video backend.
5. А в планах еще портирование всего этого под линукс, написание movie maker’a под макос, кроссплатформенная работа с веб-камерами… и может быть даже это все буду делать я…

Эх пойти бы сейчас в пастухи…