fox 1.2.x and FXPy

[Asier]

Is there any plan to make bindings of the future fox toolkit 1.2.x for
python? New widgets, antialiased fonts and so on is a "Good Thing".

GTK is a pain, wxpython is horribly slow, and tkinter doesn't have
good look and widgets are too basic.

The bindings in http://fxpy.sf.net are very old and python 2.3 isn't
supported.
If you need bindings for linux it compiles without problems, but under
Windows+VC6 I've had lots of problems, so after a lot of tries I've
compiled the bindings of fox 1.0.51 for windows with jpeg+png+zlib
support, with the mingw32 (gcc 3.3.1) suite (uffs!!!) for python
2.3.x.

It seems to work reasonably well. If anyone is interested in the
package I can e-mail it (tar.bz2, weights about 2MB)

I've tried the tnfox bindings but they are very slow and need some
non-standard libraries from msvc 7.1 and openssl.

--
Asier.

[Peter Hansen]

Asier wrote:

Is there any plan to make bindings of the future fox toolkit 1.2.x for
python? New widgets, antialiased fonts and so on is a "Good Thing".

GTK is a pain, wxpython is horribly slow, and tkinter doesn't have

^^^^^^^^^^^^^^^^^^^^^^^^^
Your experience is clearly at odds with what most other people report
about wxPython. (And, I might add, about GTK, as far as I can tell,
though I haven't used it myself.)

-Peter

[Josiah Carlson]

>> Is there any plan to make bindings of the future fox toolkit 1.2.x for

python? New widgets, antialiased fonts and so on is a "Good Thing".

GTK is a pain, wxpython is horribly slow, and tkinter doesn't have

^^^^^^^^^^^^^^^^^^^^^^^^^
Your experience is clearly at odds with what most other people report
about wxPython. (And, I might add, about GTK, as far as I can tell,
though I haven't used it myself.)

Agreed. I've never felt wxPython was slow, and have heard that PyGTK is
comparable (in terms of features, ease of use, etc.) to wxPython.

- Josiah

[Asier]

Peter Hansen <pe***@engcorp.com> wrote in message

GTK is a pain, wxpython is horribly slow, and tkinter doesn't have

^^^^^^^^^^^^^^^^^^^^^^^^^
Your experience is clearly at odds with what most other people report
about wxPython. (And, I might add, about GTK, as far as I can tell,
though I haven't used it myself.)

GTK is a pain because it's design doesn't fit well in my brain. Yes, I
know it isn't a good reason, but I feel more comfortable with other
approachs. I must say that pygtk is the best binding in terms of
support and features.

And I say wxPython is slow because startup time. I must develop for
old systems (Pentium 200, 64MB RAM) and takes a very long time to
start. That's a big step. If you have recent hardware wxpython is
great, but with old systems IMHO it's slow.

I like FXPy because it's very fast, has a lot of widgets and works
reasonably well.

--
Asier.

[Lothar Scholz]

ka******@gmx.net (Asier) wrote in message news:<4e**************************@posting.google. com>...

Is there any plan to make bindings of the future fox toolkit 1.2.x for
python? New widgets, antialiased fonts and so on is a "Good Thing".

I don't think that Lyle will put more work in the project and it will
be a lot of work to get 1.2.x running. Even the ruby bindings that are
actively under development are still 1.0.x

If you don't like GTK or WxWidgets you should look at the FLTK
bindings.

[David Bolen]

Josiah Carlson <jc******@nospam.uci.edu> writes:

Is there any plan to make bindings of the future fox toolkit 1.2.x for
python? New widgets, antialiased fonts and so on is a "Good Thing".

GTK is a pain, wxpython is horribly slow, and tkinter doesn't have

^^^^^^^^^^^^^^^^^^^^^^^^^
Your experience is clearly at odds with what most other people
report about wxPython. (And, I might add, about GTK, as far as I
can tell, though I haven't used it myself.)

Agreed. I've never felt wxPython was slow, and have heard that PyGTK
is comparable (in terms of features, ease of use, etc.) to wxPython.

Well, as long as you don't include startup time I'd agree, but it is a
bit bloated in terms of loading that initial support DLL, which
includes potentially far more of wxWindows (oops, wxWidgets) than a
given application needs.

Of course, you could rebuild the DLL removing support for the various
stuff you don't currently need, but that's not too convenient for
maintaining over time, and not everyone has the facilities for
rebuilding the wxPython DLL from wxWidgets source.

I seem to recall reading that 2.5.x might contain (or support)
fracturing the main monolithic DLL into well-defined smaller pieces
that hopefully will improve this.

-- David