pythoncard-users Mailing List for PythonCard (Page 9)

Just a word of warning for anybody thinking of upgrading to the latest
versions of wxPython and Python on Vista...
...you might want to wait a bit, or be prepared for some code twiddling.
After installing Python 2.6 + wxPython 2.8.9.2 I found that most of the
PythonCard sample applications would crash after a few seconds. Then
some of the wxPython demos started failing too. 
At first I thought it might be because I'm running Vista via VirtualBox
on my Mac. Then I discovered via the wxPython mailing list:
<http://trac.wxwidgets.org/ticket/10082>
and the likely cause:
<http://www.tejerodgers.com/snippets/2009/why-wxpython-crashes-python-26/
>
I'm running 32-bit and not wxPython 2.8.9.1 so it doesn't quite
match the bugtracker case, but having uninstalled everything and gone
with Python 2.5 instead for the time being everything is now working.
-- 
XXXXXXXXXXX

On Thu, 5 Mar 2009 14:54:20 +0530 GoWtHaM NaRiSiPaLli
<nar...@gm...> wrote:
> I am looking at a way to gracefully closing the PythonCard
> application and report back as log give some information or do the
> clean up before ending the script.
> To present a sample, heres some code written over minimal.py script.
>
> <snip> 
> 
> It never prints the statement in except whenever I end the program
> with ctrl + c.
> 
> On a normal loop, like this- It works and prints the statement..
>
> <snip> 
> 
> Is there an alternate way of doing this so that I can capture the
> keyboard interrupt before the script closes.
Are you actually able to shutdown the application with ctrl + c ? I
didn't expect it to work when I tried it here, and it didn't on Windows
or OpenBSD, so it's difficult to replicate the problem.
Since ctrl + c is the standard copy shortcut that didn't surprise
me...I would have expected to have to do some kind of special keyboard
event handling.
What operating system are you running?
-- 
XXXXXXXXXXX

Hi All,
I am looking at a way to gracefully closing the PythonCard application and
report back as log give some information or do the clean up before ending
the script.
To present a sample, heres some code written over minimal.py script.
====================================================
from PythonCard import model
class Minimal(model.Background):
 def on_initialize(self, e):
 self.test = 'test code'
 print 'Inside Init'
if __name__ == '__main__':
 app = model.Application(Minimal)
 print help(app)
 #app.RedirectStdio('output.txt')
 try:
 app.MainLoop()
 print 'Action after the loop'
 except (KeyboardInterrupt, SystemExit):
 print 'Program execution has been stopped by keyboard interrupt'
====================================================
It never prints the statement in except whenever I end the program with ctrl
+ c.
On a normal loop, like this- It works and prints the statement..
==========================
import time
try:
 while 1:
 time.sleep(1)
except KeyboardInterrupt:
 print 'Program execution has been stopped by keyboard interrupt'
===========================
Is there an alternate way of doing this so that I can capture the keyboard
interrupt before the script closes.
Thanks,
Gowtham N

Ah, right.
Windows XP
wxPython 2.8
On Sun, Feb 15, 2009 at 8:36 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote:
> On 2009年2月13日 09:37:00 -0800 Morgan Venable <ve...@gm...>
> wrote:
>
>> When I run the resulting application, the gauge component no longer
>> renders correctly.
>>
>> Instead of showing its usual orange progress boxes, it's whitish and
>> turns transparent as the gauge fills -- in my case you just see the
>> background color filling up the gauge.
>
> Well, I have to confess to still using the old McMillan utility, so I'm
> probably not going to be much help. What OS and version of wxPython is
> this?
>
> --
> XXXXXXXXXXX
>

On 2009年2月13日 09:37:00 -0800 Morgan Venable <ve...@gm...>
wrote:
> When I run the resulting application, the gauge component no longer
> renders correctly.
> 
> Instead of showing it's usual orange progress boxes, it's whitish and
> turns transparent as the gauge fills -- in my case you just see the
> background color filling up the gauge.
Well, I have to confess to still using the old McMillan utility, so I'm
probably not going to be much help. What OS and version of wxPython is
this?
-- 
XXXXXXXXXXX

Hi All,
I've got an odd little bug.
When I run from source, the gauge component works fine.
I'm packaging up my application with py2exe:
"python setup.py py2exe"
When I run the resulting application, the gauge component no longer
renders correctly.
Instead of showing it's usual orange progress boxes, it's whitish and
turns transparent as the gauge fills -- in my case you just see the
background color filling up the gauge.
Py2exe doesn't throw any build errors, and the gauge component is
included in the setup.py file below.
Is it possible I need to import something else explicitly in my source
to make this work?
I already import PythonCard.components as well as "model" and "dialog"
Here's my setup.py:
from distutils.core import setup
import py2exe
import os
# find pythoncard resources, to add as 'data_files'
pycard_resources=[]
for filename in os.listdir('.'):
 if filename.find('.rsrc.')>-1:
 pycard_resources+=[filename]
