pythoncard-users

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

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

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".

Please reply with your gripes about PythonCard,
whether it is something as fundamental as the strong
ties to wxPython, the somewhat clunky resourceEditor,
lack of sizer support, missing widgets supported by
wxPython, standalone build issues, etc. If you don't
mention a problem, then chances are it won't get
coverage on the developers mailing list that it
deserves. If you think the project focus is wrong,
then say so; if you expected a better tool for
building database applications, share your thoughts...
If you really want something that works just like
HyperCard did, now is a good time to make that clear.
And yes, documentation or lack of, just like
everything else, is fair game. If you've been lurking
on the list, its time to speak up :)

You can also reply with what you like most about
PythonCard, so as we're thinking about later versions
from 1.1 - 2.0, that feature doesn't get dropped.

ka
p.s. I'm currently traveling and using an email
address that is effectively a blackhole for messages,
so there is no need to reply to this address as I
won't be checking it.


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

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

[Brian D. <deb...@ho...>]

Hi everyone,

Personally, I would love the resource editor to be as simple as it is but 
with user oriented features like when double clicking a button, open de 
source file and add on_cmdButton_mouseClick(self, event) and stuff like 
that. :)

Hope this inspires to a powerfull editor, it would be really nice.

Regards,


Brian

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

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

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

I think doubleclicking the widget in resource editor should bring up the 
Property Editor, rather than the source file. This is the behavior in 
HyperCard and similar environments such as Revolution. I think 
shift-doubleclicking the widget might be a nice shortcut for bringing up 
the source code.

But which source code? Usually a background is linked to a Python script 
containing a class MyBackground, and usually this is where an event is 
stored...but not always. Maybe this should be a settable property in the 
resource file, which defaults to undefined, and when undefined just looks 
for a same-named Python script as the resource file. 

Also, regarding the opening of source code from Resource Editor, I think 
it would be nice to have a global prefererence governing the choice of 
preferred text editor. The choice of text editors is highly idiosyncratic, 
and may not want to use the PythonCard Code Editor. 




"Brian Debuire" <deb...@ho...> 
Sent by: pyt...@li...
03/29/2005 11:59 AM

To
pyt...@li...
cc

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






Hi everyone,

Personally, I would love the resource editor to be as simple as it is but 
with user oriented features like when double clicking a button, open de 
source file and add on_cmdButton_mouseClick(self, event) and stuff like 
that. :)

Hope this inspires to a powerfull editor, it would be really nice.

Regards,


Brian

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

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

[Liam C. <cy...@gm...>]

Hi, 

While I enjoy the excitement of a good treasure hunt in model.py, some
thorough docs would be good.

I'd offer to write them, but I keep having "Oh, so that's how you do
that" moments.


On Tue, 29 Mar 2005 12:31:23 -0600, bra...@om...
<bra...@om...> wrote:
>  
> I think doubleclicking the widget in resource editor should bring up the
> Property Editor, rather than the source file. This is the behavior in
> HyperCard and similar environments such as Revolution. I think
> shift-doubleclicking the widget might be a nice shortcut for bringing up the
> source code. 
>  
> But which source code? Usually a background is linked to a Python script
> containing a class MyBackground, and usually this is where an event is
> stored...but not always. Maybe this should be a settable property in the
> resource file, which defaults to undefined, and when undefined just looks
> for a same-named Python script as the resource file. 
>  
> Also, regarding the opening of source code from Resource Editor, I think it
> would be nice to have a global prefererence governing the choice of
> preferred text editor. The choice of text editors is highly idiosyncratic,
> and may not want to use the PythonCard Code Editor. 
>  
>  
>  
>  
>  "Brian Debuire" <deb...@ho...> 
> Sent by: pyt...@li... 
> 
> 03/29/2005 11:59 AM 
>  
> To pyt...@li... 
>  
> cc 
>  
> Subject RE: [Pythoncard-users] time to share your PythonCard gripes and
> likes 
>  
>  
>  
>  
>  
> Hi everyone,
>  
>  Personally, I would love the resource editor to be as simple as it is but 
>  with user oriented features like when double clicking a button, open de 
>  source file and add on_cmdButton_mouseClick(self, event) and stuff like 
>  that. :)
>  
>  Hope this inspires to a powerfull editor, it would be really nice.
>  
>  Regards,
>  
>  
>  Brian
>  
>  _________________________________________________________________
>  Don't just search. Find. Check out the new MSN Search! 
>  http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>  
>  
>  
>  -------------------------------------------------------
>  SF email is sponsored by - The IT Product Guide
>  Read honest & candid reviews on hundreds of IT Products from real users.
>  Discover which products truly live up to the hype. Start reading now.
>  http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>  _______________________________________________
>  Pythoncard-users mailing list
>  Pyt...@li...
>  https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>  
>  


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.

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

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

