2.9.1.1 20100922 Preview

wxPython Dev
21

It's working as expected here. The typemap is converting "" to an invalid wxColour object and then when MarkerDefine is called it is checking the colour's Ok() method before passing it on to the rest of the STC code.

···

On 9/29/10 1:07 PM, jmfauth wrote:

On 29 sep, 20:45, Robin Dunn<ro...@alldunn.com> wrote:

On 9/28/10 10:51 AM, jmfauth wrote:

...

If you can make a small sample that shows the problem then I can trace
through it in the debugger and see better what is happening.

# -*- coding: ascii -*-
# MarkerDefineTest.py // 29 Sept 2010 // jmf

--
Robin Dunn
Software Craftsman

22

Well, in that case it quite mysterious.

···

On 30 sep, 19:33, Robin Dunn <ro...@alldunn.com> wrote:

On 9/29/10 1:07 PM, jmfauth wrote:

> On 29 sep, 20:45, Robin Dunn<ro...@alldunn.com> wrote:
>> On 9/28/10 10:51 AM, jmfauth wrote:

>> ...

>> If you can make a small sample that shows the problem then I can trace
>> through it in the debugger and see better what is happening.

> # -*- coding: ascii -*-
> # MarkerDefineTest.py // 29 Sept 2010 // jmf

It's working as expected here. The typemap is converting "" to an
invalid wxColour object and then when MarkerDefine is called it is
checking the colour's Ok() method before passing it on to the rest of
the STC code.

23

I like the "DVC" stuff, are the ListCtrl and TreeListCtrl the basic
controls, or are they using new ones?

They are new widgets that use the DataViewCtrl to implement classes that are similar to wxListCtrl and wxTreeCtrl.

Multisash:*
Following traceback when pointing at the little tab on top left (below
red spot).

Traceback (most recent call last):
File "C:\Python26\lib\site-packages\wx-2.9.1-msw\wx\lib\multisash.py",
line 584, in OnMouseMove
self.px,self.py = self.ClientToScreenXY(evt.X,evt.Y)
AttributeError: 'MouseEvent' object has no attribute 'X'

Fixed. X --> x and Y --> y

*Popup Control:*
On first use can not select "today", i.e. date with blue border

Fixed. The CalendarCtrl is no longer sending selection events for days that are already selected.

*Threads:*
Demo window is sized to small, i.e. thread bars are not visible if not
resizing frame manually.

Fixed. Used SetMinSize instead of SetSize.

*ColourDB:*
Is drawing over the top of what is already shown in the demo tab. E.G.
use DragXXXList and then go to ColourDB

Fixed. Use wx.BG_STYLE_ERASE so erase window events will be sent.

A couple other remarks:
- the demo tries to install to "Program Files" on Windows (I am on 7 64
bit), would be much nicer if it would install into e.g. Pythonxx\Doc

Is there any precedent for using this location by other Python packages?

- it would also be nice when installing the demo that the installer asks
which Python version to use. I have 2.5 and 2.6 but 2.5 is default for
.py/.pyw but new stuff I try with 2.6, and it took me a moment to figure
out why the demo loaded with wxPython 2.8 and not 2.9.

I think that sometime in the past that I had used the Python executable in the shortcuts instead of just relying on the .pyw association, but there was some problem that prompted me to change it to the way it is now. I don't remember what it was however, I'll give this some more thought and consider changing it again.

···

On 9/30/10 2:31 AM, werner wrote:

--
Robin Dunn
Software Craftsman

24

Great, patiently waiting for the next preview then :slight_smile:

Werner

···

On 30/09/2010 19:00, Robin Dunn wrote:

On 9/30/10 4:08 AM, werner wrote:

font.GetFamily() returns 77

If I run my application using wxPython 2.8.11 unicode I get '74'.

Any idea of where I should look for why I get a different value within
OLV when changing to wxPython 2.9.

This bug in wx.Font has been fixed. 77 is wx.FONTFAMILY_UNKNOWN, the change was to instead have it return wx.FONTFAMILY_DEFAULT when it can't figure out the family.

25

I like the "DVC" stuff, are the ListCtrl and TreeListCtrl the basic
controls, or are they using new ones?

They are new widgets that use the DataViewCtrl to implement classes that are similar to wxListCtrl and wxTreeCtrl.

I googled a bit on it, didn't find a nice comprehensive example but the doc (wxWidgets: wxDataViewCtrl Related Classes) gives me something to chew on :slight_smile: .

...
great that you could fix things so quickly.

A couple other remarks:
- the demo tries to install to "Program Files" on Windows (I am on 7 64
bit), would be much nicer if it would install into e.g. Pythonxx\Doc

