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