PyFLTK - an underrated gem for GUI projects

[Claudio Grondi]

> So I hope this humble message might inspire some folks to have a serious
> look at pyfltk. For many situations, PyFLTK can take you to break-even
> point quickly, and deliver net savings in time and effort after that.

Animated by your posting I have downloaded:
  fltk-1.1.6-source.zip  (3.073.432 bytes)
  pyFltk-1.1rc1.tar.gz     (306.323 bytes)
.
I use Microsoft Windows 2000 (and/or XP) with installed
MSVC++ .NET 2003 compiler environment and I am running
Python version 2.4.2.

The compilation of FLTK run without problems and after some minor
adjustments I was also able to build and install pyFltk.

Running some of the test examples
(e.g. C:\Python24\pyfltk\test\doublebuffer.py)
I am getting an error I have never seen before:

==============================================================
TitleOfMessageBox:
  Microsoft Visual C++ Runtime Library

TheMessage:
  Runtime Error!

  Program: C:\Python24\python.exe

  The application has requested the Runtime to terminate it in an unusual
way.
  Please content the application's support team for more information.
==============================================================

Also cube.py (which runs ok as fltk-1.1.6\test\cube.exe i.e. the  genuine
FLTK test app as also the doublebuffer.exe does) crashes in the pyFLTK
version with:

C:\>C:\Python24\pyfltk\test\cube.py
Traceback (most recent call last):
  File "C:\Python24\pyfltk\test\cube.py", line 218, in ?
    form.show(len(sys.argv), sys.argv)
  File "C:\Python24\Lib\site-packages\fltk.py", line 2164, in show
    def show(*args): return _fltk.Fl_Window_show(*args)
TypeError: Swig director python method error: Error detected when calling
Fl_Group.handle.
 argument number 1: a 'Fl_Group *' is expected, 'MyBox' is received

Most of the other test scripts seem to run ok.

Any hints about the possible reasons of the problems described above are
welcome.

It appears to me, that the
 C:\Python24\Lib\site-packages\_fltk.pyd  and the *.py files
is all what is required to run pyFltk, so there will be no problem for
pyFltk if I delete the genuine FLTK files - am I right?

Claudio
P.S. If someone is interested in getting the _fltk.pyd (the pyFLTK Windows
binary version for Python 2.4), he/she is welcome to let me know about it.


"aum" <aum at spam.me.please> schrieb im Newsbeitrag
news:pan.2005.11.07.00.23.39.597631 at spam.me.please...
> Hi all,
>
> I've been doing a fair bit of python gui programming on and off, jumping
> between different widget sets along the way, from anygui, to pythoncard,
> to tkinter/PMW, then to wxPython/wxGlade, and have now settled on a python
> gui API that seems to get barely a mention - PyFLTK.
>
> PyFLTK (http://pyfltk.sourceforge.net) is a SWIG-generated Python
> wrapper around the multiplatform FLTK widget set ('Fast Light Tool Kit'
> - http://fltk.sourceforge.net). In recent months, this wrapper has
> stabilised to the point where it's fit for production projects.
>
> A recent development that's given PyFLTK even more power is the
> companion utility program, 'flconvert', which takes gui layout files
> (created with the FLTK 'fluid' gui designer program) and turns them into
> importable Python modules that Simply Just Work.
>
> Every widget set has its place, and I feel this applies in no small part
> to PyFLTK.
>
> To me, wxPython is like a 12-cylinder Hummer, with fuzzy dice hanging
> from the mirror, fridge and microwave in the back, and DVD consoles on
> every seat, towing a campervan - absolute power and luxury, giving 8mpg
> if you're lucky.
>
> wxPython has the cost of a massive disk and memory footprint. A 'hello,
> world' turned into a windoze exe with py2exe weighs in at around 15MB,
> and takes 6-10 seconds to load up on a 2GHz Athlon box, about as long as
> Photoshop! For large and intricate apps, wxPython is a logical choice,
> but for smaller progs it's serious overkill IMHO.
>
> Whereas PyFLTK feels more like an average suburban 4-door sedan giving
> 70mpg, nothing too flash, but easy to drive, easy to park and generally
> comfortable, and easy to look after. The widget set is pretty simple,
> but covers all the basics and includes good rich-text features in
> listboxes, as well as an html viewer that supports html2.0 and parts of
> html3.0.
>
> Some of the things I'm liking about PyFLTK include:
>  - way less code to get things done
>  - some nice automagic, for instance in setting up tiling (similar to
>    wx's splitter windows)
>  - an absolute minimum of 'voodoo programming' (which was a constant
>    bugbear for me with tkinter)
>  - apps compile small, and start up fast
>  - a really good designer program - fltk's 'fluid' program is light
>    years ahead of wxglade imho
>
> Also, FLTK's intuitive, semantically clear API makes it really
> approachable for newcomers. One can write a 'hello, world' in 5 lines:
>
>   import fltk
>   label = "something here" # to stop string being gc'ed
>   w = fltk.Fl_Window(100, 100, 300, 200, label)
>   w.show()
>   fltk.Fl.run()
>
> So I hope this humble message might inspire some folks to have a serious
> look at pyfltk. For many situations, PyFLTK can take you to break-even
> point quickly, and deliver net savings in time and effort after that.
>
> -- 
> Cheers
> David
>
> -- 
> Cheers
> David
>