pythoncard-users — PythonCard Users and Developers

[Pythoncard-users] Updated EXPERIMENTAL resource Editor - now at v0.3

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

> Unfortunately, 0.3 will not be out tonight as previously expected.

Version 0.3 is now available, at 
www.tweedly.net/Python/newresourceEditorv0.3.zip 
Note in particular the need to update Pythoncard/widget.py for this 
version.


----------------------------------------------------
Experimental Resource Editor v 0.3

This version of the resource Editor has the following changes:

0.2:  as 0.1, with the addition of layering for multiple components,
rectangular marquee selection and bug fixes - see "0.2" for details.

0.3: bug fixes:
        click-on-space deselects all components will now cause
            switch back to single mode
        ctrl-click to deselect component failed to remove said component
            from componentList display
     automatic naming rules - see below


IMPORTANT NOTE: 0.3 requires you to update Pythoncard/widget.py When
you unzip the newresourceEditorv0.3 directory, you will find the
updated version of widget.py inside the resource editor directory. You
need to copy this over to the top-level of your Pythoncard
directory. Please keep a copy of the existing widget.py in case of problems.


Property editor window display.

The propertyEditor Window has been extensively changed. Previously it
was a small window, showing a list of components and a list of
attributes applicable to the currently selected component. The
currently selected attribute was displayed (and editable) below this.

The new version uses a much larger window, again showing a list of
components. For the currently selected component, ALL attributes are
shown, in a large area to the right. Any of the attributes can be
edited directly, and the change will take effect as soon as the focus
leaves the field being edited (the Update button is still also
available).

0.3
Component naming when created - automatic naming rules

When a component is newly created, its name is automatically generated;

 - if a new component being added, the name is formed by taking the
   component type name, and appending an integer - the smallest number
   which provides a new unique name. Thus: Button1, Button2, Button3,
   ...

- if a component is being created by either a copy/paste, or
  Edit/Duplicate command, then name is based on the existing
  component, with an integer appended (again, smallest number to
  produce a new name is used). Thus: if Button1 is being Duplicated,
  the new component will be Button11, or Button12, or Button13....

If the component has a label or text attribute, this will be
automatically generated; it will be the same as the name.

Both the name and the label/text are marked as being "auto-generated"
(actually, as NOT being "user-specified"). If either one is edited by
the user, it is then marked as "user-specified", and it will no longer
be subject to automatic updating. So long as the name or label/text
are not user-specified, they will be automatically updated if the other
one is modified by the user.

The label/text will be set to the same as the name.

The name will be set to the same as the label, but with all characters
except letters and numbers removed, all spaces converted to underscore
("_"), and all other characters removed. Any leading numbers or
underscores will be removed (to ensure it is a valid variable name),
and it will be shortened to a maximum of 24 characters long. Then an
integer will be appended, the smallest number producing a new unique
name is used.

In the propertyEditor display, alongside the name and label/text is a
checkbox showing whether each is user-specified or not. If you modify,
for instance, the name it will automatically check the associated
checkbox. If you wish the name to revert to being automatically
generated, simply uncheck this box.

0.3 end


0.2 section ....  replaced by the above auto-naming rules
In the existing resourceEditor, every time you create a component
(either from the Component menu, or by Duplicate, or Paste), you are
presented with a dialog box to specify the name (and label / text for
those components that have them).


I have taken that out (at least for now) - so the component is
immediately created with the default name/label. I've found this
better and faster for my testing - but I'm not sure if it would be the
same when using the resourceEditor "for real", rather than for
testing.

If you want to revert to the earlier behaviour, find the line
       result = fakeEmptyDialog(desc, offsets, promptString)
around line 1334. Comment it out, and reinstate the previous line.

The medium-term intent is to extend the "clever default"s for deriving
labels from names, or names from labels - so that you can achieve what
you need with the minimum amount of typing possible. Stay tuned ....
.... end of 0.2 section

Multiple components.

You can select multiple components and perform various operations on
them. Clicking on a component selects it (just as before). Ctrl-click
will add a component to the selected set, or remove it if it is
already in there.  The property window can be watched to let you know
if you are in "single-component mode" or "multiple-component mode".

If you select a number of components, and then deselect all but one of
them, you remain in multi-component mode. (NB this feels better to me
- but is certainly a candidate for later change if we think we
should.) This does save a "flash" back into single mode display, when
de-selecting and re-selecting most of a group.

If there is NO component selected, and you select the first one by
Ctrl-Click, then you enter multi-component mode immediately. The
specific reason I did this no longer applies - but I'd got used to it
by then. Again, this does save a certain amount of "flashing" between
the two modes (and their display).

Note that when in multiple-component mode, the component box in the
property window is for display only - you cannot click in that box to
(de)select components. "0.2" - fixed; in 0.1, it did allow clicking in
this box, with varied and interesting results. A related fix involving
selecting first component from this componentList in the
propertyEditor, and additional components by Ctrl-clicking also fixed.

It shows only those components which are in the
selected set. This is mostly because Pythoncard doesn't have a
multi-choice list box, but also partly because using a multi-choice list
would make it harder to see at a glance which are selected.

Once a set of components have been selected, you can mouse-down
(i.e. press and hold, no ctrl-key) WITHIN one of the selected
components; this will bring up the enclosing rectangle for the whole
set, and you can then move them around. 

They can also be moved using the arrow keys; however, this has always
been a bit flaky - sometimes the key events get captured by something
else, and used for filed-traversal-tabbing. It may be a bit more flaky
with the new display panel - see "nudge commands" below for other
options.

Note that Copy, Cut and Paste *do* work for multiple components. There
isn't yet a Delete command that works for multiple-component mode, but
you can simply Cut them in the meantime.

0.2 changes - marquee selection

Multiple component selection using rectangular "marquee"

You can select multiple components by enclosing them within a
rectangular "marquee". The basic form involves pressing the mouse
button down NOT within any component, and while holding the button
down, dragging the mouse out to surround some components. These
components will become a new multiple-component selection, replacing
any previous selection.

You can modify this by using modifier keys while doing the rectangle 
selection.

1. No modifier - define a new selection

2. shift-rectangle : add enclosed components to existing selection
   (any enclosed components already selected remain selected)

3. ctrl-rectangle : toggle the status of enclosed components (i.e. if
   already selected, remove it, if not already selected, add it)

4. shift-ctrl-rectangle : subtract from existing selection

end of this 0.2 change.




Buttons for layer changes.

A component can be moved Back/Forward using the main menu Options /
Send to Back, etc., or the shortcut keys Ctrl-1, Ctrl-2, etc.
However, these keys don't work when focus is in the property
window. Buttons have been added (below the component list box) to
allow re-layering of a component.

0.2 changes : Relayering of multiple components.

As well as the 4 buttons corresponding to the existing commands, there
are two additional ones which only take effect when there are multiple
components selected.  First, a description of what it means to
re-layer multiple components.

All the selected components are put, in the order they were selected,
together in the final order list. The base component (first one
selected) is then moved back or forward according to the given
command, with all other selected components following it.

In some cases, you will want to collect the selected components
together in the component ordering, but without changing the base
component's place in the order. The first new button "gather together"
does this.

The second new button takes a set of components and re-layers them
according to their position, in approximate "reading" order; top-left
to bottom right, in rows. Just like "Gather together", this re-ordered
set of components finish up adjacent in the layer ordering, following
the place in order of the base component.

