Re: [Pythoncard-users] Re: platform-specific resource files now supported

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

On Apr 12, 2005, at 11:25 AM, Michael Sorich wrote:

> The topic of platform-specific resource files made me
> wonder whether it is possible for a resource file to
> inherit from another resource file. If the differences
> between platform specific resources are relatively
> minor, I would think it would be simpler to inherit
> from a base resource and only include the components
> and properties to be changed.

You could probably do this manually, but the resourceEditor certainly 
doesn't support it. You would need to do your own logic that mirrors 
what PythonCard does with internationalResourceName to figure out the 
resource filenames; You can't use periods in filenames like we do if 
you want Python to be able to import the files, so instead of 
minimal.rsrc.py and minimal.win.rsrc.py you would want to use 
underscores: minimal_rsrc.py minimal_win_rsrc.py, which you could 
import. The current resource files are read in as text files and then 
run through eval() so anything eval() can handle is valid, including 
doing an import and then replacing certain elements of a list, 
dictionary, etc.

Since your next question is probably going to be "Why don't we just 
change the resource file format and loader then?" the answer is 
installed base and "if it ain't broke, don't fix it". I think we should 
probably figure out the next evolution of the resource file format, 
whether it continues to be valid Python, XML, support subclassing, 
whatever, and then add support for that in PythonCard 1.x in addition 
to still supporting the old format. That process would be part of the 
PythonCard 2.0 discussion.

You can easily do your own custom loading and such today, but like I 
said, the framework and tools won't know about a different format, so 
there is extra work for you.

> On a different topic, could someone remind me of the
> reasons why components are accessed from
> self.components rather than self?
> E.g. self.components.button1 vs. self.button1
> If I allowed self to lookup self.components would this
> cause a problem with the program? I think I remember
> there being some discussion on this in the past, but I
> cannot find it in the archive.
>
> Thanks,
>
> Michael

There is a very simple reason for this and its called name collision. 
If the components could be accessed as self.button1 then the names 
would need to be different than any methods or other attributes of the 
Background class, super and subclasses. There would probably be some 
other complications that would require __getattr__ and __setattr__ 
methods for Background and slow down and complicate all member 
accesses, but the name collision is the still the primary reason.

ka