wxPython 2.5.1.0p8 Preview

Hi All,

The next preview build of wxPython is now available at

http://starship.python.net/crew/robind/wxPython/preview/2.5.1.0p8/

There are not very many real visible changes in this preview since the
last one, but there have been a number of behind the scenes changes,
changes to track new modifications to the C++ lib, and of course lots
of bug fixes. A few of the more notable things:

* Menu and toolbar items can now be given an ID of -1 and they will
   then generate a new ID for themselves, similar to how windows do.
   To accommodate this the value of wx.ID_SEPARATOR was changed to -2,
   (it was -1.) The various methods for adding items to a wx.Menu will
   now return a reference to the wx.MenuItem (toolbar already did this)
   and so you can use the item for binding events without having to
   track IDs. For example, instead of this::

     menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
     self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)

you can do this::

     item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
     self.Bind(wx.EVT_MENU, self.OnExit, item)

or even this::

     item = menu.Append(-1, "E&xit", "Terminate the App")
     self.Bind(wx.EVT_MENU, self.OnExit, item)

* Updated the AnalogClockWindow with many enhancements from
   E. A. Tacão.

* wxMac now has wx.ToggleButton!

* wx.stc.StyledTextCtrl has been updated to version 1.58 of Scintilla.

* On the wx.stc.StyledTextCtrl performance issues on wxMac: I wasn't
   able to find a way to quickly measure the fully antialiased fonts
   with enough accuracy, so instead I reimplemented the current
   algorithm in a slightly more efficient manner. Since it is still
   something that will take O(n^2) time I've added a SetUseAntiAliasing
   method (and GetUseAntiAliasing too) that will turn off the use of
   antialiased fonts in the wxSTC, allowing it to bypass the slow text
   measuring routines and use the fast and simple one instead. By
   default the setting is turned off. When run on OSX The Py* apps
   have a new item on the Options menu for controlling this setting if
   you would like to experiment with it.

* Lot's of docstrings added. A *ton* more to go. Riaan has sent me a
   script he has started on for converting the metadata to reference
   docs, but I haven't been able to spend much time on furthering it
   yet. Consequently the C++ docs are still included with this
   preview, and probably will be for the release as well, but we are
   definitely on the road to making that not be necessary any more.
   I've been real pleased with the modifications I made to SWIG to
   facilitate this work, it is progressing well.

···

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

Hi Robin,

The only issues I have to report on OS X are that the Grid_MegaExample crashes and that MimeTypesManager spits out a traceback and leaves gunk all over the wxNotebook screen (don't know why this is...), and of course the button fonts look a little too big now. (Though I've followed this on wx-dev and I think Stefan has already committed a fix.)

Otherwise, things are looking pretty good. =) Nice to see wxToggleButton working and wxSTC is in some cases faster with Anti-aliasing turned off. (Though it still seems slow in wxSTC demo1.) How are you drawing the text, BTW, for the wxSTC? Are you just using wxDC methods?

Thanks,

Kevin

···

On Feb 27, 2004, at 11:11 AM, Robin Dunn wrote:

Hi All,

The next preview build of wxPython is now available at

http://starship.python.net/crew/robind/wxPython/preview/2.5.1.0p8/

There are not very many real visible changes in this preview since the
last one, but there have been a number of behind the scenes changes,
changes to track new modifications to the C++ lib, and of course lots
of bug fixes. A few of the more notable things:

* Menu and toolbar items can now be given an ID of -1 and they will
  then generate a new ID for themselves, similar to how windows do.
  To accommodate this the value of wx.ID_SEPARATOR was changed to -2,
  (it was -1.) The various methods for adding items to a wx.Menu will
  now return a reference to the wx.MenuItem (toolbar already did this)
  and so you can use the item for binding events without having to
  track IDs. For example, instead of this::

    menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
    self.Bind(wx.EVT_MENU, self.OnExit, id=wx.ID_EXIT)

you can do this::

    item = menu.Append(wx.ID_EXIT, "E&xit", "Terminate the App")
    self.Bind(wx.EVT_MENU, self.OnExit, item)

or even this::

    item = menu.Append(-1, "E&xit", "Terminate the App")
    self.Bind(wx.EVT_MENU, self.OnExit, item)

