wxPython Phoenix Demo Discussion & Ideas

[Metallicow]

wxPython Phoenix Demo Discussion & Ideas
This errm... thread/mail thingy serves as a discussion place for the new
wxPython "Phoenix" demo
currently as of June-2013 it is still WIPz

Current Initial Fork:
=====================
Metallicow's GitHub demo WIPz branch
https://github.com/Metallicow/Phoenix/tree/demo

Metallicow's Github Library Fixes branch
https://github.com/Metallicow/Phoenix/tree/library-branch
=====================

First of all, I would like to thank robin for making wxPython
available to everyone.
Thanks.

Now Onward...
Idea1:
I would like to see more than just one demo...

Topic1: Creating New "Official" wxPython Demo
Robin has brought up the idea of creating a new "Official" Demo for project
Phoenix...
- This is great. New Learnings/New Ideas from the lead developer.

Topic2: Porting existing wxPython Demo
I have started a port of the wx2.9.4.0 Demo which will serve as a base demo
updated.
- Update the old demo to phoenix. Clean up whole demo/docs. Add new/missing
class demos. Overall provide an example for everything(all options) in
demos. Then use as a base for new stuff.
- Users can also help Robin do this in the meantime, until everything gets
worked out "Officially". Ex: attach small demo here or create fork.

Topic3: Creation of a New wxPython - "Users" Demo
Discussion of a Custom wxPython Demo created by wxPython users for wxPython
users. Whatever you what(within reason) under your Ex:username/catagory.
- May include simple or custom example demos showing basic examples or
showcasing users custom widget creation talents.
Ex: I have ported Eddies's RoundButton to Phoenix and would like it
included in the standard library... since it is licensed under wxPython
license this is OK.
Ex: Port GradientOverlayPanel to Phoenix/Demo. This is one of my custom
widgets.
-- users should...create source for the standard wx lib dist and also a
create demo showcasing it(actually working).
-Submitted Demos can also be catagorized as "Just for fun" widgets:
Ex:bubble demo, small(ish) tetris/mine game demos, snakey goes wild
animation demo.
- Create a small code base for templates.
- Improve the Demo Stc Code Editor to be as advanced, but user friendly as
possible.
- Make the demo portable. And by portable I mean works with MSWin, Linux,
Mac, etc... natively.

Please state Topic subject# when replying.
Ex:
"""
RE: Topic1:
... sounds good to me!
"""

or

"""
RE: Topic3:
... I'd like this included in the standard lib...
"""

[Metallicow]

Topic2: WIPz Images of New Demos

Loading Image...
Loading Image...
NotificationMessage doesn't really need a preview.

image previews of some missing demos.

[Metallicow]

@Robin: Topic2 - Is there any specific reason for having "bitmaps" and
"bmp_source" directories? Can these two directories be merged into
"images", organized better as to image catagory and upload my script that
creates the whole images.py file in one go?

Also there is still a empty demo/dllwidget directory in the src builds. Saw
your commit to get rid of it.

[Robin Dunn]

