[wxPython] newbie questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[wxPython] newbie questions

Robin Becker-7
Hi I'm trying to get into wxPython and have a number of probably stupid
questions.

1) Why is it assumed that C++ documentaion is sufficient? I know enough
C++, but find the wxWindows documentation a bit confusing. It is also a
bit out of date eg I can't seem to find the border sizer.

2) Why is the wrapping so thin? I think the spirit of python would
suggest that coordinates & sizes could be simply specified as (x,y) or
(w,h) (or the list equivalents) rather than as wxPosition(x,y) &
wxSize(w,h). What are all the rather exotic registry type functions etc
doing in a Gui toolkit?

3) I see claims that this is much better than Tkinter. It certainly
looks good, but I think programming it is more difficult (at least for
me). Why do I need integer identifiers for some kinds of thing and in
wxPython at least why aren't they completely hidden ie controlled by the
toolkit.

4) The more complex widgets look to be ideal candidates for internal
structure, but I'm not sure I can figure out how to make use of them.
For example I would like to put a 4 by 4 grid into a border sizer and
have both rows and columns expand appropriately. Alternatively have the
rows fixed size and expand say the last column. I tried a few things,
but couln't get the behaviour I needed.

5) I know this is a beta, but on my win95 osr2 system the demo code
vertical scrollbar had some very exotic effects (giant white patches
across the whole screen). I cannot reproduce this easily, but have seen
it twice.


Sorry to start out nitpicking; the overall look is good, but I need more
than that to convince me to abandon Tkinter. So is there anything easy
to help me convince myself.
--
Robin Becker

_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] newbie questions

Paul Sokolovsky-4
Hello Robin,

Robin Becker <[hidden email]> wrote:

RB> Hi I'm trying to get into wxPython and have a number of probably stupid
RB> questions.

    Well, riscing get ahead of author, I'll try to express my guesses
and opinions.

[]

RB> 2) Why is the wrapping so thin? I think the spirit of python would
RB> suggest that coordinates & sizes could be simply specified as (x,y) or
RB> (w,h) (or the list equivalents) rather than as wxPosition(x,y) &
RB> wxSize(w,h). What are all the rather exotic registry type functions etc
RB> doing in a Gui toolkit?

    I may guess it's because wxPython is (mostly) automatically
generated wrapper around wxWindows, created by SWIG. While SWIG allows
easy and robust interface creation, it suffers some drawbacks,
most of which can be called "staticity" - when something is needed, it
must exactly reflect C/C++ type, natural dynamic typedness is not supported.
Function overloading is not supported (note that wxPython have to
deviate from wxWindows to workaround this). And keywords just recently
was introduced - before you had to specify all gory C++ arguments. But
just look how much of wxWindows is wrapped and how little there
wxPython's bugs (except SWIG-prescribed ones)!

RB> 3) I see claims that this is much better than Tkinter. It certainly
RB> looks good, but I think programming it is more difficult (at least for
RB> me). Why do I need integer identifiers for some kinds of thing and in
RB> wxPython at least why aren't they completely hidden ie controlled by the
RB> toolkit.

    AFAIU wxWindows now, they are introduced exaclty to hide unneeded
details - you just assign IDs and forget it. I agree that it's more
natural for C++ than to Python.

RB> 4) The more complex widgets look to be ideal candidates for internal
RB> structure, but I'm not sure I can figure out how to make use of them.
RB> For example I would like to put a 4 by 4 grid into a border sizer and
RB> have both rows and columns expand appropriately. Alternatively have the
RB> rows fixed size and expand say the last column. I tried a few things,
RB> but couln't get the behaviour I needed.

    O, I don't even dream about it. After all, wxWindows is only *C++*
toolkit. IMHO, its main merit is that much is already there, but when
job comes to something new...

RB> 5) I know this is a beta, but on my win95 osr2 system the demo code
RB> vertical scrollbar had some very exotic effects (giant white patches
RB> across the whole screen). I cannot reproduce this easily, but have seen
RB> it twice.

    That's something that bothers me, too. wxPython really looks nice,
