470,647 Members | 1,389 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,647 developers. It's quick & easy.

fox 1.2.x and FXPy

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.
Jul 18 '05 #1
5 1776
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
Jul 18 '05 #2
>> 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
Jul 18 '05 #3
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.
Jul 18 '05 #4
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.
Jul 18 '05 #5
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
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Benjamin | last post: by
5 posts views Thread by Jonathon McKitrick | last post: by
3 posts views Thread by Roland | last post: by
27 posts views Thread by xeys_00 | last post: by
1 post views Thread by Kenneth McDonald | last post: by
4 posts views Thread by fabdeb | last post: by
1 post views Thread by Korara | last post: by
reply views Thread by warner | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.