* Updated the AnalogClockWindow with many enhancements from
  E. A. Tacão.

* wxMac now has wx.ToggleButton!

* wx.stc.StyledTextCtrl has been updated to version 1.58 of Scintilla.

* On the wx.stc.StyledTextCtrl performance issues on wxMac: I wasn't
  able to find a way to quickly measure the fully antialiased fonts
  with enough accuracy, so instead I reimplemented the current
  algorithm in a slightly more efficient manner. Since it is still
  something that will take O(n^2) time I've added a SetUseAntiAliasing
  method (and GetUseAntiAliasing too) that will turn off the use of
  antialiased fonts in the wxSTC, allowing it to bypass the slow text
  measuring routines and use the fast and simple one instead. By
  default the setting is turned off. When run on OSX The Py* apps
  have a new item on the Options menu for controlling this setting if
  you would like to experiment with it.

* Lot's of docstrings added. A *ton* more to go. Riaan has sent me a
  script he has started on for converting the metadata to reference
  docs, but I haven't been able to spend much time on furthering it
  yet. Consequently the C++ docs are still included with this
  preview, and probably will be for the release as well, but we are
  definitely on the road to making that not be necessary any more.
  I've been real pleased with the modifications I made to SWIG to
  facilitate this work, it is progressing well.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwindows.org

Kevin Ollivier wrote:

Hi Robin,

The only issues I have to report on OS X are that the Grid_MegaExample crashes and that MimeTypesManager spits out a traceback and leaves gunk all over the wxNotebook screen (don't know why this is...),

Thanks. I'll take a look.

and of course the button fonts look a little too big now. (Though I've followed this on wx-dev and I think Stefan has already committed a fix.)

Yeah, I think that was checked in after I started doing the builds. But IIRC it is still using the large font, (which I understand is the "more correct" font to use accoring to the HIG,) the fix just reduced the amount of extra space on the sides of the button. The true "fix" will be adding options allowing the app to choose which set of UI fonts it will use.

Otherwise, things are looking pretty good. =) Nice to see wxToggleButton working and wxSTC is in some cases faster with Anti-aliasing turned off. (Though it still seems slow in wxSTC demo1.) How are you drawing the text, BTW, for the wxSTC? Are you just using wxDC methods?

Yep, see the methods of the SurfaceImpl class in http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/src/stc/PlatWX.cpp?rev=1.56&content-type=text/vnd.viewcvs-markup

Surface is an abstract interface to drawables that Scintilla uses for insulating itself from the various platforms it supports. (In our case the platform is wxWidgets.) The change I mentioned is the addition of wxDC::GetPartialTextExtents and using it in SurfaceImpl::MeasureWidths. For wxMac, wxDC::GetPartialTextExtents will use a single call to the MeasureText API when the font being measured is not antialiased. But when antialiasing is turned on it has to remeasure (using GetThemeTextDimensions) from the begining of the string for every character in the string to get a proper measurement that accounts for fractional widths of individual characters. (Although it is still a pixel off sometimes. It should probably round values instead of truncating...)

···

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

Hi Robin,

Kevin Ollivier wrote:

Hi Robin,
The only issues I have to report on OS X are that the Grid_MegaExample crashes and that MimeTypesManager spits out a traceback and leaves gunk all over the wxNotebook screen (don't know why this is...),

Thanks. I'll take a look.

and of course the button fonts look a little too big now. (Though I've followed this on wx-dev and I think Stefan has already committed a fix.)

Yeah, I think that was checked in after I started doing the builds. But IIRC it is still using the large font, (which I understand is the "more correct" font to use accoring to the HIG,) the fix just reduced the amount of extra space on the sides of the button. The true "fix" will be adding options allowing the app to choose which set of UI fonts it will use.

I double-checked Apple's HIG and it does say to use the 'normal' size. So I guess I should get used to them! =)

Otherwise, things are looking pretty good. =) Nice to see wxToggleButton working and wxSTC is in some cases faster with Anti-aliasing turned off. (Though it still seems slow in wxSTC demo1.) How are you drawing the text, BTW, for the wxSTC? Are you just using wxDC methods?

Yep, see the methods of the SurfaceImpl class in http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/src/stc/PlatWX.cpp?rev=1.56&content-type=text/vnd.viewcvs-markup

Surface is an abstract interface to drawables that Scintilla uses for insulating itself from the various platforms it supports. (In our case the platform is wxWidgets.) The change I mentioned is the addition of wxDC::GetPartialTextExtents and using it in SurfaceImpl::MeasureWidths. For wxMac, wxDC::GetPartialTextExtents will use a single call to the MeasureText API when the font being measured is not antialiased. But when antialiasing is turned on it has to remeasure (using GetThemeTextDimensions) from the begining of the string for every character in the string to get a proper measurement that accounts for fractional widths of individual characters. (Although it is still a pixel off sometimes. It should probably round values instead of truncating...)

Just a guess based on some googling, but have you tried calling the FontManager's SetFractEnable(TRUE) function before calling MeasureText? More info is here:

http://developer.apple.com/documentation/Carbon/Reference/Font_Manager/fm_ref_chap/function_group_10.html

Thanks,

Kevin

···

On Feb 27, 2004, at 1:52 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

Yeah, I think that was checked in after I started doing the builds. But IIRC it is still using the large font, (which I understand is the "more correct" font to use accoring to the HIG,) the fix just reduced the amount of extra space on the sides of the button. The true "fix" will be adding options allowing the app to choose which set of UI fonts it will use.

I double-checked Apple's HIG and it does say to use the 'normal' size. So I guess I should get used to them! =)

Does it say anything about the other controls or just buttons. That part of the recent change confuses me. I would think that all the controls should be changed.

Otherwise, things are looking pretty good. =) Nice to see wxToggleButton working and wxSTC is in some cases faster with Anti-aliasing turned off. (Though it still seems slow in wxSTC demo1.) How are you drawing the text, BTW, for the wxSTC? Are you just using wxDC methods?

Yep, see the methods of the SurfaceImpl class in http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/src/stc/ PlatWX.cpp?rev=1.56&content-type=text/vnd.viewcvs-markup

Surface is an abstract interface to drawables that Scintilla uses for insulating itself from the various platforms it supports. (In our case the platform is wxWidgets.) The change I mentioned is the addition of wxDC::GetPartialTextExtents and using it in SurfaceImpl::MeasureWidths. For wxMac, wxDC::GetPartialTextExtents will use a single call to the MeasureText API when the font being measured is not antialiased. But when antialiasing is turned on it has to remeasure (using GetThemeTextDimensions) from the begining of the string for every character in the string to get a proper measurement that accounts for fractional widths of individual characters. (Although it is still a pixel off sometimes. It should probably round values instead of truncating...)

Just a guess based on some googling, but have you tried calling the FontManager's SetFractEnable(TRUE) function before calling MeasureText?

Yes I tried it. It had no effect at all (in my limited test cases anyway) on MeasureText. Looking closer at the font now used in wxSTC by default I see that it is doing some AA, just not as much as wxMac does by default. My guess is that since wxMac is using DrawThemeTextBox when AA is turned on in wxDC::DoDrawText, and GetThemeTextDimensions for measuring, that the FontManager APIs don't apply. Unfortunatly there doesn't seem to be a MeasureText equivallent in the Theme APIs.

···

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

Robin Dunn wrote:

Kevin Ollivier wrote:

Yeah, I think that was checked in after I started doing the builds. But IIRC it is still using the large font, (which I understand is the "more correct" font to use accoring to the HIG,) the fix just reduced the amount of extra space on the sides of the button. The true "fix" will be adding options allowing the app to choose which set of UI fonts it will use.

I double-checked Apple's HIG and it does say to use the 'normal' size. So I guess I should get used to them! =)

Does it say anything about the other controls or just buttons. That part of the recent change confuses me. I would think that all the controls should be changed.

Ah, I see Stefan has already mentioned that it will be done.

···

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

Well so far I haven't been able to get PythonCard to run with the new build
which appears to be an issue with the readPyValFromConfig function in
STCStyleEditor.py. However, since this works fine in 2.4.2.4 and 2.5.1.0p7 I
suspect it has more to do another app initialization problem. I'm
investigating, but so far I'm stumped. Does the SyntaxError message below
make any sense to anyone; I'm recovering from the flu so maybe my brain is
just broke?!

C:\python\PythonCardPrototype>samples\minimal\minimal.py -d
Traceback (most recent call last):
  File "C:\python\PythonCardPrototype\samples\minimal\minimal.py", line 17,
in ?

    app = model.PythonCardApp(Minimal)
  File "C:\python\PythonCardPrototype\model.py", line 238, in __init__
    wx.wxApp.__init__(self, 0)
  File "C:\Python23\Lib\site-packages\wx\core.py", line 5040, in __init__
    self._BootstrapApp()
  File "C:\Python23\Lib\site-packages\wx\core.py", line 4791, in
_BootstrapApp
    return _core.PyApp__BootstrapApp(*args, **kwargs)
  File "C:\python\PythonCardPrototype\model.py", line 337, in OnInit
    self.showShell() # KEA pyCrust support
  File "C:\python\PythonCardPrototype\model.py", line 294, in showShell
    parentApp=self)
  File "C:\python\PythonCardPrototype\debug.py", line 555, in __init__
    STCStyleEditor.initSTC(parentApp.shell, configfile, 'python')
  File "C:\python\PythonCardPrototype\STCStyleEditor.py", line 1161, in
