Thanks for your attention. I agree with you in the case of servers. But I'm talking about the desktop (sorry forgotten to mention it). I hope you'll agree with me that for a desktop it's a very (very!) unlikely such a situation which would happen (if at all) only under very heavy stress. I think common sense implies that a "normal" desktop user would rather want a quick system that feels and acts quickly (roughly saying) 99.9999% of the time rather than constantly "feel and act" slowly but manage to properly treat that (roughly saying) one in a million situation (if at all). By the way, I think that because of this, the "delete" sometimes doesn't work in Nautilus (seems to be lost) but don't quote me on this as I don't know if this particular issue is related to gio. I hope you'll agree that because of this there should be some change (in gio), at least let the developer customize the timing or so. On a somewhat different note, isn't set_rate_limit() designed to solve this timing issue? And if so, am I right in asserting that it's not working?
On Mon, May 31, 2010 at 5:09 PM, Emmanuele Bassi <eba...@gmail.com> wrote: > On Mon, 2010-05-31 at 14:28 +0300, Владимир wrote: > > > So I've dropped the gio monitor and started using inotify in the app > > I'm creating because of this (i.e. because I want end users to > > think/feel that my app is quick). > > and yet you'll achieve the opposite as soon as you start getting > multiple events (that would be coalesced by GIO) and when you try to > handle them all you'll essentially perform a DoS on your UI. > > ciao, > Emmanuele. > > -- > W: http://www.emmanuelebassi.name > B: http://blogs.gnome.org/ebassi > > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