# includes for py2exe
includes=[]
for comp in ['button','image','staticbox',\
 'statictext','textarea','textfield','multicolumnlist','bitmapcanvas','gauge']:
 includes += ['PythonCard.components.'+comp]
print 'includes',includes
opts = { 'py2exe': { 'includes':includes } }
print 'opts',opts
# end of py2exe stuff
setup(name='pySprintsMainMini',
 version='0.1',
 url='about:none',
 author='morgan venable',
 author_email='root@127.0.0.1',
 package_dir={'pySprintsMainMini':'.'},
 packages=['pySprintsMainMini'],
 data_files=[('.',pycard_resources)],
 console=['pySprintsMainMini.py'],
 options=opts
 )
thanks!
morgan

Anybody else using PythonCard + wxPython 2.8.9.x? 
I've just noticed that my TextArea components have broken - if I update
the text property in my code or through the resource editor it gets
garbled when the application runs. Also, if I take an existing sample
project and add a TextArea component, when the default text is
generated as "TextArea1" the actual output is partially garbled.
-- 
XXXXXXXXXXX

On 2008年12月30日 12:24:20 -0800 "Alec Bennett" <wry...@gm...>
wrote:
> The final thing I need to be able to do is pass the app a parameter.
> Can you see an easy way to do that? Something like this... Note the
> "test" and "dummy" below. This fails with "No such file or directory:
> 'test'".
That'll be because the Application object expects the second parameter
passed to it to be a resource filename that already exists. You can
then specify something other than minimal.rsrc.py.
You could subclass again...
from PythonCard import model
class Minimal(model.Background):
 
 def __init__(self, aParent, aBgRsrc):
 aBgRsrc.style = ['wx.DEFAULT_FRAME_STYLE','wx.STAY_ON_TOP']
 model.Background.__init__(self, aParent, aBgRsrc)
 
 
class MyApplication(model.Application):
 
 def __init__(self, frameClass, param1):
 print "This should go to console: %s" % (param1,)
 model.Application.__init__(self, frameClass) 
 
if __name__ == '__main__':
 app = MyApplication(Minimal, "test")
 app.MainLoop()
The problem is, if you want to pass "test" into Minimal through the
__init__ methods you're probably going to have to hack model.py. You
could be lazy and set up a global variable. Pythoncard doesn't really
expect you to be passing in parameters from the command line, for
example, and really expects stuff to arrive either via the resource
file or via the on_initialize() method in the Minimal object. Again
though, whenever I've done that, it's tended to be via a configuration
file, e.g. to switch on debugging via a .INI file.
-- 
XXXXXXXXXXX

The final thing I need to be able to do is pass the app a parameter.
Can you see an easy way to do that? Something like this... Note the
"test" and "dummy" below. This fails with "No such file or directory:
'test'".
from PythonCard import model
import wx
class Minimal(model.Background):
 def __init__(self, aParent, dummy, aBgRsrc):
 aBgRsrc.style = ['wx.DEFAULT_FRAME_STYLE','wx.STAY_ON_TOP']
 model.Background.__init__(self, aParent, dummy, aBgRsrc)
if __name__ == '__main__':
 app = model.Application(Minimal, "test")
 app.MainLoop()

Thank you! Works like a proverbial charm.
To anyone else coming down this road, here's how to make a PythonCard
app always on top:
test.py:
from PythonCard import model
import wx
class Minimal(model.Background):
 def __init__(self, aParent, aBgRsrc):
 aBgRsrc.style = ['wx.DEFAULT_FRAME_STYLE','wx.STAY_ON_TOP']
 model.Background.__init__(self, aParent, aBgRsrc)
if __name__ == '__main__':
 app = model.Application(Minimal)
 app.MainLoop()
test.rsrc.py
{'application':{'type':'Application',
 'name':'Minimal',
 'backgrounds': [
 {'type':'Background',
 'name':'bgMin',
 'title':u'Tester',
 'size':(403, 371),
 'backgroundColor':(0, 0, 0),
 'style':['resizeable'],
 'components': [
{'type':'StaticText',
 'name':'Testing',
 'position':(151, 131),
 'font':{'faceName': u'Tahoma', 'family': 'sansSerif', 'size': 12},
 'foregroundColor':(255, 255, 0, 255),
 'text':u'Testing',
 },
] # end components
} # end background
] # end backgrounds
} }

