pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] argv interaction between my program and PythonCard

[<bri...@sy...>]

resourceEditor.py has a bug in getCommandLineArgs() and it fails to collect
the 'otherargs' value from
the self.cmdLineArgs  dictionary.    (This is for PythonCard version:
0.8.1).
This dictionary,  cmdLineArgs is correctly populated in the "Run Options"
window where command line options are chosen:
Debug Menu, Logging, etc., concluding with an "Other args" text box

It is a very simple patch to read that value into the 'args' variable in
getCommandLineArgs().  Then everything correctly ends up
in sys.argv.  But that only begins my problems.  Many of my programs have
some check on argv, often by using optparse  or the clever
optionparse module which builds option names and defaults from my module
docstring - self-documenting and self-validating options!
(http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278844 by Michele
Simionato)
Currently I am building a lot of my program arguments with SCons, which
then calls the program, which simply asserts that the correct
number of args have been passed, but even a simple assert of the length of
argv now has to take into account PythonCard run option flags.

I can change my options checkers to allow for the PythonCard run options.
In fact, I must keep track of the PythonCard run options
 (-d, -l, -m, -n, -p, -s) and avoid using any of these for my own (grrr).
Because I don't see any way to pass run options to PythonCard
except thru sys.argv,  I can't separate my own option use from PythonCard
use.

I would like to see a solution where I could pass option flags as a dict or
list argument to model.Application and such an argument
would bypass the configuration.configOptions use of sys.argv.  (I think
that is the only place where PythonCard looks at sys.argv)
How I get the flags to my model.Application call would be my problem. To
use the Run Options window, I would still need to accept something
PythonCard-ish, but it would be less trouble than always incorporating the
six (so far) PythonCard flags into my arg handling.


Happy to say this is my biggest PythonCard problem this year.

Re: [Pythoncard-users] wxChoice stringSelection field

[Alex T. <al...@tw...>]

Albert J. Boehmler wrote:

>I do have a minor issue, though. I have an application which is using
>PythonCard version: 0.8.1 and wxPython version: 2.5.3.1 on Windows. It
>simulates output strings for a sensor and uses many "Choice" components.
>I am using a timer to build and send an output string based on the
>values of the GUI elements once a second.
>
>The issue I am running into is that the "stringSelection" values are
>read while the drop-down list is active and the highlighted value is
>sent. I'd like to only send the value when an item has been selected;
>until a different item has been selected, the original value should be
>sent. Is there any simple way to do this? I've noticed that the ComboBox
>doesn't do this, but I'd rather not use that if I can avoid it.
>
>  
>

I created an example like you describe (I think - want to check this is 
what you currently do). Resource file has just a single "Choice" 
component called "Choice1" (oops - just noticed that I used selection 
instead of stringSelection - but should be the same .... )

> #!/usr/bin/python
> from PythonCard import model, timer
>
> class MyBackground(model.Background):
>
>     def on_initialize(self, event):
>         # if you have any initialization
>         # including sizer setup, do it here
>         self.timer = timer.Timer(self.components.Choice1, -1)
>         self.timer.start(1000)
>         pass
>         
>     def on_Choice1_timer(self, event):
>         print self.components.Choice1.selection
>
>
> if __name__ == '__main__':
>     app = model.Application(MyBackground)
>     app.MainLoop()

Then changed it by adding a variable (self.choice, which is initialized 
to -1, and is set only when the "select" event happens. I think this 
does what you want.

> #!/usr/bin/python
>
> """
> __version__ = "$Revision: 1.5 $"
> __date__ = "$Date: 2004/04/30 16:26:12 $"
> """
>
> from PythonCard import model, timer
>
> class MyBackground(model.Background):
>
>     def on_initialize(self, event):
>         # if you have any initialization
>         # including sizer setup, do it here
>         self.timer = timer.Timer(self.components.Choice1, -1)
>         self.timer.start(1000)
>         self.choice = -1
>         pass
>         
>     def on_Choice1_select(self, event):
>         self.choice = self.components.Choice1.selection
>
>     def on_Choice1_timer(self, event):
>         print self.components.Choice1.selection, self.choice
>
>
> if __name__ == '__main__':
>     app = model.Application(MyBackground)
>     app.MainLoop()




-- 
Alex Tweedly       http://www.tweedly.net




-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Alex T. <al...@tw...>]

Sells, Fred wrote:

>A. Pythoncard runtime support.
>
>
>5. Additional compound widget. - a static text "label" and a text field 
>good idea; most common use is label:control so you need some way to define
>the default spacing so a bunch can be placed in a column with the labels and
>data entry fields properly lined up.
>
I still have no idea whether this would be
 - a single new component  (probably too many values need to be attached ??)
 - a container with two components (probably too complex)
 - a resourceEditor convenience only
 - something else.

I think the issue of getting a number of fields into columns and lined 
up well is just a specific case of alignment, and is going to be solved 
anyway, by either the ability to select multiple components (and then 
align and move them), or the ability to specify sizing / layout schemes, 
or both.

> Anticipate need for one label and
>several data entry fields on a single row like city-state-zip.
>  
>
But each of those would be a label : field on its own, wouldn't it ? 
What additional features would be needed in the "compound widget" to 
support this ?

>B. Geometry managements (aka sizers, resizing, etc.)
>We had a simple grid (default to 100x100) with "attachment properties" on
>each widget.  If both right and left edge of widget were attached, it would
>move and resize with window resize, etc.  To simplify the use of
>attachement, we had an attachment dialog that had 4 sets of identical
>"attaching controls" arranged at North, South, East, West.  Combined with
>multiple widget select, you could attache left and right sides of a bunch at
>once, then go back and individually set top,bottom.  It was not as elegant
>as most UI builders, but it was easy (the product was, after all, "ezX")
>  
>
I think it's a little bit too simple for Pythoncard; it can't adequately 
handle some very simple cases (e.g. the scrolling text dialog, with one 
growable size textarea and one fixed size button below it), and I think 
that could put a lot of people off.

