pythoncard-users Mailing List for PythonCard (Page 200)

Below is the start of some documentation for the Button widget. Feel free to
make suggestions on wording, layout, etc. I'm not good at documenation, so
your suggestions can't be any worse than what I've done.
Button is the simplest widget, but most of the other widgets share its
attributes and events, so if we can get the Button documenation to a point
that we are happy with, we can put the text into an HTML layout and then
document the remaining widgets following the same style. I don't have time
today, but tomorrow I'm going to look at some other reference works and see
if there is a more appropriate format.
You can look at spec.py and widget.py to see the specification the framework
actually uses and the actual Button class and its methods.
ka
---
Button
 Attributes:
 backgroundColor
 color: tuple (r, g, b), "named color", or hex color string "#FF00FF"
 color is always returned as an rgb tuple
 command
 string
 enabled
 boolean
 font
 Font
 foregroundColor
 color: tuple (r, g, b), "named color", or hex color string "#FF00FF"
 color is always returned as an rgb tuple
 label (mandatory)
 string
 name (mandatory, read-only)
 string
 position
 tuple (x, y)
 specifying -1 for either x or y will use the default x or y
position
 size
 tuple (width, height)
 specifying -1 for either width or height will use the
default
 width or height
 toolTip
 string
 visible
 boolean
 # I need to revise some of the widget.py code before documenting the
'methods' completely. This section is more of a note to myself than what
would go into the online docs.
 Methods:
 getId()
 this should be a read-only attribute
The following are also methods, but I think they will be changed. In the
case of addEventListener and notifyEventListeners you won't see them
anymore, because they will start with a leading underscore and I think
setFocus() will just be another attribute.
 setFocus()
 see if this works as an attribute
 focus = 1 or 0
 addEventListener, notifyEventListeners should start with an
underscore
 Events:
 gainFocus
 loseFocus
 mouseClick
 mouseContextDoubleClick
 mouseContextDown
 mouseContextUp
 mouseDoubleClick
 mouseDown
 mouseDrag
 mouseEnter
 mouseLeave
 mouseMiddleDoubleClick
 mouseMiddleDown
 mouseMiddleUp
 mouseMove
 mouseUp
 Handling events:
 Events are handled by defining a method handler in the background
class. The method name takes the form of 'on_widgetName_event'. For example,
to handle a 'mouseClick' for a Button widget with a name of 'button1' you
would create a method:
 def on_button1_mouseClick(self, target, event):
 print 'hello ' + target.name
 Which outputs:
>>> hello button1
 Event order:
 gainFocus, mouseDown, mouseUp, mouseClick
 The best way to see events in action is to just start a sample like
