POLL: wx.DC methods

[Jean-Michel_Fauth]

1) I read and reread carefully all the opinions. The lack
of consistency in wxPython seems to be the common denominator
of all posts (and also in previous threads). This is going
far deeper than the names and arguments of the dc.methods().

2) I think, we should see the problem from one another
perspective. The real question is: To whom is wxPython
adressed? Of course, to Python users, however I see two
groups of users.

(a) C++ experimented users. For those people, wxPython
is just a Python wrapper of wxWidgets. Eg, they are aware
the position of a wx.Window -a tuple- is the Python pendant
of a C structure called wx.Point. Realizing this, they
tend to accepts everything.

(b) Pure Python users and/or C++ illiterate users. For
the members of this group, wxPython is just a Python
module. It is an important module, because it is
their GUI toolkit. This module should behave like any other
Python module. In the ideal case, they do not want to know
from where wxPython is coming from. They even do not want
to know that wxPython is written in C/C++. It could have been
done in pascal or assembler.

Unfortnatelly (if I can say like this), wxPython developpers
belong to the (a) group. (I know, there are some pure
wxPython widgets). I am a member of the (b) group.

4) For clarity, a Python user has to know two thinks:
i) a position is a 2-tuple (x, y)
ii) a size is a 2-tuple (w, h).
Amen, that's all. She/he even does not have to know,
a position is wx.Point.

···

=============================================================
It is amazing to see, that just sticking on this convention,
the *whole* library becomes limpid.

It's clear with and without keyword arguments.
wx.Frame.__init__(self, parent, id, title=s, pos=(10, 10), size=(600, 500), style=sty)
or
wx.Frame.__init__(self, parent, id, title=s, (10, 10), (600, 500), style=sty)

It avoids duplicate functions.
dc.DrawPoint and dc.DrawPointXY

It can eliminate some opaque functions.
self.GetSize()
self.GetSizeTuple()
I do not care GetSize() returns a <class 'wx.core.Size'> object.
Knowing the returned size is a <type 'tuple'>, (a, b) is enough.

Event methods
...

and so on

5) Backward compatibility. That's an holly word!
If you do not make this changes in now (2.5), when
will be these done?

Jean-Michel Fauth, Switzerland

[Bob_Klimek]

Jean-Michel Fauth wrote:

(a) C++ experimented users. For those people, wxPython
is just a Python wrapper of wxWidgets. Eg, they are aware
the position of a wx.Window -a tuple- is the Python pendant
of a C structure called wx.Point. Realizing this, they
tend to accepts everything.

(b) Pure Python users and/or C++ illiterate users. For
the members of this group, wxPython is just a Python
module. It is an important module, because it is
their GUI toolkit. This module should behave like any other
Python module. In the ideal case, they do not want to know
from where wxPython is coming from. They even do not want
to know that wxPython is written in C/C++. It could have been
done in pascal or assembler.

I'm definitely in the (b) group as well. After all, wxPython is a Python GUI. Why not make it look and feel like Python?

It avoids duplicate functions.
dc.DrawPoint and dc.DrawPointXY

Its silly to have two versions like this.

It can eliminate some opaque functions.
self.GetSize()
self.GetSizeTuple(

The second form should not exist. Again, since wxPython is a Python GUI, why not have it return what would be expected in a python program?

If you do not make this changes in now (2.5), when
will be these done?

Agree! Now seems like a good time! After the python docs come out, no one will complain that there is a syntax difference between wxPython and wxWidgets.

Bob

[Peter_Damoc1]

1) I read and reread carefully all the opinions. The lack
of consistency in wxPython seems to be the common denominator
of all posts (and also in previous threads). This is going
far deeper than the names and arguments of the dc.methods().

True

2) I think, we should see the problem from one another
perspective. The real question is: To whom is wxPython
adressed? Of course, to Python users, however I see two
groups of users.

(a) C++ experimented users. For those people, wxPython
is just a Python wrapper of wxWidgets. Eg, they are aware
the position of a wx.Window -a tuple- is the Python pendant
of a C structure called wx.Point. Realizing this, they
tend to accepts everything.