but when it comes to real work, many small problems arise. But it
largely improves with each beta. And Robert Dunn is very responsive
with advice, as you might have seen on the list.

RB> Sorry to start out nitpicking; the overall look is good, but I need more
RB> than that to convince me to abandon Tkinter. So is there anything easy
RB> to help me convince myself.

    Tkinter? O, don't say! You might heard shade of scepticism about
wxPython in my words above. But anything else I just don't use!
Tkinter? But it doesn't include such trivial thing as tree widget! And
when business comes to extensions such as Tix, I have to wait
half-second between node-click and its expansion. And after all: all
what I needed to do, I was able to do in wxPython. Well, sometimes I
have to workaround. But I barely could do half of that in Tkinter.

RB> --
RB> Robin Becker



Best regards,
 Paul                            mailto:[hidden email]



_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] newbie questions

Robin Becker-7
In article <[hidden email]>, Paul Sokolovsky <[hidden email]>
writes
>Hello Robin,
>
...
>
>    Tkinter? O, don't say! You might heard shade of scepticism about
>wxPython in my words above. But anything else I just don't use!
>Tkinter? But it doesn't include such trivial thing as tree widget! And
>when business comes to extensions such as Tix, I have to wait
>half-second between node-click and its expansion. And after all: all
>what I needed to do, I was able to do in wxPython. Well, sometimes I
>have to workaround. But I barely could do half of that in Tkinter.
...
>
>Best regards,
> Paul                            mailto:[hidden email]
>
>
thanks for your input. Tk has many diferent tree widgets; one of the
nicest is in pure tcl in the BWidget set. I'm actually coming from that
direction so won't argue about what is the best. I happen to find tree
widgets a real pain to use; again all that glitters is not gold. One of
the things which bothers me about both wxWindows and fox is that the
standard widgets lack sensible default handlers and behaviours.
--
Robin Becker

_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] newbie questions

Robin Dunn
In reply to this post by Robin Becker-7
> Hi I'm trying to get into wxPython and have a number of probably stupid
> questions.
>
> 1) Why is it assumed that C++ documentaion is sufficient? I know enough
> C++, but find the wxWindows documentation a bit confusing.

Because maintaining a completly separate set of documents for virtually the
same thing is something I don't want to spend all my time on.  When a C++
developer makes a change to the C++ class, it affects the wxPython class
too.  If he updates the C++ docs to reflect the change then I don't have to
do anything except maybe add/modify method definitions.  If I had to track
all the documentation changes too then it would either become hopelessly out
of date very fast or wxPython would grow very slowly.

On the other hand, there is an effort underway create a tool for maintaining
wxPython specific documentation.  It will hopefully be able to suck initial
information from some of the SWIG output and maybe from the C++ docs too.
I'll defer and let Erik comment on its status when he is ready.


> It is also a
> bit out of date eg I can't seem to find the border sizer.

The original wxBoxSizer and the wxBorderSizer were Python-only classes and
not part of the C++ library, and so were not part of the C++ docs.  (This is
where Erik's project will come in handy, but in the meantime I will probably
be adding a new section to the wxWindows docs to handle things like this.)

On a related note, now that wxSizer and friends are part of the C++ library,
their Python-only implementation will be phased out, mainly because there is
a tighter integration with wxWindow and friends in the C++ lib.  I plan on
making them fully subclassable so custom sizers can still be done easily in
Python.


> 2) Why is the wrapping so thin?

Mainly because of the documentation issue!  <wink>

> I think the spirit of python would
> suggest that coordinates & sizes could be simply specified as (x,y) or
> (w,h) (or the list equivalents) rather than as wxPosition(x,y) &
> wxSize(w,h).

I actually got started on this a couple days ago.  In the next release
you'll be able to use either wxPoints, etc. or tuples/lists interchangeably.

