[Tfug] wxWidgets

[Bexley Hall]

Hi, Chris,

[wxPython]

> I didn't think the documentation for wxPython was always all that
> thorough either, for what that's worth.

<shrug>  People usually slack off on documentation and testing,
IME.  Silly as these are oftyen more important than the code
itself!  :<

> Nevertheless I was able to use wxPython,
> leaning sometimes on the extensive example code in the
> official wxPython demo.
> 
> I found that wxPython includes layout components that are
> specifically designed to produce "panels" (as you call them)
> that are smart enough to resize themselves within a user-resized window.

But does this resizing extend to the widgets within?  E.g., can
you have a listbox *within* that "box" (frame?) also grow to match
the growh of the "box" that contains it?

> I myself used components like wxBoxSizer (aka BoxSizer).
> Based on what I saw when I used them, I believe these
> should readily handle all the example requirements cases that you gave.

OK, I'll spend some time plowing through the examples just to get
a better feel.

> There are multiple alternatives for layout in wxPython,
> so if you choose a totally different layout method that has
> no connection to wxBoxSizer, my comments might not apply.
> 
> My development was more oriented around specifying the
> layout I wanted
> in code than using "grab-n-drag" type GUI drawing
> tools, so I can't comment on the latter.

Yes, in limbo-tk I did the same -- I wrote a "packer" that
would let me specify my widgets in a "table" (array)
and just have the packer take that array and build the screen
from it for me.  I.e., keeps the code *really* tiny (a few
*K* for a screen).

> I wrote & used software that called wxPython on some
> different Windows boxes, of which the slowest was a supposed
> "500 GHz" CPU box,
> but maybe kind of slow for that.  If I had a complicated

Yeah, anything les than a few THz is slow under windows!  ;-)

> GUI (and I did in one app, with 80-90 visible controls and
> multiple levels
> of nesting) redraw could then take a good fraction of a
> second on that old semi-500 GHz box.
> Using post-2001 computers, *or* a simpler GUI,
> you should hope for faster redraw on resize. :-)

Goal is (always) to use *slow* (cheap) hardware.  I.e., not
needing a few gazillion CPU cycles just to draw an image
(and then spend a few jigazillion more CPU cycles in a tight
spin waiting for the user to do something!  :< )

> I know there's a bundled all-in-one wxPython installer
> (for Windows at least)
> but it packs a significant amount of stuff in it--
> I think a version of MFC is even included in that Windows
> verison. MFC does *NOT* have a tiny footprint, IMHO.

I suspect Python with wxWidgets isn't particularly small, either!
<frown>  E.g., I can do a limbo-tk system for a few MB (including
the actual application) if I ran it native.  :-/

> I would guess the wx installers for non-Windows OSes would
> likely have a smaller footprint, as no one in their right
> mind would rely on MFC to implement GUIs for those systems. :-)
> 
> I do wonder, what non-Windows systems are you very
> interested in supporting?

Think "kiosks", "control panels" (for instruments), etc.
Why put a disk drive and a bloated OS in a machine if you
don't *have* to?  (just that much more stuff that can
"go wrong" and that must be tested/documented/etc.)

Thanks!
--don
> --Chris