(b) Pure Python users and/or C++ illiterate users. For
the members of this group, wxPython is just a Python
module. It is an important module, because it is
their GUI toolkit. This module should behave like any other
Python module. In the ideal case, they do not want to know
from where wxPython is coming from. They even do not want
to know that wxPython is written in C/C++. It could have been
done in pascal or assembler.

Unfortnatelly (if I can say like this), wxPython developpers
belong to the (a) group. (I know, there are some pure
wxPython widgets). I am a member of the (b) group.

As we can see in the wxPython API, painfully clear sometimes, our beloved toolkit is built from wx to python not the other way around. It is first wx and then python, if it would have been first a python module and then, in implementation, a wx.... a lot of things would have looked different

4) For clarity, a Python user has to know two thinks:
i) a position is a 2-tuple (x, y)
ii) a size is a 2-tuple (w, h).
Amen, that's all. She/he even does not have to know,
a position is wx.Point.

In my view wx.Point as an abstraction does not provide bennefit over a simple tuple so theoreticaly it shouldn't exist. Ofcourse, I might be wrong... I don't see the benefit in IDs and, let's face it, how many force you to use one? I think ALL OF THEM. How many people use -1 all over the code as an ID? I never used anything else.

=============================================================
It is amazing to see, that just sticking on this convention,
the *whole* library becomes limpid.

It's clear with and without keyword arguments.
wx.Frame.__init__(self, parent, id, title=s, pos=(10, 10), size=(600, 500), style=sty)
or
wx.Frame.__init__(self, parent, id, title=s, (10, 10), (600, 500), style=sty)

It avoids duplicate functions.
dc.DrawPoint and dc.DrawPointXY

It can eliminate some opaque functions.
self.GetSize()
self.GetSizeTuple()
I do not care GetSize() returns a <class 'wx.core.Size'> object.
Knowing the returned size is a <type 'tuple'>, (a, b) is enough.

Event methods
...

and so on
5) Backward compatibility. That's an holly word!
If you do not make this changes in now (2.5), when
will be these done?

What you're talking here about is "spring cleaning" of the API
When will this happen? Well... I suspect something like a couple of weeks after we manage to build the Robin-Duplicator
Now seriously... 2.5 might be a little bit to late... there are a lot of people using it already and I don't think they'll appreciate problems due to yet another API change.
The way I see it... the only way things are gonna get fixed is if a sub-project is started from the python end, something like anygui, and when this subproject finishes its port of wx functionality the "old way" gets dropped to "once uppon a time". After this... if you want "the old way" get an older version or maybe a compatibility layer to the new version.

Jean-Michel Fauth, Switzerland

My point of view is this: I haven't contributed anything to the wxpython project, not even 2 lines of code, so I have no wright to ask for anything. I would love to be able to do something BUT I'm way too lazy, I have way too little time, way too little knowledge. I plan to start some teaching classes in the Fall, maybe I'll become a teacher after all "those who cannot do... teach"

···

On Thu, 22 Apr 2004 16:42:12 +0200, Jean-Michel Fauth <jmfauth@bluewin.ch> wrote:

--
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/about.html

[Roger_Binns]

Peter Damoc wrote:

How many people use -1 all over the
code as an ID? I never used anything else.

Err, I have static class members with ids all over the
place (the opposite of your statement). This is necessary
to hook toolbar buttons to the same menu ids, or where I
have widgets in HTML files that need to trigger an action.

... "old way" .... "new way" ....

I have yet to see a compelling reason why (x,y) is better
and/or more Pythonic than x,y.

Taking a step back, here are all the points I see.

(1) wxPython should be Pythonic as appropriate. Python
     lists should be used where the API takes lists,
     Python strings should be used where the API takes
     strings, Python tuples should be used where the
     api takes points/rects etc.

* This is already the case and has been for a long
     time.

(2) It is Pythonic for a function to take named arguments
     (as opposed to *args, **kwargs). If complex overloading
     is needed, it is Pythonic to have differently named
     functions rather than resort to *args, **kwargs.

