[openbeos] Re: StyledEdit news of various interest

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 25 Jul 2003 17:41:59 +0200 CEST

On Thu, 24 Jul 2003 21:07:13 -0700 PDT "Andrew Bachmann" <
shatty@xxxxxxxxxxxxx> wrote:
> Okay, now that I've shown my ignorance of C vs. C++ linking, I'll try 
> again.
> It sounds like we agree to put the CharacterSet and 
> CharacterSetRoster
> code in libtextencoding.so.

Yep. Please rename them to BCharacterSet[Roster] then, or at least put 
them into the BPrivate namespace.

> I will keep the current method of creating the
> CharacterSet objects in source.  I will separate the creation code 
> from the
> object code though, like it should be.

How about:

enum {
        MAX_CHAR_SET_ALIASES    = 32,
};

struct character_set {
        uint32          id;
        uint32          MIBenum;
        const char      *print_name;
        const char      *iana_name;
        const char      *mime_name;
        const char      *aliases[MAX_CHAR_SET_ALIASES];
};

static const character_set sCharacterSets[] = {
        {
                B_UNICODE_UTF8,
                106,
                "Unicode",
                "UTF-8",
                "UTF-8",
                { NULL }
        },

        {
                B_ISO_8859_1,
                4,
                "ISO Latin 1",
                "ISO_8859-1:1987",
                "ISO-8859-1",
                { "iso-ir-100", "ISO_8859-1", "ISO-8859-1", "latin1", "11", 
"IBM819",
                  "CP819", "csISOLatin1", NULL }
        },

        // ...
};

static size_t sCharacterSetCount
        = sizeof(sCharacterSets) / sizeof(const character_set);

Then BCharacterSet could simply be a wrapper for the structure and 
would be very light-weight. BCharacterSetRoster would contain no data 
at all (or only a cookie for iteration) and creating it on the stack 
would be fine.

> So, I'm trying to figure out where to put these files in cvs.  
> convert_to_utf8
> and convert_from_utf8 are grouped into the Support Kit by the
> BeBook.  As such, the files could go in current/src/kits.  Anyone 
> have a
> better alternative?  Also, the CharacterSet.h would presumably go 
> into
> current/headers/os/support? or perhaps current/headers/private/
> support?
> UTF8.h is in current/headers/os/support.

Since it's a private API for the time being, the headers should go into 
`headers/private/support'. The implementation is fine in `src/kits/
support'.

> Axel is right about iconv being part of glibc.  glibc is LGPL, and so 
> is
> iconv.  Somewhere in the back of my mind I thought iconv used to be
> pure GPL, but I was wrong.  However, I'm still fuzzy on what's okay
> with LGPL and what's not.  (I Am Not A Lawyer, and so I just want
> someone official to say it's okay.)  Perhaps we can have a FAQ or
> something on licensing issues and get a final say on LGPL.

That would be nice indeed. Anyway, as handled in other places, LGPL 
libraries are OK to be used, though one should avoid to use source code 
from them directly. libroot is an exception, of course, since the whole 
library is based on glibc.

> It was my intention to include iconv from libtextencoding.so and to
> implement the major bulk of the heavy lifting by simply calling to
> iconv.  Depending on the interface to iconv, which I am not very
> familiar with, it may be more desirable to create new conversion
> functions that could be more useful than the convert_to_utf8 and
> convert_from_utf8 functions.  (libiconv has some direct conversions
> which could be much faster and/or less lossy)  I can take a look at
> this but I'd like to have a green light on iconv first, of course. :-
> )

As long as convert_{to,from}_utf8() are there, things are fine, I'd 
say.

CU, Ingo


Other related posts: