Matt wrote: > I would like to suggest a mode of action to get UTF8 support complete. > My main issue is not knowing where to start and which places in the > source code were already touched. We agreed a long time ago to not > introduce a new string type, so here is what we could do: > > Any parameter that should take a text string should contain utf8 in its > name. For example, once we change > > Fl_Widget(int x, int y, int w, int h, const char *label) > > and *all* functions that depend on it, we can change the footprint to > > Fl_Widget(int x, int y, int w, int h, const char *label_utf8)
I don't think that this is very useful. *ALL* strings in FLTK 1.3 must be UTF-8 encoded. That's the goal we want to achieve. Thus, if we want to mark any parameter names by adding a prefix or suffix, we should only mark the _exceptions_. I.e. if there is a conversion or OS-specific function that take a "wide character" parameter, then we should mark this one with _wc or similar - if this is necessary at all. Otherwise we would have to change 99% of the parameter names. The same applies to the (doxygen) docs: We don't need to specify that a string must be UTF-8-encoded. However, we should document all exceptions. But since the user interface must all be UTF-8 anyway, this shouldn't be much work. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
