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