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

Недавно я жаловался на большой размер ехе в 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() будет отлично работать.

Столкнулся только что с багом – есть наследник от wxScrolledControl’a, контента мало – линеек прокрутки нет, то есть client size = virtual size. Крутим над ним колесиком мыши – прокручивая “вверх”, после этого GetViewStart() говорит нам что у нас позиция по вертикали минус сколько-то…, GetScrollPos() возвращает правильный ноль. Точно грешить на wxWidgets не могу – так как и приложение там сложное, у окна есть еще 1 или даже два базовых класса, которые возможно обрабатывают скролл мышкой (Скорее всего конечно нет, но совсем не удивлюсь если так:)), да и версия либы там весьма древняя. Но тем не менее следует иметь ввиду, что что возможно есть такая особенность, beware 🙂

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

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

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

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

Наткнулся на разное поведение wxListCtrl’a под виндой и маком. Надо при смене выделения в другом контроле устанавливать правильное выделение в wxListCtrl. Под виндой все просто

Под маком надо обязательно сбрасывать старое выделение и только потом ставить новое.

Если вас вдруг  угораздило работать с какой-нибудь старой библиотекой которая не хочет понимать пути в юникоде… то ключ к решению wxFileName::GetShortPath(), а все правильное решение такое:

wxString path = ….

wxFileName fn(path, _T(“name”), _T(“ext”));

fn.Normalize();

xz.Open((const char*)fn.GetShortPath().ToAscii());

wxString path = ….

wxFileName fn(path, _T(“name”), _T(“ext”));

fn.Normalize();

xz.Open((const char*)fn.GetShortPath().ToAscii());

Posted in Использование | Tags: код
Comments Off on Передача Unidode пути к файлу в ANSI библиотеку