версия 1.х точнее не помню, лицензия GPL, ОС Linux RedHat версию тоже не помню, WDM KDE тоже не помню версию

нельзя сказать, чтобы именно работал, скорее как раз познакомился

какие MFC??...  какой в болото .NET???... 

Qt - откровенно не идеал, есть масса недостатков, но это лучший инструмент, с которым приходилось работать, а недостатки со временем исправляются

первый раз знакомился с Qt в середине 90-х, уже тогда это был отличный инструмент для быстрого создания приложений, а сейчас вообще не о чем говорить... на голову выше всего остального, хотя есть еще над чем работать

а! теперь ясно в чем дело...

после hide на него ссылка все равно где-то будет, кроме моего списка arrayList? это не правильно...

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

зачем так сделано, что если из контейнера удаляется, на экране все равно остается? 

к некоему QVBoxLayout добавляется некоторое количество таблиц, которые создаются


когда надо, некоторые удаляются так:


в результате виджет из бокса не исчезает, хотя изображение меняется - исчезает двойная полоска, отделяющая его от предыдущего виджета

что не так делаю?

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

мне это сейчас сделать - 1 минута... блокировка элементов давным давно есть, надо только ее вызывать в той функции, которая ответственна за проверку пройденного времени и включение песочных часов

а вместо надписи "Рисуем" вполне устраивают песочные часы

угу, для каких-то приложений примерно так и надо делать, хотя без всяких FIFO можно вполне обойтись

но в моем случае, поскольку пока Redraw не выполнится, гуй и не должен полноценно работать, ибо не с чем

а вот таймеры, и все, что к гую не относится, по идее должно...

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

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

одним только таймером для этого не обойдешься, сделать придется чуть больше

хотя это как-то "по-DOS-овски" в единичном случае схляет, но хотелось некий регулярный способ получить, чтобы можно было потом просто вызывать одну функцию во всех похожих случаях

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

хех... попробовал добавить вызов processEvents() внутрь Redraw(), причем не на каждый элемент, а только перед некими "крупными" действиями, результат удручающий... оно то заработало, но отрисовка замедлилась в несколько раз, и что самое ужасное, стало видно, как сцена рисуется, чего собственно и следовало ожидать

то есть, надо вычленить, и разрешить только событие таймера, чтобы processEvents() разрешало прохождение только его событий, либо хотя бы запретить прохождение событий при рисовании - а такой возможности нет...   есть только два флага QEventLoop::ExcludeUserInputEvents и QEventLoop::ExcludeSocketNotifiers, оба не подходят

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

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

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

это все понятно, но несколько не то... может потребоваться, например, разные типы виджетов в разных ячейках одной колонки

например, в колонке отображаются данные разных типов: целое, логическое, вещественное - для целых удобно спином или редактированием менять значение, для вещественных надо иметь возможность редактирования, или выбора из предопределенных символьных эквивалентов (PI, E, PI/2 и тд), для логических только выбор из списка ИСТИНА или ЛОЖЬ

ну или какой-нибудь более сложный случай

странно, что нет вызова setItemDelegateForCell ( int row, int column, QAbstractItemDelegate * )

придется наверно в моем случае "с делегатом мудрить", так похоже проще всего получится

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

не вижу возможности установить делегата для отдельной ячейки, вижу только на таблицу, строку или колонку - ткните носом, плз, если такое есть