On 2008年12月29日 23:22:55 -0800 "Alec Bennett" <wry...@gm...>
wrote:
> I'm trying to subclass the Minimal example so I can make the window
> always on top. I'm having trouble doing it though. Can someone
> possibly point out what I'm doing wrong?
If I understand the PythonCard model.py source correctly, the
Application object initializes the Background object but you have
created an __init__ method in Minimal so that gets called instead.
You don't then call the Background __init__ which does various other
start-up tasks and I'm guessing that is why the application does not
work.
(You don't say what is wrong when you run it, but trying it here I just
get a blank window).
If you just want to add the STAY_ON_TOP style then try the
following...it seems to work here:
from PythonCard import model
class Minimal(model.Background):
 
 def __init__(self, aParent, aBgRsrc):
 aBgRsrc.style = ['wx.DEFAULT_FRAME_STYLE','wx.STAY_ON_TOP']
 model.Background.__init__(self, aParent, aBgRsrc)
 
if __name__ == '__main__':
 app = model.Application(Minimal)
 app.MainLoop()
aBgRsrc is the application bacground resource properties from the
resource file. Adding an extra style is a bit tricky, but since you
have set it to 'resizeable' and the Background object translates that
into wx.DEFAULT_FRAME_STYLE you can replace that with the two item
list. The Background object has been coded to eval() each item in the
list (hence I've made them strings) and bitwise OR them.
-- 
XXXXXXXXXXX

I'm trying to subclass the Minimal example so I can make the window
always on top. I'm having trouble doing it though. Can someone
possibly point out what I'm doing wrong?
Here's my stripped down example, called test.py. Note the 3rd
parameter currently called "dummy" in the init statement, which might
be a source of troubule. Also I was wondering if I need to define a
panel? And if so, does it need to have a specific name?
from PythonCard import model
import wx
class Minimal(model.Background):
 def __init__(self, parent, dummy):
 wx.Frame.__init__(self, parent, -1, "Test", style = wx.STAY_ON_TOP)
 #panel = wx.Panel(self, -1)
 self.Show()
if __name__ == '__main__':
 app = model.Application(Minimal)
 app.MainLoop()
Here's the resource file, called test.rsrc.py:
{'application':{'type':'Application',
 'name':'Minimal',
 'backgrounds': [
 {'type':'Background',
 'name':'bgMin',
 'title':u'Tester',
 'size':(403, 371),
 'backgroundColor':(0, 0, 0),
 'style':['resizeable'],
 'components': [
{'type':'StaticText',
 'name':'Testing',
 'position':(151, 131),
 'font':{'faceName': u'Tahoma', 'family': 'sansSerif', 'size': 12},
 'foregroundColor':(255, 255, 0, 255),
 'text':u'Testing',
 },
] # end components
} # end background
] # end backgrounds
} }

On 2008年12月26日 15:15:19 -0800 Kevin Altis <al...@se...>
wrote:
> PythonCard is just wxPython underneath, so yeah I would just do your 
> wxPython windows as child windows. The single wx.App as you 
> discovered is the big limitation and since PythonCard wouldn't work 
> without having all the setup from the initialization loop you must 
> let your PythonCard app be the initial control.
Cheers. The main PythonCard application is basically a tree-control
component that can be double-clicked to launch an old legacy Win32
application with different parameters based on the tree node selected.
The wxPython window is a dialog window for sending report documents to
the same database server as the legacy app. 
Both windows were developed in isolation and my initial plan was to be
lazy and use the same threading code to handle the legacy application
launching and the report window launching. It works, but the wxPython
application is too slow. There's no reason anymore not to combine the
code...other than time and effort.
> In general, the initial loading of the wxPython runtime is slow the 
> first time, but once it has been done, subsequent loads can be
> pretty fast as long as the application is still in the cache. You
> would have to experiment to see if you're limited by memory or if
> this is just a problem with a py2exe build; the executables will be
> different for a "compiled" py2exe application than when you're
> running wxPython out of the site-packages library of Python.
I think I need to do some more research. Since both the PythonCard
and wxPython application require the same runtime DLLs (Python 2.3
and wxPython 2.8) and the PythonCard window is already running, I was
expecting caching to speed up the launch of the wxPython-only
application. But it's taking several seconds even when you launch it
several times in a row. Meanwhile, the legacy Win32 application is fast
enough on the first launch and instant from then on.
-- 
XXXXXXXXXXX
Support4Omega Ltd.
Tel: 07793 134456
Fax-2-Email: 0870 7051877
Web: www.support4omega.co.uk

On Dec 24, 2008, at 3:05 AM, XXXXXXXXXXX wrote:
> Has anybody done this?
>
> I have a PythonCard application that currently launches a second
> application, which is a wxPython executable. Both get compiled with
> py2exe and this works fine, except running the wxPython application is
> pretty slow, expecially over a network. This appears to be down to the
> time taken for the second Python and wxPython runtime DLLs to load and
> run.
>
> So...I am resigned to merging the code and making the
> wxPython application a child window (maybe modal, maybe not). My first
> task appears to be getting rid of the wx.App instance in the wxPython
> code, but is there anything else I need to be aware of? Has anybody
> done this before and compiled a list of things to watch out for?
>
> Thanks
> -- 
> XXXXXXXXXXX
PythonCard is just wxPython underneath, so yeah I would just do your 
wxPython windows as child windows. The single wx.App as you 
discovered is the big limitation and since PythonCard wouldn't work 
without having all the setup from the initialization loop you must 
let your PythonCard app be the initial control.
One other possibility would be to keep one or both of the apps always 
running and communicate as a client/server or some other networking 
via threads, Twisted, etc.
In general, the initial loading of the wxPython runtime is slow the 
first time, but once it has been done, subsequent loads can be pretty 
fast as long as the application is still in the cache. You would have 
to experiment to see if you're limited by memory or if this is just a 
problem with a py2exe build; the executables will be different for a 
"compiled" py2exe application than when you're running wxPython out 
of the site-packages library of Python.
ka

Has anybody done this?
I have a PythonCard application that currently launches a second
application, which is a wxPython executable. Both get compiled with
py2exe and this works fine, except running the wxPython application is
pretty slow, expecially over a network. This appears to be down to the
time taken for the second Python and wxPython runtime DLLs to load and
run.
So...I am resigned to merging the code and making the
wxPython application a child window (maybe modal, maybe not). My first
task appears to be getting rid of the wx.App instance in the wxPython
code, but is there anything else I need to be aware of? Has anybody
done this before and compiled a list of things to watch out for?
Thanks
-- 
XXXXXXXXXXX

Hi all,
I've been having a lot of errors on exit in GTK -- Ubuntu 8.10.
They tend to look like this:
[quote]
(python:7330): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.16.6/gobject/gsignal.c:1741: instance
`0x132fd10' has no handler with id `121'
(python:7330): GLib-GObject-WARNING **:
/build/buildd/glib2.0-2.16.6/gobject/gsignal.c:1741: instance
`0x1807ad0' has no handler with id `873'
[end quote]
A bunch (two to eight) get spewed on every application exit (or
attempt, regardless of success). There is no other error data.
The number of errors is consistent.
Has anyone else seen this?
I don't see these errors when running on Windows XP (no surprise).
My code uses the following widgets:
TextField
TextArea
BitmapCanvas
StaticText
Button
Gauge
I've tried correlating the number of errors with the specific widgets
I'm using, but they don't seem to add up to anything sensible.
Can anyone shed light on this?
thanks!
morgan

On 2008年11月28日 10:30:20 +0100 Nextime <ne...@ne...> wrote:
> Why all the thread about the fork except for the first message that i
> have re-posted, and seem also other old messages like one from Tweedly
> of the Nov 13th at least, doesn't appear on the web archive?
> 
> Anyone have an idea on why this happen?
No idea....but it's nothing new and not unique to this list. They may
still turn up, out of sequence. It's one of the reasons why I stick to
reading mailing lists with an email client.
-- 
XXXXXXXXXXX

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Why all the thread about the fork except for the first message that i
have re-posted, and seem also other old messages like one from Tweedly
of the Nov 13th at least, doesn't appear on the web archive?
Anyone have an idea on why this happen?
- -- 
Franco Lanza
My blog: http://www.nexlab.it
email: ne...@ne...
Fax/Tel: +39 0331 682151
Cell: +39 339 8125940
Busto Arsizio (VA) - Italy
- -----------------------------------
NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
- -----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
- -----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkkvuiwACgkQ3+31gNYTLVDjWQCfaLrFBJx5wLamcFMk8YhYKDnn
VrcAn3JMPnLWWiZfeJlTSAB4Mbx+wzfq
=fsle
-----END PGP SIGNATURE-----

I think it's always a bit ugly to have a "hostile" forking. But my
sympathies are with Nextime here.
Managing the difference between work-in-progress vs. stable releases
*is* a problem that has been reasonably solved by the branching /
tagging mechanisms of source-control systems. There doesn't seem a
strong reason to have to manually juggle patches from different
web-sites. That appears unnecessary extra work.
I look forward to being able to install bleeding edge PythonCard /
Picard in one go; and I hope that pushing the sizers on users may
actually focus more attention and testing on them.
OTOH, I'd suggest to Nextime that he makes a tag of the pre-sizer
release so that those who are concerned can avoid it.
phil
On Thu, Nov 27, 2008 at 8:59 PM, Nextime <ne...@ne...> wrote:
> On Thu, Nov 27, 2008 at 10:50:30PM +0000, Alex Tweedly wrote:
>> All the other changes I made to Pythoncard followed the same, or
>> similar, process:
>> - put code (or diffs) on a website OR send them directly to fellow
>> collaborators
>> - announce to users list
>> - get feedback, update, .....
>> - once there has been enough feedback and/or enough bugs fixed, post
>> diffs to developers list
>> - incorporate any developer changes / suggestions
>> - then and only then put into cvs
>
> I don't agree with this method.
>
> In my opinion, any changes or patch shuld be committed on an
> experimental branch (or even in trunk/HEAD for little projects ),
> only this way people interested in the developement
> version can test it and provide feedback in an actively manner.
>
> When and if the changes will be considered stable enough, they will be
> included in the release branch, or tag, or stable, or what you want to call it.
>
> This is how most of the projects go ahead, and i think is the only way
> to let developers that know what they do find, test, and patch or reply
> with feedback.
>
>> That worked pretty well, until we got the sizer changes. A good number
>> of people were interested - but not sufficiently to actually test it
>> thoroughly. That kind of convinced me that there was actually less need
>> than I had thought, as confirmed by my own experience.
>
> I don't agree. It don't work pretty well if we have about 1 commit a
> year.
>
> Also, this isn't the only one issue. Also there is the problem of the
> devel ml not responsive, and i don't want to see an answer to every
> message in few minutes/hours, but i want an answer at least in 1/2 weeks
> where i ask about the status of the project. Exceptions permitted, of
> course, but Jesus, this is the usual way on pythoncard, not an
> exception.
>
>> I found that many times I used Pythoncard for a quick, simple GUI for my
>> own use without needing sizers (and if I wanted to use it
>> cross-platform, then I'd just adjust things).
>
> I agree in this. Me too. But this isn't a reason to let the project
> stalled for *TWO YEARS*!
>
>> The way I read your email, these changes were (or were going to be)
>> included in the svn trunk - so no-one can dowload Picard without getting
>> these changes included.
>
> Yes, no one can download it without those changes included. Exactly, no
> one can download the new *developement* branch without those changes
> included. When and only when i will release something that i will call
> "stable" you can argue with those things.
>
>> If that's not the case, and people can get the
>> reliable version of the layoutEditor or *choose* to get this version,
>> then that's fine. But if these changes come included by downloading
>> Picard, then I think it would be worth a specific warning about this
>> part of the code (though you could argue this email thread should be
>> enough of a disclaimer).
>
>
> People that download a trunk developement branch from an svn usually
> know what they do. People that don't know what to do, usually don't know
> how to use an svn repository nor how to install something that isn't an
> exe or msi installer.
>
> Anyway, after all, i've done my choice. I now have a fork with the
> things i want to have, i will have a new project that will evolve more
> quickly, probably in different direction of pythoncard. Anyone is free
> to follow me or to stay here... to wait something moving.
>
>
>> Good luck
>
> Thanks.
>
>
> --
>
> Franco Lanza
> My blog: http://www.nexlab.it
> email: ne...@ne...
> Fax/Tel: +39 0331 682151
> Cell: +39 339 8125940
> Busto Arsizio (VA) - Italy
> -----------------------------------
> Per consulenze telefoniche chiamate:
> ** 899.161.414 **
> Servizio riservato ai maggiorenni,
> tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta)
> abilitazione decreto ministero delle comunicazioni
> n. 145 del 02/03/2006, offerto da Deram Srl in
> collaborazione con UnixMedia Srl
> -----------------------------------
> NO TCPA: http://www.no1984.org
> you can download my public key at:
> http://danex.nexlab.it/nextime.asc || Key Servers
> Key ID = D6132D50
> Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
> -----------------------------------
> echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
> -----------------------------------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkkvNHsACgkQ3+31gNYTLVB4dQCg0CnAHefQFnxJ97wwZ3EIFgtr
> tK0AoIzHk+LKo4Ngo/P0Dj3we4jShb8X
> =wedb
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>

On Thu, Nov 27, 2008 at 10:50:30PM +0000, Alex Tweedly wrote:
> All the other changes I made to Pythoncard followed the same, or 
> similar, process:
> - put code (or diffs) on a website OR send them directly to fellow 
> collaborators
> - announce to users list
> - get feedback, update, .....
> - once there has been enough feedback and/or enough bugs fixed, post 
> diffs to developers list
> - incorporate any developer changes / suggestions
> - then and only then put into cvs
I don't agree with this method.
In my opinion, any changes or patch shuld be committed on an
experimental branch (or even in trunk/HEAD for little projects ), 
only this way people interested in the developement
version can test it and provide feedback in an actively manner.
When and if the changes will be considered stable enough, they will be
included in the release branch, or tag, or stable, or what you want to call it.
This is how most of the projects go ahead, and i think is the only way
to let developers that know what they do find, test, and patch or reply
with feedback.
> That worked pretty well, until we got the sizer changes. A good number 
> of people were interested - but not sufficiently to actually test it 
> thoroughly. That kind of convinced me that there was actually less need 
> than I had thought, as confirmed by my own experience.
I don't agree. It don't work pretty well if we have about 1 commit a
year.
Also, this isn't the only one issue. Also there is the problem of the
devel ml not responsive, and i don't want to see an answer to every
message in few minutes/hours, but i want an answer at least in 1/2 weeks
where i ask about the status of the project. Exceptions permitted, of
course, but Jesus, this is the usual way on pythoncard, not an
exception.
> I found that many times I used Pythoncard for a quick, simple GUI for my 
> own use without needing sizers (and if I wanted to use it 
> cross-platform, then I'd just adjust things).
I agree in this. Me too. But this isn't a reason to let the project
stalled for *TWO YEARS*!
> The way I read your email, these changes were (or were going to be) 
> included in the svn trunk - so no-one can dowload Picard without getting 
> these changes included.
Yes, no one can download it without those changes included. Exactly, no
one can download the new *developement* branch without those changes
included. When and only when i will release something that i will call
"stable" you can argue with those things.
> If that's not the case, and people can get the 
> reliable version of the layoutEditor or *choose* to get this version, 
> then that's fine. But if these changes come included by downloading 
> Picard, then I think it would be worth a specific warning about this 
> part of the code (though you could argue this email thread should be 
> enough of a disclaimer).
People that download a trunk developement branch from an svn usually
know what they do. People that don't know what to do, usually don't know
how to use an svn repository nor how to install something that isn't an
exe or msi installer.
Anyway, after all, i've done my choice. I now have a fork with the
things i want to have, i will have a new project that will evolve more
quickly, probably in different direction of pythoncard. Anyone is free
to follow me or to stay here... to wait something moving.
> Good luck
Thanks.
-- 
Franco Lanza
My blog: http://www.nexlab.it
email: ne...@ne...
Fax/Tel: +39 0331 682151
Cell: +39 339 8125940
Busto Arsizio (VA) - Italy
-----------------------------------
Per consulenze telefoniche chiamate:
 ** 899.161.414 **
Servizio riservato ai maggiorenni, 
tariffazione flat Euro 15 iva inclusa (solo scatto alla risposta) 
abilitazione decreto ministero delle comunicazioni 
n. 145 del 02/03/2006, offerto da Deram Srl in 
collaborazione con UnixMedia Srl 
-----------------------------------
NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------

Nextime wrote:
> On Wed, Nov 26, 2008 at 10:36:54PM +0000, Alex Tweedly wrote:
> 
>> Nextime wrote:
>> 
>>> Hello all.
>>>
>>> As a demostration that nothing is moving here, after few posts saying 
>>> "i don't agree with a fork", nothing more on this list or in
>>> developement of PythonCard.
>>>
>>> 
>>> 
>> Other than my post on the 13th ?
>> I haven't yet seen any reply to what I said.
>> 
>
>
> Sorry but i don't see nor in the archive nor in my email any post from
> you on the 13th.
>
> 
Hmmmm - odd. I know I sent it, and received a copy of it back - no idea 
why you don't / didn't see it.
Most of it is probably out of date now, so I'll include just the two 
most relevant paragraphs again here :
> What new things do we have ? Which of them are *ready* to go into 
> the actual project ?
>
> I know for sure that my sizer code isn't ready to be committed. 
> That's why it's on a separate website - it's still 'experimental'. It 
> hasn't been tested anywhere near enough to be ready to put it into 
> CVS. It's fine for someone who has been actively following discussions 
> to try something that may break, or behave strangely, or indeed may 
> work but just not be the right approach in the long run; but it would 
> be very wrong to put such experiments into the repository where anyone 
> trying out Pythoncard for the first time is exposed to those dangers.
>>> - Patched with changes from Alex Tweedly for sizers
>>> 
>>> 
>> I strongly recommend that these not be used, other than for testing 
>> purposes.
>> 
>
> Well, do you know the words "developement version" and "pre-release"?
>
> 
Yes, thanks. I have spent a few years managing software development 
groups of 150+ engineers - I'm far too familiar wth both those terms 
:-) And with the wide variety of meanings people attach to each of them.
> This is not a "stable download released" but a developement one.
> When those changes are tested enough they will be released as default
> download, for the moment they are in a developement version.
>
> Also, if you don't put the code in a branch or in a developement
> version, how can anyone test it and give you feedback?
>
> 
How can anyone test it or give feedback ? Easy -
 I put it on a website.
 I announced it on the pythoncard-users list.
 A number of people (including you) managed to find it;
 quite a few expressed some interest in it;
 but very, very few tested it and provided any feedback.
All the other changes I made to Pythoncard followed the same, or 
similar, process:
 - put code (or diffs) on a website OR send them directly to fellow 
collaborators
 - announce to users list
 - get feedback, update, .....
 - once there has been enough feedback and/or enough bugs fixed, post 
diffs to developers list
 - incorporate any developer changes / suggestions
 - then and only then put into cvs
That worked pretty well, until we got the sizer changes. A good number 
of people were interested - but not sufficiently to actually test it 
thoroughly. That kind of convinced me that there was actually less need 
than I had thought, as confirmed by my own experience.
I found that many times I used Pythoncard for a quick, simple GUI for my 
own use without needing sizers (and if I wanted to use it 
cross-platform, then I'd just adjust things). If I did want to release 
the program to other people, I'd do so after some time - so the basic 
layout, controls, components, etc. were fairly settled - and in that 
case, it wasn't a big deal to put the sizers in as code (as is done, 
e.g., in 'findfiles'). And for the early experimentation, I much 
referred the static layout of the existing editor to the thought and 
effort needed to organize and put components into sizers). So even I 
didn't actually use the sizer changes enough :-)
Net result - it just hasn't been tested that much. It's at a very 
different stage of readiness than the rest of the code in the Pythoncard 
repository.
>> I'll look at any feedback (on this list), but can't guarantee 
>> to respond in a timely manner.
>> 
>
> You can have feedback if you put your code in Pythoncard, but the
> codebase of Picard will be different from the Pythoncard soon, so,
> feedback from Picard will not be the one that you want here.
>
> 
I can have feedback from anyone who wants to download it from 
tweedly.net and test it - it's been there for almost 3 years now, 
without gathering much feedback. (Anyone who wants the URL, or docs, 
etc. can contact me off-list.)
> I will look at any feedback and i try to respond in timely manner on the
> right mailing list for the project *with* the code to be tested.
>
> 
>> I do not stand behind these 
>> not-yet-properly-tested changes, and I think it's a bad idea to have 
>> them included in the default download.
>> 
>
> It is a svn trunk version... not a default download.
>
> 
The way I read your email, these changes were (or were going to be) 
included in the svn trunk - so no-one can dowload Picard without getting 
these changes included. If that's not the case, and people can get the 
reliable version of the layoutEditor or *choose* to get this version, 
then that's fine. But if these changes come included by downloading 
Picard, then I think it would be worth a specific warning about this 
part of the code (though you could argue this email thread should be 
enough of a disclaimer).
Good luck
-- Alex.