'proof' with the Message Watcher (-m command-line option), then uncheck the
"Hide unused" checkbox. For example, here is a sequence copied from the
Message Watcher, after clicking on 'Button 1' I moved the mouse and clicked
on 'Button 2':
mouseClick : button1
(mouseMove : button1)
(mouseMove : button1)
(mouseMove : button1)
(mouseLeave : button1)
(mouseEnter : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(mouseMove : button2)
(loseFocus : button1)
(gainFocus : button2)
(mouseDown : button2)
(mouseUp : button2)
(mouseClick : button2)
(mouseMove : button2)
 The messages in parenthesis are messages (events) not handled by a
method (handler) in the background, so only the 'mouseClick' for 'button1'
had a handler in the example above.
 Example initialization string in a resource (.rsrc.py) file:
 {'type':'Button',
 'name':'button1',
 'position':(10, 10),
 'label':'Button 1'
 }

We should probably have a different error checking mechanism rather than
throwing a generic exception, but the error:
unable to load template.py
shows that the problem is that there isn't a 'template.py' file to load.
The problem is that your .rsrc.py and main source file don't match up. You
must have used the resourceEditor sample to create your layout and so it
generated default values for the stack and background names. You have:
{'stack':{'type':'Stack',
 'name':'Template',
 'title':'Template Resource',
 'position':(66, 0),
 'size':(500, 600),
 'backgrounds': [
 {'type':'Background',
 'file':'template.py',
 'classname':'Template',
 'name':'bgTemplate',
 'components': [
at a minimum, you need to change the background info. After you do your
first 'Save As...' with the resourceEditor, you can quit, open up the file
you saved with an editor, and change the stack and background info, then you
won't have to worry about it unless you decide to change background names...
later. To test your code, I renamed the files to 'sliders.py' and
'sliders.rsrc.py'
 'backgrounds': [
 {'type':'Background',
 'file':'sliders.py',
 'classname':'aaa',
 'name':'bgMin',
 'components': [
I left the 'name' of the background the same, you can change it to something
more meaningful, but then you need to make sure that the method def matches.
 def on_bgMin_select(self,target,event):
By convention, 'classname' should start with a capital letter and should be
meaningful, but 'aaa' is still valid, so I didn't change it.
You don't need the 'on_sld1_select' method since you have a background one,
so I commented that out. It turns out my original message had a typo and a
logic problem, so the following line:
 if name[:3] == 'sld' and int(name[:3]) in [1,2,3,4]:
 ^
should be:
 if name[:3] == 'sld' and int(name[3:]) in [1,2,3,4]:
however, that doesn't work because trying to do int('Result') throws an
exception, so assuming that you only have four regular sliders and a result
slider you would want to do:
 if name[:3] == 'sld' and name[3:]) != 'Result':
Finally, you didn't have a calcResult method, so I added it below, but
didn't finish the calculation for you, so you'll need to change that. The
last thing that the code below doesn't do is deal with your calculation
giving you a result outside the min and max values for your result slider.
You'll have to decide how you want to deal with that possibility.
That gives us changed this code for the class:
class aaa(PythonCardPrototype.model.Background):
 def on_menuFileExit_select(self, menu, event):
 self.Close()
 def calcResult(self):
 s1 = self.components.sld1.value
 s2 = self.components.sld2.value
 s3 = self.components.sld3.value
 s4 = self.components.sld4.value
 result = 10 # put your calculation here
 return result
 def displayResult(self,result):
 self.components.sldResult.value=int(result)
 def on_bgMin_select(self,target,event):
 name = target.name
 if name[:3] == 'sld' and (name[3:]) != 'Result':
 self.displayResult(self.calcResult())
I noticed that your sliders are in a strange order in your layout:
 sld4
 sldResult
 sld1
 sld3
 sld2
Perhaps you should exchange their y values to make the UI better.
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Ronald
> D Stephens
> Sent: Sunday, September 02, 2001 6:07 PM
> To: pyt...@li...
> Subject: [Pythoncard-users] Braindead debugging
>
>
> PythonCard file, aaa.py
>
> #!/usr/bin/python
>
> """
> __version__ = "$Revision: 1.1 $"
> __date__ = "$Date: 2001年08月06日 20:32:41 $"
> """
>
> import PythonCardPrototype
> from PythonCardPrototype.loader import configOptions
> import os, sys
>
> class aaa(PythonCardPrototype.model.Background):
>
> def on_menuFileExit_select(self, menu, event):
> self.Close()
>
>
> def displayResult(self,result):
> self.components.sldResult.value=int(result)
>
> def on_sld1_select(self,target,event):
> result = self.calcResult()
> self.displayResult(result)
>
>
> def on_bgMin_select(self,target,event):
> name = target.name
> if name[:3] == 'sld' and int(name[:3]) in [1,2,3,4]:
> self.displayResult(self.calcResult())
>
>
> if __name__ == '__main__':
> base, ext = os.path.splitext(sys.argv[0])
> filename = base + ".rsrc.py"
>
> configOptions()
>
> app = PythonCardPrototype.model.PythonCardApp(filename)
> app.MainLoop()
> __________________________________________________________
> ________________________________________________________
>
>
> aaa.rsrc.py
>
> {'stack':{'type':'Stack',
> 'name':'Template',
> 'title':'Template Resource',
> 'position':(66, 0),
> 'size':(500, 600),
>
> 'backgrounds': [
> {'type':'Background',
> 'file':'template.py',
> 'classname':'Template',
> 'name':'bgTemplate',
> 'components': [
>
> {'type':'Slider',
> 'name':'sldResult',
> 'position':(6, 91),
> 'size':(200, 20),
> 'layout':'horizontal',
> 'max':400,
> 'min':1,
> 'value':55,
> },
>
> {'type':'Slider',
> 'name':'sld1',
> 'position':(9, 160),
> 'size':(200, 20),
> 'layout':'horizontal',
> 'max':100,
> 'min':1,
> 'value':55,
> },
>
> {'type':'Slider',
> 'name':'sld2',
> 'position':(10, 295),
> 'size':(200, 20),
> 'layout':'horizontal',
> 'max':100,
> 'min':1,
> 'value':64,
> },
>
> {'type':'Slider',
> 'name':'sld3',
> 'position':(11, 227),
> 'size':(200, 20),
> 'layout':'horizontal',
> 'max':100,
> 'min':1,
> 'value':1,
> },
>
> {'type':'Slider',
> 'name':'sld4',
> 'position':(10, 9),
> 'size':(200, 20),
> 'layout':'horizontal',
> 'max':100,
> 'min':1,
> 'value':28,
> },
>
> ] # end components
> } # end background
> ] # end backgrounds
> } }
>
>
> attmpt to run results:::
>
>
> unable to load template.py
> Traceback (most recent call last):
> File "C:/Python21/PythonCardPrototype/samples/minimal/aaa.py",
> line 38, in ?
> app = PythonCardPrototype.model.PythonCardApp(filename)
> File "C:\PYTHON21\PythonCardPrototype\model.py", line 125, in __init__
> clazz = module.__dict__[ bg.classname ]
> UnboundLocalError: local variable 'module' referenced before assignment
>
> Look, I promise to stop wasting your time soon...
>
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Morning all, I take a couple of days away from e-mail and the list goes 
bananas. Maybe I should take a couple of weeks off ;-)
Anyway, Ron, you are almost there, I've annotated the lines you need to 
change;
Ronald D Stephens wrote:
> PythonCard file, aaa.py
> 
> #!/usr/bin/python
> 
> """
> __version__ = "$Revision: 1.1 $"
> __date__ = "$Date: 2001年08月06日 20:32:41 $"
> """
> 
> import PythonCardPrototype
> from PythonCardPrototype.loader import configOptions
> import os, sys
> 
> class aaa(PythonCardPrototype.model.Background):
> 
> def on_menuFileExit_select(self, menu, event):
> self.Close()
> 
> 
> def displayResult(self,result):
> self.components.sldResult.value=int(result)
> 
> def on_sld1_select(self,target,event):
> result = self.calcResult()
> self.displayResult(result)
> 
> 
> def on_bgMin_select(self,target,event):
> name = target.name
> if name[:3] == 'sld' and int(name[:3]) in [1,2,3,4]:
> self.displayResult(self.calcResult())
> 
> 
> if __name__ == '__main__':
> base, ext = os.path.splitext(sys.argv[0])
> filename = base + ".rsrc.py"
> 
> configOptions()
> 
> app = PythonCardPrototype.model.PythonCardApp(filename)
> app.MainLoop()
> __________________________________________________________
> ________________________________________________________
> 
> 
> aaa.rsrc.py
> 
> {'stack':{'type':'Stack',
> 'name':'Template',
> 'title':'Template Resource',
> 'position':(66, 0),
> 'size':(500, 600),
> 
> 'backgrounds': [
> {'type':'Background',
> 'file':'template.py',
-- 'file':'aaa.py',
> 'classname':'Template',
-- 'classname':'aaa',
> 'name':'bgTemplate',
> 'components': [
> 
> {'type':'Slider', 
> 'name':'sldResult', 
> 'position':(6, 91), 
> 'size':(200, 20), 
> 'layout':'horizontal', 
> 'max':400, 
> 'min':1, 
> 'value':55, 
> },
> 
> {'type':'Slider', 
> 'name':'sld1', 
> 'position':(9, 160), 
> 'size':(200, 20), 
> 'layout':'horizontal', 
> 'max':100, 
> 'min':1, 
> 'value':55, 
> },
> 
> {'type':'Slider', 
> 'name':'sld2', 
> 'position':(10, 295), 
> 'size':(200, 20), 
> 'layout':'horizontal', 
> 'max':100, 
> 'min':1, 
> 'value':64, 
> },
> 
> {'type':'Slider', 
> 'name':'sld3', 
> 'position':(11, 227), 
> 'size':(200, 20), 
> 'layout':'horizontal', 
> 'max':100, 
> 'min':1, 
> 'value':1, 
> },
> 
> {'type':'Slider', 
> 'name':'sld4', 
> 'position':(10, 9), 
> 'size':(200, 20), 
> 'layout':'horizontal', 
> 'max':100, 
> 'min':1, 
> 'value':28, 
> },
> 
> ] # end components
> } # end background
> ] # end backgrounds
> } }
> 
> 
> attmpt to run results:::
> 
> 
> unable to load template.py
> Traceback (most recent call last):
> File "C:/Python21/PythonCardPrototype/samples/minimal/aaa.py", line 38, in ?
> app = PythonCardPrototype.model.PythonCardApp(filename)
> File "C:\PYTHON21\PythonCardPrototype\model.py", line 125, in __init__
> clazz = module.__dict__[ bg.classname ]
> UnboundLocalError: local variable 'module' referenced before assignment
> 
> Look, I promise to stop wasting your time soon...
> 
No wasting, you've identified an interesting point. By not changing the 
'file' and 'classname' attributes of your stack you managed to confuse 
the loader. Its an interesting conundrum, because we run aaa.py which 
causes the framework to load aaa.rsrc.py which *must* point back to 
aaa.py otherwise you see the error you got. Smacks of a bit of a 
circular reference to me and maybe something worth looking at?
I know the original intention was for a run time engine which would 
first look at the rsrc file, thus the reference to aaa.py and class aaa 
makes sense. Perhaps it is just our round about unit testing strategy 
that causes the confusion. I leave it to the team to decide ...
I haven't looked at the documentation but I suspect we need another paragraph in 'getting started'. I'll have a look at adding it later.
Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

PythonCard file, aaa.py
#!/usr/bin/python
"""
__version__ = "$Revision: 1.1 $"
__date__ = "$Date: 2001年08月06日 20:32:41 $"
"""
import PythonCardPrototype
from PythonCardPrototype.loader import configOptions
import os, sys
class aaa(PythonCardPrototype.model.Background):
 def on_menuFileExit_select(self, menu, event):
 self.Close()
 
 def displayResult(self,result):
 self.components.sldResult.value=int(result)
 def on_sld1_select(self,target,event):
 result = self.calcResult()
 self.displayResult(result)
 def on_bgMin_select(self,target,event):
 name = target.name
 if name[:3] == 'sld' and int(name[:3]) in [1,2,3,4]:
 self.displayResult(self.calcResult())
if __name__ == '__main__':
 base, ext = os.path.splitext(sys.argv[0])
 filename = base + ".rsrc.py"
 configOptions()
 app = PythonCardPrototype.model.PythonCardApp(filename)
 app.MainLoop()
__________________________________________________________
________________________________________________________
aaa.rsrc.py
{'stack':{'type':'Stack',
 'name':'Template',
 'title':'Template Resource',
 'position':(66, 0),
 'size':(500, 600),
 'backgrounds': [
 {'type':'Background',
 'file':'template.py',
 'classname':'Template',
 'name':'bgTemplate',
 'components': [
{'type':'Slider', 
 'name':'sldResult', 
 'position':(6, 91), 
 'size':(200, 20), 
 'layout':'horizontal', 
 'max':400, 
 'min':1, 
 'value':55, 
 },
{'type':'Slider', 
 'name':'sld1', 
 'position':(9, 160), 
 'size':(200, 20), 
 'layout':'horizontal', 
 'max':100, 
 'min':1, 
 'value':55, 
 },
{'type':'Slider', 
 'name':'sld2', 
 'position':(10, 295), 
 'size':(200, 20), 
 'layout':'horizontal', 
 'max':100, 
 'min':1, 
 'value':64, 
 },
{'type':'Slider', 
 'name':'sld3', 
 'position':(11, 227), 
 'size':(200, 20), 
 'layout':'horizontal', 
 'max':100, 
 'min':1, 
 'value':1, 
 },
{'type':'Slider', 
 'name':'sld4', 
 'position':(10, 9), 
 'size':(200, 20), 
 'layout':'horizontal', 
 'max':100, 
 'min':1, 
 'value':28, 
 },
] # end components
} # end background
] # end backgrounds
} }
attmpt to run results:::
unable to load template.py
Traceback (most recent call last):
 File "C:/Python21/PythonCardPrototype/samples/minimal/aaa.py", line 38, in ?
 app = PythonCardPrototype.model.PythonCardApp(filename)
 File "C:\PYTHON21\PythonCardPrototype\model.py", line 125, in __init__
 clazz = module.__dict__[ bg.classname ]
UnboundLocalError: local variable 'module' referenced before assignment
Look, I promise to stop wasting your time soon...

> From: Peter Cleaveland
>
> I just started reading the list, and I noticed the discussion of "sizers"
> to control the GUI appearance. I can sure see the cross platform
> differences in widget rendering. What are sizers? (They sound like
> something from the Java AWT - but I'm just guessing.) It's clear
Yes, Java AWT and Swing support sizers as part of the layout manager.
Originally, there was just the grid bag layout, but now Java supports box
layout as well. HTML tables are another form of sizer layout. You can read
up on sizers in the wxWindows documentation that came with your wxPython
installation. In the "Classes by category" section look under 'Window
layout' and then look at wxSizer, wxGridSizer, wxFlexGridSizer, etc.
Everyone that wants to contribute ideas or code should read those sections.
I haven't done much with "sizers" myself and in fact started reading up on
the various forms today. It would be great if somebody can correct me where
I made a mistake in my description above or better yet provide more insight
into what wxWindows/wxPython does right or wrong with regards to sizers.
After we are happy with our Font implementation I will be getting more into
sizers. I already have an idea how we might implement them so that their
description would be relatively easy to grasp.
> Perhaps PythonCard could borrow some of the CSS syntax. Specifying
> font-family as a list of requested fonts, falling to default if none are
> available. Font-size and box/containment properties (border, padding,
> margin, etc.) could be in pixels, but the actual width and height of most
> things could fall where they may.
Last week the font discussion centered around CSS-like syntax for the font
family and facename. I didn't implement it yet because I'm still thinking
about how the user (programmer) will need to manipulate the fonts in real
programs versus initialization. At a minimum, there will always be a default
family that must be specified: serif, sansSerif, monospace.
CSS is too complicated for us to implement a complete-CSS syntax and I'm not
sure that most of it applies anyway. I am much more interested in something
like TABLE for our sizers, but done with Python lists and dictionaries
instead of using tags like <TABLE> <TR> <TD> ... and then implementing dot
notation to reference individual elements. However, I've only thought about
this for a little while and my initial thoughts on the matter could be
either too limited or difficult to implement or both.
There is actually quite a lot of work going into the wxHTML control for
wxWindows and even in the upcoming wxWindows/wxPython 2.3.2 it will be much
more capable than the one available today. We won't be able to do a GUI
layout editor that uses HTML, that is simply too complicated, but we will
probably be able to support the use of HTML with embedded widgets for
layouts sometime in the future if somebody wants to go that route. The
layout capabilities won't be as advanced as what you can pull off with say
Internet Explorer today, but if you're careful you will be able to do quite
a lot and probably share layout between web pages and PythonCard apps. I
keep reminding myself about Zope and how Zope and PythonCard might
complement each other for just this type of cross-platform (web and desktop)
work.
ka

> From: Ronald D Stephens
>
> I guess what I have in mind is this. I want to set up a
> collection of several sliders, to use as data input devices. Then, I need
> to do a calculation on the data, and send the output to a results
> slider. In other words, if S1 thorugh S5 are the input sliders, I
> need to do something like
>
> (S1 +5(S2) + 3(S3) -4(S4))/S5
>
> and then output the result to an output slider.
Okay, this is a very specific problem, which I'll go into below. In general,
you'll have to decide whether to use the widgets as data storage or whether
they simply represent a 'view' of some internal variables you keep track of
yourself. The samples have example of doing both.
You want to use the 'value' attribute of the slider. For example, if you
have a a slider with a name of 'sld1' then:
 self.components.sld1.value
will give you an integer that you can use in your calculation. Then when you
have your calculated value, do something like:
 def displayResult(self, result):
 self.components.sldResult.value = int(result)
I would wrap up the calculation in its own method (as an example I'll just
refer to it as 'calcResult'), which returns your result. You can have the
result slider dynamically changed by responding to a 'select' event for all
the sliders.
 def on_sld1_select(self, target, event):
 result = self.calcResult()
 self.displayResult(result)
You would need a separate handler for each slider, so rather than do that,
you could use a background handler. I remember you asking about background
handlers before. Your background has a name, I'll assume it is 'bgMin' like
the 'minimal.py' sample and that sliders one through five are named like the
one above.
 def on_bgMin_select(self, target, event):
 name = target.name
 if name[:3] == 'sld' and int(name[3:]) in [1,2,3,4,5]:
	 self.displayResult(self.calcResult())
There are other ways to solve your problem, but something like that should
work. Your result slider will change dynamically as you drag sliders one
through five.
You'll want to initialize all your sliders with appropriate min/mix values,
but you can change these dynamically while the program is running by setting
the 'min' and 'max' attributes or using the 'setRange(min, max) method.
If you later decide that you also want to display the results and inputs
numerically as well as via a slider you can add StaticText or TextField
(with 'editable' = 0) widgets that are updated as the slider values change.
ka

Hi all,
I just started reading the list, and I noticed the discussion of "sizers" 
to control the GUI appearance. I can sure see the cross platform 
differences in widget rendering. What are sizers? (They sound like 
something from the Java AWT - but I'm just guessing.) It's clear the fixed 
co-ordinate system HyperCard used will be difficult to sustain across many 
platforms and windowing kits.
I've done a lot recently with these same issues in the HTML world. I am 
working on some ASP code that uses an XML Schema to dynamically define HTML 
data collection forms to build a valid XML document. I found I could get 
decent layout control without absolute positioning, using just tables, some 
<div> container elements, and CSS. There is little use of fixed pixel 
sizes, so the layouts to look reasonable in IE, Opera and Netscape.
Perhaps PythonCard could borrow some of the CSS syntax. Specifying 
font-family as a list of requested fonts, falling to default if none are 
available. Font-size and box/containment properties (border, padding, 
margin, etc.) could be in pixels, but the actual width and height of most 
things could fall where they may.
Peter

> 4. What is the best way to tie widget actions or commnads to
> > Python logic or formulae? Maybe this isn't implemented yet, if so, how
> > do you think it will work in future?
>
> I'm not sure what you're asking here, can you go into more depth, provide an
> example of what you're trying to do, etc.?
>
> ka
I guess what I have in mind is this. I want to set up a collection of several sliders, to use as data input devices. Then, I need
to do a calculation on the data, and send the output to a results slider. In other words, if S1 thorugh S5 are the input sliders, I
need to do something like
(S1 +5(S2) + 3(S3) -4(S4))/S5
and then output the result to an output slider.

> From: Neil Hodgson
>
> > I really dislike the UI for the Property Editor and want to recode it so
> > that it presents a grid of properties and values like VB, Boa, and most
> > other tools that let you change the attributes of widgets. However, the
> one
> > we have today is working, so it keeps getting knocked down on
> my priority
> > list.
>
> On Linux/X/GTK+ the property editor often moves when you click on it
> making the UI quite difficult to use. The default font sizes are also very
> small there. I'm not sure which code is responsible for this but
> even after
> trying to do the right thing in Scintilla/SciTE, the setup for GTK+ has to
> choose 12 point to be similar to 10 point on Windows.
I'm pretty sure the window or panel jumping is a known Linux bug with
wxPython, but I'm not sure if it is a specific to a particular version or
whether it is fixed in the upcoming version 2.3.2. Rowland mentioned this
when I first did the original proof. Here's an email from 2001年07月02日:
Kevin: My friend Rowland says that under Linux the window jumps down 20
pixels every time he hides/shows the window.
Robin: This sounds like a bug in wxWindows that was just fixed today
according to the CVS update messages.
All of the 'Debug' windows are coded in wxPython directly, they are outside
the PythonCard framework and event model, so that they don't impact the base
application. Consequently, They can be coded with sizers and there could be
some additional options for the default fonts or they could just pick up
whatever the underlying default scheme or theme indicates. Perhaps you are
already doing something like that for your code that we could apply?
ka

> I really dislike the UI for the Property Editor and want to recode it so
> that it presents a grid of properties and values like VB, Boa, and most
> other tools that let you change the attributes of widgets. However, the
one
> we have today is working, so it keeps getting knocked down on my priority
> list.
 On Linux/X/GTK+ the property editor often moves when you click on it
making the UI quite difficult to use. The default font sizes are also very
small there. I'm not sure which code is responsible for this but even after
trying to do the right thing in Scintilla/SciTE, the setup for GTK+ has to
choose 12 point to be similar to 10 point on Windows.
 Neil

> From: Ronald D Stephens
>
> 1. The resource editor and property editor are awesome! They work
> so simply that I can already add widgets and change properties
> easier than with any other program I have ever tried.
I really dislike the UI for the Property Editor and want to recode it so
that it presents a grid of properties and values like VB, Boa, and most
other tools that let you change the attributes of widgets. However, the one
we have today is working, so it keeps getting knocked down on my priority
list.
> 2. Where is the best description of the commands available for
> each widget type?
Events and attributes for each widget are described in spec.py. widget.py
has the full method list for each widget. There is no standalone
documenation for either widget attributes or events yet. Initial attempts
using pydoc and happydoc didn't work so well. Documentation continues to be
high on my priority list, so I'll get into again once the labor day weekend
is over and the guests staying with us are gone.
> 3. I like dot notation, for what its worth.
Yes, Neil and Patrick have done a good thing.
> 4. What is the best way to tie widget actions or commnads to
> Python logic or formulae? Maybe this isn't implemented yet, if so, how
> do you think it will work in future?
I'm not sure what you're asking here, can you go into more depth, provide an
example of what you're trying to do, etc.?
ka

1. The resource editor and property editor are awesome! They work so simply that I can already add widgets and change properties
easier than with any other program I have ever tried.
2. Where is the best description of the commands available for each widget type?
3. I like dot notation, for what its worth.
4. What is the best way to tie widget actions or commnads to Python logic or formulae? Maybe this isn't implemented yet, if so, how
do you think it will work in future?
Ron Stephens

Two more interesting articles:
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html
http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html
Don't let the java focus scare you.
---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."
-----Original Message-----
From: pyt...@li...
[mailto:pyt...@li...]On Behalf Of Patrick K.
O'Brien
Sent: Sunday, September 02, 2001 11:45 AM
To: Pythoncard
Subject: [Pythoncard-users] Dot syntax and the risk of overexposure
Because I'm a big fan of straightforward dot syntax, I've been helping Kevin
and company with some of the "magic" aspects in python that allow code like
the following in PythonCard:
>>> comp.button1.font.size = 10
So far we have focused on exposing as many attributes as possible through
dot syntax. At some point, however, we need to focus on which attributes
*should* be exposed. To help us all keep in mind the fact that good OO
design would have us limit the amount of exposure we give to an object, I'd
like to start a discussion by recommending the following article by Allen
Holub. If you like this one, he has several others on his website. Let me
know what you think about this article on "What Is An Object" and what it
might mean for PythonCard:
http://www.holub.com/goodies/what_is_an_object.html
---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."
_______________________________________________
Pythoncard-users mailing list
Pyt...@li...
https://lists.sourceforge.net/lists/listinfo/pythoncard-users

> From: Patrick K. O'Brien
>
> So far we have focused on exposing as many attributes as possible through
> dot syntax. At some point, however, we need to focus on which attributes
> *should* be exposed. To help us all keep in mind the fact that good OO
> design would have us limit the amount of exposure we give to an
> object, I'd
> like to start a discussion by recommending the following article by Allen
> Holub. If you like this one, he has several others on his website. Let me
> know what you think about this article on "What Is An Object" and what it
> might mean for PythonCard:
>
> http://www.holub.com/goodies/what_is_an_object.html
This is a good start for object-oriented issues, but I'm sure a lot of the
OOP gurus lurking on the list can suggest some other ones.
A lot of this article focuses on problems that arise due to the use of
explicit types such as using an int versus a float which is always a problem
with static typed languages like C. While we have some of these issues
ourselves, Python reduces a lot of the type worries. For example, it is
legal to specify a backgroundColor or foregroundColor as an rgb tuple (0, 0,
255), a named string "blue" or a hex string "#0000FF". Frankly, that makes a
lot of OO programmers cringe, but I think it is easier for the user
(programmer). Obviously, there are still exposed types there, and in C++ and
Java you could do something like that too to support multiple argument
types, so I guess my point isn't as relevant as it looked when I started
this paragraph. :) Ah, now that feels like the OOP discussions I'm used to.
The other part of the article hints at model-view-controller issues, but
then goes in a direction that I find simply stupid, which is that every
class has to know how to "draw yourself in this window" That is simply not
doable, let alone maintainable, there are too many possibilities, so again
you end up with a system that doesn't work except within extremely limited
possibilities.
ka

Because I'm a big fan of straightforward dot syntax, I've been helping Kevin
and company with some of the "magic" aspects in python that allow code like
the following in PythonCard:
>>> comp.button1.font.size = 10
So far we have focused on exposing as many attributes as possible through
dot syntax. At some point, however, we need to focus on which attributes
*should* be exposed. To help us all keep in mind the fact that good OO
design would have us limit the amount of exposure we give to an object, I'd
like to start a discussion by recommending the following article by Allen
Holub. If you like this one, he has several others on his website. Let me
know what you think about this article on "What Is An Object" and what it
might mean for PythonCard:
http://www.holub.com/goodies/what_is_an_object.html
---
Patrick K. O'Brien
Orbtech (http://www.orbtech.com)
"I am, therefore I think."

Don't know why I forgot this, but it is fixed now in cvs. 'Show Resource'
button shows the .rsrc.py file for a sample. You can just download
'samples.py' and 'samples.rsrc.py' from:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pythoncard/PythonCardPrototyp
e/samples/
and replace the ones in release 0.4.4.1
Patrick pointed out the 'samples' should be in the list of samples, so I
fixed that as well. The code needs refactoring now, but it does seem to
work.
ka

Patrick worked some more magic and added "dot dot" support to the Font
class, so it is now legal to do something like:
self.components.field1.font.size = 12
Previously you would have needed to get the font first, change the font
size, then set the font of the widget. Obviously the notation above is what
you would expect, so it is great to see it working.
The same kind of "dot dot" magic will be required for other classes or
complex mutable types like the items list for Choice, List, and RadioGroup
if we want dot notation to work consistently.
This change is in cvs which impacted font.py and widget.py, feel free to
play around with it. The only thing important to remember now is that there
is a one to one relationship between a Font instance and a widget because
the Font keeps track of the widget as its parent.
ka

Kevin Altis wrote:
 > Right now, all our samples have: #!/usr/bin/python
 >
 > should we change them to:
 >
 > #!/usr/bin/env python
 >
 > It looks like the latter is preferred.
 >
It really just depends on where Python is installed on the *nix machine 
in question. I've seen some people say that Python is *usually* 
installed to some particular directory on *nix machines, but I've seen 
quite a few different Python directories.
My webserver uses /usr/bin/python1.5 (The 1.5 is because ever since the 
company that hosts Useless Python was recently sold, and nobody admits 
to being the one who is doing the hosting. The upside is that we have 
free hosting. The downside is we'd rather pay our bills and get that 
upgrade to Python 2.x so I can write new scripts to automate the site.).
And while I'm here, I'll introduce myself. I'm Rob from Useless Python. 
I don't think we have a link to PythonCard resources on Useless yet, but 
we'll be glad to set one up or help out in any way we can. For instance, 
if anyone would like to contribute something made with PythonCard, or a 
source file related to it in some way, a plug with a link can be 
inserted into the file description (Made with PythonCard!, or similar?).
For those to whom the holiday applies,
Happy Labor Day weekend,
Rob
-- 
A {} is a terrible thing to waste.
Useless Python!
http://www.lowerstandard.com/python

Okay, you know the drill by now. I'm not going to announce this anywhere
else until I know that the Unix launching works for someone besides Neil,
plus I would like to make sure I didn't botch something up today that was
working yesterday for release 0.4.4.
http://sourceforge.net/project/showfiles.php?group_id=19015
0.4.4.1 contains the samples launcher named appropriately samples.py and
located in the samples directory. I also updated the Getting Started
document based on the suggestions in Guido's email. Hopefully, I got that
part right too.
http://pythoncard.sourceforge.net/getting_started.html
"share and enjoy"
ka

On 2001年8月31日, Kevin Altis wrote:
>Right now, all our samples have:
>#!/usr/bin/python
>
>should we change them to:
>
>#!/usr/bin/env python
>
>It looks like the latter is preferred.
No. The path depends on the distribution and Distutils are
capable of mending it to the needs.
env doesn't allow to add an argument.
>ka
Sincerely yours, Roman Suzi
-- 
_/ Russia _/ Karelia _/ Petrozavodsk _/ rn...@on... _/
_/ Saturday, September 01, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Brain: The apparatus with which we think that we think." _/

"Kevin Altis" <al...@se...> writes:
> Also, if we do distutils will that allow us to automatically set the
> execute bit ('chmod +x scriptfile') on all the samples?
Yes. distutils should also automatically mangle the #! lines, too.
distutils is good(tm).
Cheers,
M.
-- 
 surely, somewhere, somehow, in the history of computing, at least
 one manual has been written that you could at least remotely
 attempt to consider possibly glancing at. -- Adam Rixey

> The samples launcher (samples.py) seems to be working fine on Windows, but
I
> can't test it on Unix, so I don't know if the os.spawnv code below is
> correct. If someone in Unix land can confirm that it works or provide a
> better solution that would be great.
 This works fine for me:
import os
os.system('minimal/minimal.py -s')
 On the top of the files, either of these work for me:
#!/usr/bin/env python
 or
#!/usr/bin/python
 In res.py,
 self.dictionary = eval( open( rsrcFileName ).read().replace('\r\n',
'\n') )
 makes the code work on Linux without needing to fix up the resource
files. It still works on Windows with this change but I'm not sure whether
Macs need '\r; line endings.
 Neil

Also, if we do distutils will that allow us to automatically set the execute
bit ('chmod +x scriptfile') on all the samples?
ka
> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Friday, August 31, 2001 9:00 PM
> To: pythoncard-Users
> Subject: [Pythoncard-users] Unix Python path
> 
> 
> Right now, all our samples have:
> #!/usr/bin/python
> 
> should we change them to:
> 
> #!/usr/bin/env python
> 
> It looks like the latter is preferred.

Right now, all our samples have:
#!/usr/bin/python
should we change them to:
#!/usr/bin/env python
It looks like the latter is preferred.
ka

> From: Neil Hodgson
>
> The sizes of widgets and fonts and the visual appearance
> depends on which
> GTK+ theme you are using. Therefore Jeff's screenshots look a lot
> different
> to mine (he has chosen a theme similar to Motif and I chose one similar to
> Windows) and as various parameters, such as font size, change
> other elements
> need resizing. Explicitly setting fonts in your application is
> frowned upon
> because you should be able to choose this in the GTK+ theme control panel
> for global effect. Windows has similar features but they are used
> less often
> and for smaller visual changes - few Windows users know how to change the
> dialog font which causes many dialogs to display badly.
I have tried some of the alternate Windows schemes, but I can't remember now
whether wxWindows actually used different default sizes and fonts correctly
all the time. I'll experiment with that more to see what does and doesn't
work in anticipation of doing positioning and sizing that isn't absolute.
So, in the sizer realm are we going to also need to support relative font
sizes as well, so you say something is 100%, 180% ...? Does this map to
wxPython or do we have to manage it ourselves - it looks like the latter
IIRC?
> > Did you do an ascii or binary transfer? Unix folks please speak up so we
> can
> > address issues with line endings or anything else that I'm
> missing because
> > I'm using Windows 2000. I got Unix out of my system a long time ago and
> > don't plan on going back, so somebody else is gonna have to help here.
>
> Most Python code copes well with the extra \r characters but
> the resource
> files don't so one thing that can be done is to explicitly replace all
> '\r\n' with '\n' before evaling on Linux.
So doesn't the -a option take care of this when the file is unzipped or was
the problem the ftp transfer? If we use distutils will the conversion be
done automatically? I can start automating the conversion to just newlines
before zipping, but that might cause other problems.
ka