Beware that the reading order works well if the components are
non-overlapping, but can be hard to predict when there are multiple
overlapping components selected (e.g. if you were to edit the resource
editor's own resource file, where the "single-mode" and
"multiple-mode" controls occupy the same area, and simply select all
of them, you will get a different result from what you expect or
want. This is a result of the comparison function used to sort into
"reading order" - if one component is entirely below another, the
order is clear; otherwise they are assumed to be on the same row, and
sorted according to X coord.

NB There is a definite lack of visual feedback from these
commands. I'm trying to find a good way to give this feedback - any
suggestions gratefully received.

 These command will probably go on the menu eventually.

end of this 0.2 change


Arrow keys & Buttons to 'nudge' components.

The arrow keys can be used to reposition a component, as
before. However, they now have the added feature that

 - Ctrl-arrow will move in that direction by the currently specified
    grid step, and align to the grid even if the "Align to grid"
    option is not enabled.

 - Shift-arrow will move by the grid step distance, but without
   rounding to the grid

 - Shift-Ctrl-arrow will move by the square of the grid size (and
   round to the basic grid). Good accelerator for big moves - beware
   you can jump right off the window if you're not careful.

As mentioned above, occasionally (or perhaps often), one or more of
the placed components gets in the way of key events ['buttons start
tabbing, calendar starts moving the selected date, etc.]. Therefore
there are now button on the property window to move the selected
component or components. these are in the box labelled "NUDGE" at the
bottom-left.

Clicking on each arrow button here moves the component in the obvious
direction. The number inside these buttons controls how far the
components are moved; 1 moves by 1 pixel, 2 by a grid-step, 4 by the
square of a grid-step. (3 is the same as 2 for now). These moves
always honour the Align to Grid setting.  [NB - this may change -
either to be simply pixel distance, or a drop-down choice for the 1 vs
grid vs grid*grid to allow all the choices available by the arrow
keys.]

Various operations are enabled when in multi-component mode. Remember 
that the *order* the components were selected (visible by order they are 
listed in the component box) is significant for many of these.

Align operations.

The box labelled "ALIGN" contains six buttons, which align the
components up with the first selected on. They can be aligned by left
side, right side, top, bottom (four buttons grouped to the left). Or
the centres of the components can be aligned, either vertically or
horizontally (i.e. into a column or into a row).


Distribute operations.

The box labelled "DISTRIBUTE" has four buttons; two on the left for
distributing horizontally and two on the right for vertical
distribution.

The top button on each side distributes the components "edge-to-edge";
i.e. the first component does not move, the second one is placed to
the left (or below) such that the edges line up, then the third, etc.

The lower button distributes them with even-sized gaps from
"first-to-last"; i.e. the first and last components do not move, the
others are distributed between them such that the gaps between the
edges are equal sized (or as close as possible). Note that if the
components add up to larger than the total distance between first and
last, then they will overlap (i.e. the 'gap' can be negative), but it
will still be evenly shared between them.

Equalize operations.

The box labelled "EQUALIZE" has three buttons, which set the width
(the height, or both) of all other components selected to match the
first component.

0.2 changes : Bug fixes since 0.1

1. Never save sizing handles to resource file. 

In 0.1, if you selected multiple components, and then saved the
resource file, the sizing handles were saved to the file along with
the user's components. Oops.  Fixed now.



Other changes and bug-fixes included.

1. Flaky behaviour on re-sizing a component.

Moving the cursor rapidly back inside a Textfield (or TextArea, or
...) while re-sizing it would cause it to change to almost random
size.

2. Flaky "move" - double-click.

Double-clicking within a Button component prior to moving it would
cause the mouse to become "locked" into that component. So you could
click outside the component, and it would nevertheless move with the
mouse; also you were unable to select another component, or the
menu. Could be solved by clicking in another window (though not
another window of this program), and then clicking back in this
window.

I've got a "fix" for this in place - though I don't understand why it
works. (I discovered that all subsequent mouse events were reporting
the "getEventObject() wrongly, and having a handler for doubleClick -
even one that does nothing - seems to solve it.

You shouldn't - but might - see a dialog that says
    "You double-clicked - please don't"
This means that work-around didn't work - just click OK to the dialog
and you'll be able to continue.

3. Calendar component "hops"

There is code to ensure that components with a border allow for that
when calculating moves; without this a click on the component would
"hop" it by the border width. This hadn't been done for Calendar
components, and has now.

[ Mac users - please let me know if I guessed right for the offset needed ]

4. Static line and gauges/sliders ignored layout setting.

The setting for layout (either horizontal / vertical) was being ignored.



Clearly still missing .....
1. [DONE] re-layer for multiple components
2. delete multiple components (but Cut is done already)
3. [DONE] select multiple components by rectangular marquee
4. select multiple components by regular expression
      (useful if you use systematic names, and want to pick them all ....)
5. undo (at least for the multiple-component operations).
Do be careful; you can mess up really fast with multiple component 
operations !
6. Temporary hide/show of selected components.
(Take a look at the property window in the resource editor - it's a
pain to work on because the single-component mode fields overlap the
multi-component mode buttons.



-- 
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.11.5 - Release Date: 04/05/2005

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

Bo Green wrote:

> Another somewhat related issue, with the 0.2 I'm using now, 
> <ctrl>-deselecting one component from a multiple-selection doesn't 
> remove it from the sublist of components in propEd. It should, right?

Certainly should - will be fixed in v0.3

Unfortunately, 0.3 will not be out tonight as previously expected.

It's going well enough (in fact, code is done), but I got caught up in 
watching the election results, and as a result I'm not done with the  
regression testing and packaging/testing.  I'll finish up tomorrow when 
I'm less likely to make silly mistakes.

-- 
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.11.5 - Release Date: 04/05/2005

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

The only argument I can think of to change those two is that in both 
cases you mentioned (one component left, zero components left), the 
propEd widgets no longer have any real meaning in a multi-component 
sense. What's the point of equalizing, aligning, or distributing one 
component (or zero components). So it makes sense to switch back to the 
mode where the propEd buttons and fields make the most contextual sense.
Not a bust 'em down argument, but something to kick around.

Another somewhat related issue, with the 0.2 I'm using now, 
<ctrl>-deselecting one component from a multiple-selection doesn't 
remove it from the sublist of components in propEd. It should, right?
Bo


Alex Tweedly wrote:

>
> When you get down to a single component remaining selected, I *could* 
> switch to single-mode - but don't.
> If you then deselect that last one, I *could* switch to single mode - 
> but don't.
>
> If you think it should do those - you need to convince me :-)   If you 
> do have good arguments for doing that, it will be fairly easy to 
> implement, but I don't want to change without being convinced.
>

Re: [Pythoncard-users] RPM problem with libsdl

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

On Thu, 2005-05-05 at 13:28, Al wrote:
> Sorry, this is not quite directly relevant to PythonCard as program, but is a 
> problem with trying to get it installed.  I'm on Mandrake 10.2.  
> 
> Trying to install WXPython, to use PythonCard.  Blocked by missing libsdl.    
> Download and try to install, it says it already is installed.  Do rpm 
> -replace, and it says file missing cannot be opened.  Consider removing and 

On Mandrake, you're generally better off using the 'urpmi' tool to
install packages rather than using the base 'rpm' command itself. This
will resolve dependencies automatically for you. In your case, you ought
to be able to just do:

urpmi wxpython-X.X.X.rpm

With whatever the appropriate RPM filename is. Try that and let us know
how you get on.

-- 

Regards

Phil Edwards
Brighton, UK

[Pythoncard-users] RPM problem with libsdl

[Al <pal...@ya...>]

Sorry, this is not quite directly relevant to PythonCard as program, but is a 
problem with trying to get it installed.  I'm on Mandrake 10.2.  

Trying to install WXPython, to use PythonCard.  Blocked by missing libsdl.    
Download and try to install, it says it already is installed.  Do rpm 
-replace, and it says file missing cannot be opened.  Consider removing and 
replacing, but this will take out a whole lot of other stuff like Amarok.    
Do rpm rebuilddb, and situation doesn't change.    Do rpm -qa --last and find 
that it is indeed there, and was installed during my recent upgrade to 10.2.  
Do find, and it comes up with file not found.  Inspect /lib in the file 
manager and it does indeed seem not to be there.  But using the Mandrake rpm 
wizard, remove, it can see it well enough to offer to remove it.

WXP on the other hand obviously can't see it well enough to install.  What 
next?

Suggestions gratefully received,

Al

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

Alex Tweedly wrote:

> I think this will give me maximum useful names with minimum effort.  But 

> I'm perfectly willing to consider any other suggestions for how to do 
> this better.   Or if you don't think it should do any such auto-name 
> generation, tell me that too.

Your auto-naming rules sound promising. I'm looking forward to testing;
my schedule is pretty tight over the next few days, so it will probably be
Sunday before I can get to it. 

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

Bo Green wrote:

>
> Alex:
> 0.2 is awesome. I have one very small thing related to switching 
> between modes, I'm almost (but not quite) embarrassed to mention it. 

Never be embarrassed to ask for a feature in software :-)

> When I'm in multi-component mode, and I click on empty space in the 
> main window (i.e., deselect all components),  I would like propEd to 
> switch back to single-component mode, and currently it continues to 
> display only the previously selected (multiple) components until I 
> select another single component.
> Like I said, a small thing, but not totally insignificant.

That sounds like a reasonable request - will be in v0.3
BUT - I don't plan to change the current behaviour when deselecting 
multiple components one-by-one by ctl-clicking them.

When you get down to a single component remaining selected, I *could* 
switch to single-mode - but don't.
If you then deselect that last one, I *could* switch to single mode - 
but don't.

If you think it should do those - you need to convince me :-)   If you 
do have good arguments for doing that, it will be fairly easy to 
implement, but I don't want to change without being convinced.