initSTC
    (cfg, commonDefs, styleIdNames, styles, predefStyleGroupNames,
  File "C:\python\PythonCardPrototype\STCStyleEditor.py", line 1098, in
initFrom
Config
    commonStyleIdNames = readPyValFromConfig(cfg, 'common.styleidnames')
  File "C:\python\PythonCardPrototype\STCStyleEditor.py", line 1073, in
readPyVa
lFromConfig
    return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
  File "<string>", line 1

    ^
SyntaxError: unexpected EOF while parsing

Anyway, I thought I might find some clues by seeing if Boa had the same
problem even though my version of STCStyleEditor.py is slightly different,
so I updated Boa from cvs and gave it a try. Boa fails because wxSP_FULLSASH
is not defined.

C:\mypython\boa>boa.py
Starting Boa Constructor v0.2.8
importing wxPython
reading user preferences
Traceback (most recent call last):
  File "C:\mypython\boa\Boa.py", line 231, in ?
    import Preferences, Utils, About
  File "C:\mypython\boa\Preferences.py", line 130, in ?
    execfile(file)
  File "C:\cvshome\.boa-constructor\prefs.rc.py", line 25, in ?
    splitterStyle = wxCLIP_CHILDREN | wxSP_LIVE_UPDATE | \
NameError: name 'wxSP_FULLSASH' is not defined

ka

Hi Robin,

[snip]

Yep, see the methods of the SurfaceImpl class in http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/contrib/src/stc/ PlatWX.cpp?rev=1.56&content-type=text/vnd.viewcvs-markup

Surface is an abstract interface to drawables that Scintilla uses for insulating itself from the various platforms it supports. (In our case the platform is wxWidgets.) The change I mentioned is the addition of wxDC::GetPartialTextExtents and using it in SurfaceImpl::MeasureWidths. For wxMac, wxDC::GetPartialTextExtents will use a single call to the MeasureText API when the font being measured is not antialiased. But when antialiasing is turned on it has to remeasure (using GetThemeTextDimensions) from the begining of the string for every character in the string to get a proper measurement that accounts for fractional widths of individual characters. (Although it is still a pixel off sometimes. It should probably round values instead of truncating...)

Just a guess based on some googling, but have you tried calling the FontManager's SetFractEnable(TRUE) function before calling MeasureText?

Yes I tried it. It had no effect at all (in my limited test cases anyway) on MeasureText. Looking closer at the font now used in wxSTC by default I see that it is doing some AA, just not as much as wxMac does by default. My guess is that since wxMac is using DrawThemeTextBox when AA is turned on in wxDC::DoDrawText, and GetThemeTextDimensions for measuring, that the FontManager APIs don't apply. Unfortunatly there doesn't seem to be a MeasureText equivallent in the Theme APIs.

Hmmm... Thinking about it more, I don't think DrawThemeTextBox is really the best tool for the job here. It's mainly for simple drawing, IIUC, like static text controls, and Apple's docs say it isn't fully Unicode-compliant. Have you looked at ATSUI to see if it provides the functions you (and maybe wxDC <wink, wink>) need? =)

