> Yes. I suggest Fl types for strings and individual characters. > Currently I have: > > Fl_String: basically typedef'd to "char*" (UTF-8 encoded > unicode), but > on WinCE, it would be WCHAR* > Fl_Char: a single Unicode character (32-bit), or WCHAR on CE
I think this is probably right for our string and char types, but I didn't do this... I couldn't decide what the right underlying types would be. For example, should we use the win32 WCHAR type for Fl_Char on all the MS platforms, that sort of thing? Would that work better for the underlying MS API's? Also, there's something odd about the "native" types on OSX (I can't remember the details now, I think I was expecting them to be 32-bit but a lot of them seem to actually be 16-bit or etc...) > Fl_Shortcut: a Unicode character pls flags for modifier keys (alt, > ctrl, etc.) OK, I think I like this idea - the underlying type will be a struct/class comprising a Fl_Char and a flags word? Something like that? > Furthermore, we need to manage fonts > Fl_Font: 32 bit index (or "enum", just like it is) into the font table I think I did this... > and we need to manage graphics coordinates: > Fl_Coord: and this one is tricky! Currently we use 32bit in the > interface and 16bit internally. Going 32bit is obvious, but is that > sufficient? To look good, text must be positioned at subpixel > resolution! Would it make sense then to give all coordinates in > "float"? Or even "double"? Or we can continue to > differentiate between > window coordinates and quick drawing (32 bit integer) and "slow" > graphics going through the matrix and text (float). Does that > mean we > will need two types then: Fl_CoordI and Fl_CoordF? This is a tricky one. For now, I just changed the co-ord size to 32-bit, but as you point out, that doesn't really address the sub-pixel positioning, which will probably become more common as more systems deal with anti-aliasing and etc too... Having float co-ords feels wrong to me, but I think that's just because it is unfamiliar! > > That is all we will be doing, plus allowing for basic Unicode text > entry of course. We can not provide a full fledged bidirectional > universally language-compatible word processing widget. Does anybody have experience with SCIM/XIM, and it's equivalents on winXX and OSX? I guess we need to play nice with these things for Unicode text entry, but I really don't have much experience of their use. -- Ian SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