* wxPython is sort of like this already, hence the need
     for differently named functions where C++ only has one
     overloaded function. The use of *args, **kwargs in
     wxPython is mostly a SWIG implementation detail, and
     efforts are towards trying to resolve this, and make
     it less user visible.

(3) The C++ code does have overloaded functions with the
     same name, and the documentation does describe them
     (most of the time). wxPython typically picks the
     most common/normal form to use the same name as the
     documentation/C++ and adds extra differently named
     functions for the other forms, which is usually
     mentioned in the documentation.

* This is already the case. A good example is the
     constructor for wx.Bitmap which has 6 overloaded
     variants described in the doc, and for which there
     are 5 differently named wxPython functions.

(4) The main (only area of contention is what to
     do about APIs that take coordinates and sizes.
     The question is what is the most common/normal
     form for these as this is the chance to make wxPython
     do that in a non-backwards compatible fashion.
     The two choices are as seperate parameters or
     as points/tuples.

     wxPython 2.4 *and* the documentation show the
     form taking seperate x, y, width, height
     parameters as either the only form or the first
     documented form. Every other windowing toolkit
     I looked at (Tk, MFC, Win32, GTK, Xt, Xlib) does
     this as well. [The exception is that they all use
     a structure(tuple) for dealing with a rectangle, as
     does wxWidgets and wxPython]

* I have yet to see any reason why wxPython should
     be different from all that, other than some people
     like it. That doesn't prevent the other form being
     available under a different name.

     It would make sense if there was some sort of
     convention for the name, in the same way that
     APIs in other languages usually append a W for
     functions that take Unicode/wide strings.

Roger

[Paul_Moore1]

"Roger Binns" <rogerb@rogerbinns.com> writes:

I have yet to see a compelling reason why (x,y) is better
and/or more Pythonic than x,y.

I think that the key point is not some abstract concept of
"Pythonicness" (Pythonicity???) but practical usability. In Python,
tuples are so easy to use that passing points/sizes around as tuples
is extremely natural. I don't think that this is so much the case in
C++.

For example, in Python, I'd naturally generate a list of random points
as

    l = [(randint(0,100), randint(0,200)) for n in range(200)]

Then, to draw radius-10 circles at each point,

    for pt in l:
        dc.DrawCircle(pt, 10)

Compare this to the non-tuple version:

    for pt in l:
        dc.DrawCircle(pt[0], pt[1], 10)

This second version just obscures the intent, IMHO.

In C++, I *might* use a wxPoint (I don't know, I've never used
wxWidgets in C++) but I don't think it's as clear-cut. Tuples in
Python just feel "lightweight".

I take the point about the documentation. But as others have said, bad
documentation shouldn't drive the issue. I'm not clear if your point
is that the C++ wxPoint variants are *undocumented*, or just
documented *second*.

If the former, that's a documentation lack, and should be treated as
such.

If the latter, ordering doesn't matter to me - if I see two documented
variants, and the second one feels more "natural" in Python, then I'll
prefer that one. As Python can't (easily) support both variants, I'll
happily accept a "global" wxPython note to the effect that the wxPoint
variation is the one that is used in all cases.

Paul.

···

--
This signature intentionally left blank

[Chris_Barker1]

Thanks for the summary, Roger.

Roger Binns wrote:

(4) The main (only area of contention is what to
     do about APIs that take coordinates and sizes.

I agree. Let's all focus on just this point.

     The question is what is the most common/normal
     form for these

I don't think we should choose the most common or normal..we should choose the best form for wxPython. We'll all have our different ideas about what's best, of course.

     The two choices are as seperate parameters or
     as points/tuples.

* I have yet to see any reason why wxPython should be different from all that, other than some people
     like it.

I don't see any reason that it should be the same either. Honestly, I think this is all about what people like.

I'll tell you why I like the tuple version. First of all it's not tuple, it's any python sequence of two integers. This is important because I sometimes use a Numeric array, and one could use a custom class it that made sense.

I like the coords to be paired up because it makes much more sense to me to treat two coordinates as one thing. They aren't really useful without each other. When I notice that every single time I use, "x", I also use "y", it makes sense to store them as a single variable: "point". That why the wxPoint structure exists in C++. It's not a big deal to me, but I'll be storing an manipulating point data in a single object, and I'd much rather write:

DC.DrawPoint(point)
than
DC.DrawPoint( point[0], point[1] )

     It would make sense if there was some sort of convention for the name,

That has been established:

DC.DrawSomethingXY(....)

Although I'd be just as happy to see that version deprecated.

One more point: I suspect that one reason so many toolkits use an x,y format is that there is a need to keep things from depending on two many particular structures. Any C code is going to have a way to pass two integers. If you require a wxPoint, for instance, you are requiring your users to us wxPoints to store their coordinates (Or do a conversion at every call). Python auto-polymorphism makes this much simpler. I can pass in a wxPoint, a tuple, or any sequence of two integers. I can also just do:

DC.DrawPoint( (x,y) )

so all I need is the extra parentheses. This is so easy, the only reason I see not to do it is backward compatibility, and we've already broken 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

[Roger_Binns]

Chris Barker wrote:

I don't think we should choose the most common or normal..we should
choose the best form for wxPython.

common/normal implies best (or rather I meant it

I don't see any reason that it should be the same either. Honestly, I
think this is all about what people like.

I keep giving a very good one. The documentation already has
the "same" form either exclusively or listed first. The weaker
reason (I personally consider it a very good one) is that the
"same" form is the standard for all GUIs I could find, and
consequently means that wxPython programmers can participate
in a bigger community without "arbitrary" differences.

In terms of what people like, that isn't necessarily the best thing
to do. For example in Python itself the best thing has been BDFL's
taste rather than what people like, although many end up liking
his taste

I'll tell you why I like the tuple version. First of all it's not tuple,
it's any python sequence of two integers. This is important because I
sometimes use a Numeric array, and one could use a custom class it that
made sense.

That is just an argument as to why there should be two forms, not
which one should be primary (although it is obvious which you prefer
as primary

I like the coords to be paired up because it makes much more sense to me
to treat two coordinates as one thing. They aren't really useful without
each other.

That is fine for coordinates, but what about dimensions? And there
are a few places throughout the API where only one part of a coordinate
or dimension is used.

> It would make sense if there was some sort of
> convention for the name,

That has been established:

DC.DrawSomethingXY(....)

It's a bad convention for something that takes dimensions
(which is WH) and could even lead to a XYWH suffix. Before
you know it, we will be doing hungarian convention

Using composite types (Point etc) isn't quite the panacea.
For example manipulating it introduces slicing it:

   pt=(pt[0]+7, pt[1])

Roger

[Roger_Binns]

Paul Moore wrote:

I take the point about the documentation. But as others have said, bad
documentation shouldn't drive the issue.

Personally I think that the documentation is the most important
issue! There is no value in having to explain to someone,
especially a newbie, that everywhere they see int x, int y in
the documentation, they *must* replace it with (x, y) or
add XY to the function, or maybe it is WH, or maybe both,
except in cases where only one coordinate or dimension is
needed in which case there is no suffix most of the time.

I'm not clear if your point
is that the C++ wxPoint variants are *undocumented*, or just
documented *second*.

It is both. For some functions, the wxPoint variants are not
documented at all. For other functions it is documented second.
The documentation is thoroughly consistent in that the
x, y form is always documented, and is always documented first
if there are multiple variants.

If the latter, ordering doesn't matter to me - if I see two documented
variants, and the second one feels more "natural" in Python, then I'll
prefer that one.

In most cases (eg wxBitmap constructor) you would expect the
most common form first, and each variant is *very* different.
I would expect the bare name to be used for that first
variant, and the other ones to have different wxPython
names listed in the same order.

Roger

[Robin]

Roger Binns wrote:

Using composite types (Point etc) isn't quite the panacea.
For example manipulating it introduces slicing it:

   pt=(pt[0]+7, pt[1])

>>> pt = wx.Point(11,22)
>>> pt = pt + (7,0)
>>> print repr(pt)
wx.Point(18, 22)

···

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

[Chris_Barker1]

Roger Binns wrote:

Chris Barker wrote:

I don't think we should choose the most common or normal..we should
choose the best form for wxPython.

common/normal implies best (or rather I meant it

not for me. That's my point (pun intended!)

I keep giving a very good one. The documentation already has
the "same" form either exclusively or listed first.

I thought we put this to bed...I don't think we should make this decision on the basis of poorly designed/implemented C++ docs.

The weaker
reason (I personally consider it a very good one) is that the
"same" form is the standard for all GUIs I could find, and
consequently means that wxPython programmers can participate in a bigger community without "arbitrary" differences.

Different libraries have different API s. This is a FAR more minor difference than most of the others. And I argued before that the motivations behind the design of many of those APIs is C oriented..yecch!

For example in Python itself the best thing has been BDFL's
taste rather than what people like, although many end up liking
his taste

Well in this case the BDFL is Robin, and I generally like Robin's taste as well. Believe me, when Robin announces that he's made I decision about this, I'll shut up.

That is just an argument as to why there should be two forms, not
which one should be primary (although it is obvious which you prefer
as primary

right, Besides, I'm not sure I like twp forms. If the x,y version is selected as primary, I'll probably just use that.

That is fine for coordinates, but what about dimensions? And there
are a few places throughout the API where only one part of a coordinate
or dimension is used.

I'm not arguing that you shouldn't be able to access them individually...

DC.DrawSomethingXY(....)

It's a bad convention for something that takes dimensions
(which is WH) and could even lead to a XYWH suffix. Before
you know it, we will be doing hungarian convention

Nooo! not that!...I have no problem with the convention, but if you can come up with a better one, that's great.

Using composite types (Point etc) isn't quite the panacea.
For example manipulating it introduces slicing it:

   pt=(pt[0]+7, pt[1])

That's why I use Numeric arrays:
>>> from Numeric import *
>>>
>>> pt = array( (4,5) )
>>> pt
array([4, 5])
>>> shift = array( (7,0 ) )
>>> shift
array([7, 0])
>>>
>>> pt += shift
>>> pt
array([11, 5])

And I never said it was a panacea, just that I like to do it that way.

I've spent way too much time writing to this mailing list today...I'll stop now!

-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_Barker1]

I know I said I'd stop, but I can't help myself!! make me stop, someone!

Roger Binns wrote:

Paul Moore wrote:

I take the point about the documentation. But as others have said, bad
documentation shouldn't drive the issue.

Personally I think that the documentation is the most important
issue!

I'm assuming that the docs can be and will be corrected. If not, then you have a very good point, but also if not, that's really pathetic! Also, the Python specific docs are on the way, and we really need those!

As a note, A colleague of mine, who is new to wxPython, just asked about wx.EmptyBitmap, which he had seen in an example, and couldn't find in the docs. He asked if there was another doc he hadn't look in, or if the docs were "seriously deficient" Personally, I don't think this kind of thing is that serious, and it turns out wxEmptyBitmap is documented right where it should be: in a wxPython Note under wxBitmap. However, the point is that users would be a lot happier if there were complete python-oriented docs. And we'll get those soon.

-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

[Roger_Binns]

Robin Dunn wrote:

Roger Binns wrote:
> Using composite types (Point etc) isn't quite the panacea.
> For example manipulating it introduces slicing it:
>
> pt=(pt[0]+7, pt[1])

>>> pt = wx.Point(11,22)
>>> pt = pt + (7,0)
>>> print repr(pt)
wx.Point(18, 22)

You have actually pointed out an error that could inadvertently
arise with this scheme.

If I get passed a point from elsewhere to manipulate,
I might write something like this:

  return pt + (7,0)

Since tuples (or sequences to keep Chris happy and wx.Point
are almost interchangeable, something unexpected could very
easily happen depending on what I was actually passed.

I can't do type coercion either as it generates an exception
if pt is already a wx.Point:

  return wx.Point(pt) + (7,0)
  
Roger

[Robin]

Roger Binns wrote:

Robin Dunn wrote:

Roger Binns wrote:

Using composite types (Point etc) isn't quite the panacea.
For example manipulating it introduces slicing it:

  pt=(pt[0]+7, pt[1])

>>> pt = wx.Point(11,22)
>>> pt = pt + (7,0)
>>> print repr(pt)
wx.Point(18, 22)

You have actually pointed out an error that could inadvertently
arise with this scheme.

If I get passed a point from elsewhere to manipulate,
I might write something like this:

  return pt + (7,0)

Since tuples (or sequences to keep Chris happy and wx.Point
are almost interchangeable, something unexpected could very
easily happen depending on what I was actually passed.

I can't do type coercion either as it generates an exception
if pt is already a wx.Point:

  return wx.Point(pt) + (7,0)

But this does work since wx.Points can be tuple-unpacked:

  return wx.Point(*pt) + (7,0)

I used that form on all the grafted-in methods in the compatdc.py module I sent yesterday to ensure that no matter what they are passed they'll be able to use them as wx.Points.

···

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

[Roger_Binns]

Chris Barker wrote:

I'm assuming that the docs can be and will be corrected.

That implies they are wrong!

Also, the Python specific docs are on the way, and we really need those!

I haven't seen any mention or intention that the Python specific
ones will be as complete as compared to the current wxWidgets ones.

For example, outside of the API reference there are overviews on
specific classes, lists of tags supported by wxHTML, information
on application shutdown etc. Some of that should be wxPython
specific (such as how to internationalize and localise an
application) but most isn't.

which he had seen in an example, and couldn't find in
the docs.

The Windows help engine is fairly terrible and the wx
one isn't much better for that sort of thing. Both can
find the page, but neither seem to have a way of searching
within a page.

Having the help also available on the web is a great help.
For example see this http://bitpim.sourceforge.net/testhelp/
You can even link to individual pages:
http://bitpim.sourceforge.net/testhelp/support.htm#donotdo

Roger

[Jean_Brouwers]

It sounds like we have at least three separate issues and can't
seem to get any closer to consensus and resolution.

1) The first and main issue is, does wxPtyhon need to support
two API models, a Python tuple model *and* the current C++ model?

2a) If the answer to 1) is no, the next question is, which one?

2b) If the answer to 1) is yes, the next issue is what naming
convention to use in wxPython to distinguish both models?

3) There is a problem with the documentation, both for wxPython and
C++. This is an important, but separate issue.

We should first figure out what the answer to issue 1) is. There
is no point argueing the next issues until we have concensus on
that.