http://developer.apple.com/documentation/Carbon/Reference/ATSUI_Reference/index.html

There's a section on "Obtaining Text Metrics", which may be what you're looking for.

Thanks,

Kevin

···

On Feb 27, 2004, at 3:06 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

Hmmm... Thinking about it more, I don't think DrawThemeTextBox is really the best tool for the job here. It's mainly for simple drawing, IIUC, like static text controls, and Apple's docs say it isn't fully Unicode-compliant. Have you looked at ATSUI to see if it provides the functions you (and maybe wxDC <wink, wink>) need? =)

http://developer.apple.com/documentation/Carbon/Reference/ ATSUI_Reference/index.html

There's a section on "Obtaining Text Metrics", which may be what you're looking for.

Yep. I looked at it, but with just trying to get the measurements. I didn't want to mess with wxDC::DrawText without fully understanding why it is the way it is.

I wouldn't mind if somebody changes DrawText and the rest of wxDC to use ATSUI, (it's already used in DrawRotatedText) but it probably won't be me. ATSUI is extremly complex... I had a hard time understanding the docs about it and never did get any measurements that were even close to what I was expecting. For example, Measure text gives something like [0, 8, 12, 22, 28, 37] for one of the series of characters I was testing with, and with ATSUI all I could ever get was [0, 6, 12, 12, 12, 12] and I tried it with a few different APIs and approaches. I probably just didn't set things up right...

···

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

Kevin Altis wrote:

    commonStyleIdNames = readPyValFromConfig(cfg, 'common.styleidnames')
  File "C:\python\PythonCardPrototype\STCStyleEditor.py", line 1073, in
readPyVa
lFromConfig
    return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
  File "<string>", line 1

    ^
SyntaxError: unexpected EOF while parsing

Invalid syntax in the config file maybe?

Anyway, I thought I might find some clues by seeing if Boa had the same
problem even though my version of STCStyleEditor.py is slightly different,
so I updated Boa from cvs and gave it a try. Boa fails because wxSP_FULLSASH
is not defined.

Yeah, Riaan knows about it.

···

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

From: Robin Dunn

Kevin Altis wrote:
> commonStyleIdNames = readPyValFromConfig(cfg, 'common.styleidnames')
> File "C:\python\PythonCardPrototype\STCStyleEditor.py", line 1073, in
> readPyVa
> lFromConfig
> return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
> File "<string>", line 1
>
> ^
> SyntaxError: unexpected EOF while parsing

Invalid syntax in the config file maybe?

Except that there is no error when running under 2.4.2.4 or 2.5.0.1p7. I
simply swap to p8 and I have the error above.

ka

Hi Robin,

Kevin Ollivier wrote:

Hmmm... Thinking about it more, I don't think DrawThemeTextBox is really the best tool for the job here. It's mainly for simple drawing, IIUC, like static text controls, and Apple's docs say it isn't fully Unicode-compliant. Have you looked at ATSUI to see if it provides the functions you (and maybe wxDC <wink, wink>) need? =)
http://developer.apple.com/documentation/Carbon/Reference/ ATSUI_Reference/index.html
There's a section on "Obtaining Text Metrics", which may be what you're looking for.

Yep. I looked at it, but with just trying to get the measurements. I didn't want to mess with wxDC::DrawText without fully understanding why it is the way it is.

Might be worth asking Stefan so we know what the options are here.

I wouldn't mind if somebody changes DrawText and the rest of wxDC to use ATSUI, (it's already used in DrawRotatedText) but it probably won't be me. ATSUI is extremly complex... I had a hard time understanding the docs about it and never did get any measurements that were even close to what I was expecting. For example, Measure text gives something like [0, 8, 12, 22, 28, 37] for one of the series of characters I was testing with, and with ATSUI all I could ever get was [0, 6, 12, 12, 12, 12] and I tried it with a few different APIs and approaches. I probably just didn't set things up right...

Actually, in researching more about using ATSUI I was able to find someone who made a port of Scintilla to OS X, and used ATSUI to do it. Download link can be found from here:

http://mailman.lyra.org/pipermail/scintilla-interest/2003-May/002756.html