Is the PythonCardToDoList discontinued?
http://wiki.wxpython.org/index.cgi/PythonCardToDoList

In the current PythonCard my biggest problem is sys.argv

If I have my own command line args and check for unexpect args in my code,
that logic gets scrambled when I use the PythonCard resouce editor and it
places the run options in the command line. I guess that when I plan to use
PythonCard I need to make allowances for PythonCard command args, but I
have my doubts about 'other args' in the Run Options window. I cannot get
my own args into the command line this way. The
resource_editor_overview.html,Figure 19 ("Run Options Dialog") does not
even show the current 'other args' text field, so I'm more lost than ever.

The other problem with sys.argv is that it complicates running code by
importing a module. Without some tacky manipulation of sys.argv, I'm
limited to running my code only one way, as a Python script.  Perhaps
Application __init__ should have an alternate argument for all the values
which it currently searches in sys.argv.  It does appear that all use of
sys.argv, especially sys.argv[0], occurs through Application __init__

I'm glad to say that is my biggest PythonCard problem.


As for wishes, I don't know the status or schedule of such things, but I
would dearly like scroll controls (wxScrolledWindow?) for the background
window. PythonCard is the easiest toolkit with the capability to place a
bitmap on the background, so please don't drop any of the current
background functionality in exchange for that scrolling.

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

[Peter C. N. <spa...@le...>]

It'd be nice if the python shell within codeEditor could be
re-initialized once you've gotten to the point where you've screwed
everything up.  I don't see a way for doing that right now, except for
re-starting codeEditor.

-Peter

On Tue, Mar 29, 2005 at 09:01:35AM -0800, 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".
> 
> Please reply with your gripes about PythonCard,
> whether it is something as fundamental as the strong
> ties to wxPython, the somewhat clunky resourceEditor,
> lack of sizer support, missing widgets supported by
> wxPython, standalone build issues, etc. If you don't
> mention a problem, then chances are it won't get
> coverage on the developers mailing list that it
> deserves. If you think the project focus is wrong,
> then say so; if you expected a better tool for
> building database applications, share your thoughts...
> If you really want something that works just like
> HyperCard did, now is a good time to make that clear.
> And yes, documentation or lack of, just like
> everything else, is fair game. If you've been lurking
> on the list, its time to speak up :)
> 
> You can also reply with what you like most about
> PythonCard, so as we're thinking about later versions
> from 1.1 - 2.0, that feature doesn't get dropped.
> 
> ka
> p.s. I'm currently traveling and using an email
> address that is effectively a blackhole for messages,
> so there is no need to reply to this address as I
> won't be checking it.
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.

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

[Liam C. <cy...@gm...>]

Hi, 

A Pythoncard wiki would also be nice.

And being able to pass arguments to children window when doing a 
x = model.ChildWindow(), the current method works, but it's not overly Pythonic.


Regards, 

Liam Clarke


