Abstracting away glib?

[Jan Engelhardt]

On Monday 2009-02-02 13:15, Mourad De Clerck wrote:
>
>Now, don't get me wrong: if glib gets in the way of your esthetic
>senses, or you dislike it for some other reasons, feel free to toss it;
>I'm already grateful people are taking an interest in mc at all. But I'd
>expected you to start using more of glib, instead of less. Because it's
>well tested and in wide use, and because you can take advantage of
>features that glib implements so you don't have to implement or maintain
>these; stuff like GIO/GVFS, win32 portability, etc.

As an mc user, I do not really care how much glib is used or not.
But I used to rip glib out of pam_mount for I did not very art-ful.

A gem from a few years ago:

	/* FIXME: getting rid of the const is silly, but I didn't write g_tree_insert */ 
	g_tree_insert(x->fillers, (char *) key, (char *) val); 

Also, the typedef definitions are really worrisome. I think someone
was too eager in ensuring portability. Why define gconstpointer if
your compiler has const void *? Obviously, gconstpointer is there for
compilers that have no void. But then again, glib does not even
support such compilers in the first place, and neither would I
suggest such a prehistoric compiler to anyone.

	static gint _cmp(gconstpointer a, gconstpointer b) { 
	...
	}
	x = g_tree_new(_cmp);

Or take this:

	return g_spawn_async_with_pipes(wd, (char **)argv, (char **)envp,
		flags, cs, data, pid, istdin, istdout, istderr, err);

Which reminds me of
http://mirror.linux.org.au/linux.conf.au/2008/Fri/mel8-137.ogg
("preferably not too many args").

That provided enough reasons for me to do without glib and instead
use my own.