reid wrote:
Initially I didn't want to re-build the list every time a change was made because this introduces unnecessary processing.
I now clear and rebuild the list everytime a change is made and format the rebuilt list using a cell_data_func callback.
Hi Paul,
It's fine to rebuild the list. But when the user right click on a row to remove it from the queue, you can just remove that row from the underlying data model. In this way, you do not need to rebuild the entire list.
This has led me to another problem - everytime the user mouses over the list the callback is called. How can I stop this from happening?
I know the fact that the cell_data_func is called so frequently (e.g. everytime there's any update in the underlying model or any movement in the treeview) makes us feel that it will be very inefficient and will cause some flashing of the screen.
However, having worked with the treeview for so long, I was always amazed at this cell_data_func. It seems to have its own internal optimization to process the treeview update efficiently.
For example, take a look at this example:
Sample Code 490: How to have a start stop button in GtkTreeView - Part 1 - using liststore
You can see independent hundredth-second timer running concurrently across every row as shown below:
So, don't worry too much about the cell_data_func being called too many times or feel that it's being inefficient. Most of the time, if there's any slowness in your application, it's usually not due to the cell_data_func.
(By the way, if you're echoing any debugging information to the command window in this function, try to turn them off in your "live" application. I find that any echoing of information to the command window from within the cell_data_func will significantly slow down the efficiency of this function.)
Regards,
/kksou