On Tue, 29 Mar 2005 12:50:56 -0800, Peter C. Norton
<spa...@le...> wrote:
> It'd be nice if the python shell within codeEditor could be
> re-initialized once you've gotten to the point where you've screwed
> everything up.  I don't see a way for doing that right now, except for
> re-starting codeEditor.
> 
> -Peter
> 
> On Tue, Mar 29, 2005 at 09:01:35AM -0800, 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".
> >
> > Please reply with your gripes about PythonCard,
> > whether it is something as fundamental as the strong
> > ties to wxPython, the somewhat clunky resourceEditor,
> > lack of sizer support, missing widgets supported by
> > wxPython, standalone build issues, etc. If you don't
> > mention a problem, then chances are it won't get
> > coverage on the developers mailing list that it
> > deserves. If you think the project focus is wrong,
> > then say so; if you expected a better tool for
> > building database applications, share your thoughts...
> > If you really want something that works just like
> > HyperCard did, now is a good time to make that clear.
> > And yes, documentation or lack of, just like
> > everything else, is fair game. If you've been lurking
> > on the list, its time to speak up :)
> >
> > You can also reply with what you like most about
> > PythonCard, so as we're thinking about later versions
> > from 1.1 - 2.0, that feature doesn't get dropped.
> >
> > ka
> > p.s. I'm currently traveling and using an email
> > address that is effectively a blackhole for messages,
> > so there is no need to reply to this address as I
> > won't be checking it.
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Small Business - Try our new resources site!
> > http://smallbusiness.yahoo.com/resources/
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Pythoncard-users mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 
> --
> The 5 year plan:
> In five years we'll make up another plan.
> Or just re-use this one.
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
> 


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.

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

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

How could it be any nicer than this?
http://wiki.wxpython.org/index.cgi/PythonCard
(via left side of http://pythoncard.sourceforge.net/)

pyt...@li... wrote on 03/29/2005 02:41:38
PM:

> Hi,
>
> A Pythoncard wiki would also be nice.
>
> And being able to pass arguments to children window when doing a
> x = model.ChildWindow(), the current method works, but it's not
> overly Pythonic.
>
>
> Regards,
>
> Liam Clarke
>
>

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

[Bo G. <bo...@sy...>]

My biggest requests right now are sizer support, and a scrollable 
Background & PageBackground, but that's just because of the particular 
challenges I'm faced with today. Ask me tomorrow, different answers 
probably. I also would like to see more features in the resource editor 
(as others have mentioned), but first give us multiple windows, please. 
Code completion in the code editor would be sweet indeed.
The other thing I would like to see is a list of valid events and 
methods for each Pythoncard component, which could act as an easy 
reference guide. I guess you could call that documentation. Pythoncard 
is awesome, it's definitely making life easier for me.
No complaints really, just a request to keep adding features.
BG



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".
>
>Please reply with your gripes about PythonCard,
>whether it is something as fundamental as the strong
>ties to wxPython, the somewhat clunky resourceEditor,
>lack of sizer support, missing widgets supported by
>wxPython, standalone build issues, etc. If you don't
>mention a problem, then chances are it won't get
>coverage on the developers mailing list that it
>deserves. If you think the project focus is wrong,
>then say so; if you expected a better tool for
>building database applications, share your thoughts...
>If you really want something that works just like
>HyperCard did, now is a good time to make that clear.
>And yes, documentation or lack of, just like
>everything else, is fair game. If you've been lurking
>on the list, its time to speak up :)
>
>You can also reply with what you like most about
>PythonCard, so as we're thinking about later versions
>from 1.1 - 2.0, that feature doesn't get dropped.
>
>ka
>p.s. I'm currently traveling and using an email
>address that is effectively a blackhole for messages,
>so there is no need to reply to this address as I
>won't be checking it.
>
>
>		
>__________________________________ 
>Do you Yahoo!? 
>Yahoo! Small Business - Try our new resources site!
>http://smallbusiness.yahoo.com/resources/ 
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>  
>

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

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.