Re: [Pythoncard-users] XRC file support in PythonCard

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

On Apr 21, 2006, at 10:49 PM, Kevin Altis wrote:

>
> On Apr 19, 2006, at 2:34 PM, Winston Wolff wrote:
>
>> Is anybody thinking about integrating XRC files in PythonCard?
>>
>> Here are my reasons why it would be a good idea:
>> 	- Could use a number of GUI builders such as wxGlade.
>> 	- PythonCard's resourceEditor has problems including:
>> 		- on Mac OS X grow handles don't appear
>> 		- on Mac OS X sizes get "stuck" and I can't grow widgets
>> 		- Layouts/Sizers are not supported.
>>
>> I'm thinking about a resource loader in PythonCard that would load  
>> an .XRC file (XML file written out by wxGlade or XRCed) and then  
>> do the regular PythonCard magic for binding events to widgets.
>>
>> The great thing about PythonCard is how it links up widgets and  
>> handlers automatically, saving great amounts of time and  
>> simplifying your code.  Probably when it was first written,  
>> wxPython GUI editors were not very good, or didn't exist.  But now  
>> they are better than PythonCard's resourceEditor.  Let's leverage  
>> other's work on GUI editors, and take the good part from PythonCard.
>>
>> Would anybody use this?  Would I be allowed to add it to the  
>> sourceforge repository?  Any other technical issues?
>>
>> -Winston
>
> If all you really want is the auto-event binding that would be  
> relatively easy to separate from the rest of PythonCard. It could  
> even be done so that there isn't a central dispatcher if you don't  
> care about event tracing. What you would do is iterate over the  
> widgets after the XRC has been loaded. Dabo might be another tool  
> to look at.
>
> There isn't a one-to-one match between the standard  wxWidgets/ 
> wxPython widget attributes so at a minimum PythonCard would  
> probably need a custom XRC loader and some attributes that can be  
> set in the resourceEditor. For example, a wxButton in an XRC file  
> normally has the following possible attributes: XML ID, label,  
> default, pos, size, and style. In addition, it has the style  
> attributes: fg, bg, font, enabled, focused, hidden, tooltip. For  
> the most part the names are just different than what is used for  
> PythonCard so that is proably a simple translation. "XML ID" could  
> be treated as the PythonCard "name" attribute which is crucial for  
> event binding. The "command" attribute has no equivalent in XRC.
>
> Having PythonCard be able to support XRC files for resources that  
> follow some specific guidelines such as using XML ID as the "name"  
> probably wouldn't be that hard, though you might lose support for  
> some PythonCard attributes and/or wxWidget attributes that  
> PythonCard doesn't currently recognize. A module that was able to  
> load the XRC files directly would be preferable, but a conversion  
> tool would avoid requiring modification of the framework itself. If  
> the framework has to deal with it I suspect you would need to  
> "walk" the layout after it is loaded and translate between wxPython  
> attributes and PythonCard ones, doing GetXXX() method calls in most  
> cases.
>
> What is much more complicated and unlikely to happen is having the  
> resourceEditor be able to read and write generic XRC files. That  
> would be something to tackle after just being able to load was  
> implemented.
>
> ka
>

Another issue I forgot to mention is that none of the other layout  
tools that support XRC files are going to support PythonCard  
components which are all subclasses of wxPython controls. This means  
that even if you had a module that could load an XRC file and then  
bound the methods, you wouldn't have any of the helper methods or  
attributes so you would have to change the class of each object at  
runtime to the appropriate PythonCard component. Again, this makes an  
XRC -> PythonCard resource translator preferable for simplicity sake.

But the dabo approach to just embracing one form of sizer for layouts  
and abandoning fixed layouts except for backwards PythonCard 1.x  
compatibility is probably the right answer.

ka