Blinking line in QListView/QTableView/QTreeView

[raven-worx]

@ShinSat said in Blinking line in QListView/QTableView/QTreeView:

Any pointers to right direction is welcome.

• return the color from your model for the Qt::BackgroundRole for the corresponding indexes
• use a timer which toggles the state and triggers a dataChanged() signal in the model (for the whole row)

[ShinSat]

Thanks for an update, @raven-worx
Is this an idea about assigning one timer to each row?

Sat

[VRonin]

• subclass the view
• add a private timer that takes care of timing the blinking and a boolean that keeps track of the state of the blink
• connect the timer timeout to the view's update and a slot that inverts the boolean
• reimplement viewOptions() calling the base class implementation and then changing the backgroundBrush property of the result based on the boolean value

[ShinSat]

Thank you very much for your help, all.
Here, I'm also trying using QPropertyAnimation but no luck so far... :<
I would like to share a proven, stable, and light weight implementaion.

    def make_blink_wgt(self, obj):
        eEffect = QGraphicsColorizeEffect(obj)
        obj.setGraphicsEffect(eEffect)

        anim = QPropertyAnimation(eEffect, b'color')
        anim.setDuration(1000)
        anim.setLoopCount(30)
        anim.setStartValue(obj.palette().text().color())
        anim.setEndValue(obj.palette().text().color())
        anim.setKeyValueAt(0.5, QColor(0, 255, 0))

        anim.start()

[ShinSat]

One thing I'm not sure is the cost of the implementation. Since my display items are going to be huge(eg. tens of thousands). What do you think about the difference between subclassing View and Model?
Of course, I don't mean every item to be blinked. These are, for example, just newly added items and the ones which are dynamically evaluated in run time as important items.

BTW, signaling dataChanged in the View affects the whole items, which is a big cost, isn't it?

Sat

[ShinSat]

@raven-worx

return the color from your model for the Qt::BackgroundRole for the corresponding indexes
use a timer which toggles the state and triggers a dataChanged() signal in the model (for the whole row)

I'm testing the idea you shared in pyqt5.9.1 on Win7 and not succeeding in emitting dataChanged().
Are you able to share an example?

Sat

[ShinSat]

@ShinSat Regarding emitting dataChanged, I testing a timer, called watch_dog, emitting dataChanged signal in the model. But nothing happend in the list. What am I misunderstanding?? :<<
How can I explicitly invoke BackgroundRole in data() in the model?

    def watch_dog(self):
        print('Bow')
        th = threading.Timer(TIMER, self.watch_dog)
        th.start()
      # do something here
        self.dataChanged.emit(self.createIndex(2, 0), self.createIndex(2, 2))

Update:
self.modelReset.emit() , instead of dataChanged.emit(), works. Strange..Why dataChanged() does not update the view in real time.

[ShinSat]

Looks like I'm trying to update with dataChanged in the MODEL, but the VIEW should be refreshed instead, am I right?

Sat

[raven-worx]

@ShinSat said in Blinking line in QListView/QTableView/QTreeView:

Looks like I'm trying to update with dataChanged in the MODEL, but the VIEW should be refreshed instead, am I right?

with the dataChanged() signal you tell the view that the data has changed and that is need to update itself. Other than the reset() signal, the dataChanged() signal doesn't clear selections.

So i guess your model index parameters are incorrect at the time you emit the dataChanged() signal?
(The indexes are 0-based of course)

[ShinSat]

Thank you very much for your help, @raven-worx.
I found that I was calling the MODEL's datachanged, but it worked when I called VIEW's one.
Yes, I think it was my fault. I need some more tests but it should be OK. :)

BTW, one thing I'm still not sure is the cost of updating the view with timer because my data will be tens of thousands...

Sat

[raven-worx]

@ShinSat said in Blinking line in QListView/QTableView/QTreeView:

BTW, one thing I'm still not sure is the cost of updating the view with timer because my data will be tens of thousands...

depends.
Of course you should only use a single timer for all rows, not a timer for each row.
First implement it and then get rid of the possible bootlenecks