Abdelrazak Younes wrote: > Georg Baum wrote: >> Abdelrazak Younes wrote: >> >>> Dear all, >>> >>> I think we are very close to a 1.5.0 release, >> >> Not really. > > 1.5.0 doesn't have to be perfect WRT unicode.
No, but as I stated several times I don't want any unciode related regression in 1.5.0. > I reckon that a 1.5.0 > working fine for the latin world (and RTL language) is good enough for > now. CJK and advanced input method can wait for 1.5.1. Input method yes, but not a very basic CJK support, because adding that would be a file format change, and not having it would be a regression. See bug 3043 for details. >>> 3203 possible to import non-utf8 text files >>> >>> Seems difficult to do internally. I think an external python solution >>> would be nice. >> >> Very easy to do internally with the iconv_codecvt_facet. The difficult >> question is how to do the UI. > > I seem to remember a python program that can detect encoding and convert > to utf8 with a good reliability. If this works, maybe we don't need to > do this internally? And so we don't need to ask the user a question he > will probably don't know the answer... I don't like that, since it will not work by definition. I prefer to have control over the chosen encoding. BTW, this bug is not too important for me. You can always convert files to utf8 e.g. with recode, and you can even create a special import format if you like. >>> 3288 event handler crash >>> >>> Don't know, don't seem to happen frequently (never seen it). >> >> Please read my comment. The particular reason for this crash was solved, >> but we must ensure that we don't throw an exception in the event handler. >> Otherwise this has the potential for real dataloss. > > So, could a "catch (...)" in GuiApplication::event() solve the issue? Almost. Please read the comments of the bug. The qt error message tells how to solve that, and I wrote somewhere that the normal ermegency save procedure should be started. in the catch block. Georg
