Awhile back someone said they were doing some work on wrapping the
FrameLayout class in wxPython. I can't seem to find the mails anymore
so don't remember who-- anyone have any idea if there's been any
progress?
Thanks in advance!
--Ix
IxokaI wrote:
Awhile back someone said they were doing some work on wrapping the
FrameLayout class in wxPython. I can't seem to find the mails anymore
so don't remember who-- anyone have any idea if there's been any
progress?
Not that I know of. The thing that worries me about wxFrameLayout is that it looks to be following the same path that the C++ OGL library is on. It doesn't seem to be very well maintained, and so if it did get wrapped for Python it risks to be difficult to understand for most people and difficult to get problems fixed. On the other hand, it is all generic code and so if there is enough interest to have it in wxPython then it could be ported to Python code as OGL was and then every one who uses it from Python would also be qualified to fix bugs and enhance it.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Hmm, looking at the code, it does appear to be basically straight wx,
so maybe such a port would be fairly straightforward.
We need this functionality pretty darn badly to get the interface we
want, so I'll see if The Powers will allocate time. Doubtful,
deadlines! aah! We'll see, we'll see.
I've never done wx C++ to wxPython porting before-- never actually
used wx in C++ at all. When the OGL stuff was ported, was there any
Gotcha's that you remember that might cause a problem?
--Ix
···
On Tue, 21 Sep 2004 12:05:46 -0700, Robin Dunn <robin@alldunn.com> wrote:
IxokaI wrote:
> Awhile back someone said they were doing some work on wrapping the
> FrameLayout class in wxPython. I can't seem to find the mails anymore
> so don't remember who-- anyone have any idea if there's been any
> progress?Not that I know of. The thing that worries me about wxFrameLayout is
that it looks to be following the same path that the C++ OGL library is
on. It doesn't seem to be very well maintained, and so if it did get
wrapped for Python it risks to be difficult to understand for most
people and difficult to get problems fixed. On the other hand, it is
all generic code and so if there is enough interest to have it in
wxPython then it could be ported to Python code as OGL was and then
every one who uses it from Python would also be qualified to fix bugs
and enhance it.--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
IxokaI wrote:
Hmm, looking at the code, it does appear to be basically straight wx,
so maybe such a port would be fairly straightforward.We need this functionality pretty darn badly to get the interface we
want, so I'll see if The Powers will allocate time. Doubtful,
deadlines! aah! We'll see, we'll see.I've never done wx C++ to wxPython porting before-- never actually
used wx in C++ at all. When the OGL stuff was ported, was there any
Gotcha's that you remember that might cause a problem?
Hopefully Pierre will answer as he did the majority of the work, but from some of the bugs that have been corrected afterwards I have some that I can share:
* Watch the case on similar methods names. wxList has Append() but when you port it and use a Python list it is append()
* Keep in mind that your functions may not be getting wx.Point, wx.Size, wx.Colour and etc. instances in the parameters, but sequences (or strings for colours). So decide up front how you are going to use the objects internally (as a sequence/string or a wx object) and ensure that any member variables that you save are in the right format. (If you are just passing it on to some wx function you don't need to do anything) For sequences you can do this trick:
self.pt = wx.Point(*pt)
and it will then convert pt to a Point and it will even work if it was a Point already.
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn <robin@alldunn.com> writes:
> IxokaI wrote:
> > Hmm, looking at the code, it does appear to be basically straight wx,
> > so maybe such a port would be fairly straightforward.
> >
> > We need this functionality pretty darn badly to get the interface we
> > want, so I'll see if The Powers will allocate time. Doubtful,
> > deadlines! aah! We'll see, we'll see.
> >
> > I've never done wx C++ to wxPython porting before-- never actually
> > used wx in C++ at all. When the OGL stuff was ported, was there any
> > Gotcha's that you remember that might cause a problem?
> >
>
> Hopefully Pierre will answer as he did the majority of the work, but
> from some of the bugs that have been corrected afterwards I have some
> that I can share:
>
> * Watch the case on similar methods names. wxList has Append() but when
> you port it and use a Python list it is append()
>
> * Keep in mind that your functions may not be getting wx.Point, wx.Size,
> wx.Colour and etc. instances in the parameters, but sequences (or
> strings for colours). So decide up front how you are going to use the
> objects internally (as a sequence/string or a wx object) and ensure that
> any member variables that you save are in the right format. (If you are
> just passing it on to some wx function you don't need to do anything)
> For sequences you can do this trick:
>
> self.pt = wx.Point(*pt)
>
> and it will then convert pt to a Point and it will even work if it was a
> Point already.
>
The port of OGL was pretty straightforward but there are some things to watch
out for...
* Remember that code can be in both header files and c++ files.
* Python is much more lenient with memory resources (we have a GC after all),
so when the C++ code traverses a list and releases every member, you
can often just skip that or if the list is to be used again, just
do l = []
* If you're going to be backwards compatible, be aware of int/float issues.
Just because the c++ code does f = x / 2 doesn't mean you can (f is float,
x is int).
* After a while you will start to recognize some patterns, when you do, go
over your previous code and see if you have missed it earlier. One example
is looping over a list:
wxNode *node = m_children.GetFirst();
while (node)
{
wxShape *child = (wxShape *)node->GetData();
...
}
which in python would be:
for child in self._children:
...
As you see, I converted m_xxx to self._xxx. That just seemed the sensible
thing to do.
* And also, always think: Is there a python built-in/library to do this?
Don't do work you don't have to. I did on occasion and it's not fun when
you realise it.
Well, there's probably a lot more that could be said, let me know if you'd
like any more info/help.
···
--
Pierre Hjälm