-
I say no to adding the pseudo-props as parameters. For the simple reason that i think the other way, with each prop set on its own line more readable. And that, it seems to me, in python is a valid reason! ;)
-
I say allow it... it's very nice to be able to create and initialize the object in just one statement. The fact that both size and Size might be valid parameter values doesn't seem like a big deal if you document clearly that the ones that start with a capital letter are really just properties that can be set in the constructor.
-
One more vote for inclusion of such parameters in constructor. Why? because this will allow *BOTH* one line creation and multiple line creation of widgets, also I think that is closer to "batteries included" philosophy.
-
To have both (current and new situation) would be fine. But, I think the current situation is enough. A user always can write a proc or class to get the other way.
-
The redundancy in the constructor and the clash between nomenclatures is unappealing. It would be nice, however, to have a mechanism by which "property sets" can be carried around as data and easily set. So I vote for a SetProperties and a named properties initializer argument:
b = Button(parent, properties={
'Size':(100, 25),
'Position':(20,20),
'BackgroundColor':'yellow')
b.SetProperties(**myproperties)
This would also make it easier for someone to configure a portion of their GUI from a resource file.
An option for normalizing the nomenclature is to make the properties case insensitive or to auto-translate into lowercase or mixedCase.
-
Well, I like the idea of allowing it both ways. Making the properties case insensitive appeals to me also.
-
I'd vote for lowercase parameters in the constructor AND lowercase property names. :)
-
Re lowercase property names... There are two issues with this:
1. wxPython objects have a lot of methods like SetXXX and GetXXX; e.g. SetSize/GetSize, SetPosition/GetPosition, etc. In Wax, there are "pseudo" properties; widget.GetSize() can be replaced by widget.Size, and widget.SetSize(x) can be replaced by widget.Size = x. In other words, we look for "Get"/"Set" plus the name. The name part of GetSize is "Size", not "size".
2. Having property names that start with an uppercase letter allows you to add all kinds of attributes with lower case names, without having the risk of a name clash. As long as you stick to names that start with a lowercase letter, you won't accidentally overwrite any property names.
So the current property names are probably here to stay. :)
-
I like the multi-valued SetProperties option, but not in the constructor since that would confuse properties with the window styles (eg. orientation, etc.) which must be set at construction. You still get 2-line initialization without the size/Size confusion.
lx's idea looks like a reasonable compromise for the "batteries included" philosophy of 1-line initialization, and could achieve more compatible notation using 'dict':
b = Button(parent,properties=dict(Size=(100, 25), Position=(20,20),BackgroundColor='yellow'))
-
I don't think that you should mix the new properties with the existing properties in the constructor. That could be confusing due to the redundancy issue. However, it is possible to still allow such properties to be included in the constructor, separated from the regular parameters.
You could do this by adding a single parameter to each constructor. You could call this parameter 'properties', and it would contain a dictionary of property/value pairs.
So instead of:
b = Button(parent, Size=(100,100), Position=(10,10))
you would have:
b = Button(parent, properties={'Size':(100,100), 'Position':(10,10)})
The code that parses this properties dictionary could ignore any invalid property for the current object.
Your proposed SetProperties() method would take the same parameter:
props = {'Size':(100, 100)}
props['Position'] = (10, 10)
b.SetProperties(props)
You could write the code that parses this dictionary in such a way that would automatically assimilate new properties when they are added to the the base controls. You could actually use the same parsing routine for all the various controls, as long as they conform to the standard wx naming conventions (GetXXX and SetXXX).
Drawbacks? Well, if you build the property dictionary right in the constructor call, it's a bit ugly, with all those colons and squigglies, but if that turns your stomach, you still have the option of building the property dictionary beforehand:
props = {}
props['Size'] = (100, 100)
props['Position'] = (10, 10)
b = Button(parent, properties=props)
Hopefully this is some food for thought.
Peter
-
I am constructing an application in wxpython and
have encountered the same problem.
My solution is to adopt the "skin" concept I see in
other applications.
Basically anything that concerns the visual appearance
of the widget I bundle up in a separate skin object.
I have a hook into a widget to pass it an entire skin.
This lets the skin be changed dynamically.
Here are the advantages I see to using the skin model:
o a new skin can be written by someone other than an app developer
o a bunch of methods are removed from any particular widget's
interface
The downside is you need to construct a skin framework
for your app.