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.