On środa 18 grudzień 2002 11:12 am, Andre Poenitz wrote: > On Wed, Dec 18, 2002 at 10:57:50AM -0500, Kuba Ober wrote: > > Not only shot, but possibly too wide as well. I don't think we really > > need 32 bits per character. Having 16 bits per character works fine in > > QString, so I presume that's all that's needed. > > 640k of RAM should be enough for everybody.
No doubt when we encounter some extraterrestrial civilization we may need many more characters than 64k (say 1/2 of that if we consider underutilized pages) ;-) Well, could anybody tell what doesn't fit into ucs2? Or, are there any unicode pages that are outside of ucs2? The reason I'm asking is that it would really make QString <-> basic_string<uint16_t> conversion very quick, and Lars would be happier not having to QString'ify whole LyX, methinks. Actually, I also think that sticking with std:: and boost:: in gui-independent stuff is a good idea. And then John would be happy since he wouldn't have to worry about basic_string to QString conversions being slow (if it matters at all). Another option would be to copy QString's sources from Qt, rename the class name to lyxstring, and just use that lyx-wide instead of std::basic_string. > 1.3.0 is almost finished. So I doubt this will happen. I'm worried about that. The question is whether 1.3.0's Qt frontentd is of any use as it is right now, due to how multiencoding stuff is (not) implemented right now. Disclaimer: I didn't look at the source, so I'm just repeating what behaviors have been reported on the list (and what John admitted to, as well ;-) Definitely `the LANG implies encoding' thing is very bad as it makes no sense in light of how X passes keysyms (they are language-independent and depend on modmap/keyboard only!) to the apps. Cheers, Kuba Ober
