On Sat, 4 Oct 2003 18:11:59 +0200 (CEST) Robert Vazan <[EMAIL PROTECTED]> wrote:
RV> > Boundaries would include all GUI calls. RV> RV> The same practice can be applied to wxWindows. I understand that wxWindows RV> is separate team and they won't cooperate with us. But we can still convert RV> Mahogany incrementally and switch wxWindows in one moment. wxWindows is hardly a separate team but this doesn't change anything: wxWindows is ok Unicode-wise, it's just M which isn't. RV> > All operations with wxString. And RV> > probably more. This would be just crazy. RV> RV> You get the same with Unicode build. Remember we have wxChar and wxString RV> (and wxTextFile) everywhere exactly for this reason. Mixed code would add RV> conversion calls, but it would remove switched types in converted areas. Sorry, I'm not sure I understand this? RV> I don't think that adding conversion function calls is that costly. We can RV> give them one-character codes to make them almost invisible. "Costly" as in programming time, not run-time performance. RV> > I don't think that converting to Unicode is that difficult. RV> RV> But then you can get errors on startup. For example, I just compiled RV> Mahogany against wxGtk2 and it crashes while trying to display first RV> message, complaining about fonts. Well, it's a bug in Mahogany quite probably... I've never used it with GTK2 yet. Also, if we use GTK2, we'd use Unicode build of it and not the ANSI one. RV> > Win9x doesn't support Unicode version of Win32 API natively. Recently, MS RV> > released MSLY (Layer for Unicode) which emulates it by doing what you say RV> > below. It is much better than before but it is unfortunately quite buggy. RV> RV> But wxWindows can do conversion internally just like that MSLY. If it RV> doesn't, we will convert at wxWindows interface. What for? This wouldn't work better than MSLU... Again, converting is *not* that simple. Look at all the time I spent fixing bugs in the new composer related to encodings. And it's still buggy :-( RV> But you still have to maintain all this in non-Unicode build and you have RV> to maintain non-Unicode build while Win9x and Gtk1.2 are around. No, if we switch to Unicode, we forget about ANSI build, of course. I don't have enough time to maintain both. For GTK I think it should be reasonable to start using GTK2, it is installed on 90% of Linux machines by now. For Win9x, we have MSLU in the short term and in longer term we can hope they're going to disappear too. RV> I really don't understand why Unicode application couldn't run on RV> non-Unicode platforms. Sure that mixing languages in one document would RV> not work, but that's just about all there is to it. In theory, this is how it should work. In practice it's a bit more complicated usually... Regards, VZ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
