Помогите организовать мигание иконки внутри делегата

[lit-uriy]

Kolobok и break
каждый из вас по своему прав, но каждый из вас до конца не рассказывает оппоненту свою мысль.

у делегата действительно нет функции  paintEvent. У него есть функция paint.
В событии рисования представления, т.е. в его paintEvent по мимо рисования того, что непосредственно к нему относится, ещё вызываются функции paint всех делегатов, которые видны в данный момент и все предшествующие им.
Т.е. если в данный момент в таблице видны строки/столбцы в диаппазоне 5...9, то вызываются методы рисования делегатов принадлежащих строкам/столбцам с 0 по 9.

Итого: инициатором рисования делегата является представление, но весь алгоритм рисования делегата находится в самом делегате

[BRE]

Набросал примерчик. С картинками затеваться было лениво, сделал мигание слова 'Alarm', если в ячейке находиться буква 'A'
Для оптимизации желательно добавить обновление не всего viewport, а только области для нужной колонки, тоже стало лениво
Хотя, Qt сам частенько обнавляет весь viewport...

Код

C++ (Qt)
#include <QApplication>
#include <QTableView>
#include <QItemDelegate>
#include <QStandardItemModel>
#include <QPainter>
#include <QTimer>
#include <QDebug>
 
class Delegate : public QItemDelegate
{
        Q_OBJECT
public:
        Delegate() : m_state( false ) {}
 
        void paint( QPainter *painter, const QStyleOptionViewItem &option, const QModelIndex &index ) const;
 
public slots:
        void stateChanged()
        {
                m_state = !m_state;
        }
 
private:
        bool    m_state;
};
 
void Delegate::paint( QPainter *painter, const QStyleOptionViewItem &option, const QModelIndex &index ) const
{
        if( !index.isValid() )
                return;
 
        painter->save();
        QString val = index.data( Qt::DisplayRole ).toString();
        if( val == "A" )
                painter->drawText( option.rect, m_state? "Alarm" : "" );
        else
                painter->drawText( option.rect, val );
        painter->restore();
}
 
int main( int argc, char *argv[] )
{
        QApplication app( argc, argv );
 
        QStandardItemModel model( 10, 10 );
        model.setItem( 1, 0, new QStandardItem( "A" ) );
        model.setItem( 3, 0, new QStandardItem( "A" ) );
        model.setItem( 4, 0, new QStandardItem( "A" ) );
        Delegate delegate;
 
        QTableView view;
        view.setModel( &model );
        view.setItemDelegateForColumn( 0, &delegate );
        view.show();
 
 
        // Таймер меняет состояние и заставляет перерисоваться view
        QTimer timer;
        QObject::connect( &timer, SIGNAL( timeout() ), &delegate, SLOT( stateChanged() ) );
        QObject::connect( &timer, SIGNAL( timeout() ), view.viewport(), SLOT( update() ) );
        timer.start( 1000 );
 
        return app.exec();
}
 
#include "main.moc"
 

[Kolobok]

Я извиняюсь за лаконичность. Клавиатура виртуальная.

Рисовать делегат может только внутри paintEvent представления. Поэтому вызывать таймером какие-либо слоты делегата для перерисовки смысла не имеют.

[crossly]

Я извиняюсь за лаконичность. Клавиатура виртуальная.

Рисовать делегат может только внутри paintEvent представления. Поэтому вызывать таймером какие-либо слоты делегата для перерисовки смысла не имеют.

простите .... где вы говорите это написано.... ??

[BRE]

Рисовать делегат может только внутри paintEvent представления. Поэтому вызывать таймером какие-либо слоты делегата для перерисовки смысла не имеют.

Ну так оттуда и зовется QAbstractItemDelegate::paint.

[Kolobok]

простите .... где вы говорите это написано.... ??

Где написано что?

[crossly]

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

[Kolobok]

Потому что у делегата нет QPaintDevice. Ему не на чем рисовать. Кроме того, он не знает, что рисовать и где. Все это делегат может получить только из paintEvent представления, но никак от таймера.

[crossly]

тем не менее приведенный выше пример работает....

[Kolobok]

тем не менее приведенный выше пример работает....

Потому что представление каждую секунду принудительно перерисовывается. Этот способ я уже описывал.

Код:

class MyDataModel : public QAbstractItemModel {
....
virtual void data( ..);  // добавить выдачу для Qt::BackgroundRole
...

void NextBlink( void ) { mBlinkState = (mBlinkState + 1) % 2; }

QVector <QModelIndex> mBlinkCell; // массив мигающих ячеек
int mBlinkState:                          // напр. 0 = синий, 1 = красный и.т.п.
};

По таймеру таблица говорит модели NextBlink и вызывает перерисовку нужных ячеек.
Правда, судя по исходникам, background (возвращаемый data) будет игнорироваться для выделенных ячеек если showDecorationSelected = true в стиле. Но оно public, так что можно напр. перекрыть paint для делегата. Короче, раскрасить ячейку можно  

В этом варианте мигающие элементы придется хранить и во view(очень плохо). Или по сигналу таймера вызывать repaint().

[break]

Потому что у делегата нет QPaintDevice. Ему не на чем рисовать. Кроме того, он не знает, что рисовать и где. Все это делегат может получить только из paintEvent представления, но никак от таймера.

Что рисовать делегат знает по тз., где рисовать тоже знает - это передается входными параметрами в ф-ю paint.
Таймер предлагался к использованию для изменения флажка состояния. Как и приведено в примере выше у BRE.
Да и в принцепе для мигания - вам один хрен будет нужен таймер, а иначе как???
Совершенно непонятно чем не нравится приведенный пример. Хранить функционал мигания в моделе уж точно худшая мысль. Писать вьюв который будет уметь мигать - тоже бред, чтобы этого не делать и были придуманы делегаты.
IMHO: Ерундовая тема раздулась на 3 страницы - совершенно непонятно почему и зачем.

[crossly]

совершенно согласен....

[Kolobok]

Хранить флаг анимации и управлять анимацией это разные вещи. Первое может быть в модели или делегате, второе в модели или вью. Где - не принципиально если не требуется оптимизация. Все это время я пытался сказать, что делегат не может управлять анимацией.

ИМХО лучше весь код иметь в одном классе.

[crossly]

тем не менее приведенный здесь код говорит об обратном...

[BRE]

Хранить флаг анимации и управлять анимацией это разные вещи. Первое может быть в модели или делегате, второе в модели или вью. Где - не принципиально если не требуется оптимизация.

Что значит не принципиально?
Есть одна модель, которая представляет данные для нескольких вьюшек.
Для каждой вьюшки состояние аварии показывается по разному. Для одной (это таблица) - миганием иконки в ячейке, для другой (а это может быть и какой нибудь QGraphicsView) - разбегающимися слониками. Для поддержки второго типа индикации, тоже добавим еще один специальный столбик в модель, для сохранения координат слоников? 
Модель - предоставила данные - АВАРИЯ, как и кто это будет сигнализировать для нее вопрос не интересный.

ИМХО лучше весь код иметь в одном классе.

А это все можно скрыть внутри, С++ же.