>New Feature Request: Need to be able to specify containers either in same
>file or different file to control multiple widgets at once. Handy for a
>"mode change" where one set of controls vanishes and another appears.
>Valuable to define this stuff in a different file/window and then import
>(perhaps only at runtime, use space holder in resource editor) so gui is
>more modular.
>  
>
Hmmm - interesting viewpoint. I want them in the resource editor more 
than I want them at runtime. I'd like to use them for moving groups of 
components around, selecting the subset to align or distribute, etc.   
Some of that can be done with "at the time" selection of multiple 
components, but I'd really like to make some of those collections 
"permanent" (e.g. all the address components in a contacts database).

There is an experimental "container" component - but I think it was 
problematic (before my time :-)  Making it a "first-class" component I 
think introduces some difficulties - need to get it into the event 
hierarchy, etc.

I'd be content with a simple "list of other component names" which could 
be used to select a set of  components in one operation - both in 
resource editor, and at run-time to enable the vanishing you described.

Not sure what extra modularity you were looking for - I can't imagine a 
case where you wouldn't want to be able to see / modify these groupings 
in a layout editor.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

[Pythoncard-users] wxChoice stringSelection field

[Albert J. B. <Boe...@fa...>]

Hi,

I'd like to say that PythonCard has made my job of writing hardware
simulators pretty easy. Thanks for the software.

I do have a minor issue, though. I have an application which is using
PythonCard version: 0.8.1 and wxPython version: 2.5.3.1 on Windows. It
simulates output strings for a sensor and uses many "Choice" components.
I am using a timer to build and send an output string based on the
values of the GUI elements once a second.

The issue I am running into is that the "stringSelection" values are
read while the drop-down list is active and the highlighted value is
sent. I'd like to only send the value when an item has been selected;
until a different item has been selected, the original value should be
sent. Is there any simple way to do this? I've noticed that the ComboBox
doesn't do this, but I'd rather not use that if I can avoid it.

Thanks.

Sincerely,
Bert Boehmler

[Pythoncard-users] iterating over components

[Michael S. <mik...@ya...>]

Am I correct in assuming the code below is the
standard way of iterating over components?

for component in self.components.itervalues():
   do stuff

The following seems more intuitive to me.

for component in self.components:
   do stuff

However, this causes a KeyError exception because
__iter__ is not defined. Is it ambiguous as to what
self.components should iterate over? If this makes
sense, an option would be to alias __iter__ in
WidgetDict (model.py) to UserDict.UserDict.itervalues.


Michael

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

Re: [Pythoncard-users] ACCU conference

[Alex T. <al...@tw...>]

Phil Edwards wrote:

>I notice in the slides you say that PythonCard isn't suitable for large
>projects - I think you're doing yourself a dis-service, I must say! My
>PIMP application currently runs to almost 5,000 lines of code, and the
>prototype standaloneBuilder in CVS has topped 2,000 lines.
>
>Python seems to produce less lines of code for a given solution than a
>lot of languages, so I think 5,000 lines constitutes a 'big' project in
>anyones book! :-)
>  
>
Different definition of "big" :-)
Last project I worked on professionally was somewhere around 5-10 
million lines of code (mostly C, small chunks of C++), depending on how 
you counted it.

And I do think it would be "interesting" to get things set up for a 
fully multi-developer single application in PythonCard - possible of 
course, but not the target area that PythonCard is best at.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.3 - Release Date: 25/04/2005

Re: [Pythoncard-users] ACCU conference

[Phil E. <ph...@li...>]

On Mon, 2005-04-25 at 17:02, Kevin Altis wrote:
> Many thanks to Alex for filling in for me! The ACCU slides were almost 
> identical to my Pycon presentation and the same sample application, the 
> mortgage calculator, in the samples/financial folder were used for the 
> demo.
> 

I'd just like to echo these sentiments - well done, Alex!

> http://www.python.org/pycon/2005/papers/42/PythonCard_Pycon_2005.pdf
> 

I notice in the slides you say that PythonCard isn't suitable for large
projects - I think you're doing yourself a dis-service, I must say! My
PIMP application currently runs to almost 5,000 lines of code, and the
prototype standaloneBuilder in CVS has topped 2,000 lines.

Python seems to produce less lines of code for a given solution than a
lot of languages, so I think 5,000 lines constitutes a 'big' project in
anyones book! :-)

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] newbie, tool to print resource structure

[Andy T. <an...@ha...>]

Schollnick, Benjamin wrote:
>>Back in the 90's my company made a commercial Motif 
>>GUI-Builder. From that experience I concur that being able to 
>>manually edit the resource file is a necessity, even though 
>>it may be seldom used.
> 
> 
> A slight clarification...
> 
> I am not saying that you can't edit the resource file manually...
> 
> I am suggesting that the Resourceeditor is the only guaranteed method to
> produce a resource file.
> 
> The resource editor can't make typos, make white space errors, make
> syntax errors, or any of a 100s of human errors...
> 
> While the manually edited file should be okay, it's a valid concern that
> someone might manually edit the file and goof something up.  Then demand
> that Kevin "fix" the problem....
> 
> **** I have been in that situation before.  ****
> 
> I feel that it's important to at least acknowledge that manually editing
> the file may not always be possible, nor supported....
> 
> What if Kevin moves to a XML based format?  Sure it's plain ascii, but I
> personally don't feel that manually editing the tag data is worth it...
> 
> 
> Or heaven forbid a binary format....  
> 
> 		- Ben
> 

Your points are all valid, but you *can* manually edit the resource file 
and it will always be perfectly acceptable to do so. This being an open 
source project no one has to provide support if they don't want to, 
people can 'demand' all they like. I think I can guarantee that if 
someone has a problem and posts an invalid resource file to the list it 
will be spotted very quickly.

The whole point of PythonCard is to make the simple things easy but not 
to stop people working in the fashion they choose. And if they choose to 
edit their own resource files then we shouldn't in any way stop them. As 
far as I'm concerned manually editing the resource file is *always* 
going to be, if not supported, certainly allowed.

