pythoncard-users

[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] 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

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] 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] 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] 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] 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

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

[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] 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

[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 - now at v0.3

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

Alex Tweedley wrote on 05/06/2005 03:53:27 PM:

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

I am trying .3 for the first time with PythonCard .82, and have replaced
the widget.py. I notice that the CVS version number on your widget.py (
1.133)
is older than the one in PythonCard .82  (1.136).

When I launch the NewResourceEditor.0.3, I get the following error:

oms-ballen:~ ballen$ pythonw2.4 
/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py 
Traceback (most recent call last):
  File 
"//Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/wx-2.6-mac-unicode/wx/_core.py", 
line 11904, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 163, 
in on_initialize
    self.components[sizingHandle] = self.sizingHandleTemplate
  File "/OMS/dev/pythonPackages/PythonCard/model.py", line 98, in 
__setitem__
    control = component.ComponentFactory().createComponent(self.parent, 
self.parent.panel, item)
  File "/OMS/dev/pythonPackages/PythonCard/component.py", line 347, in 
createComponent
    component = clazz(aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/components/image.py", line 70, 
in __init__
    widget.Widget.__init__( self, aParent, aResource )
  File "/OMS/dev/pythonPackages/PythonCard/widget.py", line 63, in 
__init__
    component.Component.__init__(self)


At that point, the new ResourceEditor launches, but when I create a widget 
I get a similar
error:

TypeError: __init__() takes exactly 2 arguments (1 given)
Traceback (most recent call last):
  File "/OMS/dev/pythonPackages/PythonCard/menu.py", line 204, in 
_dispatch
    handler(background, aWxEvent)
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 1685, 
in on_componentAdd_command
    self.create_component(desc)
  File "/OMS/dev/misc/newresourceEditorv0_3/resourceEditor.py", line 1543, 
in create_component
    self.components[name] = desc
  File "/OMS/dev/pythonPackages/PythonCard/model.py", line 98, in 
__setitem__
    control = component.ComponentFactory().createComponent(self.parent, 
self.parent.panel, item)
  File "/OMS/dev/pythonPackages/PythonCard/component.py", line 347, in 
createComponent
    component = clazz(aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/components/textfield.py", line 
85, in __init__
    widget.Widget.__init__(self, aParent, aResource)
  File "/OMS/dev/pythonPackages/PythonCard/widget.py", line 63, in 
__init__
    component.Component.__init__(self)

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

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

"""
__version__ = "$Revision: 1.136 $"
__date__ = "$Date: 2005/03/28 17:29:37 $"
"""

import wx
import event
import error
import font
import graphic
import component


def makeNewId(id):
    if id == -1:
        return wx.NewId()
    else:
        return id


class WidgetSpec( component.ComponentSpec ) :
    def __init__( self, name, parent, events, subclassAttributes ) :
        events.extend( event.WIDGET_EVENTS )
        attributes = {
            'id':{'presence':'optional', 'default':-1},
            'enabled' : { 'presence' : 'optional', 'default' : 1 },
            'visible' : { 'presence' : 'optional', 'default' : 1 },
            'foregroundColor' : { 'presence' : 'optional', 'default' : None },
            'backgroundColor' : { 'presence' : 'optional', 'default' : None },
            #'helpText' : { 'presence' : 'optional', 'default' : '' },
            'toolTip' : { 'presence' : 'optional', 'default' : '' },
            'font' : { 'presence' : 'optional', 'default' : None },
            'position' : { 'presence' : 'optional', 'default' : [ -1, -1 ] },
            'size' : { 'presence' : 'optional', 'default' : [ -1, -1 ] },
            'nameSpecified' : {'presence':'optional', 'default': 0 },
            'labelSpecified' : {'presence':'optional', 'default': 0 },
            'userdata' : {'presence':'optional', 'default':''}
            }
        attributes.update(subclassAttributes)
        component.ComponentSpec.__init__( self, name, parent, events, attributes )        
       

class Widget(component.Component):
    """
    The base class for all of our GUI controls.
    Each Widget must bind itself to the wxPython
    event model.  When it receives an event
    from wxPython, it will convert the event
    to a PythonCArd event.Event ( SelectEvent, ClickEvent,
     etc ) and post the event to the EventQueue.
    """
   # _spec = WidgetSpec()

    def __init__(self, aParent, aResource):
        component.Component.__init__(self, aResource)
        self._parent = aParent
        self._resource = aResource
        self._setNameSpecified(self._resource.nameSpecified)
        self._setLabelSpecified(self._resource.labelSpecified)                
        self._setUserdata(self._resource.userdata)
        # KEA 2004-04-23
        # Controls are enabled and visible by default
        # so no need to enable and call Show unless False.
        if not self._resource.enabled:
            self._setEnabled(self._resource.enabled)
        if not self._resource.visible:
            self._setVisible(self._resource.visible)
        if self._resource.foregroundColor is not None:
            self._setForegroundColor(self._resource.foregroundColor)
        if self._resource.backgroundColor is not None:
            self._setBackgroundColor(self._resource.backgroundColor)
        if self._resource.toolTip != "":
            self._setToolTip(self._resource.toolTip)
        if self._resource.font is None:
            self._font = None
        else:
            self._setFont(font.Font(self._resource.font, self))

    def __repr__(self):
        return str(self.__dict__)

    def _getId(self):
        # KEA 2004-04-20
        # the id is generated using makeNewId by the base wxPython control
        return self.GetId()

    def _setId(self, id):
        raise AttributeError, "id attribute is read-only"

    # KEA 2004-04-21
    # finding the parent is probably going to be a common task
    # I'm tempted to make this a read-only attribute like id
    # but the user would never specify it, so it won't show up
    # in the spec, but before that is done the framework, samples,
    # and tools have to be checked for use of a parent variable
    def getParent(self):
        return self.GetParent() 
    
    def _getToolTip(self):
        try:
            return self.GetToolTip().GetTip()
        except:
            return ""
    
    def _getFont(self):
        if self._font is None:
            desc = font.fontDescription(self.GetFont())
            self._font = font.Font(desc)
        return self._font
    
    def _setForegroundColor( self, aColor ) :
        aColor = self._getDefaultColor( aColor )
        self.SetForegroundColour( aColor )
        self.Refresh()   # KEA wxPython bug?
    
    def _setBackgroundColor( self, aColor ) :
        aColor = self._getDefaultColor( aColor )
        self.SetBackgroundColour( aColor )
        self.Refresh()   # KEA wxPython bug?
        
    def _setToolTip(self, aString):
        toolTip = wx.ToolTip(aString)
        self.SetToolTip(toolTip)
    
    def _setFont(self, aFont):
        if isinstance(aFont, dict):
            aFont = font.Font(aFont, aParent=self)
        else: # Bind the font to this widget.
            aFont._parent = self
        self._font = aFont
        aWxFont = aFont._getFont()
        self.SetFont( aWxFont )

    def _getNameSpecified(self):
        return self._nameSpecified

    def _setNameSpecified(self, aBoolean):
        self._nameSpecified = aBoolean

    def _getLabelSpecified(self):
        return self._labelSpecified

    def _setLabelSpecified(self, aBoolean):
        self._labelSpecified = aBoolean

    def _getUserdata(self):
        return self._userdata 

    def _setUserdata(self, aString):
        self._userdata = aString

    def _getDefaultColor( self, aColor ) :
        if aColor is None :
            return wx.NullColour
        else :
            # KEA 2001-07-27
            # is the right place for this check?
            if isinstance(aColor, tuple) and len(aColor) == 3:
                return wx.Colour(aColor[0], aColor[1], aColor[2])
            else:
                return aColor

    # KEA 2004-04-16
    # can the method below be replaced with
    #setFocus = wx.Window.SetFocus
    # even if Widget doesn't subclass wx.Window?
    # the same issue applies to other aliases that might be created
    # above and below
    # if not perhaps Widget should subclass wx.Window?
    def setFocus(self):
        self.SetFocus()

    def _getPosition(self):
        # get the actual position, not (-1, -1)
        return self.GetPositionTuple()  

    def _setPosition(self, aPosition):
        self.Move(aPosition)

    def _getSize(self):
        # return the actual size, not (-1, -1)
        return self.GetSizeTuple()

    def _setSize(self, aSize):
        self.SetSize(aSize)

    def _getEnabled(self):
        return self.IsEnabled()

    def _setEnabled(self, aBoolean):
        self.Enable(aBoolean)

    def _getVisible(self):
        return self.IsShown()

    def _setVisible(self, aBoolean):
        self.Show(aBoolean)

    def _getForegroundColor(self):
        return self.GetForegroundColour()

    def _getBackgroundColor(self):
        return self.GetBackgroundColour()

    def redraw(self):
        """Force an immediate redraw without waiting for an event handler to finish."""
        self.Refresh()
        self.Update()

    # KEA 2004-04-16
    # if a subclass overrides any of the methods below then it needs to
    # set the property as well so the appropriate method gets used
    backgroundColor = property(_getBackgroundColor, _setBackgroundColor)
    font = property(_getFont, _setFont)
    foregroundColor = property(_getForegroundColor, _setForegroundColor)
    enabled = property(_getEnabled, _setEnabled)
    id = property(_getId, _setId)
    #position = property(wx.Window.GetPositionTuple, wx.Window.Move)
    position = property(_getPosition, _setPosition)
    size = property(_getSize, _setSize)
    toolTip = property(_getToolTip, _setToolTip)
    nameSpecified = property(_getNameSpecified, _setNameSpecified)
    labelSpecified = property(_getLabelSpecified, _setLabelSpecified)
    userdata = property(_getUserdata, _setUserdata)
    visible = property(_getVisible, _setVisible)

    # KEA 2004-05-02
    # this will probably end up in Scriptable or Component
    # it should be completely generic
    # the only problem part would be the reference to the parent (background)
    # where the events are actually defined which would make this problematic
    # for a compound component or events bound to a Panel
    # what we really want is a reference to the application instance
    # there is probably some method to give us that in wxWidgets
    # UPDATE - I think GetTopLevelParent is what I was looking for
    def _bindEvents(self, eventList):
        # shouldn't components be subclasses of Scriptable?
        # components would have their own handlers but when
        # looking for a handler match it will search the parents
        # for now just grab handlers from the background
        
        # the references below would be self.findHandler instead of
        # background.findHandler
        
        # KEA 2004-09-13
        # switching back to the earlier hack for finding the parent background
        # in order to support the PageBackground experiments
        #background = self.GetParent().GetParent()
        parent = self.GetParent()
        if isinstance(parent, wx.Dialog):
            background = parent
        else:
            background = parent.GetParent()

        if wx.GetApp()._showDebugMenu:
            bindUnusedEvents = True
        else:
            bindUnusedEvents = False
        
        # helper variable to simplify test for whether to bind InsteadOfTypeEvents
        # there is a good chance we will need to know
        # which events are bound, if we want to dynamically add or remove
        # events later, so go ahead and keep a reference to the list
        self.boundEvents = {}
        
        self.eventIdToHandler = {}
        self.wxEventIdMap = {}

        if 0:
            print "\nBINDING...", self.name

        actionBindings = {}
        if self.actionBindings is not None:
            actionBindings = self.actionBindings
        for eventClass in eventList:
        #for eventClass in ButtonEvents:
            # need to figure out a way to avoid the need
            # for this id to class mapping which is used in _dispatch below
            self.wxEventIdMap[eventClass.id] = eventClass
            # command handler overrides normal mouseClick or select handler
            # so dispatch will automatically dispatch to the command handler
            # by looking up the handler this way
            # it also means that if there is a command association with this component
            # then the regular mouseClick or select handler will never be bound, just ignored
            if issubclass(eventClass, event.CommandTypeEvent) and self.command:
                handler = background.findHandler('on_' + self.command + '_command')
                if not handler:
                    handler = background.findHandler('on_' + self.name + '_' + eventClass.name)
            else:
                handler = background.findHandler('on_' + self.name + '_' + eventClass.name)
            if not handler:
                handler = background.findHandler('on_' + eventClass.name)
            if not handler:
                handlerData = actionBindings.get(eventClass.name)
                if handlerData is not None:
                    handlerObjectName, handlerFunction = handlerData
                    handlerObject = background.components.get(handlerObjectName)
                    if handlerObject is not None:
                        handler = getattr(handlerObject, handlerFunction, None)
                    if not handler:
                        handler = background.findHandler('on_' + handlerObjectName + '_' + handlerFunction)
            if handler or bindUnusedEvents:
                # only bind events that have an event handler
                # in this scenario unused events are never bound
                # which is more efficient, but the Message Watcher needs
                # to be changed
                # alternatively we can bind everything and then in _dispatch
                # if there isn't a match in eventIdToHandler then we know
                # the event isn't used and we can set used to False
                # the complication would be that we probably have to have to
                # always call Skip() which may or may not be a hassle with components
                
                # this doesn't bind command events
                # they would be of the form on_somename_command
                # or perhaps on_command but I don't think we would want
                # to support that
                # the event binding would be specific to a component
                # since on dispatch command overrides something like mouseClickEvent
                # but the name of the command is not related to the component
                # need to look at whether self.command has a value and then bind
                # with ButtonMouseClickEvent.binding if that isn't already bound
                # then in dispatch have to check again I think
                
                # need to avoid double binding
                # also binding shouldn't be order-specific
                # so how to avoid binding mouseDrag to _dispatch
                # if mouseMove is already bound or if binding mouseMove
                # not rebinding if mouseDrag is already bound
                # perhaps MouseDragEvent keeps a reference to MouseMoveEvent
                # and that is inserted into boundEvents, then we check boundEvents
                # prior to rebinding?
                if not self.boundEvents.get(eventClass.binding, None):
                    self.Bind(eventClass.binding, self._dispatch)
                    self.boundEvents[eventClass.binding] = eventClass.name
                if handler:
                    if 0:
                        print "  binding", self.name, eventClass.name, handler.__name__, eventClass.id
                    # KEA 2004-05-02
                    # change to just using the method directly, Handler class not needed
                    # actually the Handler class isn't needed at all
                    # so if the initial list built to simplify findHandler
                    # just stores a reference to the method that would be fine
                    # as long as the whole system uses that
                    # the only reason we don't just build the list ourselves
                    # in _bindEvents is that every component needs to do findHandler
                    # so it is more efficient to do once when the Scriptable object
                    # is created than to reparse for each component
                    #self.eventIdToHandler[eventClass.id] = handler
                    #self.eventIdToHandler[eventClass.id] = handler.getFunction()
                    self.eventIdToHandler[eventClass.id] = handler

        if 0:
            print "\n  boundEvents:"
            for name in self.boundEvents.values():
                print "   ", name
            print "\n\n"
            print "\n  self.eventIdToHandler:"
            for id in self.eventIdToHandler:
                # KEA 2004-05-02
                # change to just using the method directly, Handler class not needed
                #print "   ", id, self.eventIdToHandler[id]._function
                print "   ", id, self.eventIdToHandler[id]
            print "\n\n"

    def _dispatch(self, aWxEvent):
        eventType = aWxEvent.GetEventType()
        eventClass = self.wxEventIdMap[eventType]
        
        eventClassInstance = eventClass()
        # decorate will add the relevant event attributes
        aWxEvent = eventClassInstance.decorate(aWxEvent, self)

        if self.command and isinstance(eventClassInstance, event.CommandTypeEvent):
            # need to report the name for the handler if it exists
            eventName = 'command ' + self.command
        else:
            if isinstance(eventClassInstance, event.InsteadOfTypeEvent):
                # changes eventType if needed
                # e.g. mouseDrag instead of mouseMove
                eventType = eventClassInstance.translateEventType(aWxEvent)
            eventName = self.wxEventIdMap[eventType].name
            
        # cleanup
        eventClass = None
        eventClassInstance = None

        # it shouldn't be possible to be in _dispatch for an event
        # that wasn't bound above, but just in case...
        # KEA 2004-05-02
        # change to just using the method directly, Handler class not needed
        #handler = self.eventIdToHandler.get(eventType, None)
        handler = self.eventIdToHandler.get(eventType, None)
        # KEA 2005-03-28
        # don't fire events when objects are in the process of being deleted
        if handler and not aWxEvent.target.IsBeingDeleted():
            event.EventLog.getInstance().log(eventName, self.name, True)
            if 0:
                print "dispatching", handler.__name__
            # make a lowercase alias
            aWxEvent.skip = aWxEvent.Skip

            # the event handlers are part of the Background so
            # we have to have a reference to call the handler below
            
            # if Scriptable takes over the dispatch then
            # this would need to work differently if the actual
            # handler could be somewhere else
            
            # KEA 2004-09-13
            # switching back to the earlier hack for finding the parent background
            # in order to support the PageBackground experiments
            #background = self.GetParent().GetParent()
##            background = wx.GetTopLevelParent(self)
            parent = self.GetParent()
            if isinstance(parent, wx.Dialog):
                background = parent
            else:
                background = parent.GetParent()

            # this is what is in event.py
            # aHandler.getFunction()( aOwner, self.getSource(), self )
            # KEA 2004-05-02
            # change to just using the method directly, Handler class not needed
            #handler.getFunction()(background, aWxEvent)
            handler(background, aWxEvent)
            
            # do we have to clean up this alias?
            aWxEvent.skip = None
            # how about this local reference to handler?
            handler = None
            background = None
        else:
            event.EventLog.getInstance().log(eventName, self.name, False)
            # hopefully this is all we need to do for "unused events"
            aWxEvent.Skip()

        # cleanup
        aWxEvent.target = aWxEvent.eventObject = None


class Panel(wx.Panel):

    def __init__(self, aParent, imageFile, tiled):
        wx.Panel.__init__(self, aParent, -1, 
            style=wx.TAB_TRAVERSAL | wx.NO_FULL_REPAINT_ON_RESIZE)
        self._frame = aParent
        self._imageFile = imageFile
        self._backgroundTiling = tiled
        # KEA 2001-07-27
        # Load the bitmap once and keep it around
        # this could fail, so should be a try/except.
        if imageFile is not None :
            self._bitmap = graphic.Bitmap(imageFile)
            wx.EVT_ERASE_BACKGROUND( self, self.onEraseBackground )
            
        wx.EVT_WINDOW_DESTROY(self, self._OnDestroy)

    def _OnDestroy(self, event):
        # memory leak cleanup
        self._bitmap = None

    def tileBackground(self, deviceContext):
        # tile the background bitmap
        sz = self.GetClientSize()
        bmp = self._bitmap.getBits()
        w = bmp.GetWidth()
        h = bmp.GetHeight()

        if isinstance(self, wx.ScrolledWindow):
            # adjust for scrolled position
            spx, spy = self.GetScrollPixelsPerUnit()
            vsx, vsy = self.GetViewStart()
            dx,  dy  = (spx * vsx) % w, (spy * vsy) % h
        else:
            dx, dy = (w, h)

        x = -dx
        while x < sz.width:
            y = -dy
            while y < sz.height:
                deviceContext.DrawBitmapPoint(bmp, (x, y))
                y = y + h
            x = x + w

    def getForegroundColor(self):
        return self.GetForegroundColour()

    def getBackgroundColor(self):
        return self.GetBackgroundColour()

    def _getDefaultColor(self, aColor):
        if aColor is None :
            return wx.NullColour
        else :
            # KEA 2001-07-27
            # is the right place for this check?
            if isinstance(aColor, tuple) and len(aColor) == 3:
                return wx.Colour(aColor[0], aColor[1], aColor[2])
            else:
                return aColor
            
    def setForegroundColor(self, aColor):
        aColor = self._getDefaultColor(aColor)
        self.SetForegroundColour(aColor)
        self.Refresh()   # KEA wxPython bug?
    
    def setBackgroundColor(self, aColor):
        aColor = self._getDefaultColor(aColor)
        self.SetBackgroundColour(aColor)
        self.Refresh()   # KEA wxPython bug?

    def onEraseBackground(self, aWxEvent):
        deviceContext = aWxEvent.GetDC()
        
        if not deviceContext :
            deviceContext = wx.ClientDC(self)
            r = self.GetUpdateRegion().GetBox()
            deviceContext.SetClippingRegion(r.x, r.y, r.width, r.height)
                                                       
        if self._backgroundTiling:
            self.tileBackground( deviceContext )
        else:
            deviceContext.DrawBitmapPoint(self._bitmap.getBits(), (0, 0))

    position = property(wx.Panel.GetPositionTuple, wx.Panel.SetPosition, doc="position of the panel") 
    size = property(wx.Panel.GetSizeTuple, wx.Panel.SetSize, doc="size of the panel") 

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.

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