extend inotify-based signals for gtk3

[step-]

This PR replaces #116.

This commit extends the signal handling code involved with "auto-refresh" and "file-monitor" custom attributes to make it compile and work with GTK+-3.

It also fixes several "implicit declaration" compiler warnings.

The following scripts are simple and effective tests for auto-refresh and file-monitor because they set up 100 watches. Make sure to test all eight combinations: {gtk2, gtk3} x {w/, w/o inotify} x {auto-refresh, file-monitor}:

• examples/pixmap/pixmap_auto_refresh
• examples/pixmap/pixmap_file_monitor

[01micko]

looks ok in gtk2 :)

[dimkr]

No objections from my side.

There are some inconsistencies in coding style (i.e. G_IO_STATUS_NORMAL != g_io_channel_read_chars() instead of g_io_channel_read_chars() != G_IO_STATUS_NORMAL) but maybe they annoy only me, and I'm not familiar enough with the codebase to tell if these changes can introduce a memory leak.

[step-]

Thanks @01micko and @dimkr for your approval.

There are some inconsistencies in coding style (i.e. G_IO_STATUS_NORMAL != g_io_channel_read_chars() instead of g_io_channel_read_chars() != G_IO_STATUS_NORMAL)

I agree. Let me explain why I prefer this coding style. Consider what could happen in C when one writes if (p == NULL) ... vs if(p = NULL) -- the latter being a typo and p a pointer -- both are valid, both are frequently used in C programs, and the typo will likely cause some hard to find bug. I suppose this kind of bug is one reason for gcc to insist that assignments in an if condition be wrapped in brackets. But if one writes if (NULL == p) as a habit, the typo if (NULL = p) will generate a genuine syntax error, not a warning. When C compilers don't warn about missing brackets in assignments of if conditions, this habit of reversing operands is defensive programming.

[dimkr]

I agree. Let me explain why I prefer this coding style.

I've used this coding style ("Yoda notation") for years, but at some point in my life, my boss asked me not to use this coding style. It's often frowned upon, because only a tiny minority of C code is written like that, and it slows down both coding (for those not used to this) and reviews.

Eventually, I got used to the "normal" style and I prefer it. When I write in C today, I never assign values inside an if, to avoid confusion: every assignment inside an if is unintentional.

Defensive programming principles have their merits, but I think the cost is too high in the case of Yoda notation, especially when collaborating and when you can set up CI that builds with -pedantic -Werror, etc'.

[step-]

Thanks for your comments. I try to refrain from assignments inside an if condition but typos are typos and, as you say, they are unintentional. I fully agree to the merits of CI.