On 2008年11月27日 19:58:27 +1100 Andy Todd <an...@ha...>
wrote:
> Python 2.6 does not break compatibility with previous versions,
> Python 3.0 does, however. As far as reports go there shouldn't (touch
> wood) be any problems running code like PythonCard under Python 2.6
Kevin and I had a short conversation on the developer list about this,
and from some VERY brief testing it looks like all my
non-ctypes-using projects still work fine under Python 2.6 + wxPython
2.8.9.1 (on Windows XP at least).
The only thing that seems to have broken is the PythonCard installer,
but this looks like the same issue that broke the
PythonCard 0.81 installer when Python 2.4 came out. I've added the
issue to the bugtracker.
-- 
XXXXXXXXXXX

Mark Carter wrote:
> Hello.
> 
> On Wed, Nov 26, 2008 at 5:41 PM, Nextime <ne...@ne...> wrote:
>> So, with all my thanks for all original developers of pythoncard
>> for the base code of the new project, i have forked pythoncard.
> 
And good luck to Franco with his new project.
> I love Pythoncard, and as a casual hobby programmer, PythonCard has
> given me an easy to use way make GUIs for my Python programs. It's
> helped me transition from Visual Basic to Python (moving away from VB,
> by far the biggest obstacle is replacing the superb interface building
> tools). Looking for a quick and easy way to do a GUI with Python,
> PythonCard came out way ahead of Glade/QT/wxWidgets/etc.
> 
> I do think there is PythonCard development going on, but it's no doubt
> done in whatever spare time the developers have. However, where I
> think a lot of end users have lost confidence in the project is simply
> that despite whatever development may be happening, there hasn't been
> a history of frequent releases of executable installers. Rather than
> very infrequent releases with major changes, end users prefer frequent
> releases with incremental improvements.
> 
+1, and a fair call. It has also generally relied on the project 
benevolent dictator being interested and making the changes he wanted to 
make. As I previously stated, if someone wants to step up and provide 
patches or new code for PythonCard we have the ability to let them 
become project developers on SourceForge. Given a sufficient track 
record of contribution it should also be possible to make other people 
project administrators. As a wise man once said - show us the code.
> 
>> - dropping out codeEditor, resourceEditor,
> 
> Please don't drop codeEditor... I quite liked it as part of the
> package; very useful.
> 
> 
>> - change resource files to an XML format
> 
> I know that XML is the cool thing these days, but whatever you do,
> please keep the files in a simple enough format that they can be
> hand-edited if necessary. I liken it to HTML versus CSS... HTML you
> can do by hand, and it's simple. CSS is so complex that it's barely
> human-readable. It may be great if you're using expensive proprietary
> software for web development, but it's an example of complexity going
> beyond the bounds of being beneficial, and instead becoming a burden.
> 
+1, we talked about this over the life of the project and could never 
come up with a compelling reason to change the current, simple, resource 
file format to XML. It just introduces another level of complexity for 
no real benefit.
> Beyond that, I haven't had an itch to scratch with programming for a
> while, so I can't comment too much on Pythoncard's current state.
> Although I'll probably be updating my Python install to 2.6 and
> checking that my software still works... I recall that when reading
> that they planned to break compatibility with past code in Python 2.6
> that it sounded like a really boneheaded idea... hopefully I'll find
> that it was only obscure code that was going to become incompatible.
> 
Python 2.6 does not break compatibility with previous versions, Python 
3.0 does, however. As far as reports go there shouldn't (touch wood) be 
any problems running code like PythonCard under Python 2.6
> Mark
> 
Regards,
Andy
-- 
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Hello.
On Wed, Nov 26, 2008 at 5:41 PM, Nextime <ne...@ne...> wrote:
> So, with all my thanks for all original developers of pythoncard
> for the base code of the new project, i have forked pythoncard.
I love Pythoncard, and as a casual hobby programmer, PythonCard has
given me an easy to use way make GUIs for my Python programs. It's
helped me transition from Visual Basic to Python (moving away from VB,
by far the biggest obstacle is replacing the superb interface building
tools). Looking for a quick and easy way to do a GUI with Python,
PythonCard came out way ahead of Glade/QT/wxWidgets/etc.
I do think there is PythonCard development going on, but it's no doubt
done in whatever spare time the developers have. However, where I
think a lot of end users have lost confidence in the project is simply
that despite whatever development may be happening, there hasn't been
a history of frequent releases of executable installers. Rather than
very infrequent releases with major changes, end users prefer frequent
releases with incremental improvements.
> - dropping out codeEditor, resourceEditor,
Please don't drop codeEditor... I quite liked it as part of the
package; very useful.
> - change resource files to an XML format
I know that XML is the cool thing these days, but whatever you do,
please keep the files in a simple enough format that they can be
hand-edited if necessary. I liken it to HTML versus CSS... HTML you
can do by hand, and it's simple. CSS is so complex that it's barely
human-readable. It may be great if you're using expensive proprietary
software for web development, but it's an example of complexity going
beyond the bounds of being beneficial, and instead becoming a burden.
Beyond that, I haven't had an itch to scratch with programming for a
while, so I can't comment too much on Pythoncard's current state.
Although I'll probably be updating my Python install to 2.6 and
checking that my software still works... I recall that when reading
that they planned to break compatibility with past code in Python 2.6
that it sounded like a really boneheaded idea... hopefully I'll find
that it was only obscure code that was going to become incompatible.
Mark

