Any chance this patch or similar might make it into 2.9.3?
Following notes from my original post of this to the user list.
Werner
My initial go was to basically rename existing sc.SizedPanel to
sc.SizedParent and get rid of the __init__ code, however I couldn't make
the new sc.SizedPanel (which was basically just the old __init__ code to
see the AddChild, SetSizerType and GetSizerType methods.
Anyhow even if above worked I am not aware of a way to handle the
following type of code "sp.ScrolledPanel.SetSizer(self, sizer)" in
SizedParent that always the correct base class would be called.
If anyone can point me to some documentation/sample code on how this can
be done I have another look.
In the mean time attached is a proposed patch using a different way
which still has a minimal amount of duplicated code in the different
sub-classes.
I am putting the helmet on - so please comment on this;-)
The problem on my end is basically that I have been swamped the past few weeks, and it looks like it will continue for at least another week or two. From what I've seen of the code, I'm definitely on board with getting it into 2.9.3, and if Robin doesn't beat me to it, I'll try to get it in when I have time.
Thanks,
Kevin
···
On Nov 2, 2011, at 6:58 AM, werner wrote:
Kevin and/or Robin,
Any chance this patch or similar might make it into 2.9.3?
Following notes from my original post of this to the user list.
Werner
My initial go was to basically rename existing sc.SizedPanel to
sc.SizedParent and get rid of the __init__ code, however I couldn't make
the new sc.SizedPanel (which was basically just the old __init__ code to
see the AddChild, SetSizerType and GetSizerType methods.
Anyhow even if above worked I am not aware of a way to handle the
following type of code "sp.ScrolledPanel.SetSizer(self, sizer)" in
SizedParent that always the correct base class would be called.
If anyone can point me to some documentation/sample code on how this can
be done I have another look.
In the mean time attached is a proposed patch using a different way
which still has a minimal amount of duplicated code in the different
sub-classes.
I am putting the helmet on - so please comment on this;-)
Please also add to the demo a sample of using SizedScrolledPanel. And adding docstrings to the new classes (or others if you want) if you're able would certainly be a Good Thing.
···
On 11/2/11 6:58 AM, werner wrote:
In the mean time attached is a proposed patch using a different way
which still has a minimal amount of duplicated code in the different
sub-classes.
I am putting the helmet on - so please comment on this;-)
In the mean time attached is a proposed patch using a different way
which still has a minimal amount of duplicated code in the different
sub-classes.
I am putting the helmet on - so please comment on this;-)
Please also add to the demo a sample of using SizedScrolledPanel.
Done
And adding docstrings to the new classes (or others if you want) if you’re able would certainly be a Good Thing.
Done, please critic.
I’ll add just a comment on the docstrings: when you introduce a newline character on the :param: declaration, you should add a space to align the first character of the newline with the “p” or :param:, i.e. not like this:
:param prop: valid strings are “proportion”, “hgrow”, “vgrow”,
“align”, “halign”, “valign”, “border”, “minsize” and “expand”
But like this:
:param prop: valid strings are “proportion”, “hgrow”, “vgrow”,
“align”, “halign”, “valign”, “border”, “minsize” and “expand”
I know it seems like a minor issue but in the past I have seen Sphinx complaining about incorrect indentation on newline characters for docstrings.