[Pythoncard-devel] Multi-resource editor

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

I've been bringing the "newResourceEditor" up to date with the latest 
CVS, and fixing up some of the problems with it. I'd now like a 
volunteer or two to help me test it on non-Windows machines, and some 
agreement (or discussion) on how to proceed with it.

How to Proceed.

The intent was to make this a branch in CVS. That seemed to make sense 
to allow it to be properly distributed and tested by a number of people 
- but it has the disadvantage (if I understand it properly) that this 
makes it difficult to have both the original resourceEditor and the 
branched-resourceEditor in a single installation. Being a cautious type, 
I like having the old one around as easy backup, and imagine others 
would feel the same.

So I would prefer to add it as an additional tool (like the newer 
version of the codeEditor). I think that would encourage more people to 
try it out, and therefore more people to give necessary feedback which 
would be needed before we could think about making the new one a 
complete replacement for the existing one.

Non-Windows volunteers.

I have partially implemented some sizer-based adjustment to the layout. 
I have tested it as best I can on Windows (by faking the returned sizes 
and seeing if the layout adjusted reasonably), but it needs to be tested 
on Mac and/or Unix to see how it does.
Warning: it's only a partial implementation; it (should) deal with the 
properties that do not occur in every component (i.e. those below 
"position and size" line in the display.If it works OK for those, then 
I'll go back and do the standard ones (oddly enough, that's actually 
noticeably harder).

Other changes.

The one new feature that didn't feel quite right to me was the 
implementation of the name-derivation scheme. I really liked the idea - 
that you could modify only the name and the label (or text, or textarea) 
would adjust accordingly, or vice versa - but the implementation seemed 
clumsy. It was clumsy because :
 - two check boxes needed - ugh.
 - needed an update to widget.py, so harder to run in parallel
 - backwards compatibility required that the default for the two new 
properties be "true", while the resourceEditor required that the initial 
value for new components be "false" - so almost all resource files would 
specify values for these properties.

I've come up with a new scheme, which I like much better, but which 
needs to be tried out by others. (Where this description says "label", 
it could equally be "text" or "textarea").

The name and label are tied together; editing either one will make the 
corresponding adjustment to the other. If you want them to be different, 
you check the "Allow Different" checkbox before making the change. This 
checkbox is a control for the operation of the editor - it is not a 
property of the component, and is not stored in the resource file.

When a component is selected, the name and label are compared - if they 
are already different, then "Allow Different" flag is set - otherwise it 
will be false.   (And in particular, this means that when pre-existing 
resource files are read in, they operate exactly as before, and 
unless/until a component is edited, it is not affected in any way).

So - if you are editing a component where they currently match, and you 
click on "Allow Different" but then go off and select another component 
without changing either name or label, then when you come back to this 
original component, the flag will no longer be set. That might be a 
surprise the first couple of times it happens - but in fact, most likely 
in real use you would clock on the checkbox and immediately change one 
of them.

Font property.

I have found the field containing a textual description of the font to 
be pretty useless. The text name is so long that to get to the relevant 
part of the info, you need to click and side-scroll - and even then it's 
pretty unreadable. Any time I want to check on the font info, I find it 
easier to just click on the font button, and see in the pop-up dialog 
what I need.

And it was almost impossible to fit the button on the same horizontal 
line as the field - so I have (temporarily) just removed the field, and 
now it looks much better without (for me) any disadvantage in how I use 
it.  If anyone objects, it can be put back easily - esp non-Windows 
users who may have more useful font names. 

So please let me know what you think about the font button / field.

Anyone willing to test please contact me off-list and I'll email you a 
current copy.
Anyone who doesn't think it could go as an additional tool, please 
respond on-list.
Anyone who thinks it should be an additional tool, please respond 
on-list also.

Thanks,

-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/2005