Re: [Pythoncard-users] I'm learning - added .rsrc awareness to 'FindFiles'

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

On Sep 16, 2004, at 3:23 PM, Alex Tweedly wrote:

> At 14:46 16/09/2004 -0700, Kevin Altis wrote:
>
>
>> I'm glad you were able to work this out. I haven't had resourceEditor 
>> support in findfiles previously, because usually I want to edit the 
>> .rsrc.py files using the codeEditor to make some quick change. 
>> However, I think it would be a good option that could be toggled on 
>> and off, so I'll look at adding that. In the meantime, all you need 
>> to do is a simple string check, in fact, I'm not sure why I'm not 
>> doing this in the existing code, except maybe the current way seemed 
>> cleaner than filename.endswith('.py) or filename.endswith('.pyw').
>
> Well, os.path goes to all the trouble of giving us a splitext 
> function, so it may be a good idea to use it. Some day, someone may 
> find a file system that uses something other than "." as the separator 
> ....
>
>>         if filename.endswith('.rsrc.py'):
>>             program = os.path.join("..", "resourceEditor", 
>> "resourceEditor.py")
>>         elif os.path.splitext(filename)[-1] in ['.py', '.pyw']:
>>         ...
>> Obviously, you can put the additional code in to check for a 
>> resourceEditor.pyw file, but the main thing is to just use the 
>> endswith string method and make sure that check is done before the 
>> .py/.pyw check.
>
> You could go one step further and do
>    name,ext = os.path.splitext(filename)
>    if ext in ['py', 'pyw]]:
>        if name.endswith(".rsrc") then
>                resource editor
>        else:
>                code editor
>   else:
>      text editor
>
> (Hmmm - or get really carried away and put in a table of file types 
> and programs to use to open them with - with a menu option to 
> create/edit associations, and .... :)

Actually, that was the plan at one point, but it seemed like overkill. 
Sort of like having a built-in codeEditor (childWindow) in findfiles, 
though that is actually easy to do and sort of appealing, hmm...

> Which brings me to a real question ... why   .rsrc.py  rather than  
> .rsrc ?
> That way you could have associated .rsrc with the resource editor in 
> the OS.

Historical decision. There is a .py extension because the resource 
files are valid python files, so if you open them in a Python-aware 
editor you get syntax highlighting, syntax checks should work, etc. I 
also needed a way of separating attributes of the filename to support 
automatic international resource support like minimal.fr.rsrc.py so 
dots seemed like the way to go.

What we need to decide is whether the current import methodology makes 
sense or whether it would actually be better to make the resources into 
real modules so they could just be imported. To do that, the extra dots 
as separators have to be dropped they would be misinterpreted by 
import. Switching to underscores would solve the problem there.

The resource file would need one tiny change, something like:

RESOURCE_DICT = { 'application':{ 'type':'Application',

instead of just

{ 'application':{ 'type':'Application',

The reason for the uppercase name is that if something obvious and 
unique like that is used, then it would be relatively simple to 
identify it as a global in any file. Conceivably, you could then 
inherit attributes from other resource files which would reduce 
duplication of common menus, or layouts. I don't know how the 
resourceEditor would be able to parse that, but it has some interesting 
uses.

Anyway, we have to decide about changes like that pretty soon. I've 
been putting it off since it means changing so many files, but it needs 
to be done before say release 0.9. To minimize hassles it would be a 
good time to decide whether the CustomDialog resource format should 
really be different than Background as well as whether the name 
Background should finally be changed to just plain Window or Frame or 
something before we get to 1.0

ka