[wxPython-dev] 20060711 test build uploaded

[Robin Dunn]

jmf wrote:
>  > Sorry, I forgot to write something about that.  I've updated the
>  > automated build scripts to be able to either build just the Unicode
>  > version or both ANSI and Unicode.  The eventual goal is to just build
>  > and distribute the Unicode version and I thought that the 2.7 series
>  > might be a good time to at least make it possible.  It also reduces the
>  > full build time by a few hours, so it is especially nice for the preview
>  > builds.
> 
> I was a little bit jittering when I read this. In the last times I toyed
> a lot with with the unicode version. I had no too much problems with the
> unicode version if I except the StyledTextCtrl which is, in my mind, really
> the bottleneck.
> I attempted to write a new class, a derived class of the StyledTextCtrl,
> which is agnostic in respect to the unicode/ansi version, and failed.
> If it is possible to overwrite some methods, some other methods like
> GetCharAt() are impossible to handle. More or less, all the methods
> related to the caret position or the char position are difficult to
> handle.
> 
> I have updated the regulex application, see the screenshot,
> http://www.chez.com/spinecho/pyregulex/pagregulex.html .
> Porting such an application to the unicode version is practically
> impossible.

What exactly is the problem?  Is it that the character positions don't 
line up with the internal document because of using utf-8 internally? 
We should be able to come up with a way to either fix that or workaround it.

BTW, a year or so back I added methods to the STC class to get and set 
text as utf-8?  Does that help?

> 
> Just out of curiosity, have you any idea about the number of 
> unicode/ansi downloaded versions or users ?

It depends on the platform.  Some are about 50/50, and are close enough 
that it leads me to believe that it is due to most people downloading 
both versions so they would probably be okay having just one as long as 
the apps they are using would work.  For other platforms it is about a 
3-1 unicode-ansi ratio.  Also, nearly all of the linux distros that I 
know of that provide wxPython packages already are only offering the 
unicode build.

>  From the changes.html doc, I was very pleased to read this:
> 
> wx.DC.BeginDrawing and EndDrawing have been deprecated in the C++ code, 
> so since they never really did anything before they are now just empty 
> stubs in wxPython.
> 
> I always dropped these from my code and I never had any problems. :-)

Personally I think it is unfortunate they were dropped.  It would have 
been a great way to implement double buffering for only those platforms 
and DC types where it makes sense and let the drawing go strait through 
in other situations (like on OSX or in wx.PrinterDC for example.)

-- 
Robin Dunn
Software Craftsman
http://wxPython.org  Java give you jitters?  Relax with wxPython!