The project isn't likely to move to any other resource format, take a 
look at the mailing list archives from 2001 and 2002 where this 
discussion last took place. No one was keen on XML (or any other) 
resource file formats then and I don't see any evidence that this has 
changed in the mean time.

The only XML type thing that may happen (and don't hold your breath) is 
that someone may write a converter which turns your resource file into a 
wxPython .xrc file, but that's a different conversation and I'll leave 
it there.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Re: [Pythoncard-users] filename in result from saveFileDialog?

[Phil E. <ph...@li...>]

On Sun, 2005-04-24 at 22:03, Steve Christensen wrote:

> 
> Upgrading to the 2.5.5.1 release of wxPython cleared up the problem with
> saveFileDialog (it now returns the absolute path)
> 

Well, it's 50% fixed. If you supply a default filename to the dialog and
the user simply clicks the OK button to accept the default, you'll find
that result.paths[0] contains something like:

/path/to/some/directory/..

If the user types something in the filename box, then you do indeed get
the absolute path back. Also, this bug only applies to GTK2, i.e. it
works as expected on Windows. Methinks a posting to the wxPython-users
list is in order...

> Upgrading to 2.5.5.1 also fixed another intermittent problem I was
> having.  (when I set an Image control to a new file, on one set of
> images an error dialog would pop-up complaining about large files not
> being supported... I can't remember the exact message)

Ahh, excellent. I was seeing this occasionally in an application of
mine. 

-- 

Regards

Phil Edwards
Brighton, UK

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[<bra...@om...>]

Alex Tweedly wrote on 04/24/2005 07:07:40 PM:

> 5. Additional compound widget.
> Seems like every app I do (and 90% of the ones I see), involve a fair 
> number of "paired" components - a static text "label" and a text field 
> (or text area), with the label text is right aligned, to the left of the 

> text field (or occasionally above and left aligned). It would make it 
> much easier for me to have a single widgets (labeled text field, labeled 

> text area) - and a few extra properties such as label text, horizontal 
> vs vertical, spacing and label size.
> 
> (If it isn't easy to do this, consider just doing a "fake" of it in the 
> Resource Editor).


I'm in favor of most of the things you posted, but this one in particular 
would
be most helpful to me and others who build database GUI forms. If there is
any objection to adding so many properties to TextField (you mentioned 
four),
we might be able to do without spacing and label size. I'd be happy if
the label font attributes just matched that of the text field. In other 
cases
I could just make a StaticText label.

Hm...there's also the question of left or right justification for the 
label
in the containing widget. Would there be a containing widget? Something 
that 
holds both the label and the TextField? I guess that gets into the 
question
of container widgets...

FileMaker has a feature whereby a label can be automatically generated
for a widget, but it is not attached in any way. There is a checkbox in 
the dialog
box for adding a field for the layout, along the lines of "create label 
for this field".
This might be easier to add to PythonCard, and would at least provide some
improved convenience.

Re: [Pythoncard-users] ACCU conference

[Kevin A. <al...@se...>]

Many thanks to Alex for filling in for me! The ACCU slides were almost 
identical to my Pycon presentation and the same sample application, the 
mortgage calculator, in the samples/financial folder were used for the 
demo.

http://www.python.org/pycon/2005/papers/42/PythonCard_Pycon_2005.pdf

ka
On Apr 24, 2005, at 3:39 PM, Alex Tweedly wrote:

>
> I was very lucky this last week to be able to attend the ACCU 
> conference in Oxford, England. Kevin had been scheduled to give his 
> talk on "Keeping it simple with Pythoncard" there, but was unable to 
> attend, so I went in his place.
>
> It's really great to be able to give and talk when all the hard work 
> (i.e. the preparation and writing the slides) has been done by someone 
> else :-)  The talk was a brief overview of Pythoncard, followed by a 
> demo of building a simple app from scratch. While it was a simple app, 
> it did demonstrate a variety of features, including component 
> placement and editing, 'auto' event binding, menu building, using 
> "command" instead of select in menus, dialogs, etc.
>
> ACCU *used* to stand for the "Association of C and C++ Users" - I 
> guess officially it still does, but in practice it has expanded to 
> cover a number of other languages, and is essentially an organization, 
> and conference, for professional developers. There were as many Java 
> sessions as there were C++ ones, and there was a separate Python 
> track. I believe the slides etc. will be available shortly, and once 
> they are I'll send another note to this list to let you know where to 
> find them.
>
> There were a couple of other presentations on GUI systems for Python 
> (using wxPython directly, and PyQt). Net result is I have come back 
> with a re-invigorated set of ideas on what I'd like to see in 
> Pythoncard, specifically in the Resource Editor to make it easier and 
> faster to use, so I'll post those shortly.
>
> -- 
> Alex Tweedly       http://www.tweedly.net

RE: [Pythoncard-users] time to share your PythonCard gripes and likes

[Sells, F. <fr...@ad...>]

I am a PythonCard beginner, having developed a single-window simple app that
is going into production. I previously  developed a dragon-droppings gui
builder for motif in the 90's.  Many of my comments are based on that.
However some core differences between Motif and wxWindows may make those
comments invalid.  I concur with Kevin's ideas and deleted his text where I
have nothing to add for brevity.

A. Pythoncard runtime support.


4. Event hierarchy.=20
Possible alternative: widget property has event-name <=3D> user-defined-name
pair. Only events specified here are available to the application.  All
events go to a central handler which provides a great debug node and not all
that much overhead.  The application registers for named events with a call
like PyCardEventHandler.registerForEvent(user-defined-name,
python-callable).  Benefits include: same method can handle multiple,
similar events, fewer methods=3D=3Dcleaner code.  A pretty-print routine can
show all widgets that generate events.  There can be multiple registrants
for one event (calling order needs to be deterministic, i.e. in order
registered)

5. Additional compound widget. - a static text "label" and a text field=20
good idea; most common use is label:control so you need some way to define
the default spacing so a bunch can be placed in a column with the labels and
data entry fields properly lined up. Anticipate need for one label and
several data entry fields on a single row like city-state-zip.

B. Geometry managements (aka sizers, resizing, etc.)
We had a simple grid (default to 100x100) with "attachment properties" on
each widget.  If both right and left edge of widget were attached, it would
move and resize with window resize, etc.  To simplify the use of
attachement, we had an attachment dialog that had 4 sets of identical
"attaching controls" arranged at North, South, East, West.  Combined with
multiple widget select, you could attache left and right sides of a bunch at
once, then go back and individually set top,bottom.  It was not as elegant
as most UI builders, but it was easy (the product was, after all, "ezX")

New Feature Request: Need to be able to specify containers either in same
file or different file to control multiple widgets at once. Handy for a
"mode change" where one set of controls vanishes and another appears.
Valuable to define this stuff in a different file/window and then import
(perhaps only at runtime, use space holder in resource editor) so gui is
more modular.

New Feature Request: Need to be able to "invoke" PythonCard GUI from
standard Python code, rather than subclass.  Gives much greater flexibility
to developer.

---------------------------------------------------------------------------
The information contained in this message may be privileged and / or
confidential and protected from disclosure. If the reader of this message is
not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying to this message and deleting the material from any
computer.
---------------------------------------------------------------------------

Re: [Pythoncard-users] time to share your PythonCard gripes and likes

[Alex T. <al...@tw...>]

Kevin Altis wrote:

>Periodically I like to ask people what is missing from
>PythonCard that they would like to see added. Since
>we're very close to a PythonCard 1.0 API release -
>essentially just waiting on wxPython 2.6 to be
>released before proceeding with cleanup and tweaks for
>1.0 - now is a good time to get feedback to see if
>PythonCard in its current form misses the mark for
>what people expect or want to see from "the simple way
>to build Python GUI applications".
>  
>
I tend to look at this in a few different categories.

A. Pythoncard runtime support.

(not in any order)

1. More widgets. Not a big issue for me - 90% of what I've ever wanted 
to do can be done with the current set. I think the most important is 
more wxGrid coverage - but as Andy said it's not clear whether this is 
better done via multiple Pythoncard widgets covering subsets of that 
huge, complex wxGrid.

2. More window/panel options. Adding splitters / sashes / panes is 
probably fairly high on the list of desirable items - but I've g t by 
without them so far, and can probably continue to do so for a while.

3. Better (simpler) infrastructure. Converting the codeEditor into the 
tabbedCodeEditor was not as simple as I thought it should be; there were 
many places where I had to make calls from parent to the notebook page 
(or vice versa) and these were sometimes a bit clumsy; e.g. menus are 
defined in the main window, but many of them take effect within the 
sub-windows (or within each of the sub-windows). I *think* there's scope 
for Pythoncard making this easier, by providing some systematic means to 
handle this.  (May be as simple as a "recipe" on how to do it, or a 
scriptlet in the code editor, or some real code support - don't know 
yet).  [Most of this would apply to splitters, etc. as well].

4. Event hierarchy. There's a huge step involved in going from using 
only the built-in (and very easy) Pythoncard events, to needing to use 
wxPython events directly - and that does seem to be necessary fairly 
often. Should be a way to allow better *simple* event control - 
shouldn't there ?

5. Additional compound widget.
Seems like every app I do (and 90% of the ones I see), involve a fair 
number of "paired" components - a static text "label" and a text field 
(or text area), with the label text is right aligned, to the left of the 
text field (or occasionally above and left aligned). It would make it 
much easier for me to have a single widgets (labeled text field, labeled 
text area) - and a few extra properties such as label text, horizontal 
vs vertical, spacing and label size.

(If it isn't easy to do this, consider just doing a "fake" of it in the 
Resource Editor).


B. Geometry managements (aka sizers, resizing, etc.)

For me, this is probably the most important missing piece of functionality.

1. The wxPython community is very decided to go down the route of using 
sizers; and they just don't (for me) look or feel simple. I'd be happy 
with a solution that could adequately handle 80% of the problem - 
provided it both made it reasonably clear when the UI design was going 
outside that 80%, and that when you needed to use wxPython sizers 
directly, the effort already done within Pythoncard could then be re-used. 

I think there's some chance of doing this as a follow-on from geometry 
management in the Resource Editor - see below.

{remember - there's a big problem with wxPython sizers not recognizing 
the different nature of *invisible* components)

2. The other approach is to use constraints (aka "springs and struts", 
etc.). Still needs to be thought about some more.

C.  Resource Editor

(these are in descending order of importance to me, or increasing 
difficulty of implementation)

0. Undo / redo

1. property editor window.
I find the current property window pretty clunky. Instead of displaying 
(and allowing editing of) one property at a time, with a list to select 
which property, I'd rather see a "display panel" approach where all the 
properties of the current component were shown (and all available for 
direct editing).  If this takes up too much screen real-estate, we could 
drop back to showing one of a number of subsets (basic, appearance, 
etc.) - but given that there relatively few properties, I think this 
won't be a problem.

2. fast creation of components
I don't like the steps involved in creating (or duplicating) a component.
1. menu selection to say you want to place a component
2. Type in (or edit) name and text/label in the dialog box
3. component appears at fixed position (usually where there's already a 
comp)
4. move it to where you want

I'd rather use a "mode" where I say I want to enter components (e.g. 
click on the toolbar item), then use press-drag-release to place and 
size instances of the selected component type, or simply click to place 
a default sized one.

