(...)
Читать дальше: Обработка событий в wxWidgets. (559 words)

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Уже дискуссия (4)
Больше по теме: book

Breakpoint 2, BegUtils::GetImageFromZipResource (pathURL=…, fileName=…, type=wxBITMAP_TYPE_PNG) at /media/data/work/Flashnote/src/Utility/begutils.cpp:166
/media/data/work/Flashnote/src/Utility/begutils.cpp:166:4941:beg:0x82977e3
>>>>>>cb_gdb:
> info locals
warning: static field’s value depends on the current frame – bad debug info?
/build/buildd/gdb-7.2/gdb/findvar.c:427: internal-error: read_var_value: Assertion `frame’ failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Если определения строки нет, то заходил, но падал стоило провести курсором над параметром функции – строке. Вообщем дебажить было вообще невозможно.

Решение такое:

CodeBloks -> Settings -> Compiler and debugger settings -> Debugger settings -> И там в первый едит бокс добавляем строку source  /media/data/const/wxWidgets/misc/gdb/print.py

После чего падения прекращаются, и о чудо, отладчик начинает показывать значение wxString. Жизнь сразу становится много лучше:)

Еще почитать можно тут Pretty printing wxStuff in gdb и тут

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Все молчат
Больше по теме: gdb, Ubuntu

Пытался использовать средства gtk (или posix, или чье это там), типа

#include <stdio.h> // for File I/O
#include <signal.h> // for signals
#include <unistd.h> // for sleep()

void handler(int sig)
{
        /* Just print to stderr and redirect 2>> test.txt in the shell */
    fprintf(stderr, "got %d\n", signal);

    signal(sig, handler); // let signal be caught again
}

int main()
{
    signal(SIGTERM,handler);
    signal(SIGINT,handler);
    signal(SIGQUIT, handler); // Maybe we're getting QUIT first?
    signal(SIGHUP, handler); // If the terminal closes, we might get this
    signal(SIGPIPE, handler); // Don't know why we'd get this, but check anyway
    while(1) // loop forever with most signals trapped, impolitely waiting for a kill -9  

    // run
}

Не фига, когда руками прибиваю приложение Ctrl+c в терминале или kill … срабатывает, когда вырубаю систему нет, сообщения не получаю. В инете все пишут тоже самое не работает.  Code::Blocks тоже не сохраняет данные, если что-то изменить и сделать logout.  

Получается линукс, или убунта, или гном не дает возможность приложению узнать что сессия завершается и корретно завершить работу, сохранив данные. Вот вам и Linux with a human face

Есть правда какой-то EggSMClient в виде сорцов, LGPL, его например использует GEdit и молодец, корректно обрабатывает все. Но что-то про EggSMClient ни упоминаний толком, ни документации – особенно ничего не находится, а так разобратся без бутылки не получается. Печально все это

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Уже дискуссия (9)
Больше по теме: linux, грабли

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Уже дискуссия (2)
Больше по теме: +1

Про Qt:

1. На Qt писать быстрее и проще (субьективно и смотря что)

2. Написанное под виндо в течении 3 месяцев запускается на макоси после часа работы.

3. Приложения не родные

4. Приложения здоровые.

Про wxWidgets:

1. Писать вполне нормально, хотя может и не так гладко как на Qt

2. Результат выглядит роднее

3. Бинарников по паре сотен килобайт не получается, но и не десятки метров как у Qt.

4. Запуск под макосом – требует гораздо большего количества нервов, времени и напильников.

Для этой программы я после 10 дней на вх, выбрал Qt (совсем его тогда не зная), и не пожалел. Для своих Clipdiary и Flashnote я все таки считаю что wx не плох, хотя следует признать что первая программа уже продается под МакОС, а вторая и третья только в далекой перспективе:)

В общем – как всегда для конкретной задачи, нужен конкретный инструмент.

А еще, учитывая последний маневр Нокии, есть вероятность что развитие Qt тормознется, об этом стоит тоже думать….

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Уже дискуссия (20)
Больше по теме:

Шаг первый – правильные контейнеры.

Код использовал списки, при портировании я их и заменил на QList. Но в принципе списки не самый быстрый контейнер для простых операций. Первое что я сделал заменил на QVector. Автозаменой, получил прирост в 30%.

Шаг второй – правильные методы доступа.

В поисках что бы еще улучшить, случайно наткнулся в документации на следующее

For read-only access, an alternative syntax is to use at():

at() can be faster than operator[](), because it never causes a deep copy to occur.

У нас в контейнере хранились просто int’ы, ничего более сложного, поэтому чудес я не ожидал. Но произошло чудо:)

Замена всего одной строчки в коде вида

Q_FOREACH(QList<int> pf, paths_father)

{

Q_FOREACH(QList<int> pm, paths_mother)

{

if (pf[0] != pm[0]) continue;

Дала прирост на порядок для количества путей родителей XXK на XK, и в сотню раз (!) для количества порядка 220K на 30К. Сказка.

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Уже дискуссия (18)
Больше по теме:

Ориганалы можно посмотреть тут и тут.

Правда прикольно?:)

© Begemot for Микроблог про wxWidgets, 2011. | Ссылка | Один высказался
Больше по теме: +1