On Mon, 2015-02-09 at 14:55 +0100, Bastien Nocera wrote: > On Mon, 2015-02-09 at 13:42 +0000, Philip Withnall wrote: > > On Mon, 2015-02-09 at 14:02 +0100, Bastien Nocera wrote: > > > On Mon, 2015-02-09 at 12:53 +0000, Emmanuele Bassi wrote: > > > <snip> > > > > 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. > > > > > > I wouldn't want that. I can certainly see that as a necessary evil (say > > > on application startup), and would rather it threw an error if that sync > > > call took too long instead. > > > > Why can the startup code not use a GMainLoop? Is there some pattern I’ve > > missed? I thought in all such situations you could still do with a main > > loop so you could handle Ctrl+C nicely. > > What's "handling Ctrl+C" nicely? I can Ctrl+C stuck applications fine in > most cases, and I wouldn't want the handling of such a feature to be the > main driver behind my API decisions.
Cancelling any ongoing operations and rolling back any in-progress changes, I guess. That’s a pretty vague answer. One example in my head at the moment is git-bz: it needs to handle sigint to try and keep its changes to .git and Bugzilla atomic, by preventing termination while modifying them. But yes, in the case you’re just loading resources from disk, I don’t suppose there’s any need to handle sigint specially. Though if you are (for example) loading resources synchronously on startup, you could parallelise the I/O using the main loop. > On startup, you should try to get the maximum amount of work done in the > minimum amount of time. In some cases, pre-populating the UI (while > "blocking" the mainloop) is a better idea than seeing jarring effects > after the fact, once the UI has been loaded. True. Should that not be implemented by freezing those individual widgets while populating them (for example, using the standard populate a GtkTreeModel before setting GtkTreeView:model trick), rather than blocking the entire main loop? That would allow other widgets to remain responsive. Philip
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
