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

[Denis Shelomovskij]

08.10.2011 17:17, Jacob Carlborg пишет:
> On 2011-10-08 08:49, Denis Shelomovskij wrote:
>> 07.10.2011 9:19, Jacob Carlborg пишет:
>>> On 2011-10-07 04:52, Sam Hu wrote:
>>>> Jacob Carlborg Wrote:
>>>>
>>>>> On 2011-10-03 04:29, Sam Hu wrote:
>>>>>> Jacob Carlborg Wrote:
>>>>>>
>>>>>>> On 2011-09-29 09:55, raojm wrote:
>>>>>>>> DWT2 cannot compile right on 64Bit Linux Or Windows with DMD2.053
>>>>>>>> DMD2.054
>>>>>>>> DMD2.055, Because of .length type is ulong on 64Bit system.
>>>>>>>
>>>>>>> Only 32bit platforms are ported in DWT. It does not work on 64bit
>>>>>>> platforms.
>>>>>>>
>>>>>>> --
>>>>>>> /Jacob Carlborg
>>>>>> May I ask where the latest package is?Thanks.
>>>>>>
>>>>>
>>>>> There are no pre-compiled packages.
>>>>>
>>>>> Source code: http://hg.dsource.org/projects/dwt2
>>>>> Project page: http://www.dsource.org/projects/dwt
>>>>>
>>>>> --
>>>>> /Jacob Carlborg
>>>> Thanks.Then is there any way to support utf8 characters in Text
>>>> widget,say Chinese characters?
>>>
>>> It should work. I've tested UTF8 characters outside the ASCII table but
>>> not Chinese characters. If it doesn't work please file a bug at:
>>> http://www.dsource.org/projects/dwt/newticket
>>>
>>
>> About win32 version:
>> widgets.Text doesn't support UTF-8 (I have added two FIXME notes in it's
>> source, and it was at first glance). Use widgets.StyledText instead.
>>
>> Linux version:
>> Still unstable. I haven't tested it yet.
>
> Could you report a ticket please. Or can I pull from your repository?
>

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

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.

----------
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.