Re: [Pythoncard-users] why is the framework changing?

Kevin,

As silence counts as acceptance on this list I think your proposal is 
unanimously approved.

For what its worth, I don't mind exposing more of wxPython in the 
framework as long as it is as simple and pythonic as possible.

I'd like to echo your point below, as long as PythonCard is a powerful, 
but simple to use framework I believe it will be useful. Providing more 
meaningful and straight forward ways to build GUI applications can only 
be a good thing. We just need to focus on that goal and always apply the 
KISS principle. That way we may go down some dead ends but we will 
always be moving in the right direction. Simplicity for me has two 
meanings here; the code a developer writes to get a working application 
in PythonCard should be as simple as possible and the framework itself 
should be simple and easy to understand. I'll leave it to the TimBot to 
justify my ramblings;

"""
1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one -- and preferably only one -- obvious way to
do it.
14. Although that way may not be obvious at first unless you're
Dutch.
15. Now is better than never.
16. Although never is often better than *right* now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- let's do more of those!

     -- Tim Peters' 19 Pythonic Theses, 4 Jun 1999
"""

And yes, number 3 is my favourite.

Kevin Altis wrote:

> 0.5.3 is the last prototype release that will make any pretense of hiding
> wxPython. The changes that Rowland and I started checking into cvs today are
> going to expose wxPython directly. The main focus of these changes is to
> leverage the power of wxPython and provide helper classes and wrappers where
> needed to simplify some of the more difficult aspects of wxPython. I'll go
> into the details of these changes in another message. First I want to
> clarify the "why". This is a big deal for the future of PythonCard.
> 
> First of all, I see only two usable solutions for a cross-platform GUI
> toolkit for Python. Tkinter is the obvious choice because it ships with
> Python and works on just about every platform that Python runs on. For
> various reasons outlined in past messages to the list I don't like or want
> to use tkinter. The other solution is wxPython and that is where I'm putting
> my effort.
> 
> Last month I spent time trying to create interest in a wxPython-specific
> application framework. While the idea didn't get much attention on the
> wxPython-users list, at least from people willing to do development work, it
> did help my thinking about PythonCard. I still wanted PythonCard features
> such as resource files, default attribute initialization, automatic event
> binding, and dot notation attributes. I also wanted to use more of the
> wxPython classes without having to wrap them with PythonCard-specific
> classes and method names. If possible, I also wanted to be able to rely on
> the wxPython documentation for most of the classes rather than having to
> create a completely separate documentation set. The 'state of the framework
> messages' and 'future direction of PythonCard' threads on the list also
> helped focus my thinking. You might want to go and read through some of the
> archives.
> 
> In the end, it didn't seem like there was anything particularly bad or
> difficult about the wxPython events or classes. The problem is the code
> overhead and learning curve you have to climb in order to use them even for
> a simple app. Another big issue, is that the documentation is presented from
> the standpoint of C++ instead of Python. Robin has said that the
> documentation issue will be addressed sometime after 2.3.2 is released. That
> probably fits into the same Real Soon Now universe that the Mac wxPython
> port exists in, but I'm confident it will get done; wxPython Mac is
> compiling now, it just isn't running correctly.
> 
> So, while exposing wxPython is a major change in the framework and requires
> some reworking of the existing samples, I don't think it strays from the
> real purpose of PythonCard (to me at least), which is to create a powerful,
> but simple to use, cross-platform GUI software construction kit for Python.
> 
> This is an open source project, if you feel this move is bad and disagree
> with the direction we're taking, then you need to speak up. You can always
> use release 0.5.3 or any earlier releases for projects that you want to hide
> wxPython or to use as the basis for a framework that might work on top of
> another GUI toolkit such as tkinter. I won't be spending any effort in that
> direction. The PythonCardPrototype 0.5.3 zip is in the files section and all
> of the files are tagged as proto-0_5_3 in cvs, so anyone can go back to
> 0.5.3 if they need to.
> 
> ka
> 
> 
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> 
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Another year older, still no wiser." - Me, on my birthday