WxPython versus Tkinter.

rantingrick rantingrick at gmail.com
Wed Jan 26 14:59:11 EST 2011


On Jan 26, 1:02 pm, Nicholas Devenish <misno... at gmail.com> wrote:

> I look forward to reading your PEP and initial design documents, though
> I suspect you would need the latter and to get some a decent portion of
> work done before it would even be considered as an inclusion into the
> standard library.

Yes i want to create an API similar to Tkinter but we cannot mirror
exactly Tkinter because wx takes a completely different approach to
GUI building. We need to steal all the good attributes of Tkinter (and
there are quite a few!), learn from them, and evolve the next
generation of API. Tkinter will not be a waste because we will stand
on the shoulders of Tkinter and reach even higher! Some of the
worthwhile "must haves" are:

 * Geometry managers (pack, place, grid)

The geometry managers of Tkinter are just too beautiful to let die. Wx
forces you to use Sizers which are a terrible obstacle to the new GUI
programmer. And if you want focus traversal then you must also use
Panels. This multiplicity is just too ugly for a high level API like i
am suggesting. We will need some auto generation of panels and easier
to use Sizers wrapped up in a nice Tkinter Geometry Manager like API.
This will take some work. However it can be done.

 * Tagging systems for a TextCtrl and Canvas.

Although i challenged Guido on his argument about tagging, i do much
agree that tagging is a *very* powerful feature of the TK::Text and
TK::Canvas widgets and we should no doubt incorporate this into the
API. And this would be one of the easier aspects of the design.

 * Event binding

Here is another area for improvement. While wx has been moving towards
a more "Tkinter like" binding of widget events there is still much to
be desired. However the binding is not all bad so we should not spend
too much time here if only for very small payoffs.

 * Segfaults

We must protect Python users from segfaults. This is really a
wxPython's problem however we could insulate the programmer through
many techniques on our end. Like for instance: Recreating the columns
of a list control after configuration of a single style. However
configuration needs a look at also!

 * Styles

One of the things that always bothered me about Tkinter was lack of
styles. I know this has been addressed however in the past one would
create many widgets that should share a similar style but Tkinter
forced you to feed redundant style options to all of them. We need a
way to create style objects and then use them everywhere. I think wx
supports this already.

This is just a very meager list. Much more needs consideration.
However this would be a good launch point toward some stated and
attainable goals. There is already a quite mature (citaion needed)
start with a project called wax. Check it out here...

   http://wiki.wxpython.org/Wax


> Many capable developers have
> their own occupations and might not have the spare time or desire to
> spend on a project where all evidence suggests would be a
> (non-benevolent) dictatorship where they would be endlessly browbeaten.

Well i don't want to be a dictator. I believe that in any healthy
community, every member should be a king, however no ONE member ever
wears the crown. What i mean is, everyone has a special skill that
makes them stand out from the crowd. Something that you do better than
the other members. So when the needs of my skill-set are present, i
will step forth and lead, and when the needs of your skill-set are
present, i will sit back and listen and follow YOUR lead. This is how
the strongest groups tackle the largest problems with ease.

> You have continuously tried to outright present yourself as a
> 'visionary' and speaker for the python community and then asked why
> people don't take you seriously. People would take you a lot more
> seriously if you showed that you had the vision and capability to drive
> development of such a serious undertaking, and manage such a team of
> developers, whom you have first managed to attract to the project.

Agreed, and i hope to demonstrate these skills soon. However like i
mentioned in my last statement, i am not a god, much less a dictator.
No single man or woman can accomplish these huge problems alone. It
takes a team of united folks all simultaneousness willing to lead AND
follow when the time is right for the greater good of a common goal.

>
>   - Write some design documents, or even code, laying out what you think
> the interface should be.
>   - Put it out to the community, listen to advice, make changes (it will
> NOT be perfect) and gather support.
>

I believe we are in this stage now. However much more discussion is
needed.



More information about the Python-list mailing list