Going back to Robin's original post, the choices he offered were A),
B) or C), see below. But let me re-define C) slightly: Allow both
TypeA and TypeB methods each with names TBD and drop support for
TypeB at some future release.

We may need to add a 4th one D), which would be the same as C) but
with continued support for both models, forever.

So, what is the the 'final answer': A), B), C) or maybe D)?

/Jean Brouwers
  ProphICy Semiconductor, Inc.

Robin Dunn wrote:
> Hi all,
>
> Ever since I made the changes to the wx.DC methods I've gone back and forth on whether I like it or not. The general consensus on wxPython-dev was that it was a good idea, but since it still hasn't sunk in for me I thought I would try to get opinions from a wider audience.
>
> Please (re)read this section of the MigrationGuide and then vote for one of the following:
>
> http://wxpython.org/MigrationGuide.html#new-wx-dc-methods
>
> A) It's fine as-is, please leave it alone for future versions
>
> B) It stinks, consistency isn't that important. Revert it.
>
> C) Allow both TypeA and TypeB methods to use the same "normal" name.[1]
>
> [1] This is possible using SWIG 1.3's method overloading abilities, but we will lose the use of keyword args for those methods. IOW, both of these will be possible:
>
> dc.DrawBitmap(bmp, x, y)
> dc.DrawBitmap(bmp, point)
>
> but because of what SWIG has to do to make overloading work you would only be able to use positional args, so this would not be allowed:
>
> dc.Blit(dest, size, otherDC, src, useMask=True)
>
> If I do (C) then I'll leave the 'XY' versions in place for a few releases as aliases.
>

