Re: [Pythoncard-devel] Multi-resource editor

[Kevin A. <al...@se...>]

On Jul 26, 2005, at 9:58 AM, Alex Tweedly wrote:

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

I would prefer to have it as a separate directory as well. While this 
is a bit of a pain for the initial checkin, it makes it simpler to 
update and as you pointed out leaves the original intact and available. 
The big downside is that you end up with parallel copies of files that 
are currently the same. If only a few files were changing then it might 
be better to have a single directory and simply change the name of some 
of the modules that would otherwise conflict. Since that could also 
lead to more confusion, I think we'll simply need to have you be 
responsible for updating files in the your resourceEditor.

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

I will be able to test on Panther after OSCON. I'm currently in a 
holding pattern on my Mac so that I don't break anything prior to my 
presentation next week. I backed out wxPython 2.6.x as well on the Mac 
since it appears there might be some wxSTC issues, which I'll look into 
further after OSCON.

> 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 don't have much experience with this implementation, but it seems to 
"tricky" for the average user and while it could be a clever time saver 
for your own tool where you know what to expect all the time, I expect 
it would just cause problems for an infrequent user. This widget.py 
change is probably a show-stopper.

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

My comments above apply here too, but feel free to try it out as long 
as it isn't going to require framework changes.

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

I've not been that happy with the Font property for some of the reasons 
you've specified but also because typically this property isn't changed 
and due to how defaults work, the resulting font used on the different 
platforms or even on the same platform where the user default has been 
changed, will result in messed up layouts, etc. For the display of the 
property, either single or multiple statictext fields would probably be 
better, dropping the curly braces, quotes, and commas on the actual 
display of the property. This would require some special handling using 
the normal Update button, but if the changes are only made when the 
Font dialog is accepted, then it shouldn't be an issue.

On a related note, if properties were handled by property-specific 
handlers as originally envisioned the property editor would be much 
better. We may still be able to pull that off for a 1.x version of 
PythonCard without breaking anything, but it might be something done in 
PythonCard 2 instead of we continue with the idea of self-describing 
components.

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

So, again my suggestion is that your resourceEditor be added to tools 
as its own directory and files.

ka