[haiku-development] Re: Fwd:
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 29 Jun 2010 18:51:16 +0200
On 2010-06-29 at 17:48:26 [+0200], PulkoMandy
<pulkomandy@xxxxxxxxxxxxxxxxx> wrote:
> > Hello devs,
> > I'm working on adding support for libraries localization in the Locale
> > Kit. My plan is to add a new GetNamedCatalog function, that will get a
> > name (lets say, "libbluetooth") as a parameter and load the appropriate
> > catalog from disk, then return it to the app. I think the same system
> > could then be used for add-ons. The idea for the extra argument is that
> > it will replace the mimetype used for apps, as libs have no mimetypes.
It could be made a requirement for libraries using the locale kit to have a
MIME type, if that makes things simpler. The question is how you'd
organize/find the catalogs on disk without a MIME type otherwise.
> > Designing this, I'm running into a few design questions I'm not sure
> > how to solve, and I'd like some advice from some more skilled C++ devs
> > (I don't do enough OOP at school, sadly).
> >
> > The first question :
> > As of now, each application instance builds its own BCatalog and keeps
> > it for the runtime. That's fine, because it allows multiple instances
> > of an application to run in different languages. But for libs, they can
> > get used in a lot of apps, and it seems that having a different
> > instance of the catalog for each app would be a little memory-wasting.
> > Should I keep it anyway ?
I don't see why your argument that different application instances can run
in different languages wouldn't apply to libraries just the same. While I'm
actually skeptical about the usefulness for different instances of the same
application, I can at least image that one could want to run two
applications using the same library in different languages.
That aside, I guess most libraries have a rather limited amount of
localized strings, which (due to the overhead for a areas) would probably
make any mechanism to use shared memory more expensive in the end.
Anyway, a relatively simple method of sharing catalog data would be to
mmap() the catalog file. Which only works, if the file data don't need
(much) further processing. If that's not the case, things get significantly
more complicated.
> > The second one :
> > Either way, each lib or add-on loaded in an application should register
> > to the be_locale_roster. An application does this implicitly by loading
> > a catalog, the be_app_catalog variable is set to point to it and
> > everything goes fine. But as we can (and will) have multiple add-ons
> > and libs in an application memory space, it is not possible to use a
> > single global variable for them. This was already attempted and does
> > not work. I see two solutions :
> >
> > A) Each lib/add-on has to handle its own catalog. I can see it being a
> > bit annoying because :
> > * It makes macros like B_TRANSLATE not possible to use, as they can't
> > be translated into something with a known variable name (each lib would
> > need to have his catalog in its own namespace toavoid conflicts)
> > * I'm not sure how to handle the loading and unloading of the catalog.
> > Each lib may have a different way to init, or even multiple ones, so it
> > may be difficult to ensure that the catalog is loaded only once, and
> > I'm not sure how to unload it either, as I don't think there is such
> > thing as a "library destructor".
> >
> > B) Provide some "catalog repository" in the locale kit, that is, each
> > lib would call GetNamedCatalog, then the catalog would get registered
> > in a map<name>(BCatalog) or something similar. A macro similar to
> > B_TRANSLATE, with the name as an additional parameter, could then be
> > used to fetch the catalog from there and translate a string. The
> > problem I see here :
> > * Lookup in a map can be expansive, especially if done each time a
> > string is displayed.
> > * It doesn't solve the problem of unloading the catalogs so there is a
> > risk of filling the memory with useless catalogs
> >
> > Which one is the best, do you think ?
In case you have missed it, I've proposed a solution for the library/add-on
catalogs in [1].
CU, Ingo
http://dev.haiku-os.org/ticket/6113#comment:5
Other related posts:
