Andrew is suggesting you insert a small delay in between getting the signal the 'selection_changed' signal and actually doing something about it.
By adding the delay you allow time for then next signal to come along + if you get a second signal you should reset the timer to zero, to allow for yet another user event. By tuning the size of the delay you'll cut down the number of signals for which you actually do something and performance should be good.
You need to check-out gobject.timeout_add() and gobject.source_remove(), which will allow you to set your processing to be triggered after the delay. source_remove is needed so that you can cancel an earlier timeout_add when you get a second 'selection_changed' event.
Hope that helps.
John
Matthias Kaeppler wrote:
Andrew E. Makeev wrote: > I think, it is not GTK+ neither GTKMM issue. > > You have to delay signal handler just until user keep send events to > your application. > Set timer callback where you will call "selection_changed" handler, and > reset it after each user event that changes selection. > > Regards, > -andrew
Hm, I'm not sure what you mean, can you elaborate on that? Sorry for my ignorance, I'm fairly new to the whole Gtk thing.
-- Matthias Kaeppler
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
------------------------------------------------------------------------
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
That sounds reasonable. However, this delay has to be rather small, in order not to confuse the user if something is supposed to happen on selection. But if e.g. there are delays lilke 1 second between the selections, the problem is there again.
-- Matthias Kaeppler
_______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
