On Mon, 2015-02-09 at 12:53 +0000, Emmanuele Bassi wrote: > I do agree with Philip's proposal of warning if the sync API is called > inside the default main context, even if there's the obvious issue of > console-only code that still uses a main loop, but does not have > interactivity issues. > > maybe we could use G_ENABLE_DIAGNOSTIC for this kind of messages; > after all, we're already using it for deprecated properties and > signals.
Having that kind of diagnostic (i.e. a developers-only tool) would be nice. Paired with Bastien's suggestion: > > and would rather it threw an error if that sync call took too long > instead. Didn't we have something like that for GTK+'s frame clock? I guess it boils down to really looking at where and why those sync calls are happening. For example: * I turn on my machine and start my session. Gnome-shell brings up an empty desktop. I *can't do anything* until I pop up the Activities, but when I do that, gnome-shell takes a little to read all the icons or .desktop files for the applications, and there is a noticeable delay. At startup, it could read those asynchronously so that they would be ready when I bring up the Activities for the first time. * Gnome-shell takes noticeably longer to respond at startup if the VPN is not started yet *and* my /etc/resolv.conf was left with a DNS server that is only accessible through the VPN. I don't know if gnome-shell actually needs to resolve a host name, or if it's waiting for NetworkManager for something, or what. The first case is about making the best use of time; the second one is probably just a bug, or a bad API that forces gnome-shell to wait. I don't think you can just say, "sync calls bad" all the time :) Federico -- GPG fingerprint - RSA 4096: 263F 590F 7E0F E1CB 3EA2 74B0 1676 37EB 6FB8 DCCE _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list