About Creating New Packages/Widgets & Other Dev Help

[Metallicow]

I've created quite a few widgets for my projects over the years...

Basically when I started wxPython I was slapping together a lot of widgets
to
make a new widget(s) that performed the functions I wanted and looked right
natively for my/the various platforms used. Oftentimes, these widgets didn't
have all the functionality that I wanted....

What I wanted/desired was the Ultimate Widget for the purpose at hand.

This list entails questions for Robin and other wxPython developers as to
what
the best practices are when doing this to make integrating new stuff with
the
standard wxPython library as painless as possible. Also various questions to
rack the developers brains as to Who-What-When-Where-Why-How-Huh and then
some other random stuff are welcome here.

Along this route and through my learning, there are many ways these widgets
can be produced:
Examples:
1. Generically(Ex: Slap 2 or more different widgets into a panel and call
it a day...)
2. Create a custom wx.PyControl/wx.Control with basic events all handled
specifically and classed out properly.
3. Other... / Transmogrify(Calvin & Hobbes style)...

Lets begin...

[Metallicow]

Attached are images of some of my works and works-in-progress.
Most are solely mine own creations with some being modified/improved
widgets(wxPython licensed).

ShapedBitmapButton, ThreeWaySplitter, VolumeCtrl

RoundTable #1 of questions??? (DC, Device Context)
=============================
1. How many different DC types are there?
2. What is the best performing DC's for drawing graphics?
3. Any other knowledge for improving drawing performance such as a game.
Lookup Ex: library vs. global vs. local

4. Infos about module Docstring markup? What is the standard for Classic
vs. Phoenix

ShapedBitmapButton is the Ultimate widget I have long desired for a long
time.
I have finally gotten to the point that I have gotten it(the widget) to
completely
work with alpha images correctly and also draws the underlying widgets
background
colour/bitmap/etc underneath it acceptably also performance-wise with pure
wxPy/Python.
Looking for drawing performance suggestions/knowledge. Dumbed down Version
and Full Featured Version.

ThreeWaySplitter is a modification of Andrea's FourWaySplitter to meet
the simple/more often useable/customizable side with adjusting sashes
without
all the pain in the ass of having to click twice or more to get the same
resulting
sash position with normal sash layouts or FourWaySplitter.
Looking for suggestions/ideas of improvement for sashes, and custom drawn
sashes(maybe bitmaps).

VolumeCtrl is a self explanitory.
Looking for infos on how to change the OS's volume
programatically/pythonically.
In particular, on a Mac, but also on your flavor of linux(might be
different ways/change it).

I'm not the best documentarist, and have basically replicated a lot of
Andrea's
Docstring style(rst or epydoc). Is this right and up to par with the docs
generation
for classic and phoenix? Best Links for easy learning or copying of wxPy
markup style?

[Dev Player]

Related to Other Dev Help
When I am working on a new wxPython GUI and there is a notebook widget in
it, I sometimes add a PyShell, PySliceShell and PyCrust pages to help debug
things. Although there is a specific demo showing PyCrust why not add these
pages to the demo notebook. Perhaps make them hide-able.

I sometimes add a page (panel with textctrl) showing sys.modules and a page
with sys.path.

[Robin Dunn]

Post by Metallicow
Attached are images of some of my works and works-in-progress.
Most are solely mine own creations with some being modified/improved
widgets(wxPython licensed).
ShapedBitmapButton, ThreeWaySplitter, VolumeCtrl
RoundTable #1 of questions??? (DC, Device Context)
=============================
1. How many different DC types are there?

import wx

... if x.endswith('DC'):
... print('wx.%s' % x)

Post by Metallicow
2. What is the best performing DC's for drawing graphics?

It depends on the context. In a EVT_PAINT you must use a wx.PaintDC, or
one derived from it. Outside of EVT_PAINT handlers you should use
wx.ClientDC but modern hardware and OS tend to perform better if you do
all your drawing in the paint handler. So when you need to update
something on screen outside of the paint handler then the best approach
is to just change the object's state and then call Refresh and wait for
the next paint event and then redraw based on the changed state.

The buffered DCs will buffer your drawing operations in a wx.Bitmap and
then flush them all at once to the screen using a normal DC, reducing or
preventing flicker. However on platforms that already buffer drawing
operations, or where it can be turned on programatically, then using
your own buffering is overkill, unless you are maintaining the buffer
bitmap too, or are simulating multiple layers.

Finally, if you want anti-aliased drawing or alpha transparency then you
should use wx.GraphicsContext as a layer above the DCs

Post by Metallicow
3. Any other knowledge for improving drawing performance such as a game.
Lookup Ex: library vs. global vs. local
4. Infos about module Docstring markup? What is the standard for Classic
vs. Phoenix