If the property editor window is constantly available, then I'd just 
fill in a default name to avoid a dialog box - and it's available for 
easy, immediate editing as required.

3. fast creation (again)
better name/label defaulting. Current scheme usually requires both name 
and label (or text) to be edited. I think it would be better to change 
the rules (see below), and also to keep enough info within the component 
so that the derivation can be done *when needed*, not just on initial 
entry.  This can be done in a backwards compatible manner - so it 
doesn't need to be determined before 1.0 API is fixed.

Proposed rules.
a. Name and label are either "specified" or "derived" - all start "derived"
b. When user enters a value, it is used (and is now "specified"). Need a 
way to revert to "empty, derived".
c. If name is not specified, try to derive it from label; remove non 
alpha-numeric chars, lowercase it. If label is not yet specified, this 
can't be done - create a name (as done already).
d. If label is not specified, derive it from the name (i.e. copy name).

4. Multiple components.
Allow selection (ctl-select to add, etc., and rectangular areas select) 
to select multiple components.
Click-drag on any individual sizing handle still resizes just that one 
component - but other operations apply to all selected components.

5. Geometry operations.
Once we have multiple components selected, should then be able to
   - move them all
   - delete them all
   - align (top/bottom/middle, left/right/middle)
   - distribute them (various ways)
   - relayer them (i.e. re-arrange tab order)  (various ways, but 
sorting into reading-order is probably most important).

