PythonCard thoughts

[king kikapu]

Hi to all folks here,

i downloaded and "playing" with PythonCard and i just want to share my
thoughts so maybe we can discuss a little about it.
I was used to wxGlade before and i think PythonCard is even better.
I like the separate implementation of GUI and Code that PythonCard
provides, i also like the "binding system" so you can bind functions
to events and have them executed at runtime.
I also like that it does not force you to use sizers and all that
stuff and that you can freely place your components on the form and
set their exact position just with the mouse.

The only "problem" i see with this design is that by that separation
of Gui/Code, you loose the intellisense that (ex. PyDev) some editors/
plugins can provide because in the .py file nothing is indicating
that , for example, the btnDoWork is a Button object.
This force you to remember many properties and switch back and forth
between your code and the wxPython help file. This is not the case for
wxGlade because all boilerplate code is in the same file (for good and
for bad) and PyDev (and others too) can "understand " for which kind of
objects we are talking about and so can display -and thus help us-
with their properties.

Apart from that, everything else is great.

Any opinions/suggestion on all this ?

[John Salerno]

Re: PythonCard thoughts

king kikapu wrote:

The only "problem" i see with this design is that by that separation
of Gui/Code, you loose the intellisense that (ex. PyDev) some editors/
plugins can provide because in the .py file nothing is indicating
that , for example, the btnDoWork is a Button object.
This force you to remember many properties and switch back and forth
between your code and the wxPython help file. This is not the case for
wxGlade because all boilerplate code is in the same file (for good and
for bad)

I don't know much about PythonCard or wxGlade, but I use wxPython (which
wxGlade uses, right?) and you now have the option to separate your GUI
and code using an XRC file (xml file that describes layout). So perhaps
this is something you can do with wxGlade, but at the same time it might
still create the problem you describe above. However, it's very to have
your Python files contain just logic.

[king kikapu]

Re: PythonCard thoughts

I don't know much about PythonCard or wxGlade, but I use wxPython (which

wxGlade uses, right?) and you now have the option to separate your GUI
and code using an XRC file (xml file that describes layout). So perhaps
this is something you can do with wxGlade, but at the same time it might
still create the problem you describe above. However, it's very to have
your Python files contain just logic.

Yes, both products (PythonCard and wxGlade) uses wxPython. It's just
that PythonCard is sitting on top of wxPython and it intercepts the
events generated. Then it search for an appropriate declared function
on your code and call it (all this happens at runtime).
It shield us from much of the boilerplate code that gui toolkits
require and in the case that you need to address directly wxPython,
you just can!

I discovered that when you run your designed GUI from PythonCard's
layoutEditor, you have the ability to define a command line option
that is called
"Message Watcher". This, will show you the names of the actual events
that you have to write code for, so you, at least for this, do not
have
to dig the docs for their names. Pretty good!

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

Re: PythonCard thoughts

On Mar 19, 11:44 am, "king kikapu" <aboudou...@pan afonet.grwrote:

I don't know much about PythonCard or wxGlade, but I use wxPython (which
wxGlade uses, right?) and you now have the option to separate your GUI
and code using an XRC file (xml file that describes layout). So perhaps
this is something you can do with wxGlade, but at the same time it might
still create the problem you describe above. However, it's very to have
your Python files contain just logic.

>
Yes, both products (PythonCard and wxGlade) uses wxPython. It's just
that PythonCard is sitting on top of wxPython and it intercepts the
events generated. Then it search for an appropriate declared function
on your code and call it (all this happens at runtime).
It shield us from much of the boilerplate code that gui toolkits
require and in the case that you need to address directly wxPython,
you just can!
>
I discovered that when you run your designed GUI from PythonCard's
layoutEditor, you have the ability to define a command line option
that is called
"Message Watcher". This, will show you the names of the actual events
that you have to write code for, so you, at least for this, do not
have
to dig the docs for their names. Pretty good!

Would you please explain more in detail this "Message Watcher" option?
I use PythonCard from time to time, and I find it very easy to use and
practical, even considering the small shortcomings you mentioned
above, but I have no idea of this feature you're talking about..

Regards,
Luis

[king kikapu]

Re: PythonCard thoughts

Would you please explain more in detail this "Message Watcher" option?

I use PythonCard from time to time, and I find it very easy to use and
practical, even considering the small shortcomings you mentioned
above, but I have no idea of this feature you're talking about..
>
Regards,
Luis

Luis, go to File/Run Options and check the third choice called
"Message Watcher", then run your design.
You will then see that every event that is triggered is displayed to
you and when you actually want to see the event that you interested
in,
you just cause it to happen and then it is displayed on the message
watcher event grid.
You then go to your source file and armed with the known notation
(on_controlName _eventName) you write the code.