Roger Binns wrote:

···

Paul Moore wrote:

I take the point about the documentation. But as others have said, bad
documentation shouldn't drive the issue.

Personally I think that the documentation is the most important
issue! There is no value in having to explain to someone,
especially a newbie, that everywhere they see int x, int y in the documentation, they *must* replace it with (x, y) or
add XY to the function, or maybe it is WH, or maybe both,
except in cases where only one coordinate or dimension is
needed in which case there is no suffix most of the time.

I'm not clear if your point
is that the C++ wxPoint variants are *undocumented*, or just
documented *second*.

It is both. For some functions, the wxPoint variants are not
documented at all. For other functions it is documented second.
The documentation is thoroughly consistent in that the
x, y form is always documented, and is always documented first if there are multiple variants.

If the latter, ordering doesn't matter to me - if I see two documented
variants, and the second one feels more "natural" in Python, then I'll
prefer that one.

In most cases (eg wxBitmap constructor) you would expect the
most common form first, and each variant is *very* different.
I would expect the bare name to be used for that first
variant, and the other ones to have different wxPython
names listed in the same order.

Roger

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

[Grimmtooth]

Robin Dunn wrote:

>>> pt = wx.Point(11,22)
>>> pt = pt + (7,0)
>>> print repr(pt)
wx.Point(18, 22)