Maybe at least worth a look. I'm pretty swamped right now with a Sociology paper (I think I'd rather be figuring out ATSUI... :wink: and the other patch I'm working on right now, so I don't have much time to look at this myself right now, but when things die down I might be able to take a closer look at it. I eventually want to use wxSTC with wxMozilla (and Unicode) in the future, and to do this properly probably means upgrading DoDrawText at some point.

Thanks,

Kevin

···

On Feb 27, 2004, at 4:52 PM, Robin Dunn wrote:

From: Kevin Altis [mailto:altis@semi-retired.com]

> From: Robin Dunn
>
> Kevin Altis wrote:
> > commonStyleIdNames = readPyValFromConfig(cfg,
'common.styleidnames')
> > File "C:\python\PythonCardPrototype\STCStyleEditor.py",
line 1073, in
> > readPyVa
> > lFromConfig
> > return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
> > File "<string>", line 1
> >
> > ^
> > SyntaxError: unexpected EOF while parsing
>
> Invalid syntax in the config file maybe?

Except that there is no error when running under 2.4.2.4 or 2.5.0.1p7. I
simply swap to p8 and I have the error above.

Well I still don't understand what changed between 2.5.1.0p7 and 2.5.1.0p8
that causes this to fail, but I'm assuming it is related to another part of
the initialization and I just haven't found it yet. My version of
STCStyleEditor.py still has "import *" remnants so it is more difficult to
trace what is going on.

In the short term, my fix is to simply do a try/except and return an empty
dictionary when it fails. This allows PythonCard apps to startup even if
they use the shell... There might be some other problem from returning an
empty dictionary as far as wxSTC styles are concerned, so this isn't a real
solution, but everything seems to work correctly now.

def readPyValFromConfig(conf, name):
    try:
        temp = eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
        return temp
    except:
        return {}

Riaan's version of the function in boa cvs is different than mine but still
fails. I'm not sure what he is expecting to get from stc.__dict__, doing
this sort of eval seems pretty weird. Anyway as far as the failure is
concerned, this makes me think something changed in wxPython.stc between
2.5.1.0p7 and 2.5.1.0p8.

def readPyValFromConfig(conf, name):
    return eval(conf.Read(name).replace('\r\n', '\n')+'\n', stc.__dict__)

ka

Kevin Altis wrote:

From: Kevin Altis [mailto:altis@semi-retired.com]

From: Robin Dunn

Kevin Altis wrote:

   commonStyleIdNames = readPyValFromConfig(cfg,

'common.styleidnames')

File "C:\python\PythonCardPrototype\STCStyleEditor.py",

line 1073, in

readPyVa
lFromConfig
   return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
File "<string>", line 1

   ^
SyntaxError: unexpected EOF while parsing

Invalid syntax in the config file maybe?

Except that there is no error when running under 2.4.2.4 or 2.5.0.1p7. I
simply swap to p8 and I have the error above.

Well I still don't understand what changed between 2.5.1.0p7 and 2.5.1.0p8
that causes this to fail,

wxFileConfig has been changed to allow spaces in keynames. So now if you try to read "key" but the config file has key = value then there will be no match and the default value will be returned. The eval was failing because it is apparently a syntax error to try and eval('\n')

I'll check with wx-dev to see if it should still ignore spaces at the end of the key, but in the meantime you can workaround it by removing the spaces before the '=' in the config file.

···

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

Ah, thanks for the explanation. It makes more sense now that I see Riaan is using one of those evil undocumented wxWindows classes :wink: Since I don't know exactly what it is supposed to do it is hard to know whether it would be better to use a Python standard lib equivalent or whether one even exists. I also see now that the spaces in the key-value line "common.styleidnames = {..." in my own config file is what caused the choke. Things are even worse in what Boa is trying to process.

Also, I just noticed that the copy of STCStyleEditor.py included in wxPython/samples/StyleEditor is version 1.3 from 2003/03/25 so maybe that should be updated for the next wxPython build based on whatever is being used by the current Boa.

ka

···

On Mar 1, 2004, at 1:00 PM, Robin Dunn wrote:

Kevin Altis wrote:

From: Kevin Altis [mailto:altis@semi-retired.com]

From: Robin Dunn

