On 2011-10-10 11:02, Denis Shelomovskij wrote:
They are in my commit:
http://hg.dsource.org/projects/dwt2/rev/536e43f63c81
in section
+++ b/org.eclipse.swt.win32.win32.x86/src/org/eclipse/swt/widgets/Text.d
Aha, ok.
And a few messages I had written to "doob" few months ago about that
commit. Some text from it cab be put into DWT wiki for developers.
I'll have a look at that.
----------
denis_sh wrote at 3:47 p.m. on 9 July 2011
...
It looks working good on Windows except Text widget sill doesn't support
UTF-8 and working a little on Linux: lots of segfaults when printing and
text editing and other bugs.
I have no idea how to contribute this project, because someone decided
to work internally with UTF-8 instead of UTF-16 and it causes tons of
bugs (on Windows and at least some on Linux) and it kills "easy future
merges". Encoding bugs in DWT are alive for many long years and are
looking hard to find and fix.
Worst of all original SWT knows almost nothing about UTF-16 surrogate
pairs ("almost", because nevertheless few fixes exists in the latest
versions) AND likes to call func(string, start, end) where end is the
last character index instead (no idea why they did it) an "index after
the last" as is customary and then suppose that the "index after the
last" is end+1. And SWT still has this bug.
But it become critical in DWT because UTF-8 sequences as against UTF-16
surrogate pairs are very common.
So I think DWT in it's current state doesn't worth all that hours of
fixing and testing. It should be just a DIRECT port of SWT, without
encoding conversion or it should has a big command of coders/testers to
find and fix all SWT and DWT bugs. Or I missed something?
----------
...
----------
denis_sh wrote at 10:26 p.m. on 9 July 2011
Last paragraph...
If I've fixed almost all encoding bugs in Win32 version (except Text
widget), than it is no problem. I really hope such is the case. But I'm
afraid that lots of same bugs are in other modules too and it sounds
very terrible. I think it is a good idea to fix SWT encoding bugs but we
haven't enough people. Years of bugs are self explanatory.
To tell the truth, I'm just very tired of fixing encoding problems.
----------
denis_sh wrote at 10:22 a.m. on 10 July 2011
A bit more about "easy future merges". Let's suppose SWT porting is
done. And now he want to port JFace, e.g. Let's than suppose it is a
call to swt.widgets.Text.getText (int start, int end) somewhare in JFace
and the call is like text.getText (0, s.length - 1). How should we find
that call? IMHO, the good approach is "it works if compiles". So we are
to rename getText to DWTgetText e.g. and manually explore every
compilation error.
In conclusion, SWT porting in not done and such situation can be in SWT
itself.
----------
...
----------
denis_sh wrote at 1:04 p.m. on 10 July 2011
Yes, it is really hard to find a suggestion in my posts. Because I don't
know it.
More precisely I don't see any fast solution and don't want to work for
a long one.
DWT now partially works, so let it be. Until someone will find a good
solution and time to make a reality.
Oh, yeah, this mess again. I guess UTF-8 was chosen because it's the
default string type for D. Using UTF-16 would probably be easier, at
least for the developers porting the code.
--
/Jacob Carlborg