X-Received: by 10.50.40.65 with SMTP id v1mr234825igk.4.1371235770534;
Fri, 14 Jun 2013 11:49:30 -0700 (PDT)
X-BeenThere: wxpython-***@googlegroups.com
Received: by 10.50.22.10 with SMTP id z10ls444069ige.19.canary; Fri, 14 Jun
2013 11:49:30 -0700 (PDT)
X-Received: by 10.67.22.2 with SMTP id ho2mr504416pad.21.1371235770315;
Fri, 14 Jun 2013 11:49:30 -0700 (PDT)
Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179])
by gmr-mx.google.com with ESMTPS id xb6si543238pab.0.2013.06.14.11.49.30
for <wxPython-***@googlegroups.com>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 14 Jun 2013 11:49:30 -0700 (PDT)
Received-SPF: neutral (google.com: 209.85.192.179 is neither permitted nor denied by best guess record for domain of ***@alldunn.com) client-ip=209.85.192.179;
Received: by mail-pd0-f179.google.com with SMTP id q10so841964pdj.38
for <wxPython-***@googlegroups.com>; Fri, 14 Jun 2013 11:49:30 -0700 (PDT)
X-Received: by 10.66.150.106 with SMTP id uh10mr3836346pab.118.1371235770125;
Fri, 14 Jun 2013 11:49:30 -0700 (PDT)
Received: from havok.alldunn2.com (c-98-246-90-205.hsd1.wa.comcast.net. [98.246.90.205])
by mx.google.com with ESMTPSA id xn5sm3454848pab.0.2013.06.14.11.49.29
for <wxPython-***@googlegroups.com>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Fri, 14 Jun 2013 11:49:29 -0700 (PDT)
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
In-Reply-To: <302d55fa-49eb-4d8f-87fc-***@googlegroups.com>
X-Gm-Message-State: ALoCoQlRGYe5iRePKcGrUHuOKe3Ff1hZj1smW6R34akJgxtoSmjckKXzYmKMtD4+GDhYS8NjDwKl
X-Original-Sender: ***@alldunn.com
X-Original-Authentication-Results: gmr-mx.google.com; spf=neutral
(google.com: 209.85.192.179 is neither permitted nor denied by best guess
record for domain of ***@alldunn.com) smtp.mail=***@alldunn.com
Precedence: list
Mailing-list: list wxPython-***@googlegroups.com; contact wxPython-dev+***@googlegroups.com
List-ID: <wxPython-dev.googlegroups.com>
X-Google-Group-Id: 472392765833
List-Post: <http://groups.google.com/group/wxPython-dev/post>, <mailto:wxPython-***@googlegroups.com>
List-Help: <http://groups.google.com/support/>, <mailto:wxPython-dev+***@googlegroups.com>
List-Archive: <http://groups.google.com/group/wxPython-dev>
Sender: wxPython-***@googlegroups.com
List-Subscribe: <http://groups.google.com/group/wxPython-dev/subscribe>, <mailto:wxPython-dev+***@googlegroups.com>
List-Unsubscribe: <http://groups.google.com/group/wxPython-dev/subscribe>, <mailto:googlegroups-manage+472392765833+***@googlegroups.com>
Archived-At: <http://permalink.gmane.org/gmane.comp.python.wxpython.devel/5455>

Post by Metallicow
@Robin: Topic2 - Is there any specific reason for having "bitmaps" and
"bmp_source" directories? Can these two directories be merged into
"images", organized better as to image catagory and upload my script
that creates the whole images.py file in one go?

The bmp_source folder is for those that are encoded into images.py, and
the bitmaps folder is for those images that are left as normal image
files and loaded at runtime.

Post by Metallicow
Also there is still a empty demo/dllwidget directory in the src builds.
Saw your commit to get rid of it.

Thanks, it may be due to how the buildbots update their source trees.
I'll check in to that. Is it still present in your git workspace?

[Metallicow]

No, not in my git. It came out of the nightly snapshot builds downloads.
src download.
http://wxpython.org/Phoenix/snapshot-builds/

I usually check the SVN changelog for what changes might affect updating my
widgets in my apps before torture testing the new stuff.
http://wx.ibaku.net/changelog/?t=2

Then download build if interested in droping the new copy into reg 2.8 /
2.9.4 / 2.9.5 circulation site packages and switch wx.pth/phoenix.pth files
with a small wxApp.
I just noticed it in the src download and It was empty, that's all, just a
report.

[Dev Player]

One coder's request for considerations for the wxpydemo:

One primary function of Phoenix, if I remember correctly, is to reduce
support workload on Robin and fellows One way to do this is to reduce
requests for help in forums. So the demo is a major solution to reducing
wxPython coders confusion on the wx API and tools and reduction of bug
injection via bad coding strategies. The demos code should reflect this
philosophy, meaning "Simple is Better". I'd say the demo should be less of
"what you can do" and more of a "here is how to do it".