Use reStructuredText. There is a bit in the wiki in the Phoenix section
about this.

[Werner]

On 18/01/2014 23:49, Metallicow wrote:
...

Post by Metallicow
I'm not the best documentarist, and have basically replicated a lot of
Andrea's
Docstring style(rst or epydoc). Is this right and up to par with the
docs generation
for classic and phoenix? Best Links for easy learning or copying of
wxPy markup style?

In Phoenix Andrea switched to using rst/Sphinx from epydoc which he at
some point used his agw stuff.

The guidelines are here:
http://wxpython.org/Phoenix/docs/html/DocstringsGuidelines.html

Werner

[Metallicow]

Ok, so I checked out the various DC's and it seems BufferedPaintDC works
fine for ShapedBitmapButtons purposes.
Had some crashy issues with GraphicsContext, so not sure if I am trying to
use it correctly; also I dont think it should be required for this
as the input image should handle all graphical issues... maybe this would
differ a bit with SVG when I get all that stuff figured out...
Just PNG/GIF should be fine for starters. Users can programmatic re/scaling
of the images should handle the rest if needing slight sizing tweaks.

I think I have worked out all the bugs with the various sizers
types/situations, so, ok there ATM...
Tho still need to tweak the dc stuff if using a dc gradient or whatever.
Major fubar havok ensues followed by imminent CTD when scruntching the
frame to zilch or less than dc.GetAsBitmap if image size is bigger.
Gradient scaling issue...
If I can't figure this one out with a decent fix, then dc background
support may have to be put on the side burner for a while...

Also read up on phoenix rst a bit. I think I have a general understanding
of it now... I need to test render it tho first to make sure...

More questions:
1. What would be the easiest way for me to generate the html docs for just
my few modules with the sphinx generator, so as to test what they will look
like. I didn't find any documentation on the phoenix page.
2. I read a bit about mixins on someones site... rumor is...
vs.
Does Inheritance Position/Order really matter? If so which one is correct?

3. When binding events in a mixin, does lambda provide any extra benefits?
If so How/Why?
SmartHighlighting Ex: if extra functionality is desired without overwriting
the default handler. Im guessing event.Skip() should always be wisely
placed somewhere in the event(beginning or end).

4. Is it prefered that short sample apps be in a library resource at the
end of the file? Or should they explicitly be seperate?

testApp

Attached Progress pics. Getting closer...

[Robin Dunn]

Post by Metallicow
1. What would be the easiest way for me to generate the html docs for
just my few modules with the sphinx generator, so as to test what they
will look like. I didn't find any documentation on the phoenix page.

You could use the Sphinx tools directly for initial tests. You will also
want to have the Phoenix build tool build the docs before you you are
finished, as it does some post processing of the generated text files
before running it all through Sphinx. So you will want to make sure
that those tweaks are done correctly for your documentation. Once you
have done the first pass of generating all of the docs then subsequent
updates do not take too long to process so it isn't too bad to just run
the build.py commands for your intermediate testing too.

Post by Metallicow
2. I read a bit about mixins on someones site... rumor is...
vs.
Does Inheritance Position/Order really matter?

Yes. It determines the MRO (Method Resolution Order) which is what
determines which instance of a method it uses when you call it, and
which is the next one called if the method uses super().

Post by Metallicow
If so which one is correct?

It depends.

Post by Metallicow
3. When binding events in a mixin, does lambda provide any extra benefits?

No, not any beyond using a lambda in a non-mixin class hierarchy.

Post by Metallicow
SmartHighlighting Ex: if extra functionality is desired without
overwriting the default handler. Im guessing event.Skip() should always
be wisely placed somewhere in the event(beginning or end).

It doesn't really matter where it is called. It just sets a flag that
is checked after the event handler returns.

Post by Metallicow
4. Is it prefered that short sample apps be in a library resource at the
end of the file? Or should they explicitly be seperate?

Yes, all of the above. I think it is nice to have a simple "smoke
test"[1] in the module itself that just proves that it works and not
much (if any) more. Then there should be a module in the demo that
shows a real-world example of the widget in as close to a real-world
context as possible, and which also includes overview text and detailed
comments that a newbie can use to learn about how to use the widget.
Finally, there should be a module added to unittests that fully
exercises as much of the code as possible and which includes
cross-checking and asserts to verify things like intermediate results,
that events were sent/received, that expected failures happened, etc.

[1] This term comes from the hardware world where the test consists of
applying power to the device being tested and if there is no smoke,
sparks, melting components or other signs of fundamental failure then
the test passes.