6. Geometry operations - complex
The operations listed in (5) are simple (to define - maybe not to do) - 
e.g. align left edge is (fairly) simple and unambiguous.
I see a need (or opportunity) for a more complex form of "tidy" 
operation, e.g.
vertical tidy - if the set of components selected includes multiple on 
substantially the same Y coord, those should be aligned by vertical 
centre, and distributed edge-to-edge (with spacing) horizontally. Then 
each component (or set of components) should be distributed edge-to-edge 
vertically; and aligned horizontally.
Probably needs some parameters what can be set. (!?)

7. Component grouping.
When  a set of components is selected, allow this set to be retained 
(i.e. group the components). This group, including info from vertical vs 
horizontal vs grid geometry settings can then be used to derive the 
sizer info to be used at run time.

8. Component groups for hierarchical events.
Allow operations on a group (e.g. group.visible = True, group.enabled = 
False, etc.).
Allow groups to catch events in the hierarchy. (e.g. def 
on_group_myGroup_mouseClick).

9. Move to free space ....
idea adapted from somewhere else entirely - but might work well here
we have arrow keys to move pixel-by-pixel, and ctrl-arrow to move 
grid-by-grid
add another (shift-ctrl-arrow) to move UNTIL the component is not 
overlapping any other (visible??) component
"Overlapping" should honour "min spacing" defined for other edit ops.


D. Integration of editors

I think it would be nice to have some integration between the editors
 - shift-double-click on a component and see the source in the code editor
 - shift-double-click within a handler in the code editor and see the 
component in the resource editor
etc.   but given the desire (need) to handle multiple code editors, and 
the lack of a standardized, clean way to pass info between editors, this 
doesn't get to be high on my list. 

The tabbedCodeEditor's lookup list of events for a particular component 
is handy - it would be nice to find a way to provide that for other code 
editors - maybe a text (not html) document, and/or a pop-up in the 
resource editor.


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 21/04/2005

[Pythoncard-users] ACCU conference

[Alex T. <al...@tw...>]

I was very lucky this last week to be able to attend the ACCU conference 
in Oxford, England. Kevin had been scheduled to give his talk on 
"Keeping it simple with Pythoncard" there, but was unable to attend, so 
I went in his place.

It's really great to be able to give and talk when all the hard work 
(i.e. the preparation and writing the slides) has been done by someone 
else :-)  The talk was a brief overview of Pythoncard, followed by a 
demo of building a simple app from scratch. While it was a simple app, 
it did demonstrate a variety of features, including component placement 
and editing, 'auto' event binding, menu building, using "command" 
instead of select in menus, dialogs, etc.

ACCU *used* to stand for the "Association of C and C++ Users" - I guess 
officially it still does, but in practice it has expanded to cover a 
number of other languages, and is essentially an organization, and 
conference, for professional developers. There were as many Java 
sessions as there were C++ ones, and there was a separate Python track. 
I believe the slides etc. will be available shortly, and once they are 
I'll send another note to this list to let you know where to find them.

There were a couple of other presentations on GUI systems for Python 
(using wxPython directly, and PyQt). Net result is I have come back with 
a re-invigorated set of ideas on what I'd like to see in Pythoncard, 
specifically in the Resource Editor to make it easier and faster to use, 
so I'll post those shortly.

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.10.2 - Release Date: 21/04/2005

Re: [Pythoncard-users] filename in result from saveFileDialog?

[Steve C. <stn...@xm...>]

> 
> When I use openFileDialog(), the result returns an absolute path.
> However, when I use saveFileDialog(), the result only returns the
> filename but not the path.
> 
> This is the case in my application as well as the dialog sample 
> (samples/dialogs/dialogs.py). 
> 
> 
> I'm using Mandrake 10.1, the latest PythonCard from CVS, and the following wxPython:
>     wxPython-common-gtk2-unicode-2.5.4.1-mdk101_py2.3
>     wxPython2.5-gtk2-unicode-2.5.4.1-mdk101_py2.3
> 

Upgrading to the 2.5.5.1 release of wxPython cleared up the problem with
saveFileDialog (it now returns the absolute path)

But, after upgrading I get error messages from PythonCard apps with
multicolumnlist controls. 

here's the stack trace:

  File "/home/stevec/sandbox/PythonCard/components/multicolumnlist.py", line 502, in _setItems
    self.resizeLastColumn(self.GetColumnWidth(numcols-1))
  File "/usr/lib/python2.3/site-packages/wx-2.5.5-gtk2-unicode/wx/lib/mixins/listctrl.py", line 212, in resizeLastColumn
    self.resizeColumn(self, minWidth)
TypeError: resizeColumn() takes exactly 2 arguments (3 given)



If I comment-out line 502 of PythonCard/components/multicolumnlist.py, things
appear to work OK.


