Menu
▾
▴
pythoncard-users
|
From: Winston W. <win...@st...> - 2006-04-19 21:34:17
|
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 ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york |
|
From: Alex T. <al...@tw...> - 2006-04-19 22:39:33
|
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 As far as I know, these two have been fixed in the latest version (layoutEditor in 0.8.2, only in cvs). If you aren't using that, I'd recommend an update (you can get it using anonymous cvs access - see instructions under "Development" on the left menu of www.pythoncard.org And if you're already using the latest version and still seeing these problems, I'd appreciate a full bug report so I can fix them :-) > - Layouts/Sizers are not supported. > I agree that's a problem. Partly it's because there's something of a conflict between the desirability of using sizers (on the one hand) and the desire to keep it simple and quick to make a basic app in PythonCard (I've yet to see a sizer-based layout editor that I'd describe as simple or quick). > 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. > I think the tricky part will be deciding what to do when the XRC file contains controls, options or values that PythonCard doesn't support. > 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? I'd give it a try (of course), but whether or not I'd use it is a much harder question. That would depend on the features and "style" of the GUI editors that can create xrc files. The issue I have with all the sizer-based GUI editors I've seen is that they work best when you already have a good idea of what your finished UI is going to look like (including how you want the controls split into sizers), whereas I tend to build the UI incrementally, adding controls, moving them around, etc. as the project evolves. Then (at some point) it feels settled enough that I could reasonably design a sizer tree and start allocating controls to branches of it. (currently of course I need to do that in code, which feels "wrong" but not too bad because it rarely changes much after that). It's been a while since I looked at the range of editors available, so if there is one that handles sizer-tree reconfiguration well I'd be very happy to hear about it. Assuming it was completely "parallel" to existing stuff, I can't see a reason why it couldn't be added to the repository. I think the main technical issue will be the mis-match between the set of controls presented by the editor(s) and what can actually be handled by PythonCard (but that's an off-the-cuff response - I'll give it some thought (and take a closer look at the editors and xrc itself and get back to you if I see anything else looming ....) -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.4/318 - Release Date: 18/04/2006 |
|
From: Andy T. <an...@ha...> - 2006-04-20 09:40:25
|
Alex Tweedly wrote: > Winston Wolff wrote: > >> Is anybody thinking about integrating XRC files in PythonCard? >> [snip] > > > Assuming it was completely "parallel" to existing stuff, I can't see a > reason why it couldn't be added to the repository. > > I think the main technical issue will be the mis-match between the set > of controls presented by the editor(s) and what can actually be handled > by PythonCard (but that's an off-the-cuff response - I'll give it some > thought (and take a closer look at the editors and xrc itself and get > back to you if I see anything else looming ....) > I've got an item on my to do list to write a utility to convert PythonCard resource files to XRC and vice versa. You are more than welcome to progress it as I'm not likely to get to it soon. At present there are no plans to replace PythonCard's resource files with XRC for the reasons that Alex mentions. With a conversion utility as a starting point the two may get closer together though. Regards, Andy -- -------------------------------------------------------------------------------- From the desk of Andrew J Todd esq - http://www.halfcooked.com/ |
|
From: Winston W. <win...@st...> - 2006-04-20 14:12:03
|
Dear Andy and Alex- Thanks for the fast and informed response. It sounds like this project has some serious leaders who know the code which makes me glad. If I'm going to invest some time, I don't want it to go into a black hole. Right now I'm working on a deadline and put aside PythonCard in favor of straight wxPython to get the job done. Sometime in the next month or two I'd like to work on this. I'll let you know of I make any progress. -ww ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york |
|
From: Kevin A. <al...@se...> - 2006-04-22 05:49:22
|
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 |
|
From: Winston W. <win...@st...> - 2006-04-22 13:47:52
|
> There isn't a one-to-one match between the standard wxWidgets/ > wxPython widget attributes ... The "command" attribute has no > equivalent in XRC. Yes, the lack of a "command" parameter in an XRC file is a problem. The more I fiddle with wxPython, the more I realize how nice PythonCard is, and how much time it saves. Perhaps a better use of my effort would be to add Sizers into PythonCard. Apple's Cocoa/ AppKit has the best sizers in my opinion. What would be the technical hurdles of adding that to PythonCard? -ww On Apr 22, 2006, at 1:49 AM, 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 > > > ------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Pythoncard-users mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncard-users ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york |
|
From: Kevin A. <al...@se...> - 2006-04-25 18:50:21
|
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 |
|
From: Alex T. <al...@tw...> - 2006-04-22 14:32:02
|
Winston Wolff wrote: >> There isn't a one-to-one match between the standard wxWidgets/ >> wxPython widget attributes ... The "command" attribute has no >> equivalent in XRC. > > > Yes, the lack of a "command" parameter in an XRC file is a problem. > > The more I fiddle with wxPython, the more I realize how nice > PythonCard is, and how much time it saves. Perhaps a better use of > my effort would be to add Sizers into PythonCard. Apple's Cocoa/ > AppKit has the best sizers in my opinion. What would be the > technical hurdles of adding that to PythonCard? > I'm not real familiar with Cocoa / Appkit / Xcode / Interface Builder - in fact, I've just spent the last ten minutes Googling and browsing around, and that's the sum of my knowledge of them :-) As far as I can see, the Interface Builder approach to resizing is the "rods and springs" style, as in the old Hypercard. This approach I always found easy to use, but it's generally considered less capable than the "sizer" approach. This is particularly relevant for Pythoncard (really, for wxWidgets which underlies PythonCard / wxPython). One big issue in wxPython for cross-platform development is that basic system characteristics (e.g. menu font, button font, button sizes and how much space a button needs, etc.) vary between systems. A "rods and springs" constrained layout can run into problems when even the basic visual features turn out to be larger than they had been in the original layout, and hence the constraints can't necessarily be satisfied prior to stretching, which can result in ugly overlapping components, etc. I haven 't seen a good way to get around that problem, so I eventually had to agree that the sizer approach is the better one - even though it's not as easy to use (or at least, I haven't found a layout editor that makes it easy to use). I think that you can achieve the kind of layout / resizing you want (including x-platform) with the sizers in wxWidgets - BoxSizers and FlexGridSizer get you most of the way, adding GridBagSizer gets you everything else (hopefully once I understand them better, I'll be sure that FlexGridSizer is unnecessary, and that BoxSizers + GridBagSizer is enough). I've been looking, on and off, for a while at adding sizers to the layout editor. So, triggered by your first email on this topic, I've started writing up how I think this could be (simply) done - I'll get that (first draft) out this weekend, and if you're up for it we can perhaps collaborate on it. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 21/04/2006 |
|
From: Ed L. <ed...@le...> - 2006-04-22 15:15:14
|
On Apr 22, 2006, at 10:31 AM, Alex Tweedly wrote: > I think that you can achieve the kind of layout / resizing you want > (including x-platform) with the sizers in wxWidgets - BoxSizers and > FlexGridSizer get you most of the way, adding GridBagSizer gets you > everything else (hopefully once I understand them better, I'll be > sure that FlexGridSizer is unnecessary, and that BoxSizers + > GridBagSizer is enough). Agreed. After playing around with all the various sizer options in wxPython, we settled on just that combination: dSizer is based on the wx.BoxSizer, and dGridSizer is based on wx.GridBagSizer. That seems to cover any layout situation I've come across. > I've been looking, on and off, for a while at adding sizers to the > layout editor. So, triggered by your first email on this topic, > I've started writing up how I think this could be (simply) done - > I'll get that (first draft) out this weekend, and if you're up for > it we can perhaps collaborate on it. If it saves you some effort, I went through the same effort with the Dabo Class Designer. I started with a PythonCard-like approach, with objects that used absolute positioning, and then tried to add sizers into that mix. It was impossible to visually represent that mix of sizer and non-sizer layouts together. The only approach that seemed to be feasible was to go with the sizers-only design, in which you create the sizers and allocate 'slots' that then get filled with controls. I have a couple of screencasts that show this approach in action, and also try to educate people who are new to sizers how to approach laying out a form; perhaps they might be helpful to your ideas on adding sizers to PythonCard. http://leafe.com/screencasts/sizers1.html http://leafe.com/screencasts/sizers2.html -- Ed Leafe -- http://leafe.com -- http://dabodev.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X