v0.3 will be out tomorrow, if I can get enough testing time in on it. It 
will have
 - revert to single-mode when click in "open space" causes deselection 
of all components
 - bug fix related to pasting while in multi-component mode (workaround 
is to go back to single mode before using "paste" command)
 - new name rules. (this is why it needs lots of testing ....)

I won't be surprised if the new name rules generate some discussion; in 
fact, I'll be glad if they do.
Here's the current plan for the new rules:

when a component is initially created, a name is automatically generated 
for the component. If it's an "add component" command, the name is 
"typename"+integer (e.g. Button1, Button2, ....); if it's a Duplicate or 
Paste command, the name is formed from the existing name+integer (e.g. 
Search1, Search2, ....) In either case, the integer is incremented until 
we find a "free" name.  The name is marked as being "not user specified".

The label (or text) field, if there is one, is then set to be the same 
as the name, and is also marked as "not user specified".

If either one is changed, it is then marked as "user specified" - and 
won't thereafter be modified automatically.
If the *other* one is still "not user specified", it will then be 
derived from the one which has been specified (and would change each 
time the already specified on changes).

Whew - easier with an example.

Create a button
   Button1     Button1     (both auto)
Set the name  to Search
   Search      Search        (label derived from name)
Set the name to Find
  Find        Find              (label still derived from name)
Set the label to "Find it for me"
   Find        Find it for me    (label now user specified)
