DWT2 now looks working on Windows (except Text widget doesn't

[Jacob Carlborg]

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