> Maybe it's easier to have an fl_wcwidth.c wrapper so that fl_wcwidth()
> is defined with Fl_ucs_t for the outside world, and subverts wchar_t
> internally by doing:
>
> #define wchar_t unsigned
> #include "wcwidth.c"
>
> There are things in Xutf8.h that use int, and some unsigned int.
> Do they all need to be checked too?
I had hoped to be able to use Markus Kuhn's wcwidth.c file completely
unchanged, but now that I look at it, I think it will need a couple
of tweaks to work on all platforms. [*]
I'm working on Linux only, and was able to create a hack for STR-2158
to demonstrate proof of concept, but now I would like to start putting
things under subversion, but would like advice on location.
I was originally considering having the following:
src/xutf8/mk_wcwidth.c
/* a simple rename of MK's wcwidth.c */
src/xutf8/fl_wcwidth.c
#include "mk_wcwidth.c"
int fl_wcwidth(unsigned int ucs) {
return mk_wcwidth(ucs);
}
FL/fl_utf8.h
/** doxygen comment */
FL_EXPORT int mk_wcwidth(unsigned int ucs);
but then it struck me that there are no existing fl_* files in xutf8.
If there's a logic to how the files are partitioned, I can't see it.
So, question 1: is there a better location or way of organising this?
and question 2: which of the multiple CMakeList.txt and Makefiles at
the different levels really need to be updated to get this to build?
Do I need to add this into Matt's new fluid generation handling? The
STR-2158 hack used a direct #include wcwidth,c for simplicity.
I have to admit I'm a bit confused on the current state of play here.
[*] Some thoughts on tweaks:
I only have a Linux box, and this first step seems to work without
obvious problem, but there's still the issue of wchar_t on Win32.
So we probably need to remove the #include wchar.h from MK's original
file and add a typedef wchar_t unsigned int.
Also, by adding forward declarations of MK's routines as 'static'
before the #include "mk_wcwidth.c" line we can ensure that they do
not leak out into the global namespace and cause problems.
Cheers
D.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
