Re: [Pythoncard-devel] Multi-resource editor

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

Kevin Altis wrote:

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

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

Yeah, it seemed ok at first, and did save some time, but I found I 
didn't much like it. And I really disliked the widget.py change, so I 
was glad to see the end of that approach.

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

It certainly won't involve framework changes.

It's simpler than the other scheme, but it might be a bit tricky; I 
don't find it to be, but we'll need to find out what others think once 
it's available for use. If it does turn out to be tricky for occasional 
users, then we'll take it out - but I'll definitely then propose some 
way to keep it either as an option / preference choice, or at least keep 
one-way derivation from name to label/text. I take advantage of that all 
the time in Revolution, and it is a major time-saver.

>> 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.
>
So would the multiple display fields be read-only, with changes allowed 
only via the Font dialog ? I think that would be good - I can't believe 
there are many people who make a habit of editing the descriptor string, 
so doing that would allow you to have the characteristics visible.  I'll 
try it out and see how it looks.

> 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.
>
>
> So, again my suggestion is that your resourceEditor be added to tools 
> as its own directory and files.
>
Cool, I'll do that.
(btw - it's only 4 files that have changed plus two new ones added - but 
they amount to 3400 out of a total of just over 4000 lines, so I don't 
think there's noticeable saving from keeping the unchanged files in common).

I'll see if there's any feedback on the self-adjusting layout, and 
expect to do the commit this week (pending any other opinions in 
response to this)

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