> What are all the rather exotic registry type functions etc
> doing in a Gui toolkit?

Are you refering to wxConfig?  It just made sense that a cross platform GUI
should have a cross platform way of storing configuration information that
was close to the native way of doing it.

You would be surprised (I was) at how many requests I have had for some of
the non-GUI parts of wxWindows to be wrapped into wxPython.  My initial
policy was that anything you could already do fairly easily in Python I
would not wrap, but I am begining to change my mind on several of them...
Fortunately it is now easy to create separate add-on modules for wxPython so
these things won't have to bloat the core module.


>
> 3) I see claims that this is much better than Tkinter. It certainly
> looks good, but I think programming it is more difficult (at least for
> me).

It is because Tkinter gives me a raging headache everytime I try to learn it
that wxPython continues to be developed.  So I guess despite the common
first name we are opposites.


> Why do I need integer identifiers for some kinds of thing and in
> wxPython at least why aren't they completely hidden ie controlled by the
> toolkit.
>

It has to do with how events are routed and seems fairly intuitive to me.
If you have ideas on how the ID hiding could be accomplished, I would be
interested in hearing about it.


> 4) The more complex widgets look to be ideal candidates for internal
> structure, but I'm not sure I can figure out how to make use of them.
> For example I would like to put a 4 by 4 grid into a border sizer and
> have both rows and columns expand appropriately. Alternatively have the
> rows fixed size and expand say the last column. I tried a few things,
> but couln't get the behaviour I needed.

Sizers are real new, and there is not a grid sizer yet, though it is high on
my list of must-haves.  Depending on what kind of windows are in your
sizers, you might be able to get an approximation of a grid by nesting
vertical boxes within horizontal boxes, or maybe the other way around.  But
probably the best alternative for now is wxLayoutConstraints.

>
> 5) I know this is a beta, but on my win95 osr2 system the demo code
> vertical scrollbar had some very exotic effects (giant white patches
> across the whole screen). I cannot reproduce this easily, but have seen
> it twice.

I don't think I have seen anything like this since the 0.3 days (Python 1.2,
windows 3.1 and wxWindows 1.5.something, IOW a REAL long time ago.)  If you
can narrow it down at all I would really appreciate it.  Once you do if you
could try the same thing on a machine with a different video card abd/or
video driver that would be nice too.

>
> Sorry to start out nitpicking; the overall look is good, but I need more
> than that to convince me to abandon Tkinter. So is there anything easy
> to help me convince myself.

If Tkinter is closer to the way you think, then by all means stick with it.
Tkinter just doesn't match the way I think, and apparently from what I have
been hearing, a lot of people fall into that area as well.  However I do
encourage you to keep playing with and exploring wxPython.  Who knows, you
may have an "Ah ha!" experience and suddenly start getting headaches when
you try to use Tkinter! <grin>

--
The other Robin


_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users



Reply | Threaded
Open this post in threaded view
|

Re: [wxPython] newbie questions

Robin Becker-7
In article <00a601befa28$ea0d0430$[hidden email]>, Robin Dunn
<[hidden email]> writes
...

>
>If Tkinter is closer to the way you think, then by all means stick with it.
>Tkinter just doesn't match the way I think, and apparently from what I have
>been hearing, a lot of people fall into that area as well.  However I do
>encourage you to keep playing with and exploring wxPython.  Who knows, you
>may have an "Ah ha!" experience and suddenly start getting headaches when
>you try to use Tkinter! <grin>
>
>--
>The other Robin
>
...
undoubtedly the Tk/Tcl is the way I have thought up to now. I wanted
trivet to succeed, but that seems unlikely. If not then Fox/wx must be
my bag as the alternatives are too frightful with billy goats etc. If I
can help with oddities I certainly will.
--
Robin Becker

_______________________________________________
wxPython-users maillist  -  [hidden email]
http://starship.python.net/mailman/listinfo/wxpython-users