Kevin Altis wrote:

   commonStyleIdNames = readPyValFromConfig(cfg,

'common.styleidnames')

File "C:\python\PythonCardPrototype\STCStyleEditor.py",

line 1073, in

readPyVa
lFromConfig
   return eval(string.replace(conf.Read(name), '\r\n', '\n')+'\n')
File "<string>", line 1

   ^
SyntaxError: unexpected EOF while parsing

Invalid syntax in the config file maybe?

Except that there is no error when running under 2.4.2.4 or 2.5.0.1p7. I
simply swap to p8 and I have the error above.

Well I still don't understand what changed between 2.5.1.0p7 and 2.5.1.0p8
that causes this to fail,

wxFileConfig has been changed to allow spaces in keynames. So now if you try to read "key" but the config file has key = value then there will be no match and the default value will be returned. The eval was failing because it is apparently a syntax error to try and eval('\n')

I'll check with wx-dev to see if it should still ignore spaces at the end of the key, but in the meantime you can workaround it by removing the spaces before the '=' in the config file.

Robin,

I tried to build the sorce rpm on a REdhat 7.2 system, and it failed with this message:

/usr/bin/ld: ../../../lib/libwx_gtkd_adv-2.5.so: indirect symbol `wxComboBoxBase type_info node' to `wxComboBoxBase type_info node@@WXD_2.5' is a loop
../../../lib/libwx_gtkd_adv-2.5.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [../../../lib/libwx_gtkd_xrc-2.5.so.1.0.0] Error 1
make: Leaving directory `/usr/src/redhat/BUILD/wxPythonSrc-2.5.1.0p8/bld/contrib/src/xrc'
error: Bad exit status from /var/tmp/rpm-tmp.91016 (%build)

Any ideas?

--off to try to build the source tarball instead...

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Chris Barker wrote:

Robin,

I tried to build the sorce rpm on a REdhat 7.2 system, and it failed with this message:

/usr/bin/ld: ../../../lib/libwx_gtkd_adv-2.5.so: indirect symbol `wxComboBoxBase type_info node' to `wxComboBoxBase type_info node@@WXD_2.5' is a loop
../../../lib/libwx_gtkd_adv-2.5.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [../../../lib/libwx_gtkd_xrc-2.5.so.1.0.0] Error 1
make: Leaving directory `/usr/src/redhat/BUILD/wxPythonSrc-2.5.1.0p8/bld/contrib/src/xrc'
error: Bad exit status from /var/tmp/rpm-tmp.91016 (%build)

Any ideas?

None. What version of the compiler do you have?

···

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

gcc 2.96

maybe it's time to upgrade my system anyway, but right now, I'd just like to get it to work!

I've successfully compiled wxWindows (Widgets?) from source so far...still working on that.

-Chris

Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

···

On Mar 2, 2004, at 11:37 AM, Robin Dunn wrote:

Any ideas?

None. What version of the compiler do you have?

Chris Barker wrote:

Any ideas?

None. What version of the compiler do you have?

gcc 2.96

That's what I guessed. Probably some optimization flag that the RPM build was trying to use that made it choke.

maybe it's time to upgrade my system anyway, but right now, I'd just like to get it to work!

I've successfully compiled wxWindows (Widgets?) from source so far...still working on that.

While you're doing that please keep track of anything in wxPython/docs/BUILD.txt or .../INSTALL.txt that needs more explaination or are incorrect.

···

On Mar 2, 2004, at 11:37 AM, Robin Dunn wrote:

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

Well, I tried to install it on OS-X (Panther), and it ran through the whole thing, then gave me:

"There were errors installing the software."

in the "Finishing Up" phase. Very helpful message, Isn't it?

What I'm installing on is OSX 10.3, just installed on top of 10.2. I tried to delete all the Python stuff that existed, and then installed the MacPython OS-X addons, then tried to install wxPython (wxPythonOSX-2.5.1.0p8-panther-Py2.3).

I'm really trying to test out the preview, but this just isn't going well for me.

-Chris

Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

···

On Feb 27, 2004, at 11:11 AM, Robin Dunn wrote:

The next preview build of wxPython is now available at

http://starship.python.net/crew/robind/wxPython/preview/2.5.1.0p8/