Re: [gtk-list] Re: gdki18n.h

[Owen Taylor <owt1 cornell edu>]

> On Mon, 1 Dec 1997, Owen Taylor wrote:
> 
> > Questions:
> > ----------
> > 
> > Is it OK for glib to depend on the X libraries?
> 
> hm, i definetly don't think so. i have written some small programs
> already that use glib but not gdk/gtk+. also, if gdk is designed to
> wrap Xlib, why should that affect glib? since the wchar/locale stuff
> is in fact non gui related, i think the failure has been made in the
> first place, where this got bundled with Xlib ;(

The reason it was bundled in with Xlib was that the developers
of X found that native OS support for these functions was 
often insufficient, so they provided their own implementation.

On Linux, OS support has improved significantly with glibc2, but
that still lacks support for, e.g., the asian locales.

> > If so, should this stuff be moved to glib?
> 
> just for the convenience of haveing g_something() functions
> instead of gdk_something(), hm i don't think so...

Well, also because it (at least conceptually) isn't gui related.
But since there are people using glib independent of GTK/GDK,
I'll keep the support in GDK.

> > Should gdki18n.h be installed? Should it be automatically included?
> hm, i think it should always be installed and included, to unconditionally
> provide the function prototypes (which are in the gdk_ namespace then).
> i don't wan't my application to fail in the build process because on someone
> elses system the locale support is poor or different, and some definitions
> of gdki18n.h got lost on the way.

What I meant by "included" was that currently, including 'gdk.h'
pulls in 'gdki18n.h' which redefines mbtowcs, etc. That is
clearly unacceptable.

On the other hand, if programs had to explicitly request
'gdki18n.h', redefining mbtowcs, etc., might be acceptable.  
But simply having 'gdk18n.h' define gdk_mbtowcs,
etc. would avoid the issue entirely.

Thanks for the input,
                                        Owen