Sorry for re-posting this, but it seem that this post is 
disappear from the web archive.
Hello all.
As a demostration that nothing is moving here, after few posts saying 
"i don't agree with a fork", nothing more on this list or in
developement of PythonCard.
So, with all my thanks for all original developers of pythoncard
for the base code of the new project, i have forked pythoncard.
The new project will be called "Picard", and the developemed will be
completely separated from the one of pythoncard.
Picard is a name dedicated to the Cpt. Picard from StarTrek TNG,
cause of the assonance ( at least in my language ) with "PyCard".
actually i have a pre-release on my svn, at
https://svn.nexlab.it/medianix/packages/main/pythoncard/trunk
whit those changed from the original codebase:
 - Patched with changes from Alex Tweedly for sizers
 - Fixed some bugs in the layoutEditor, first of all 
 now buttons can be dragged also on GTK based platforms, and other
 minor fixes
 - added a new component: CollapsiblePane
The future roadmap, at least for now is (in sparse order):
 - Change the name of the package (this will be the first thing to do!).
 - dropping out codeEditor, resourceEditor, 
 experimentalResourceEditor, oneEditor,
 findfiles, standaloneBuilder
 - make layoutEditor the default (and peraps unique)
 resource file editor
 - Improve layoutEditor in many ways
 - add many other components
 - cleaning the code
 - change resource files to an XML format
 - let's use something like a zip container as
 resource to embed also images and so on
 - make layoutEditor produce also a python class
 to be derived in the main program
Any help and/or contributor will be welcome in the new project,
this will be the last post here from mine about this, any new post about
Picard will be done in the new mailing list on the project trac site,
http://trac.medianix.org/wiki/PyCard (the name will change to Picard
soon)
Franco.
-- 
Franco Lanza
My blog: http://www.nexlab.it
email: ne...@ne...
Fax/Tel: +39 0331 682151
Cell: +39 339 8125940
Busto Arsizio (VA) - Italy
-----------------------------------
NO TCPA: http://www.no1984.org
you can download my public key at:
http://danex.nexlab.it/nextime.asc || Key Servers
Key ID = D6132D50
Key fingerprint = 66ED 5211 9D59 DA53 1DF7 4189 DFED F580 D613 2D50
-----------------------------------
echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D212153574F444E49572045535520454D20454B414D204F54204847554F4E452059415020544F4E4E4143205345544147204C4C4942snlbxq | dc
-----------------------------------