I love that feature. Whatever posessed me to alter parts of the demo that demonstrated it, I don't know, other than a rush to get everything 'harmonized' with the new idioms.

... If it doesn't move, eat it. If it moves, kill it. Then eat it.

[Grimmtooth]

Chris Barker wrote:

I'm assuming that the docs can be and will be corrected. If not, then you have a very good point, but also if not, that's really pathetic!

I wouldn't call it 'pathetic'. I would call it 'typical for large projects'. Which I think we can all agree that wxWidgets + wxPython qualify as. The problem that often arises is that as new features move forward, interest in tidying up the old stuff falls off.

Prgrammers love new stuff. They hate boring stuff. Documentation is - believe it - BORING! So it's not entirely suprising that there are a lot of neglected toys in the attic, as it were.

This isn't just wx(Widgets|Python). Even Python itself suffers from this. The docs just *reek* of unfinished business. Even the code itself.

... "Klingons do NOT procrastinate! It is a...TACTICAL delay!"

[Peter_Damoc1]

well I don't think they are absolutely necessary :D, maps will solve that problem for you.
keep some dictionaries available like {id:action}, {action:data} and generate the IDs automaticaly with wx.NewId()
In the handler get the action for the triggered Id and call a supervisor class like this:

comp = supervisor.getTheActiveFocusedAnxiouslyWaitingForInputComponent()
comp.do(actionMap[evt.GetId()])