I'd hope the organization of the sub-demos are:
1. native os widgets (explains what you can and can't do with them); ie
native widgets do not have certain functionality
People forget that the OS has widgets and they are expected to work a
certain way (ie not buggy) and wxPython extends some widgets.
2. non-native os widgets common in wxwidgets and wxPython/Pheonix; these
widgets are likely to be updated only on new version releases.
3. 3rd party widgets in it's own demo category; allows coders see if there
are updated versions (often maintained by the widget dev)
4. Let the demo allow for other coders to easily submit additional
sub-demos (obviously via some approval process) This can help reduce work
load because you often see people how to use a widget in a way not
currently seen in the demo. After seeing the same question of how to do
so-and-so so many times in the forums; sometimes just adding a sub-demo can
solve that recurrence.
5. Crazy idea; It would be nice if in my install of wxPyhon/Pheonix demo; i
could attach URLs to howtos to a particular subdemo; such as mailing list
forum discussions on the particular widget/solution. Then I can keep track
of known bugs; workarounds; alteratives etc. without having to install a
fresh version of Phoenix for every bug.

One way to reduce forum posts is to offer source code that lets coders see
how to change their code from the "OLD" way to the "NEW" way; Think how the
original events were bound wx.EVT_SOMEEVENT(params) changed to
self.Bind(wx.EVT_SOMEEVENT, callback, params)

Post by Metallicow
No, not in my git. It came out of the nightly snapshot builds downloads.
src download.
http://wxpython.org/Phoenix/snapshot-builds/
I usually check the SVN changelog for what changes might affect updating
my widgets in my apps before torture testing the new stuff.
http://wx.ibaku.net/changelog/?t=2
Then download build if interested in droping the new copy into reg 2.8 /
2.9.4 / 2.9.5 circulation site packages and switch wx.pth/phoenix.pth files
with a small wxApp.
I just noticed it in the src download and It was empty, that's all, just a
report.
--
You received this message because you are subscribed to the Google Groups
"wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.

[Metallicow]

Post by Dev Player
One primary function of Phoenix, if I remember correctly, is to reduce
support workload on Robin and fellows One way to do this is to reduce
requests for help in forums. So the demo is a major solution to reducing
wxPython coders confusion on the wx API and tools and reduction of bug
injection via bad coding strategies. The demos code should reflect this
philosophy, meaning "Simple is Better". I'd say the demo should be less of
"what you can do" and more of a "here is how to do it".
1. native os widgets (explains what you can and can't do with them); ie
native widgets do not have certain functionality
People forget that the OS has widgets and they are expected to work a
certain way (ie not buggy) and wxPython extends some widgets.
2. non-native os widgets common in wxwidgets and wxPython/Pheonix; these
widgets are likely to be updated only on new version releases.
3. 3rd party widgets in it's own demo category; allows coders see if there
are updated versions (often maintained by the widget dev)
4. Let the demo allow for other coders to easily submit additional
sub-demos (obviously via some approval process) This can help reduce work
load because you often see people how to use a widget in a way not
currently seen in the demo. After seeing the same question of how to do
so-and-so so many times in the forums; sometimes just adding a sub-demo can
solve that recurrence.
5. Crazy idea; It would be nice if in my install of wxPyhon/Pheonix demo;
i could attach URLs to howtos to a particular subdemo; such as mailing list
forum discussions on the particular widget/solution. Then I can keep track
of known bugs; workarounds; alteratives etc. without having to install a
fresh version of Phoenix for every bug.
One way to reduce forum posts is to offer source code that lets coders see
how to change their code from the "OLD" way to the "NEW" way; Think how the
original events were bound wx.EVT_SOMEEVENT(params) changed to
self.Bind(wx.EVT_SOMEEVENT, callback, params)

Well, here is a WIPz image.
Loading Image...

1. A demo that parses the demos for info on these things would work, or a
demo that is simple a table stating such info, or a demo that downloads a
phoenix special doc page from the web would work for this.
2. See Reply #1
3. The 3rd-party packages integration has been fixed. Andrea code had a few
mishaps and didn't quite work except for the first package imported. All
__demo__ packages will have an __init__ file in them to make them proper
packages from now on. A clone_me package will be the default with
install(sheep icon)
4. I am thinking of making a Github page for such things, which
demoDevelopers/Robin can then review packages as either such similar ideas:
as pull requests, or a user can submit a download link for package via
issues/requests, or just submit a package download link at a particular
mailing list thread.
Part of which will be the user submitting *said* package to run/save/upload
submittion file with "Official" modeline specs. This will be a special
feature of the demo editor that will check for obvious cruft, such as
trimming trailing whitespace, general style, and cleanup, via run.py
modeline so as to save devs the headache of cleaning the cruft out manually.
5. Crazy Ideas are welcome also... Tho, your particular suggestion, I
wouldn't call over the top. A simple pickle or wx.FileConfig would work
fine for this idea. It might be contained to work only a 'Portable' version
of the demo tho...

#-------------#

As far as the image posted shows a few things working...
1. 3rd Party packages are working. Not just duplicates of AGW as was the
case bug with classic.
Ex: User's Widgets, Metallicows's meh, wxPython Wiki
All packages have an __init__.py and a __demo__.py. The package
pyEmbeddedImage can be easily changed in __demo__.py with a small utility I
will write.
Basically all a user will have to do from initial install is to copy the
clone_me dir in the demo directory to a new directory name, and edit from
there. All handling of loading 3rd party packages installed(in the demo
dir) could be handled better(possibly) in main.py
Some various demos I have converted and updated from the wxPython Wiki
shows this can be easily done also in the preview image.

2. Top 5-10 officialy supported demo app(will work with run.py else work
standalone), which will be voted on per catagory. Complete simple show
apps(of which each will probably have it's own source page as to keep
things small/simple in the demo).
Ex: TrailBlazer App
Trim Trailing Whitespace App. So far...

Post by Dev Player
rstripedText = '\n'.join([line.rstrip() for line in origText.split('\n')])

is the current fastest benchmark with STC.
timeit

Post by Dev Player
"""
Eliminates/Removes all trailing/extra whitespace characters
from the end of each line in the whole document.
:param string `text`: Optionally pass some text to be returned.
|=timeit Results===================================
| timeitThisNumberTimes = 1000000
| Test results are measured in seconds as a float.
|
| def OnRemoveTrailingWhitespace
|Python 2.7.5
| repeat: [17.651515684607887, 17.508207714807128, 17.529062020949475]
|Python 3.3.2
| repeat: [15.44168775780605, 15.506561005974845, 15.525707034824123]
|==================================================
"""

Ex: Catagory: Graphical/Games Apps. wxScreensaver / wxPytrix,
SnakeyGoesWild. Classic Tetris/Snake grid-based remakes respectively. We
need these to show users how much we can stress wxPython in
real-time/benchmark/graphically. Apps code will follow timeit/other
benchmarks rules for teaching performance handling with wxPython.


Comments, Ideas, More Ideas, Complaints are welcome here.

Thanks

[Dev Player]

Good work and ideas Metallicow.

I didn't reread the whole thread so I hope this wasn't already talked
about. On points 3 and 4 about third party; 3rd party plugins might better
be installed deliberately from a different source point. Primarily to
protect the demo from 3rd party plugins that might come under fire from 4th
party copyright infringement lawyers.

[Metallicow]

Post by Dev Player
Good work and ideas Metallicow.
I didn't reread the whole thread so I hope this wasn't already talked
about. On points 3 and 4 about third party; 3rd party plugins might better
be installed deliberately from a different source point. Primarily to
protect the demo from 3rd party plugins that might come under fire from 4th
party copyright infringement lawyers.

I'm assuming and checking for "wxPython/wxWidgets License" for anything
involved in the updated Demo Version and "Official" version.
There *might* be an issue with some stuff in the wxPyWiki package
stuff(Seperate package)(? @ Robin), but since those posters contributed to
a "public knowledge base" especially designed for "wxPython", then why
wouldn't the license be wxPython???
The basic purpose here is for learning and teaching.

Ex:
I can understand whatever that "one" company(ooooooooooopps got sued) using
"FREE" nyanCat in a product without paying the author for it, based on the
fact that they didn't make commercial use of it, but they still owned the
art.
...but 'they(The Company)' did, without permission or payment also. This
type of behavior is not allowed, even by a company with $ and prestige.
PopTort(c)Cat got paid for his unlawful use by PopTort(c)Lawyers.

If any lawyer ever sues any product developer for unrightful use of
wxPython Licensed Stuff, then the blame usually ultimately lands on the
developer.
Usually this ends up as...
Someone claiming to have authored a work that they say is their own and is
not so,
Not complying with keeping the copyright within the code/honoring the
copyright,
Or having the "Same" name for a product "Trademark/Name" in the same
"Catagory", which leads to product confusion,
Not sticking to license terms,
etc...
which is quite understandable in most circumstances. Common Sense Rules
Here, Normally.

Give Credit where it is due, even if in a mile long credits.txt for example.

Everything in the "wxPython Demos", will be approved/overlooked by Robin or
me/others so to meet these universally usable-by-everyone standards.
If a problem is found, then it will be promptly removed and handled in a
sane manner.

[RANT]
After all, I believe it is time to offer FREE education in America. We all
pay Taxs of some sort/Property Tax, so why not...?
F****** communist's educate their slaves for free;
Half-Ass countries work their populous for education;
The best countries people educate their government.
Anarchist's have a place somewhere inbetween all this far and inbetween.
See what it gets the general public worldwide. A better system to work
with... without bullshit.
Enough with politics.
{/RANT}

Anyway, on with suggestions for "LEGALLY approved Demo stuff". Consider
contributing some educational material folks!
Thanks all.

Attached a pointy Example Demo Pic. Everything written here and attached
(c) me of course since I didnt provide a watermark, which is standard in
the printing industry. geez.

[Metallicow]

@Robin/AG

# * Problems with flickering related to ERASE_BACKGROUND
# and the splitters. Might be a problem with this 2.5 beta...?
# UPDATE: can't see on 2.5.2 GTK - maybe just a faster machine :)
# * Demo Code menu?
# * Annoying switching between tabs and resulting flicker
# how to replace a page in the notebook without deleting/adding?
# Where is SetPage!? tried freeze...tried reparent of dummy panel....
# AG: It looks like this issue is fixed by Freeze()ing and Thaw()ing
the
# main frame and not the notebook
# * UI design more professional (is the new version more professional?)
# * Update main overview

I assume the FIXME list has been fixed and this can be removed from
main.py.

I don't get any flickering with the splitters. Assuming the Aui Pane
Splitters... Am I right...?
Assuming the "Demo Code menu" is the implemented Demo menu...? Am I
right...?
And looks like the freeze, thaw issue was solved.

About updating the overview... What Ideas did you have for that?

[Robin Dunn]

Post by Metallicow
@Robin/AG
# * Problems with flickering related to ERASE_BACKGROUND
# and the splitters. Might be a problem with this 2.5 beta...?
# UPDATE: can't see on 2.5.2 GTK - maybe just a faster machine :)
# * Demo Code menu?
# * Annoying switching between tabs and resulting flicker
# how to replace a page in the notebook without deleting/adding?
# Where is SetPage!? tried freeze...tried reparent of dummy panel....
# AG: It looks like this issue is fixed by Freeze()ing and Thaw()ing the
# main frame and not the notebook
# * UI design more professional (is the new version more professional?)
# * Update main overview
I assume the FIXME list has been fixed and this can be removed from
main.py.

Probably.

Post by Metallicow
About updating the overview... What Ideas did you have for that?

I don't remember. (I'm not even sure I wrote that line)

[Metallicow]

Post by Robin Dunn

Post by Metallicow
I assume the FIXME list has been fixed and this can be removed from
main.py.

Probably.

I went ahead and snipped it in the branch as a commit. Everything seems to
work for me anyway, and besides they seem to be refering to/about older
versions. I have just been updating the WIPz.txt with bugs and stuff(not in
the main.py).

One other thing to discuss would be the downloading of the new docs and how
to implement allow saving them.
Is the overview tab supposed to become a HTML viewer basically...? and
snake the info on the fly or attempt to update everything on user
approval...?
What Url should be the base URL? Would fetching tutorials from the wiki be
a good idea...(Not sure.. seems to get alot of spam)?

Anywho...PushREQz is waiting on your review. Here is a screenie running on
Python 3.3.2 from the demo and library-branch commits.
Loading Image...

[Metallicow]

Ok, some progress pics on the Old framework. see attachments.

... yep still beating the old bird into working right and fixing bugs and
oversights.

@Robin: you may want to pay attention to how I did this if you might want
the new framework to possibly one day still run a oldFramework file.

Ok. the method to this madness is...
There is a problem that the demo caught an exception.
At this point, we don't know if it is a ligit error or whether it is a old
demo framework oversight.
so, in the except block what we will do I'm thinking is this...

use py_compile if an error occured in the normal procedure and if it
actually compiled, then show a panel with some message info, that the demo
may not be formatted as to what the old demo framework is expecting,
but that py_compile found no syntax errors.
The button would then attempt to run the app __file__ path normally with
subprocess.Popen.

I noted that by doing this the app may not be running on the correct
version of wxPython. This would be because you may have multiple versions
installed and the actual app.py doesn't have a wxversion.select line to
tell it what to use, so it defaults to whatever wx.pth is

As in other mail/threads, robin has discussed a bit of what he would like
the new framework for the new demo to become, and sounds promising as a
advanced framework, that will hopefully fill all educational needs for
noobs and advanced users alike.
One of the points brought up is the multiple examples for a widget idea
which can be seen in one of the attached screenies.
Basically, I see there be a need for at least 3 types of demos for each
"thing".
1. A *minimal* demo. This shows the widget at a bare minimum of code to
make it work. classes probably won't be found in these demos as they are
intended to be short and sweet.
2. An *extended* demo. This is the minimal demo done properly with
everything classed out so code is easily copyable. The extended demos will
show how all the methods in action are actually working.
3. A *showcase* demo. This would be a real-world example/sample
app/skeleton/etc.. of using the widget that is professional, but serves as
a boilerplate template code. No sillyness in the code for this one. Ex: The
current AGW AUI framework demo(the big demo) would serve fine for a
showcase demo.

As always, I keep striving to make the demos as educational and fun as
possible, so that children/noobs have as little questions as possible, yet
without losing their interest.
In the world of advertising, you need to capture the marks
attention/interest in the first 10 seconds, then strive to keep that
interest/focus.

This is my first step toward making the transition to the new
framework(whenever robin/everyone decide on a keeper structure) as now I
can work with at least both types of demo structures easily without failure.

[Metallicow]

Well, I have figured out a working walking folder structure with the
framework and some __demo__.py and "__magic__". See Attched Pic.
magic attributes integrated so far...:
__doc__
__wxPyDemoPanel__ = ''TestPanelStr"
__wxPyOnlineDocs__ = "urlStr"

I had to start classing everything out and refactor a bit of stuff to do
this correctly, but it worked out well.
The only minor thing I broke that needs some attention is the demos search
filter, which will be a bit of a trick if I where to lay a guess.

My error_handling package ExceptionHookDialog and ExceptionStrSTC works
with the manual lauched files also.
After a few more tweaks and a switchable dev def so I can refactor all the
demos right inside the demo in DEVMODE this proof of concept will have
become a full reality.
Most all error are handled at the moment but there is still a bit to do
overall in refactoring.

This iteration will actually handle all wxPython demos as I am working on
injecting certain stuff such as wxversion into the manually run files also
before run so multiple wxversion and xwx(cross-compatable) writing of code
will be easily debuggable in app.

I also added a context help button in the statusbar with custom help
popups, so that no matter where the user is, they can get some info on
whatever they are interested in.

Woot. happy dance.
This is just the beginning tho... The iteration where everything is
destroyed and rebuilt better just like the phoenix. Hopefully soon I will
have a fully working model.
Then after this I will probably look into the EventsInStyle Docs app tab
integration concept in a AUINotebook... maybe.

RE: __TestStructure__. Apparently test sheep fly in a V formation also.
LOL. Maybe I should make a piggy icon, so when pigs fly... :)