On Thu, 2015-02-12 at 12:55 -0800, Philip Chimento wrote: > On Thu, Feb 12, 2015 at 5:22 AM, Philip Withnall > <[email protected]> wrote: > On Thu, 2015-02-12 at 11:22 +0100, Alexander Larsson wrote: > > On ons, 2015-02-11 at 12:17 +0000, Philip Withnall wrote: > > > > > > I understand where you’re coming from; we should not be > irritating > > > experienced developers. I completely agree. > > > > > > What do you think of the proposal to use sync gstdio.h for > > > small/local/pseudo-file-system I/O and async GIO for all > other I/O? > > > > I don't think this is a great alternative in many cases. The > gstdio > > stuff may work fine from C, but the GObjects etc of gio > makes such use > > much nicer from language bindings. > > True. Wouldn’t the languages typically have their own native > gstdio-like > functions for local file I/O though, which would tend to be > integrated > nicely? > > > Javascript doesn't; one of the main reasons behind the decision to > make JS the first-class citizen for new Gnome apps developers was > precisely that it didn't already have its own platform. I got the > impression that using, for example, Python's native local file I/O > facilities in the Gnome stack was to be discouraged.
Bother, good point. Scrap that idea then.
In summary, options we’ve discussed so far are:
1. Use gstdio.h for small reads, GIO async for others:
- gstdio.h is rubbish from bindings
2. Warn if sync API is used from the main context, enabling the warning
on G_ENABLE_DIAGNOSTIC, and only warning if the call takes too long:
+ Helps in tracking down bugs at the source (rather than just ‘GTK+
is being blocked too long’)
+ Shouldn’t have any false positives in the cases discussed so far
(small reads from console programs, application startup)
- Requires active effort to enable (G_ENABLE_DIAGNOSTICS), limiting
its uptake
3. Rearranging the docs to promote async functions more
? Has not been discussed
- Big red warnings in the docs may just be ignored by people
Seems like option #2 is worth going ahead with. I’ve filed:
https://bugzilla.gnome.org/show_bug.cgi?id=744458
Anybody have any thoughts about option #3? I’m wary about filling the
docs up with big red warnings.
Philip
signature.asc
Description: This is a digitally signed message part
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
