Georg Baum wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a hurry.
This back and forth conversion tp/from utf8 during this transition phase
is a real hassle.
In general yes, but in this case no. In this particular case we are talking
about format names. They never appear in a document, they only appear in
the GUI if somebody wants to edit them, and we have had support for ascii
strings in GUI forever,. I don't see that it will be dropped. I don't see
any reason why a format name should be converted to docstring.
It looks to me as if you want to convert almost everything to docstring.
That would have been better done with some global search/replace.
I really think we should have done just that. We are just complicating
our life for no real benefit. What's the problem if we use unicode
capable strings to handle ascii? This is just a container. If you want
we can force them to be ascii via well placed ASSERT.
The step
by step conversion only makes sense if you don't do it blindly but look at
each conversion. I already found problematic cases (e.g. where a file
contents is interpreted as UTF8 without knowing the file encoding).
I would have preferred the other way around. Convert everything and then
look at the remaining problems.
Taking this decision now will simplify and speed-up
greatly the transition. We also need quickly the operator that Georg is
working on (+=, streams, etc).
streams are working now, I'll send the final patch soon.
Very good!
Abdel.