all the component has to do is inherit some utility class who implements "do" like this:

     def do(self, command):
         try:
             method = getattr(self, command)
             method.__call__(self)
         except:
             print "I %s can't do this: %s"%(self, command)

and implement methods named after the actions

···

On Thu, 22 Apr 2004 12:06:32 -0700, Roger Binns <rogerb@rogerbinns.com> wrote:

Peter Damoc wrote:

How many people use -1 all over the
code as an ID? I never used anything else.

Err, I have static class members with ids all over the
place (the opposite of your statement). This is necessary
to hook toolbar buttons to the same menu ids, or where I
have widgets in HTML files that need to trigger an action.

--
Peter Damoc
Hacker Wannabe
http://www.sigmacore.net/about.html

[Chris_Barker1]

Robin Dunn wrote:

>>> pt = wx.Point(11,22)
>>> pt = pt + (7,0)
>>> print repr(pt)
wx.Point(18, 22)

By the way, where does that come from? in the wxWidgets docs (at least the 2.4.2 ones) wxPoint is just a simple structure.

-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_Barker1]

Jeff Grimmett wrote:

Chris Barker wrote:

I'm assuming that the docs can be and will be corrected. If not, then you have a very good point, but also if not, that's really pathetic!

I wouldn't call it 'pathetic'. I would call it 'typical for large projects'.

That was harsh, but my point is that it shouldn't take any more work to add those methods to the docs than we have just spent in this discussion. I'm a little confused, as I thought the docs were mostly auto-generated anyway, so all the methods should be there. If someone points me to the right file to edit, I'll add the DC methods myself.

- 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