[sldev] Opinions regarding use of GTK glib on Windows/MacOS?

[alissa_sabre at yahoo.co.jp]

Developers,

I'm recently investigating several codeset/locale related issues in SL
viewer.

One of my findings is that the current viewer often uses plain C
functions whose behaviour depends on the underlying codeset/locale in
a way as if the functions were locale/codeset independent or their
support for UCS4/UTF-32 was guaranteed.  Another (not actually recent)
finding is that SL viewer seems to have tried implemening its own
locale framework (through e.g. LLResMgr class), and discontinued it
unfinished, but there are still some codes that uses it.

We can solve some large parts of the problems by introducing a set of
locale-neutral Unicode handling functions.  One possibility is to use
"String Utilities", "Unicode Manipulation", and possibly "Date and
Time" and "Character set Conversion" portions of GTK's glib.

Examples of useful glib functions include:
- g_unichar_isupper() to replace a buggy use of iswupper() in LLStringOps.
- g_ascii_strtod() to replace questionable uses of strtod().

I want to hear your opinions, especially from Lindens, on this issue.

Pros for glib:
- It's licensed under LGPL.
- Widely used.  Well maintained.
- Runs on many platforms including Windows, MacOS(*), and Linux.
- Linux version of SL viewer already uses it. (indirectly through libgtk.)
- Explicitly supports platform-independent, locale-neutral Unicode handling.
- Its Uniocde character properties table is synchronized with Unicode
  Consortium's official data.

Cons against glib:
- glib uses GTK specific typedefs for basic data types.  It makes the
  source more complicated because SL viewer already has a set of its
  own typedefs.
- Relies on GTK's unique memory allocation/release paradigm.
- The API is slightly biased toward posix based systems (IMHO).
- glib dynamic library (DLL) is big, and we only need some small
  portions of it.
- glib does not solve all issues.  Specifically, SL viewer assumes a
  locale independent version of sscanf(), that is not available in
  glib.

* GTK does *not* support cabon/cocoa of MacOS yet.  It is due to some
  difficulties to integrate some MacOS specific GUI features such as
  the system-wide menu bar.  glib is the lowest layer in GTK library
  stack, and has nothing to do with GUI.  glib is already working on
  MacOS with no trouble.

Another thought is that my future projects include adaptation of pango
in SL viewer for improved text layout, and pango requires glib.  Of
course you are free to object against pango.

    Alissa Sabre
--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/