Set the name to Search
   Search    Find it for me    (so label doesn't change).

Create another Button
    Button1    Button1
Set the label to "find me a hotel"
   findmeahotel     find me a hotel     (name derived from label - note 
spaces are removed to form legal name)
Set the label to Search
   Search1      Search     (name derived from label - integer added to 
avoid existing component name)

etc.

I think this will give me maximum useful names with minimum effort.  But 
I'm perfectly willing to consider any other suggestions for how to do 
this better.   Or if you don't think it should do any such auto-name 
generation, tell me that too.

-- 
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.11.2 - Release Date: 02/05/2005

[Pythoncard-users] Tr : Re: pythoncard applications

[TISCALI <phi...@ti...>]

 =0D
 =0D
-------Message original-------=0D
 =0D
De : Kevin Altis=0D
Date : 05/04/05 20:13:40=0D
A : Tiscali=0D
Sujet : Re: pythoncard applications=0D
 =0D
Nice! Please send an email to the pythoncard-users mailing list so=0D
everyone can see them. I'll probably add some links from the More=0D
Applications web page as well.=0D
 =0D
Thanks,=0D
 =0D
ka=0D
On May 3, 2005, at 12:55 PM, Tiscali wrote:=0D
 =0D
> some  pythoncard applications for my students.=0D
>  =0D
> http://gpib82357a.sourceforge.net/pyDS1267.htm=0D
> http://gpib82357a.sourceforge.net/pyTDS.htm=0D
> http://gpib82357a.sourceforge.net/pyBloadHC11.htm=0D
> http://gpib82357a.sourceforge.net/pyUltraISR.htm=0D
> http://gpib82357a.sourceforge.net/pyRS485.htm=0D
>  =0D
>  =0D
> Thanks a lot for your works.=0D
>  =0D
>  =0D
>  =0D
> Philippe DALET=0D
> Laboratoire STS =E9lectronique=0D
> Lyp champollion=0D
> avenue pezet=0D
> 46100 FIGEAC=0D
>  =0D
> FRANCE=0D
>  =0D
> 0683038232=0D
> phi...@vo... =0D
>  =0D
 =0D
=20

Re: [Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

Alex:
0.2 is awesome. I have one very small thing related to switching between 
modes, I'm almost (but not quite) embarrassed to mention it. When I'm in 
multi-component mode, and I click on empty space in the main window 
(i.e., deselect all components),  I would like propEd to switch back to 
single-component mode, and currently it continues to display only the 
previously selected (multiple) components until I select another single 
component.
Like I said, a small thing, but not totally insignificant.
Thanks a million for this new editor.
Bo


Alex Tweedly wrote:

> Summary: a couple of bug fixes, plus selection by rectangular "region" 
> of the window, and re-layering of multiple components.
>
> This can be found at
> www.tweedly.net/Python/newresourceEditorv0.2.zip
>
> See changes.txt for the changes (enclosed here for convenience)
>
> btw - Next time, I will spell-check the changes.txt file BEFORE 
> releasing it :-)
>
> -- Alex.
>

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.2 - Release Date: 02/05/2005

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

Alex Tweedly <al...@tw...> wrote on 05/03/2005 08:49:07 PM:

> > Distribute operations. 
> 
> This is not working in a predictable way. However, the intent show 
> by the icons is very clear. 
>> Hmmmm ... works exactly as I expect it to, for me. 

Ok, I didn't realize the order in which the components were
selected made a difference. I had expected the order would be 
determined somehow based on geometric reading left to right, 
or somesuch. Now that I understand this, the Distribute Operations
work as I would expect, and do seem more useful.

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.2 - Release Date: 02/05/2005

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

Alex,

I'm really excited about the stuff you've done on the new Resource Editor,
but unfortunately my posting from Sunday went to the wrong address.
It went to:

      pyt...@li... 

Usually when I reply to a posting on the PythonCard users list, I end up
having to copy-paste the correct  <pyt...@li...>
address, because the reply-to is usually the person posting rather than
the list. In this case, I copy/pasted the wrong address. 

I haven't yet tried your latest update, but here is what I posted on 
Sunday:

------------------------------------------


I've only tested the new Property Editor briefly, so far, but it seems 
useful
enough to start using it for some real work (at least under Windows, not 
Mac).
My only worry would be if it could somehow corrupt the resource file, but
that seems unlikely. Am I correct in thinking that you haven't touched 
anything involving the way the Resource Editor saves? 

Caveat about my Mac comments: I'm now running Mac OS 10.4 "Tiger" and that
may have thrown a monkeywrench into wxPython, so others may have better
results using 10.3.x.

On Windows XP, I'm running wxPython 2.5.3 ansi and Python 2.3.5.

Here are my initial impressions...

Alex Tweedly <al...@tw...> wrote on 04/29/2005 07:47:19 PM:

> This version of the resource Editor has the following changes:
> 
> Property editor window display.

I like the new Property Editor. My app has a lot of screens and a lot
of widgets, and this new design will help me quickly edit a lot
of widget properties without having to spend time scrolling through
lists of properties.

The new Property Editor doesn't look good on the Mac, however.
There is a lot of overlapping between widgets. On Windows XP, the only
overlapping widget is the Font button covering up part of the
Font property field. Everything else looks good on Windows XP.

The Nudge buttons don't work on Mac.

> Component naming when created.

This has improved my speed at labeling/naming widgets.
Somehow the old way of getting prompted with a dialog box
always slowed me down, and I'd frequently get the name
and the text backwards. I find the new approach far preferable,
especially in combination with the new Property Editor.


> Multiple components.

Works on Windows, not on Mac (tried various keys such as 
control-click and command-click). 

> Once a set of components have been selected, you can mouse-down
> (i.e. press and hold, no ctl-key) WITHIN one of the selected
> components; this will bring up the enclosing rectangle for the whole
> set, and you can then move them around. 

This works great--very intuitive.

> They can also be moved using the arrow keys; however, this has always
> been a bit flaky - sometimes the key events get captured by something
> else, and used for filed-traversal-tabbing. It may be a bit more flaky
> with the new display panel - see "nudge commands" below for other
> options.

At first, I had no problems nudging multiple components with the 
arrow keys. I was only testing on TextFields and StaticText components.
As soon as I started trying to move groups that included RadioGroups
or Buttons, the arrow keys just stopped working. Nudge continued to work.

> Note that Copy, Cut and Paste *do* work for multiple components. There
> isn't yet a Delete command that works for multiple-component mode, but
> you can simply Cut them in the meantime.

Copy/paste only works once when I tried for a single widget, and then
throws up a message saying the widget already exists. It would be nice
to increment with Copy2, Copy3, etc. If Resource Editor can do that,
it should be able to easily implement this feature request:

Some GUI editors have a shortcut for duplicating a widget: alt-drag
an existing widget, and a new copy can be dragged to any location.
This beats having to choose something from the component menu,
then dragging it from the default spot in the upper left corner.


> Align operations.

THANK YOU! This feature was very much needed. Your design here is very
clear and easy to use, and it appears to work, at least in the
four or five situations I tested.

> Distribute operations.

This is not working in a predictable way. However, the intent show
by the icons is very clear.

> Equalize operations.

Again, very clearn, and it seems to work very well, though I haven't tried
every possible situation.



> 1. Flaky behaviour on re-sizing a component.
> 
> Moving the cursor rapidly back inside a Textfield (or TextArea, or
> ...) while re-sizing it would cause it to change to almost random
> size.

Thank you! I am no longer seeing this problem.


> 2. Flaky "move" - double-click.

So far so, good. This problem seems to have gone away.

> You shouldn't - but might - see a dialog that says
>     "You double-clicked - please don't"
> This means that work-around didn't work - just click OK to the dialog
> and you'll be able to continue.

I haven't seen this...yet.


> 3. Calendar component "hops"
> 
> There is code to ensure that components with a border allow for that
> when calculating moves; without this a click on the component would
> "hop" it by the border width. This hadn't been done for Calendar
> components, and has now.
> 
> [ Mac users - please let me know if I guessed right for the offset 
needed ]

On the Mac, the Calendar component hops three pixels up and three pixels
left. No hopping on Windows.

> 4. Static line and gauges/sliders ignored layout setting.
> 
> The setting for layout (either horizontal / vertical) was being ignored.

Works now. Thanks!



Comments about your To-Do:

> 3. select multiple components by rectangular marquee
> 3a.  lasso ??   rectangular add/remove from existing selection, ....

Lasso seems like overkill. The rectangular marquee is very helpful,
and other GUI builders such as Revolution and FileMaker use
rectangular marquee to select multiple components.


> 6. Temporary hide/show of selected components.
> (Take a look at the property window in the resource editor - it's a
> pain to work on because the single-component mode fields overlap the
> multi-component mode buttons.

This points toward the need to have named groups of components,
as in Runtime Revolution. Groups in Revolution are a powerful and flexible
concept, though sometimes a trifle confusing. I think a "weak" group
concept might just involve a list of lists of component names,
as a property associated with the background. This would allow not only
convenient temporary hiding/showing of widgets within the Resource Editor
but also from within the background script. And of course, attributes
other than visibility could be set as a group, such as color or
font size.

[Pythoncard-users] Updated EXPERIMENTAL resource Editor v0.2

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

Summary: a couple of bug fixes, plus selection by rectangular "region" 
of the window, and re-layering of multiple components.

This can be found at
www.tweedly.net/Python/newresourceEditorv0.2.zip

See changes.txt for the changes (enclosed here for convenience)

btw - Next time, I will spell-check the changes.txt file BEFORE 
releasing it :-)

-- Alex.


bug fixes:

Note that when in multiple-component mode, the component box in the
property window is for display only - you cannot click in that box to
(de)select components. "0.2" - fixed; in 0.1, it did allow clicking in
this box, with varied and interesting results. A related fix involving
selecting first component from this componentList in the
propertyEditor, and additional components by Ctl-clicking also fixed.

 Never save sizing handles to resource file. 

In 0.1, if you selected multiple components, and then saved the
resource file, the sizing handles were saved to the file along with
the user's components. Oops.  Fixed now.



Multiple component selection using rectangular "marquee"

You can select multiple components by enclosing them within a
rectangular "marquee". The basic form involves pressing the mouse
button down NOT within any component, and while holding the button
down, dragging the mouse out to surround some components. These
components will become a new multiple-component selection, replacing
any previous selection.

You can modify this by using modifier keys while doing the rectangle 
selection.

1. No modifier - define a new selection

2. shift-rectangle : add enclosed components to existing selection
   (any enclosed components already selected remain selected)

3. ctl-rectangle : toggle the status of enclosed components (i.e. if
   already selected, remove it, if not already selected, add it)

4. shift-ctl-rectangle : subtract from existing selection


As well as the 4 buttons corresponding to the existing commands, there
are two additional ones which only take effect when there are multiple
components selected.  First, a description of what it means to
re-layer multiple components.

All the selected components are put, in the order they were selected,
together in the final order list. The base component (first one
selected) is then moved back or forward according to the given
command, with all other selected components following it.

In some cases, you will want to collect the selected components
together in the component ordering, but without changing the base
component's place in the order. The first new button "gather together"
does this.

The second new button takes a set of components and re-layers them
according to their position, in approximate "reading" order; top-left
to bottom right, in rows. Just like "Gather together", this re-ordered
set of components finish up adjacent in the layer ordering, following
the place in order of the base component.

Beware that the reading order works well if the components are
non-overlapping, but can be hard to predict when there are multiple
overlapping components selected (e.g. if you were to edit the resource
editor's own resource file, where the "single-mode" and
"multiple-mode" controls occupy the same area, and simply select all
of them, you will get a different result from what you expect or
want. This is a result of the comparison function used to sort into
"reading order" - if one component is entirely below another, the
order is clear; otherwise they are assumed to be on the same row, and
sorted according to X coord.

NB There is a definite lack of visual feedback from these
commands. I'm trying to find a good way to give this feedback - any
suggestions gratefully received.



-- 
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.11.2 - Release Date: 02/05/2005

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

Bo Green wrote:

>
> In Pythoncard/Windows, there is some strange behaviour related to 
> multiple component selection. Specifically, selecting in the property 
> editor doesn't mesh with selecting in the resource display window. If 
> you select a component in propEd, then try to <ctrl>-select a 
> component in the resEditor, behaviour is unpredictable. Various 
> combinations of alternating selecting in the two different windows 
> create more and more unexpected and sometimes buggy behaviours. At one 
> point I had two component layouts over top of each other in propEd, 
> just by selecting back and forth. These two should probably work 
> together, or at least they should transition smoothly between the two 
> modes.
> Very nice work, though. Lots of new and great functionality, and 
> easier to work with.
> Great stuff!

Thanks Bo. Sorry about the problems with the propEditor vs main window; 
I'd found one of those myself, but hadn't seen the problem with the 
"select in propEd then ctl-click others" sequence.  I have a fix for 
both those now - will test some more tonight, and tidy up other things, 
then release 0.2 later tonight.

The reason there isn't a smoother transition is that I am wary of 
showing the componentList as a multi-choice list box - it seems to me 
too easy to mislead the user. With the current single-component mode, we 
always scroll the list box so the selected item is in view; obviously 
can't guarantee that when there are multiple components chosen, so that 
display would be potentially confusing.. So I'm trying to think of the 
best way to represent this .... open to suggestions.

For now, I'll stick to a list box showing only selected components when 
in multi-component mode. While this display is visible, the box will not 
act to select a component. When a single component is selected (even if 
it was in the comp box), you can ctl-click additional components and the 
display will switch accordingly.

Version 0.2 will also have rectangular marquee selection mode, and 
re-layering of multiple component selection - details in the 
announcement which should be tonight.

-- 
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.11.2 - Release Date: 02/05/2005

[Pythoncard-users] App with child windows successfully compiled !!!... finally...

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

Hi there,

As I have ported before, I havent been able to successfully compile a pyhton 
card app with child windows, but I have now done so....I was so blind.

The change I had to do was the following:

def on_initialize(self, event):
        self.ComplejosWindow = model.childWindow(self, 
complejos.Complejos,os.path.join(self.application.applicationDirectory, 
model.internationalResourceName('complejos')))


I have to put the path manually as I had to do before with the Python Card 
Prototype version.

By the way I compiled my app with the setup.py script that comes with 
Pygame.

Is this a bug?? or is just me not doing this well??

Regards,

Brian

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

In Pythoncard/Windows, there is some strange behaviour related to 
multiple component selection. Specifically, selecting in the property 
editor doesn't mesh with selecting in the resource display window. If 
you select a component in propEd, then try to <ctrl>-select a component 
in the resEditor, behaviour is unpredictable. Various combinations of 
alternating selecting in the two different windows create more and more 
unexpected and sometimes buggy behaviours. At one point I had two 
component layouts over top of each other in propEd, just by selecting 
back and forth. These two should probably work together, or at least 
they should transition smoothly between the two modes.
Very nice work, though. Lots of new and great functionality, and easier 
to work with.
Great stuff!
Bo


Alex Tweedly wrote:

>
> I have a new version of the resourceEditor available for testing and 
> comment.
>
> It's a fairly substantial change, so should be treated with some 
> caution (i.e. save your work often, keep copies, etc.)
> However, I don't know of any bugs in it that aren't also in the 
> original 0.8.1, and haven't lost any data because of any problems with 
> it.
>
> Because it is such  a large change, I haven't yet checked it into CVS 
> - it has to be downloaded from my site, at
> http://www.tweedly.net/Python/newresourceEditorv0.1.zip
>
>
> This is a ZIP file - extract the files and you should have a single 
> directory which is a self-contained directory called newresourceEditor 
> 0.1
> (sorry if that's confusing - the zip file has (no space)v0.1, but the 
> extracted directory has a space, and just 0.1)
>
> In it, you will find a "changes.txt" with a description of the 
> significant changes. A copy is included below for convenience.
>
> Please give me any feedback - problems, comments, suggestions, etc. 
> either on this list, or if you prefer directly to al...@tw...
>
> Thanks,
> Alex.
>
>
>
>
> This version of the resource Editor has the following changes:
>
> Property editor window display.
>
> The propertyEditor Window has been extensively changed. Previously it
> was a small window, showing a list of components and a list of
> attributes applicable to the currently selected component. The
> currently selected attribute was displayed (and editable) below this.
>
> The new version uses a much larger window, again showing a list of
> components. For the currently selected component, ALL attributes are
> shown, in a large area to the right. Any of the attributes can be
> edited directly, and the change will take effect as soon as the focus
> leaves the field being edited (the Update button is still also
> available).
>
> Component naming when created.
>
> In the existing resourceEditor, every time you create a component
> (either from the Component menu, or by Duplicate, or Paste), you are
> presented with a dialog box to specify the name (and label / text for
> those components that have them).
>
> I have taken that out (at least for now) - so the component is
> immediately created with the default name/label. I've found this
> better and faster for my testing - but I'm not sure if it would be the
> same when using the resourceEditor "for real", rather than for
> testing.
>
> If you want to revert to the earlier behaviour, find the line
>       result = fakeEmptyDialog(desc, offsets, promptString)
> around line 1334. Comment it out, and reinstate the previous line.
>
> The medium-term intent is to extend the "clever default"s for deriving
> labels from names, or names from labels - so that you can achieve what
> you need with the minimum amount of typing possible. Stay tuned ....
>
>
> Multiple components.
>
> You can select multiple components and perform various operations on
> them. Clicking on a component selects it (just as before). Ctrl-click
> will add a component to the selected set, or remove it if it is
> already in there.  The property window can be watched to let you know
> if you are in "single-component mode" or "multiple-component mode".
>
> If you select a number of components, and then deselect all but one of
> them, you remain in multi-component mode. (NB this feels better to me
> - but is certainly a candidate for later change if we think we
> should.) This does save a "flash" back into single mode display, when
> de-selecting and re-selecting most of a group.
>
> If there is NO component selected, and you select the first one by
> Ctrl-Click, then you enter multi-component mode immediately. The
> specific reason I did this no longer applies - but I'd got used to it
> by then. Again, this does save a certain amount of "flashing" between
> the two modes (and their display).
>
> Note that when in multiple-component mode, the component box in the
> property window is for display only - you cannot click in that box to
> (de)select components. It shows only those components which are in the
> selected set. This is mostly because Pythoncard doesn't have a
> multi-choice list box, but also partly because using a multi-choice list
> would make it harder to see at a glance which are selected.
>
> Once a set of components have been selected, you can mouse-down
> (i.e. press and hold, no ctl-key) WITHIN one of the selected
> components; this will bring up the enclosing rectangle for the whole
> set, and you can then move them around.
> They can also be moved using the arrow keys; however, this has always
> been a bit flaky - sometimes the key events get captured by something
> else, and used for filed-traversal-tabbing. It may be a bit more flaky
> with the new display panel - see "nudge commands" below for other
> options.
>
> Note that Copy, Cut and Paste *do* work for multiple components. There
> isn't yet a Delete command that works for multiple-component mode, but
> you can simply Cut them in the meantime.
>
> Buttons for layer changes.
>
> A component can be moved Back/Forward using the main menu Options /
> Send to Back, etc., or the shortcut keys Ctrl-1, Ctrl-2, etc.
> However, these keys don't work when focus is in the property
> window. Buttons have been added (below the component list box) to
> allow re-layering of a component.
>
> As well as the 4 buttons corresponding to the existing commands, there
> is an additional one which WILL (but doesn't yet) take a set of
> components and re-layer them according the their position, in
> approximate "reading" order; top-left to bottom right, in rows. This
> command will probably go on the menu eventually.  NB - none of these
> buttons currently works in multi-component mode, but they will.
>
> Arrow keys & Buttons to 'nudge' components.
>
> The arrow keys can be used to reposition a component, as
> before. However, they now have the added feature that
>
> - Ctrl-arrow will move in that direction by the currently specified
>    grid step, and align to the grid even if the "Align to grid"
>    option is not enabled.
>
> - Shift-arrow will move by the grid step distance, but without
>   rounding to the grid
>
> - Shift-Ctrl-arrow will move by the square of the grid size (and
>   round to the basic grid). Good accelerator for big moves - beware
>   you can jump right off the window if you're not careful.
>
> As mentioned above, occasionally (or perhaps often), one or more of
> the placed components gets in the way of key events ['buttons start
> tabbing, calendar starts moving the selected date, etc.]. Therefore
> there are now button on the property window to move the selected
> component or components. these are in the box labeled "NUDGE" at the
> bottom-left.
>
> Clicking on each arrow button here moves the component in the obvious
> direction. The number inside these buttons controls how far the
> components are moved; 1 moves by 1 pixel, 2 by a grid-step, 4 by the
> square of a grid-step. (3 is the same as 2 for now). These moves
> always honour the Align to Grid setting.  [NB - this may change -
> either to be simply pixel distance, or a drop-down choice for the 1 vs
> grid vs grid*grid to allow all the choices available by the arrow
> keys.]
>
> Various operations are enabled when in multi-component mode. Remember 
> that the *order* the components were selected (visible by order they 
> are listed in the component box) is significant for many of these.
>
> Align operations.
>
> The box labeled "ALIGN" contains six buttons, which align the
> components up with the first selected on. They can be aligned by left
> side, right side, top, bottom (four buttons grouped to the left). Or
> the centres of the components can be aligned, either vertically or
> horizontally (i.e. into a column or into a row).
>
>
> Distribute operations.
>
> The box labeled "DISTRIBUTE" has four buttons; two on the left for
> distributing horizontally and two on the right for vertical
> distribution.
>
> The top button on each side distributes the components "edge-to-edge";
> i.e. the first component does not move, the second one is placed to
> the left (or below) such that the edges line up, then the third, etc.
>
> The lower button distributes them with even-sized gaps from
> "first-to-last"; i.e. the first and last components do not move, the
> others are distributed between them such that the gaps between the
> edges are equal sized (or as close as possible). Note that if the
> components add up to larger than the total distance between first and
> last, then they will overlap (i.e. the 'gap' can be negative), but it
> will still be evenly shared between them.
>
> Equalize operations.
>
> The box labeled "EQUALIZE" has three buttons, which set the width
> (the height, or both) of all other components selected to match the
> first component.
>
> Other changes and bug-fixes included.
>
> 1. Flaky behaviour on re-sizing a component.
>
> Moving the cursor rapidly back inside a Textfield (or TextArea, or
> ...) while re-sizing it would cause it to change to almost random
> size.
>
> 2. Flaky "move" - double-click.
>
> Double-clicking within a Button component prior to moving it would
> cause the mouse to become "locked" into that component. So you could
> click outside the component, and it would nevertheless move with the
> mouse; also you were unable to select another component, or the
> menu. Could be solved by clicking in another window (though not
> another window of this program), and then clicking back in this
> window.
>
> I've got a "fix" for this in place - though I don't understand why it
> works. (I discovered that all subsequent mouse events were reporting
> the "getEventObject()" wrongly, and having a handler for doubleClick -
> even one that does nothing - seems to solve it.
>
> You shouldn't - but might - see a dialog that says
>    "You double-clicked - please don't"
> This means that work-around didn't work - just click OK to the dialog
> and you'll be able to continue.
>
> 3. Calendar component "hops"
>
> There is code to ensure that components with a border allow for that
> when calculating moves; without this a click on the component would
> "hop" it by the border width. This hadn't been done for Calendar
> components, and has now.
>
> [ Mac users - please let me know if I guessed right for the offset 
> needed ]
>
> 4. Static line and gauges/sliders ignored layout setting.
>
> The setting for layout (either horizontal / vertical) was being ignored.
>
>
>
> Clearly still missing .....
> 1. re-layer for multiple components
> 2. delete multiple components (but Cut is done already)
> 3. select multiple components by rectangular marquee
> 3a.  lasso ??   rectangular add/remove from existing selection, ....
> 4. select multiple components by regular expression
>      (useful if you use systematic names, and want to pick them all ....)
> 5. undo (at least for the multiple-component operations).
> Do be careful; you can mess up really fast with multiple component 
> operations !
> 6. Temporary hide/show of selected components.
> (Take a look at the property window in the resource editor - it's a
> pain to work on because the single-component mode fields overlap the
> multi-component mode buttons.
>
>

Re: [Pythoncard-users] PythonCard on LiveCD?

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

Mark Carter wrote:
> Hello.
> 
> Does anyone know if there are currently any live CD distros that include 
>  all the necessary components (Python, wxPython, PythonCard) to do 
> PythonCard development using just a live CD and a USB flash drive for 
> storage?
> 
> Mark
> 
> 

As far as I can tell, no. I've just tried the two Live CDs [1] I've got 
in my drawer and neither of them ships with wxPython and therefore won't 
run PythonCard. I suspect that the size of wxPython (and wxWidgets) 
doesn't lend itself to packaging on a general purpose Live CD.

If you're feeling brave then it may be possible to build your own Live 
CD using morphix [2]. The web site says that they offer a reasonably 
simple way of customising the contents of a Live CD from the Debian 
package repository (which has all of the necessary bits and pieces to 
run PythonCard).

[1] http://www.ubuntulinux.org/wiki/LiveCD
     http://www.knoppix.net/
[2] http://www.morphix.org/

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

Re: [Pythoncard-users] simple layout managers

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

Michael Sorich wrote:

>I have written some code to reposition/resize
>components with changes in Background (wxFrame) size.
>There are 3 options. The only requirement for each is
>that the anchors property is set for each component –
>these indicate how the component should move/size with
>respect to its environment. I have attached a simple
>example GUI that can be run to demonstrate the 3
>layout managers. The layout manager and anchors for
>each component can be changed in
>MyBackground.on_initialize.
>
>1) Simple anchors
>
too simple ...

>2) Relative anchors
>
still too simple ....

>3) Advanced anchors 
>
getting interesting ...

>I would be interested in comments and examples where
>these layout managers do and do not work well.
>  
>
Only talking about Advanced anchors - the others really do hit their 
limits very quickly.

1. In the example you sent out, try to add a "Button 3" mid-way between 
B1 and B2.
I'd like B3 to remain mid-way between them as the window width is varied.

Can't do that currently. Would be easy enough to add a "fixed-size" 
flag, so that it could be anchored to L and R, position calculated as it 
is currently - but then adjusted to keep the size unchanged. (i.e. it 
would find the right place to grow into - but not grow, leaving space on 
each side).

2. (This may really be 1a :-)
In the devx article you mentioned, they had a static text (label) beside 
a text area; as the text area grows, the label should "float" to remain 
half-way up the side.

3. Mix of expanding and non-expanding components.

label 1: [.Txtfld 1...] label 2: [.Txtfld 2...] label 3: [.......tf3.]

where you want the labels to stay fixed-width, and the fields to grow to 
fill the available width.
(I don't think there's a way to do just that).


4. Interference.
Extend the last case ...

[button 1 across here about this long]
label 1: [.Txtfld 1...] label 2: [.Txtfld 2...] label 3: [.......tf3.]

where you want the labels to stay fixed-width, and the fields to grow to 
fill the available width.
The edges of button1 become partition edges - and so change the growth 
patterns of the textfields 1 and 2.
If you put the button way up at the top of the background, and the 
fields way at the bottom - with a lot of other stuff in between, it 
would be very hard to understand what's going on ...

-- Alex.

-- 
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.4 - Release Date: 27/04/2005

Re: [Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

Wow! That's a lot of new features and bugfixes in a short time.  I will 
try out the new Resource Editor when I get into work today.


pyt...@li... wrote on 04/29/2005 07:47:19 
PM:

> 
> I have a new version of the resourceEditor available for testing and 
> comment.
> 
> It's a fairly substantial change, so should be treated with some caution 

> (i.e. save your work often, keep copies, etc.)
> However, I don't know of any bugs in it that aren't also in the original 

> 0.8.1, and haven't lost any data because of any problems with it.
> 
> Because it is such  a large change, I haven't yet checked it into CVS - 
> it has to be downloaded from my site, at
> http://www.tweedly.net/Python/newresourceEditorv0.1.zip
> 
> 
> This is a ZIP file - extract the files and you should have a single 
> directory which is a self-contained directory called newresourceEditor 
0.1
> (sorry if that's confusing - the zip file has (no space)v0.1, but the 
> extracted directory has a space, and just 0.1)
> 
> In it, you will find a "changes.txt" with a description of the 
> significant changes. A copy is included below for convenience.
> 
> Please give me any feedback - problems, comments, suggestions, etc. 
> either on this list, or if you prefer directly to al...@tw...
> 
> Thanks,
> Alex.
> 
> 
> 
> 
> This version of the resource Editor has the following changes:
> 
> Property editor window display.
> 
> The propertyEditor Window has been extensively changed. Previously it
> was a small window, showing a list of components and a list of
> attributes applicable to the currently selected component. The
> currently selected attribute was displayed (and editable) below this.
> 
> The new version uses a much larger window, again showing a list of
> components. For the currently selected component, ALL attributes are
> shown, in a large area to the right. Any of the attributes can be
> edited directly, and the change will take effect as soon as the focus
> leaves the field being edited (the Update button is still also
> available).
> 
> Component naming when created.
> 
> In the existing resourceEditor, every time you create a component
> (either from the Component menu, or by Duplicate, or Paste), you are
> presented with a dialog box to specify the name (and label / text for
> those components that have them).
> 
> I have taken that out (at least for now) - so the component is
> immediately created with the default name/label. I've found this
> better and faster for my testing - but I'm not sure if it would be the
> same when using the resourceEditor "for real", rather than for
> testing.
> 
> If you want to revert to the earlier behaviour, find the line
>        result = fakeEmptyDialog(desc, offsets, promptString)
> around line 1334. Comment it out, and reinstate the previous line.
> 
> The medium-term intent is to extend the "clever default"s for deriving
> labels from names, or names from labels - so that you can achieve what
> you need with the minimum amount of typing possible. Stay tuned ....
> 
> 
> Multiple components.
> 
> You can select multiple components and perform various operations on
> them. Clicking on a component selects it (just as before). Ctrl-click
> will add a component to the selected set, or remove it if it is
> already in there.  The property window can be watched to let you know
> if you are in "single-component mode" or "multiple-component mode".
> 
> If you select a number of components, and then deselect all but one of
> them, you remain in multi-component mode. (NB this feels better to me
> - but is certainly a candidate for later change if we think we
> should.) This does save a "flash" back into single mode display, when
> de-selecting and re-selecting most of a group.
> 
> If there is NO component selected, and you select the first one by
> Ctrl-Click, then you enter multi-component mode immediately. The
> specific reason I did this no longer applies - but I'd got used to it
> by then. Again, this does save a certain amount of "flashing" between
> the two modes (and their display).
> 
> Note that when in multiple-component mode, the component box in the
> property window is for display only - you cannot click in that box to
> (de)select components. It shows only those components which are in the
> selected set. This is mostly because Pythoncard doesn't have a
> multi-choice list box, but also partly because using a multi-choice list
> would make it harder to see at a glance which are selected.
> 
> Once a set of components have been selected, you can mouse-down
> (i.e. press and hold, no ctl-key) WITHIN one of the selected
> components; this will bring up the enclosing rectangle for the whole
> set, and you can then move them around. 
> 
> They can also be moved using the arrow keys; however, this has always
> been a bit flaky - sometimes the key events get captured by something
> else, and used for filed-traversal-tabbing. It may be a bit more flaky
> with the new display panel - see "nudge commands" below for other
> options.
> 
> Note that Copy, Cut and Paste *do* work for multiple components. There
> isn't yet a Delete command that works for multiple-component mode, but
> you can simply Cut them in the meantime.
> 
> Buttons for layer changes.
> 
> A component can be moved Back/Forward using the main menu Options /
> Send to Back, etc., or the shortcut keys Ctrl-1, Ctrl-2, etc.
> However, these keys don't work when focus is in the property
> window. Buttons have been added (below the component list box) to
> allow re-layering of a component.
> 
> As well as the 4 buttons corresponding to the existing commands, there
> is an additional one which WILL (but doesn't yet) take a set of
> components and re-layer them according the their position, in
> approximate "reading" order; top-left to bottom right, in rows. This
> command will probably go on the menu eventually.  NB - none of these
> buttons currently works in multi-component mode, but they will.
> 
> Arrow keys & Buttons to 'nudge' components.
> 
> The arrow keys can be used to reposition a component, as
> before. However, they now have the added feature that
> 
>  - Ctrl-arrow will move in that direction by the currently specified
>     grid step, and align to the grid even if the "Align to grid"
>     option is not enabled.
> 
>  - Shift-arrow will move by the grid step distance, but without
>    rounding to the grid
> 
>  - Shift-Ctrl-arrow will move by the square of the grid size (and
>    round to the basic grid). Good accelerator for big moves - beware
>    you can jump right off the window if you're not careful.
> 
> As mentioned above, occasionally (or perhaps often), one or more of
> the placed components gets in the way of key events ['buttons start
> tabbing, calendar starts moving the selected date, etc.]. Therefore
> there are now button on the property window to move the selected
> component or components. these are in the box labeled "NUDGE" at the
> bottom-left.
> 
> Clicking on each arrow button here moves the component in the obvious
> direction. The number inside these buttons controls how far the
> components are moved; 1 moves by 1 pixel, 2 by a grid-step, 4 by the
> square of a grid-step. (3 is the same as 2 for now). These moves
> always honour the Align to Grid setting.  [NB - this may change -
> either to be simply pixel distance, or a drop-down choice for the 1 vs
> grid vs grid*grid to allow all the choices available by the arrow
> keys.]
> 
> Various operations are enabled when in multi-component mode. Remember 
> that the *order* the components were selected (visible by order they are 

> listed in the component box) is significant for many of these.
> 
> Align operations.
> 
> The box labeled "ALIGN" contains six buttons, which align the
> components up with the first selected on. They can be aligned by left
> side, right side, top, bottom (four buttons grouped to the left). Or
> the centres of the components can be aligned, either vertically or
> horizontally (i.e. into a column or into a row).
> 
> 
> Distribute operations.
> 
> The box labeled "DISTRIBUTE" has four buttons; two on the left for
> distributing horizontally and two on the right for vertical
> distribution.
> 
> The top button on each side distributes the components "edge-to-edge";
> i.e. the first component does not move, the second one is placed to
> the left (or below) such that the edges line up, then the third, etc.
> 
> The lower button distributes them with even-sized gaps from
> "first-to-last"; i.e. the first and last components do not move, the
> others are distributed between them such that the gaps between the
> edges are equal sized (or as close as possible). Note that if the
> components add up to larger than the total distance between first and
> last, then they will overlap (i.e. the 'gap' can be negative), but it
> will still be evenly shared between them.
> 
> Equalize operations.
> 
> The box labeled "EQUALIZE" has three buttons, which set the width
> (the height, or both) of all other components selected to match the
> first component.
> 
> Other changes and bug-fixes included.
> 
> 1. Flaky behaviour on re-sizing a component.
> 
> Moving the cursor rapidly back inside a Textfield (or TextArea, or
> ...) while re-sizing it would cause it to change to almost random
> size.
> 
> 2. Flaky "move" - double-click.
> 
> Double-clicking within a Button component prior to moving it would
> cause the mouse to become "locked" into that component. So you could
> click outside the component, and it would nevertheless move with the
> mouse; also you were unable to select another component, or the
> menu. Could be solved by clicking in another window (though not
> another window of this program), and then clicking back in this
> window.
> 
> I've got a "fix" for this in place - though I don't understand why it
> works. (I discovered that all subsequent mouse events were reporting
> the "getEventObject()" wrongly, and having a handler for doubleClick -
> even one that does nothing - seems to solve it.
> 
> You shouldn't - but might - see a dialog that says
>     "You double-clicked - please don't"
> This means that work-around didn't work - just click OK to the dialog
> and you'll be able to continue.
> 
> 3. Calendar component "hops"
> 
> There is code to ensure that components with a border allow for that
> when calculating moves; without this a click on the component would
> "hop" it by the border width. This hadn't been done for Calendar
> components, and has now.
> 
> [ Mac users - please let me know if I guessed right for the offset 
needed ]
> 
> 4. Static line and gauges/sliders ignored layout setting.
> 
> The setting for layout (either horizontal / vertical) was being ignored.
> 
> 
> 
> Clearly still missing .....
> 1. re-layer for multiple components
> 2. delete multiple components (but Cut is done already)
> 3. select multiple components by rectangular marquee
> 3a.  lasso ??   rectangular add/remove from existing selection, ....
> 4. select multiple components by regular expression
>       (useful if you use systematic names, and want to pick them all 
....)
> 5. undo (at least for the multiple-component operations).
> Do be careful; you can mess up really fast with multiple component 
> operations !
> 6. Temporary hide/show of selected components.
> (Take a look at the property window in the resource editor - it's a
> pain to work on because the single-component mode fields overlap the
> multi-component mode buttons.
> 
> 
> -- 
> 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.4 - Release Date: 27/04/2005
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 
4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users

[Pythoncard-users] PythonCard on LiveCD?

[Mark C. <ma...@ma...>]

Hello.

Does anyone know if there are currently any live CD distros that include 
  all the necessary components (Python, wxPython, PythonCard) to do 
PythonCard development using just a live CD and a USB flash drive for 
storage?

Mark

[Pythoncard-users] EXPERIMENTAL new version of the resource Editor for adventurous testers.

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

I have a new version of the resourceEditor available for testing and 
comment.

It's a fairly substantial change, so should be treated with some caution 
(i.e. save your work often, keep copies, etc.)
However, I don't know of any bugs in it that aren't also in the original 
0.8.1, and haven't lost any data because of any problems with it.

Because it is such  a large change, I haven't yet checked it into CVS - 
it has to be downloaded from my site, at
http://www.tweedly.net/Python/newresourceEditorv0.1.zip


This is a ZIP file - extract the files and you should have a single 
directory which is a self-contained directory called newresourceEditor 0.1
(sorry if that's confusing - the zip file has (no space)v0.1, but the 
extracted directory has a space, and just 0.1)

In it, you will find a "changes.txt" with a description of the 
significant changes. A copy is included below for convenience.

Please give me any feedback - problems, comments, suggestions, etc. 
either on this list, or if you prefer directly to al...@tw...

Thanks,
Alex.




This version of the resource Editor has the following changes:

Property editor window display.

The propertyEditor Window has been extensively changed. Previously it
was a small window, showing a list of components and a list of
attributes applicable to the currently selected component. The
currently selected attribute was displayed (and editable) below this.

The new version uses a much larger window, again showing a list of
components. For the currently selected component, ALL attributes are
shown, in a large area to the right. Any of the attributes can be
edited directly, and the change will take effect as soon as the focus
leaves the field being edited (the Update button is still also
available).

Component naming when created.

In the existing resourceEditor, every time you create a component
(either from the Component menu, or by Duplicate, or Paste), you are
presented with a dialog box to specify the name (and label / text for
those components that have them).

I have taken that out (at least for now) - so the component is
immediately created with the default name/label. I've found this
better and faster for my testing - but I'm not sure if it would be the
same when using the resourceEditor "for real", rather than for
testing.

If you want to revert to the earlier behaviour, find the line
       result = fakeEmptyDialog(desc, offsets, promptString)
around line 1334. Comment it out, and reinstate the previous line.

The medium-term intent is to extend the "clever default"s for deriving
labels from names, or names from labels - so that you can achieve what
you need with the minimum amount of typing possible. Stay tuned ....


Multiple components.

You can select multiple components and perform various operations on
them. Clicking on a component selects it (just as before). Ctrl-click
will add a component to the selected set, or remove it if it is
already in there.  The property window can be watched to let you know
if you are in "single-component mode" or "multiple-component mode".

If you select a number of components, and then deselect all but one of
them, you remain in multi-component mode. (NB this feels better to me
- but is certainly a candidate for later change if we think we
should.) This does save a "flash" back into single mode display, when
de-selecting and re-selecting most of a group.

If there is NO component selected, and you select the first one by
Ctrl-Click, then you enter multi-component mode immediately. The
specific reason I did this no longer applies - but I'd got used to it
by then. Again, this does save a certain amount of "flashing" between
the two modes (and their display).

Note that when in multiple-component mode, the component box in the
property window is for display only - you cannot click in that box to
(de)select components. It shows only those components which are in the
selected set. This is mostly because Pythoncard doesn't have a
multi-choice list box, but also partly because using a multi-choice list
would make it harder to see at a glance which are selected.

Once a set of components have been selected, you can mouse-down
(i.e. press and hold, no ctl-key) WITHIN one of the selected
components; this will bring up the enclosing rectangle for the whole
set, and you can then move them around. 

They can also be moved using the arrow keys; however, this has always
been a bit flaky - sometimes the key events get captured by something
else, and used for filed-traversal-tabbing. It may be a bit more flaky
with the new display panel - see "nudge commands" below for other
options.

Note that Copy, Cut and Paste *do* work for multiple components. There
isn't yet a Delete command that works for multiple-component mode, but
you can simply Cut them in the meantime.

Buttons for layer changes.

A component can be moved Back/Forward using the main menu Options /
Send to Back, etc., or the shortcut keys Ctrl-1, Ctrl-2, etc.
However, these keys don't work when focus is in the property
window. Buttons have been added (below the component list box) to
allow re-layering of a component.

As well as the 4 buttons corresponding to the existing commands, there
is an additional one which WILL (but doesn't yet) take a set of
components and re-layer them according the their position, in
approximate "reading" order; top-left to bottom right, in rows. This
command will probably go on the menu eventually.  NB - none of these
buttons currently works in multi-component mode, but they will.

Arrow keys & Buttons to 'nudge' components.

The arrow keys can be used to reposition a component, as
before. However, they now have the added feature that

 - Ctrl-arrow will move in that direction by the currently specified
    grid step, and align to the grid even if the "Align to grid"
    option is not enabled.

 - Shift-arrow will move by the grid step distance, but without
   rounding to the grid

 - Shift-Ctrl-arrow will move by the square of the grid size (and
   round to the basic grid). Good accelerator for big moves - beware
   you can jump right off the window if you're not careful.

As mentioned above, occasionally (or perhaps often), one or more of
the placed components gets in the way of key events ['buttons start
tabbing, calendar starts moving the selected date, etc.]. Therefore
there are now button on the property window to move the selected
component or components. these are in the box labeled "NUDGE" at the
bottom-left.

Clicking on each arrow button here moves the component in the obvious
direction. The number inside these buttons controls how far the
components are moved; 1 moves by 1 pixel, 2 by a grid-step, 4 by the
square of a grid-step. (3 is the same as 2 for now). These moves
always honour the Align to Grid setting.  [NB - this may change -
either to be simply pixel distance, or a drop-down choice for the 1 vs
grid vs grid*grid to allow all the choices available by the arrow
keys.]

Various operations are enabled when in multi-component mode. Remember 
that the *order* the components were selected (visible by order they are 
listed in the component box) is significant for many of these.

Align operations.

The box labeled "ALIGN" contains six buttons, which align the
components up with the first selected on. They can be aligned by left
side, right side, top, bottom (four buttons grouped to the left). Or
the centres of the components can be aligned, either vertically or
horizontally (i.e. into a column or into a row).


Distribute operations.

The box labeled "DISTRIBUTE" has four buttons; two on the left for
distributing horizontally and two on the right for vertical
distribution.

The top button on each side distributes the components "edge-to-edge";
i.e. the first component does not move, the second one is placed to
the left (or below) such that the edges line up, then the third, etc.

The lower button distributes them with even-sized gaps from
"first-to-last"; i.e. the first and last components do not move, the
others are distributed between them such that the gaps between the
edges are equal sized (or as close as possible). Note that if the
components add up to larger than the total distance between first and
last, then they will overlap (i.e. the 'gap' can be negative), but it
will still be evenly shared between them.

Equalize operations.

The box labeled "EQUALIZE" has three buttons, which set the width
(the height, or both) of all other components selected to match the
first component.

Other changes and bug-fixes included.

1. Flaky behaviour on re-sizing a component.

Moving the cursor rapidly back inside a Textfield (or TextArea, or
...) while re-sizing it would cause it to change to almost random
size.

2. Flaky "move" - double-click.

Double-clicking within a Button component prior to moving it would
cause the mouse to become "locked" into that component. So you could
click outside the component, and it would nevertheless move with the
mouse; also you were unable to select another component, or the
menu. Could be solved by clicking in another window (though not
another window of this program), and then clicking back in this
window.

I've got a "fix" for this in place - though I don't understand why it
works. (I discovered that all subsequent mouse events were reporting
the "getEventObject()" wrongly, and having a handler for doubleClick -
even one that does nothing - seems to solve it.

You shouldn't - but might - see a dialog that says
    "You double-clicked - please don't"
This means that work-around didn't work - just click OK to the dialog
and you'll be able to continue.

3. Calendar component "hops"

There is code to ensure that components with a border allow for that
when calculating moves; without this a click on the component would
"hop" it by the border width. This hadn't been done for Calendar
components, and has now.

[ Mac users - please let me know if I guessed right for the offset needed ]

4. Static line and gauges/sliders ignored layout setting.

The setting for layout (either horizontal / vertical) was being ignored.



Clearly still missing .....
1. re-layer for multiple components
2. delete multiple components (but Cut is done already)
3. select multiple components by rectangular marquee
3a.  lasso ??   rectangular add/remove from existing selection, ....
4. select multiple components by regular expression
      (useful if you use systematic names, and want to pick them all ....)
5. undo (at least for the multiple-component operations).
Do be careful; you can mess up really fast with multiple component 
operations !
6. Temporary hide/show of selected components.
(Take a look at the property window in the resource editor - it's a
pain to work on because the single-component mode fields overlap the
multi-component mode buttons.


-- 
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.4 - Release Date: 27/04/2005

Re: [Pythoncard-users] iterating over components

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

Michael Sorich wrote:
> 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
> 

Michael,

You are correct. Because the components are an instance of WidgetDict 
from model.py and this inherits from UserDict.UserDict there is no 
__iter__ method. I'd say that the standard way of iterating over your 
components would be;

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

To make the WidgetDict more like a standard dictionary the __iter__ 
method should return the key values and maybe we should look at 
implementing this. Does anyone have strong opinions either way?

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

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

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

Phil Edwards wrote:
> 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...

I've just tried wxPython 2.6, and it looks like that's corrected 

-Steve

[Pythoncard-users] simple layout managers

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

I have written some code to reposition/resize
components with changes in Background (wxFrame) size.
There are 3 options. The only requirement for each is
that the anchors property is set for each component –
these indicate how the component should move/size with
respect to its environment. I have attached a simple
example GUI that can be run to demonstrate the 3
layout managers. The layout manager and anchors for
each component can be changed in
MyBackground.on_initialize.

1) Simple anchors are used in Delphi and .Net Forms.
See links below for description of this
http://euler.aero.iitb.ac.in/docs/Programming/wxPython-2.5.2.8/docs/api/wx.lib.anchors.LayoutAnchors-class.html
http://www.devx.com/dotnet/Article/6964/0/page/3
This layout manager does not work well if there is
more than one component to be resized in each
direction. Thus the example attached is not a good
example for this layout manager. By limiting the
number of components that resize, this method will
work Eg set tree anchors to ‘TRB’ (Top-Right-Bottom ->
only height change), and TextArea anchors to ‘LT’
(Left-Top -> no resizing).

2) Relative anchors are very similar to simple
anchors. However, components are constrained to be a
percentage distance to the container’s edge (relative
to container’s width/height). Ie instead of setting a
distance of 10 pixels, it is set to 10% (for a
container of width 100 pixels). This layout manager is
able to able to deal with multiple resizable
components. However, the distances between all
components changes as the window resizes. If the
resizable components do not take up the majority of
the window space, the increased spacing between
components as the window grows may look strange.

3) Advanced anchors allow for multiple resizable
components and absolute spacing by dividing the window
into a grid (based on position/size of all resizable
components) and the components are anchored relative
to the closest grid line in each direction. The grid
resizes with the window and the components are resized
to maintain their distance constraints to the grid
lines.  Each column/row in the grid has a different
weight which determines the extent that the row/col
size changes with container size. The col/row weights
are automatically calculated (there are multiple
options for how this can be automatically calculated
and obviously the option to manually set the weights).
The Background has a method showPartitions(True) that
can be used to show the grid lines.

I would be interested in comments and examples where
these layout managers do and do not work well.

Michael

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