I copy from the manual of PythonCard:
"The Message Watcher integrates with the wxPython event model to show
you in real time the events that are being triggered when a PythonCard
application is running. It helps determine where the application code
should go and verify that a PythonCard application is operating as
expected."

[Steve Holden]

Re: PythonCard thoughts

king kikapu wrote:

>I don't know much about PythonCard or wxGlade, but I use wxPython (which
>wxGlade uses, right?) and you now have the option to separate your GUI
>and code using an XRC file (xml file that describes layout). So perhaps
>this is something you can do with wxGlade, but at the same time it might
>still create the problem you describe above. However, it's very to have
>your Python files contain just logic.

>
Yes, both products (PythonCard and wxGlade) uses wxPython. It's just
that PythonCard is sitting on top of wxPython and it intercepts the
events generated. Then it search for an appropriate declared function
on your code and call it (all this happens at runtime).
It shield us from much of the boilerplate code that gui toolkits
require and in the case that you need to address directly wxPython,
you just can!
>
I discovered that when you run your designed GUI from PythonCard's
layoutEditor, you have the ability to define a command line option
that is called
"Message Watcher". This, will show you the names of the actual events
that you have to write code for, so you, at least for this, do not
have
to dig the docs for their names. Pretty good!
>

The only real problem is that PythonCard appears to have run out of
development steam. I don't think there's been much^H^H^H^H any work on
it in the past year or two. This is a shame, as it showed considerable
promise.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

[John Henry]

Re: PythonCard thoughts

On Mar 19, 5:08 am, "king kikapu" <aboudou...@pan afonet.grwrote:

Hi to all folks here,
>
i downloaded and "playing" with PythonCard and i just want to share my
thoughts so maybe we can discuss a little about it.
I was used to wxGlade before and i think PythonCard is even better.
I like the separate implementation of GUI and Code that PythonCard
provides, i also like the "binding system" so you can bind functions
to events and have them executed at runtime.
I also like that it does not force you to use sizers and all that
stuff and that you can freely place your components on the form and
set their exact position just with the mouse.
>
The only "problem" i see with this design is that by that separation
of Gui/Code, you loose the intellisense that (ex. PyDev) some editors/
plugins can provide because in the .py file nothing is indicating
that , for example, the btnDoWork is a Button object.
This force you to remember many properties and switch back and forth
between your code and the wxPython help file. This is not the case for
wxGlade because all boilerplate code is in the same file (for good and
for bad) and PyDev (and others too) can "understand " for which kind of
objects we are talking about and so can display -and thus help us-
with their properties.
>
Apart from that, everything else is great.
>
Any opinions/suggestion on all this ?

(If I understand your question correctly)

There is no restirction on what you call your objects. For instance,
I do call all of my buttons btnSomeThing, and so forth. If you use
the codeEditor that comes with Pythoncard, you can easily see which
method goes with what control.

(And yes, I wish there are more developers drawn to Pythoncard too -
it's such a nice package).

[king kikapu]

Re: PythonCard thoughts


Ï/Ç John Henry Ýãñáøå:

(If I understand your question correctly)
>
There is no restirction on what you call your objects. For instance,
I do call all of my buttons btnSomeThing, and so forth.

No, i surely didn't mean this! What i mean is that the creation of
these components happens to NOT reside in the .py file that we are use
to put our logic in, so, the various Editors/Plug-ins cannot
"understand " what type is the object we refer to so they cannot
provide intellisense information.

Let' say for example, that we create a design in PythonCard that
contains a form and just one butto named btnStart. In our .py file we
want to refre to that button in a way such:
self.components .btnStart

At this point, if we had the code that created this button in our
file, PyDev (for example) would show us the properties of btnStart
because it has understood that we are using a wx.Button.

This is not the case of thePython card because this creation is
happened to runtime by...PythonCard !

Anyway, it is not that important from keeping me from using
PythonCard.

Do we know more things about the developing of this product, is it
active/dead or something ??
I plan to use it to create something that will take a long time to
finish and i wouldn't want to find out that the product is a dead-
end...

[John Henry]

Re: PythonCard thoughts

>

Do we know more things about the developing of this product, is it
active/dead or something ??
I plan to use it to create something that will take a long time to
finish and i wouldn't want to find out that the product is a dead-
end...

There is still "some" development work going on but as with *all* open-
source volunteer based projects, there is *no* gurantee that any of
these software projects not be "dead-ended". How many projects at
SourceForge are still "alive"? No different from any commercial
project, for that matter.

On the other end, being an open-source project, I myself isn't that
concerned. I found PythonCard fit my needs - it has been for several
years, and probably remain so for several years to come. The fact
that there has been no new widgets added to the project for a couple
of years didn't bother me because I have what I need. I have not run
into situations where my needs can not be met by learning from the
very extensive set of examples that matured with the package over the
years.

Do I wish that more developers pick up PythonCard and add new features
to it? Certainly. But then again, I don't have money to pay them.
What can I say? :=)