Re: File name encoding and GTK ABI compatibility on Win32
- From: Mike Hearn <mike navi cx>
- To: Owen Taylor <otaylor redhat com>
- Cc: Tor Lillqvist <tml iki fi>, gtk-devel-list gnome org
- Subject: Re: File name encoding and GTK ABI compatibility on Win32
- Date: Mon, 06 Dec 2004 16:34:23 +0000
Owen Taylor wrote:
I don't think anybody (including Microsoft) would exhibit windows.h
as an example of convenient, easy to use programming.
There are many, many things wrong with the Win32 API, but the ease of
binary distribution you get with it isn't one of them.
What it prohibits is making things "just work better" ... the
g_return_if_fail() change saved on the order of 5% code size for GTK+.
That's a pretty huge win.
It doesn't prohibit it, things can just work better for apps that
explicitly target the new GTK+ version.
Having to put -DGTK_ABI=2.6
would still confuse the heck out of beginning programmers, and cause
a big mess in the header files.
I don't see why it would be any more confusing than "Hey Bob, check out
my leet new GTK+ program ... huh, it doesn't work for you?". Specifying
the version of an API you want to target is a tested technique that
As far as making a mess of the header files, I don't think it's such a
big deal. It typically involves wrapping new functionality in an #ifdef.
For Tors need, you could do:
#if (GTK_TARGET_MINOR >= 6)
# define U(x) x ## _utf8
# define U(x) x
void U(gtk_some_function)(GtkFoo *foo, gboolean bar);
This is slightly ugly, but not hugely so - it's still easily readable -
and the portability gains are useful.
If people want their programs to have a prayer of working with older
versions of GTK+, they need to be testing extensively with those older
versions. (It's not just functions and enumerations that get added.
There's also semantic creep where combinations of function calls that
didn't used to work start working.) And at that point, we might as
well say "compile with the oldest version you want to run with.
I'm not really convinced by this - are there many examples of
applications actually depending on this semantic creep? I can't think of
any off the top of my head, certainly it should be the exception rather
than the norm.
In the case that an app depends on stuff that was broken in previous
versions, yes there is nothing you can systematically do about this. If
apps depending on previously buggy stuff is so common that it affects
library policy like this then maybe a longer beta cycle is needed to cut
down the amount of buggy code being shipped.
] [Thread Prev