Is there any precedent for using this location by other Python packages?

Not that I know off.

If not that then maybe within GetUserDataDir or below the wx install folder.

- it would also be nice when installing the demo that the installer asks
which Python version to use. I have 2.5 and 2.6 but 2.5 is default for
.py/.pyw but new stuff I try with 2.6, and it took me a moment to figure
out why the demo loaded with wxPython 2.8 and not 2.9.

I think that sometime in the past that I had used the Python executable in the shortcuts instead of just relying on the .pyw association, but there was some problem that prompted me to change it to the way it is now. I don't remember what it was however, I'll give this some more thought and consider changing it again.

Maybe make it an option the user can select during install?

Werner

···

On 30/09/2010 20:29, Robin Dunn wrote:

On 9/30/10 2:31 AM, werner wrote:

26

> - the demo tries to install to "Program Files" on Windows (I am on 7 64
> bit), would be much nicer if it would install into e.g. Pythonxx\Doc

Is there any precedent for using this location by other Python packages?

No.
On Windows the whole Python installation is quite clean.
All 3rd libraries, which are extending a Python environment
(whatever the Python version), are sitting in \site-packages.

Martin Löwis (I think) who is maintaining the msi Python
installer does a good job. When one removes a Python version
everything in removed, but the site-packages. When I update
a Python version, let say 2.5.n to to 2.5.n+1, I usually
remove the 2.5.n version and then make a fresh install of
2.5.n+1, the site-packages is preserved.

Note the presence of this file in site-packages:

README.txt
This directory exists so that 3rd party packages can be installed
here. Read the source for site.py for more details.

···

---

> - it would also be nice when installing the demo that the installer asks
> which Python version to use. I have 2.5 and 2.6 but 2.5 is default for
> .py/.pyw but new stuff I try with 2.6, and it took me a moment to figure
> out why the demo loaded with wxPython 2.8 and not 2.9.

I think that sometime in the past that I had used the Python executable
in the shortcuts instead of just relying on the .pyw association, but
there was some problem that prompted me to change it to the way it is
now. I don't remember what it was however, I'll give this some more
thought and consider changing it again.

Two comments, here

To Werner:
It seems you are confused. The default *Python* version the
system is using is one thing, the default *wxPython* version
*a* Python version is using is something else [*].

To Robin:
Relying on the py/pyw association to start a Python script
is in my understanding correct. After all, the demo.py is
just a normal Python application.
I downloaded this morning the wxPython-demo-xxxx.tar.bz2
and I unpacked it on a usb-key and run it from there, no
problem (I do not count the demo isssues). Of course,
I had to tweak a little bit and insert a wxversion() to
select the wxPython version which is not the default,
see [*].

Maybe if something could be optimized, is the *location*
of the demo (and other stuff like help files,...). Locating
it in site-packages closed to (on in) the wxPython stuff makes
more sense, especially if one condiders there is a bijection:
one demo <---> one wxPython version.

Keeping a separation between the demo and the run
time is in my mind still a good idea.

jmf

27

Hi Jean-Michel,
- it would also be nice when installing the demo that the installer asks
...

which Python version to use. I have 2.5 and 2.6 but 2.5 is default for
.py/.pyw but new stuff I try with 2.6, and it took me a moment to figure
out why the demo loaded with wxPython 2.8 and not 2.9.

I think that sometime in the past that I had used the Python executable
in the shortcuts instead of just relying on the .pyw association, but
there was some problem that prompted me to change it to the way it is
now. I don't remember what it was however, I'll give this some more
thought and consider changing it again.

Two comments, here

To Werner:
It seems you are confused. The default *Python* version the
system is using is one thing, the default *wxPython* version
*a* Python version is using is something else [*].

Nope, not confused :wink: , well aware of the two things.

My problem was that:
- have Python 2.5 installed as my default, so if I do python.exe somescript.py or just run somescript.py I get Py 2.5
- I also have Python 2.6 installed but only do testing in it at the moment, i.e. test moving my shareware to 2.6 and wxPython 2.9?.....

So, when I installed the wxPython 2.9 preview demo and run it it complained that I didn't have wxPython 2.9 and would run against wxPython 2.8, it took me a while (longer then it should have) to figure out that it picked up my default Python and it wasn't ignoring my wx.pth or something else.

So, I think it might be a good idea on installation of the demo to be able to select which Python version one wants to use, especially at the moment where I think lots of people have more then one of them (2.5, 2.6, 2.7, 3.x).

Up to Robin if he wants or doesn't want to do change anything in relation to this - hopefully I will remember next time I fall into this very little trap :slight_smile:

Werner