Upgrading to 2.5.5.1 also fixed another intermittent problem I was
having.  (when I set an Image control to a new file, on one set of
images an error dialog would pop-up complaining about large files not
being supported... I can't remember the exact message)


-Steve

[Pythoncard-users] filename in result from saveFileDialog?

[Steve C. <stn...@xm...>]

When I use openFileDialog(), the result returns an absolute path.
However, when I use saveFileDialog(), the result only returns the
filename but not the path.

This is the case in my application as well as the dialog sample 
(samples/dialogs/dialogs.py). 


I'm using Mandrake 10.1, the latest PythonCard from CVS, and the following wxPython:
    wxPython-common-gtk2-unicode-2.5.4.1-mdk101_py2.3
    wxPython2.5-gtk2-unicode-2.5.4.1-mdk101_py2.3

-Steve

Re: [Pythoncard-users] Forcing a minimized PythonCard app to appear

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

On Mon, 18 Apr 2005 13:05:28 -0700, Kevin Altis wrote:

>> One option I have is to use ctypes to create a Win32 alert dialog
>> (maybe...I'm in the process of investigating since so far my ctypes
>> experience has just been in calling my own DLLs), but I was wondering 
>> if there was any PythonCard way of getting windows to "jump" off the 
>> taskbar.
>
>I would think that just doing self.visible = True would be enough, but 
>you might also want to do call self.Raise(). However, it might be more 
>correct to use the methods in wx.TopLevelWindow such as Iconize that 
>allows you to restore the window. Also, you'll probably want to use 
>RequestUserAttention. See the wxWidgets documentation for details.

Thanks....self.visible = True seems to do the trick with the limited
amount of testing I've done this week.

However, I really must put some time aside to study the wxWidgets stuff
because I'm probably denying myself the change to do various weird and
wonderful things. At the moment I only know enough to be dangerous...

Neil

RE: [Pythoncard-users] Re: new 0.8.1 exe binary to support Python 2.3.x and 2.4.x

[Schollnick, B. <Ben...@xe...>]

Actually I had problems with 2.5.5.1 and a List Control....

I downgraded to 2.5.3.1 (??) and it worked fine...

The 2.5.x.x's are "unstable" APIs...  They may be changing the APIs on
wxPython, and I believe that there maybe a API change on the list
controls....

	- Benjamin

> -----Original Message-----
> From: pyt...@li...=20
> [mailto:pyt...@li...] On=20
> Behalf Of Andy Todd
> Sent: Thursday, April 21, 2005 7:07 AM
> To: nos...@ca...
> Cc: pyt...@li...
> Subject: Re: [Pythoncard-users] Re: new 0.8.1 exe binary to=20
> support Python 2.3.x and 2.4.x
>=20
>=20
> Don Taylor wrote:
> > Kevin Altis wrote:
> >=20
> >> I took the existing 0.8.1 zip file and created a new installer EXE
> >> for  Windows using Python 2.3.5. I've tested it myself and=20
> it seems to=20
> >> work  fine on Python 2.3.5 and Python 2.4, however I would like=20
> >> confirmation  from some other people as well. There should be no=20
> >> differences between  the contents of the release from any=20
> of the other=20
> >> 0.8.1 file sets since  I used the last release zip rather than=20
> >> building the archive from the  current cvs. This file was=20
> done simply=20
> >> to remove the installer problem  people were having with=20
> Python 2.4.
> >>
> >> http://prdownloads.sourceforge.net/pythoncard/PythonCard
> >> -0.8.1.FIXED.win32.exe?download
> >>
> >=20
> >=20
> > Kevin:
> >=20
> > Which version of wxWindows should be used for Python 2.4.x?=20
>  I could=20
> > not find a py24 version of 2.5.2.8 and the py23 version=20
> won't install=20
> > on a Python 2.4 system.
> >=20
> > Thanks,
> >=20
> > Don.
> >=20
> >=20
>=20
> Try the binary available here;=20
> http://www.wxpython.org/download.php#binaries
>=20
> It's currently version 2.5.5.1 but this *should* be fine for=20
> PythonCard=20
> 0.8.1
>=20
> I haven't installed exactly this combination on Windows so=20
> please give=20
> it a try and let us know how you fare.
>=20
> Regards,
> Andy
> --=20
> --------------------------------------------------------------
> ------------------
>  From the desk of Andrew J Todd esq - http://www.halfcooked.com/
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.=20
> Version 11 adds new functionality designed to reduce time=20
> involved in creating, integrating, and deploying reporting=20
> solutions. Free runtime info, new features, or free trial,=20
> at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Pythoncard-users mailing list Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>=20

Re: [Pythoncard-users] Re: new 0.8.1 exe binary to support Python 2.3.x and 2.4.x

[Andy T. <an...@ha...>]

Don Taylor wrote:
> Kevin Altis wrote:
> 
>> I took the existing 0.8.1 zip file and created a new installer EXE 
>> for  Windows using Python 2.3.5. I've tested it myself and it seems to 
>> work  fine on Python 2.3.5 and Python 2.4, however I would like 
>> confirmation  from some other people as well. There should be no 
>> differences between  the contents of the release from any of the other 
>> 0.8.1 file sets since  I used the last release zip rather than 
>> building the archive from the  current cvs. This file was done simply 
>> to remove the installer problem  people were having with Python 2.4.
>>
>> http://prdownloads.sourceforge.net/pythoncard/PythonCard 
>> -0.8.1.FIXED.win32.exe?download
>>
> 
> 
> Kevin:
> 
> Which version of wxWindows should be used for Python 2.4.x?  I could not
> find a py24 version of 2.5.2.8 and the py23 version won't install on a
> Python 2.4 system.
> 
> Thanks,
> 
> Don.
> 
> 

Try the binary available here; http://www.wxpython.org/download.php#binaries

It's currently version 2.5.5.1 but this *should* be fine for PythonCard 
0.8.1

I haven't installed exactly this combination on Windows so please give 
it a try and let us know how you fare.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

[Pythoncard-users] Re: new 0.8.1 exe binary to support Python 2.3.x and 2.4.x

[Don T. <nos...@ca...>]

Kevin Altis wrote:
> I took the existing 0.8.1 zip file and created a new installer EXE for  
> Windows using Python 2.3.5. I've tested it myself and it seems to work  
> fine on Python 2.3.5 and Python 2.4, however I would like confirmation  
> from some other people as well. There should be no differences between  
> the contents of the release from any of the other 0.8.1 file sets since  
> I used the last release zip rather than building the archive from the  
> current cvs. This file was done simply to remove the installer problem  
> people were having with Python 2.4.
> 
> http://prdownloads.sourceforge.net/pythoncard/PythonCard 
> -0.8.1.FIXED.win32.exe?download
> 


Kevin:

Which version of wxWindows should be used for Python 2.4.x?  I could not
find a py24 version of 2.5.2.8 and the py23 version won't install on a
Python 2.4 system.

Thanks,

Don.

RE: [Pythoncard-users] newbie, tool to print resource structure

[Schollnick, B. <Ben...@xe...>]

> Back in the 90's my company made a commercial Motif=20
> GUI-Builder. From that experience I concur that being able to=20
> manually edit the resource file is a necessity, even though=20
> it may be seldom used.

A slight clarification...

I am not saying that you can't edit the resource file manually...

I am suggesting that the Resourceeditor is the only guaranteed method to
produce a resource file.

The resource editor can't make typos, make white space errors, make
syntax errors, or any of a 100s of human errors...

While the manually edited file should be okay, it's a valid concern that
someone might manually edit the file and goof something up.  Then demand
that Kevin "fix" the problem....

**** I have been in that situation before.  ****

I feel that it's important to at least acknowledge that manually editing
the file may not always be possible, nor supported....

What if Kevin moves to a XML based format?  Sure it's plain ascii, but I
personally don't feel that manually editing the tag data is worth it...


Or heaven forbid a binary format.... =20

		- Ben

>=20
> -----Original Message-----
> From: Andy Todd [mailto:an...@ha...]
> Sent: Tuesday, April 19, 2005 5:36 PM
> To: Schollnick, Benjamin
> Cc: pyt...@li...
> Subject: Re: [Pythoncard-users] newbie, tool to print=20
> resource structure
> Importance: Low
>=20
>=20
> Schollnick, Benjamin wrote:
> >>>Very useful....  I would suggest that Kevin consider adding
> >>
> >>it to the
> >>
> >>>Resource editor and maybe even expanding on it....
> >>>
> >>>Possibly noting any non-default values that have been
> >>
> >>configured for
> >>
> >>>the widgets...
> >=20
> >=20
> >>The danger with this approach is that the printer friendly version
> >>*could* get out of sync with the resource file. Especially if the=20
> >>resource file is edited outside the resourceEditor.
> >=20
> >=20
> > While that is a valid concern.... In my opinion the user is not=20
> > suppose to edit the file outside of the ResourceEditor....
> >=20
> > So it is a moot point.
> >=20
>=20
> Sorry, but there you are wrong. The whole point of making the=20
> resource=20
> file a valid Python  file is so that you aren't restricted to=20
> using the=20
> resourceEditor to amend it.
>=20
> This is an important point and if there is any misunderstanding or=20
> mis-communication I think we should address it. Is there anything in=20
> particular that led you to this conclusion?
>=20
>=20
> [snip]
> >=20
> >=20
> > Then you are making an automated task into a manual task=20
> that has to=20
> > be run after every change made on the file.... (i.e. Pydoc)
> >=20
> > If you are concerned about allowing the user to do a manual=20
> execution=20
> > of this....  Then we could make a stub so that the user can=20
> run it.... =20
> > But it should stay in the resourceeditor to make it automagically=20
> > updated when edited in the resourceeditor.
>=20
> See Kevin's point about scriptlets, this is a perfect use=20
> case for one.
>=20
> Regards,
> Andy
> --=20
> --------------------------------------------------------------
> --------------
> ----
>  From the desk of Andrew J Todd esq - http://www.halfcooked.com/
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.=20
> Version 11 adds new functionality designed to reduce time=20
> involved in creating, integrating, and deploying reporting=20
> solutions. Free runtime info, new features, or free trial,=20
> at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Pythoncard-users mailing list Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>=20
> --------------------------------------------------------------
> -------------
> The information contained in this message may be privileged=20
> and / or confidential and protected from disclosure. If the=20
> reader of this message is not the intended recipient, you are=20
> hereby notified that any dissemination, distribution or=20
> copying of this communication is strictly prohibited. If you=20
> have received this communication in error, please notify the=20
> sender immediately by replying to this message and deleting=20
> the material from any computer.
> --------------------------------------------------------------
> -------------
>=20

RE: [Pythoncard-users] newbie, tool to print resource structure

[Schollnick, B. <Ben...@xe...>]

> > While that is a valid concern.... In my opinion the user is not=20
> > suppose to edit the file outside of the ResourceEditor....
> >=20
> > So it is a moot point.
>=20
> Sorry, but there you are wrong. The whole point of making the=20
> resource file a valid Python  file is so that you aren't restricted
> to using the resourceEditor to amend it.

So Kevin is suppose to accept typo's, and or bad syntax or managled
white space in the file?

We have a application that is perfectly able to edit and manipulate the
resource file...  If you manually change the file, you need to take
responsibility for altering the file.

Once in a blue moon I may open the file to do a group find and replace,
if I decide to radically change my naming strategy....

But that doesn't mean it's a supported method of changing the file.
How can kevin guarantee that the resource file is valid if it is not
maintained through the resourceeditor?

> This is an important point and if there is any misunderstanding or=20
> mis-communication I think we should address it. Is there anything in=20
> particular that led you to this conclusion?

Specifically, no.  But I believe that there needs to be a clear
seperation between what Kevin supports and doesn't.  Asking Kevin to
support people editing the resource file outside of the resourceeditor
is asking for support headaches.

It maybe a plain text format....  But that does not mean that you can
guarantee a valid resourcefile / python file will be the final result...

> > But it should stay in the resourceeditor to make it automagically=20
> > updated when edited in the resourceeditor.
>=20
> See Kevin's point about scriptlets, this is a perfect use=20
> case for one.

Fine....  But I do still suggest that it is a automatic feature in the
resourceeditor...  Or at least have a preference option for it to be
automatic...

I have found that feature to be very useful....  It prevents me from
having to have the resourceeditor open all the time to simply look up
the field names...

		- Benjamin

RE: [Pythoncard-users] newbie, tool to print resource structure

[Sells, F. <fr...@ad...>]

Back in the 90's my company made a commercial Motif GUI-Builder. From that
experience I concur that being able to manually edit the resource file is a
necessity, even though it may be seldom used.

-----Original Message-----
From: Andy Todd [mailto:an...@ha...]
Sent: Tuesday, April 19, 2005 5:36 PM
To: Schollnick, Benjamin
Cc: pyt...@li...
Subject: Re: [Pythoncard-users] newbie, tool to print resource structure
Importance: Low


Schollnick, Benjamin wrote:
>>>Very useful....  I would suggest that Kevin consider adding=20
>>
>>it to the=20
>>
>>>Resource editor and maybe even expanding on it....
>>>
>>>Possibly noting any non-default values that have been=20
>>
>>configured for=20
>>
>>>the widgets...
>=20
>=20
>>The danger with this approach is that the printer friendly version=20
>>*could* get out of sync with the resource file. Especially if the=20
>>resource file is edited outside the resourceEditor.
>=20
>=20
> While that is a valid concern.... In my opinion the user is not suppose
> to edit the file outside of the ResourceEditor....=20
>=20
> So it is a moot point.
>=20

Sorry, but there you are wrong. The whole point of making the resource=20
file a valid Python  file is so that you aren't restricted to using the=20
resourceEditor to amend it.

This is an important point and if there is any misunderstanding or=20
mis-communication I think we should address it. Is there anything in=20
particular that led you to this conclusion?


[snip]
>=20
>=20
> Then you are making an automated task into a manual task that has to be
> run after every change made on the file.... (i.e. Pydoc)
>=20
> If you are concerned about allowing the user to do a manual execution of
> this....  Then we could make a stub so that the user can run it....  But
> it should stay in the resourceeditor to make it automagically updated
> when edited in the resourceeditor.

See Kevin's point about scriptlets, this is a perfect use case for one.

Regards,
Andy
--=20
----------------------------------------------------------------------------
----
=20From the desk of Andrew J Todd esq - http://www.halfcooked.com/



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

---------------------------------------------------------------------------
The information contained in this message may be privileged and / or
confidential and protected from disclosure. If the reader of this message is
not the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this communication in error, please notify the sender
immediately by replying to this message and deleting the material from any
computer.
---------------------------------------------------------------------------

Re: [Pythoncard-users] newbie, tool to print resource structure

[Andy T. <an...@ha...>]

Schollnick, Benjamin wrote:
>>>Very useful....  I would suggest that Kevin consider adding 
>>
>>it to the 
>>
>>>Resource editor and maybe even expanding on it....
>>>
>>>Possibly noting any non-default values that have been 
>>
>>configured for 
>>
>>>the widgets...
> 
> 
>>The danger with this approach is that the printer friendly version 
>>*could* get out of sync with the resource file. Especially if the 
>>resource file is edited outside the resourceEditor.
> 
> 
> While that is a valid concern.... In my opinion the user is not suppose
> to edit the file outside of the ResourceEditor.... 
> 
> So it is a moot point.
> 

Sorry, but there you are wrong. The whole point of making the resource 
file a valid Python  file is so that you aren't restricted to using the 
resourceEditor to amend it.

This is an important point and if there is any misunderstanding or 
mis-communication I think we should address it. Is there anything in 
particular that led you to this conclusion?


[snip]
> 
> 
> Then you are making an automated task into a manual task that has to be
> run after every change made on the file.... (i.e. Pydoc)
> 
> If you are concerned about allowing the user to do a manual execution of
> this....  Then we could make a stub so that the user can run it....  But
> it should stay in the resourceeditor to make it automagically updated
> when edited in the resourceeditor.

See Kevin's point about scriptlets, this is a perfect use case for one.

Regards,
Andy
-- 
--------------------------------------------------------------------------------
 From the desk of Andrew J Todd esq - http://www.halfcooked.com/

Re: [Pythoncard-users] newbie, tool to print resource structure

[Kevin A. <al...@se...>]

On Apr 19, 2005, at 5:13 AM, Sells, Fred wrote:

> I use it and I edit (infrequently) outside the resource editor.  When  
> that
> happens, I use the resource editor to load and save to get it in sync.  
>  I
> have a very slight preference toward a separate module/script run from  
> the
> command line.  It would facilitate making the tool more robust and  
> making it
> easier for users to customize to meet their needs.

As a general rule, my own preference is to not add a lot of extra  
infrequently used menu items to any of the standard PythonCard tools.  
As an alternative, I added "scriptlets" to the codeEditor a long time  
ago, which are simply scripts of anything that can be run in the shell  
and that could include a standard Python module along with a call to  
run a particular function. There are some examples in the codeEditor  
scriptlets directory such as insertDateAndTime.py

import time
now = time.localtime(time.time())
dateStr = time.strftime("%A, %B %d, %Y,  %I:%M %p", now)
comp.document.ReplaceSelection(dateStr)

You can think of scriptlets as "macros" if you want and there is even  
support in the codeEditor for making menu items that run these  
scriptlets, it just isn't documented, nor is there a UI for managing  
the menu, I just never seem to get around to writing it, even though it  
is a minor amount of code and UI for the dialog. As an example, I have  
the following line in my pythoncard_config\codeeditor\user.config.txt  
file which menu item with Ctrl+1 as a shortcut in the Shell menu:

'macros': [{'filename':  
'C: 
\\python\\PythonCard\\tools\\codeEditor\\scriptlets\\insertDateAndTime.p 
y', 'key: 'Ctrl+1', 'label': 'insertDateAndTime'}],

The line is just another key/value pair in the dictionary.

The reason I bring this up is that the resourceEditor should probably  
have the same scriptlets support and with a dialog to easily allow  
people to add and remove items from the menu you can have whatever  
macros you want.

ka