demo.py is ready for use and extension
54 views
Skip to first unread message
Edward K. Ream
Feb 8, 2017, 7:17:15 AM2/8/17
to leo-e...@googlegroups.com
Revs fdb0e9c and 2b2fffea complete work on the essentials of the demo.py plugin. The highlights:
1. scripts.leo now contains a copy of the test script I used during development:
@button test-demo @key=Ctrl-9
Today's major innovation is that the script uses the Ctrl-9 key binding to start and continue the demo. This is the only key binding appropriated by the demo! Not having to switch keys eliminates a big annoyance.
This script is really a template for all demos. As I write this, I see that Leo should have a demo;; abbreviation that creates this template automatically. Coming next.
The @button node creates a custom MyDemo class that overrides the do-nothing Demo.setup_script method so that it calls demo.delete_widgets. This shows the power of subclassing the Demo class.
2. After several false starts, the graphics classes (Callout, Label, and Title) in demo.py now can use all helpers in the Demo class without using any mixin classes. This involved moving set_position and its helpers out of the Label class and back into the Demo class.
The inheritance of graphics classes is now clean. That is, the Callout and Title classes derive only from the base Label class. This is extremely important. Using a mixin class prevented easy subclassing.
Now, all graphics classes can be QtWidget's, of whatever kind. For example, Callout instances are QLabels because Callout is a subclass of Label, which is a QLabel. pyzo shows that having many base classes can work, but demo.py's present scheme is the simplest thing that could possibly work.
Summary
The overall framework for demo.py is now stable.
A new demo;; abbreviation will create a template for top-level demo scripts.
Your own demo scripts can easily define new graphics classes, using the Label, Callout and Title classes as a model.
I plan to add Image, Arrow, RedArrow and BlueArrow graphics classes soon. These will provide further examples of how to create your own graphics classes.
Do not use image-related methods of the Demo class. They will go away when the Image class is in place.
All questions and comments welcome.
Edward
1. scripts.leo now contains a copy of the test script I used during development:
@button test-demo @key=Ctrl-9
Today's major innovation is that the script uses the Ctrl-9 key binding to start and continue the demo. This is the only key binding appropriated by the demo! Not having to switch keys eliminates a big annoyance.
This script is really a template for all demos. As I write this, I see that Leo should have a demo;; abbreviation that creates this template automatically. Coming next.
The @button node creates a custom MyDemo class that overrides the do-nothing Demo.setup_script method so that it calls demo.delete_widgets. This shows the power of subclassing the Demo class.
2. After several false starts, the graphics classes (Callout, Label, and Title) in demo.py now can use all helpers in the Demo class without using any mixin classes. This involved moving set_position and its helpers out of the Label class and back into the Demo class.
The inheritance of graphics classes is now clean. That is, the Callout and Title classes derive only from the base Label class. This is extremely important. Using a mixin class prevented easy subclassing.
Now, all graphics classes can be QtWidget's, of whatever kind. For example, Callout instances are QLabels because Callout is a subclass of Label, which is a QLabel. pyzo shows that having many base classes can work, but demo.py's present scheme is the simplest thing that could possibly work.
Summary
The overall framework for demo.py is now stable.
A new demo;; abbreviation will create a template for top-level demo scripts.
Your own demo scripts can easily define new graphics classes, using the Label, Callout and Title classes as a model.
I plan to add Image, Arrow, RedArrow and BlueArrow graphics classes soon. These will provide further examples of how to create your own graphics classes.
Do not use image-related methods of the Demo class. They will go away when the Image class is in place.
All questions and comments welcome.
Edward
Edward K. Ream
Feb 8, 2017, 12:37:57 PM2/8/17
to leo-e...@googlegroups.com
On Wednesday, February 8, 2017 at 6:17:15 AM UTC-6, Edward K. Ream wrote:
Rev 79d78162 contains this morning's work. There are many improvements to demo.py and the top-level demo script, copied to scripts.leo. As promised, the overall framework is stable.
Here are the highlights, from the checkin log, which mentions a few more minor details.
New Image and Text classes
Just as promised. The Demo class contains very little widget-related code.
Improved the Demo class
- Added the demo.module ivar, bound to the leo.plugins.demo module.
This allows subclasses of Demo to access the various graphics classes defined in demo.py.
- Added demo.retain(w) and demo.delete_retained_widgets().
This allows more control over when widgets disappear.
As I write this, I see that demo.delete_one_widget would allow complete control.
- demo.parse_script_string removes blank or comment lines.
This allows users to remove slides simply by commenting out all their lines.
Improved the top-level example script
- There was never a need for wrappers. Now they are gone.
- The MyDemo.setup does all the binding by overriding various base-class methods.
Edward
Rev 79d78162 contains this morning's work. There are many improvements to demo.py and the top-level demo script, copied to scripts.leo. As promised, the overall framework is stable.
Here are the highlights, from the checkin log, which mentions a few more minor details.
New Image and Text classes
Just as promised. The Demo class contains very little widget-related code.
Improved the Demo class
- Added the demo.module ivar, bound to the leo.plugins.demo module.
This allows subclasses of Demo to access the various graphics classes defined in demo.py.
- Added demo.retain(w) and demo.delete_retained_widgets().
This allows more control over when widgets disappear.
As I write this, I see that demo.delete_one_widget would allow complete control.
- demo.parse_script_string removes blank or comment lines.
This allows users to remove slides simply by commenting out all their lines.
Improved the top-level example script
- There was never a need for wrappers. Now they are gone.
- The MyDemo.setup does all the binding by overriding various base-class methods.
Edward
Edward K. Ream
Feb 8, 2017, 1:19:40 PM2/8/17
to leo-editor
On Wednesday, February 8, 2017 at 11:37:57 AM UTC-6, Edward K. Ream wrote:
> demo.delete_one_widget would allow complete control [over widget lifetimes].
Done at eddc6a6. Here is an example script, which illustrates using demo.user_dict to communicate between different demo scripts:
w = image('C:/leo.repo/leo-editor/leo/Icons/SplashScreen.ico')
demo.retain(w)
demo.user_dict ['splash'] = w
...
demo.delete_one_widget(demo.user_dict.get('splash'))
The to-do list for the demo plugins contains just these items:
- Update the docs.
- Experiment with running demo scripts from Leo's help menu.
- Deprecate the screencast plugin. It's inferior in all respects to demo.py.
Please do play with demo.py and report any problems.
I wont' be adding any Arrow classes just now. Maybe when I have actual need for same. In fact, there is no great need for any more graphics classes. Individual demos can easily support new kinds of classes.
Edward
> demo.delete_one_widget would allow complete control [over widget lifetimes].
Done at eddc6a6. Here is an example script, which illustrates using demo.user_dict to communicate between different demo scripts:
w = image('C:/leo.repo/leo-editor/leo/Icons/SplashScreen.ico')
demo.retain(w)
demo.user_dict ['splash'] = w
...
demo.delete_one_widget(demo.user_dict.get('splash'))
The to-do list for the demo plugins contains just these items:
- Update the docs.
- Experiment with running demo scripts from Leo's help menu.
- Deprecate the screencast plugin. It's inferior in all respects to demo.py.
Please do play with demo.py and report any problems.
I wont' be adding any Arrow classes just now. Maybe when I have actual need for same. In fact, there is no great need for any more graphics classes. Individual demos can easily support new kinds of classes.
Edward
Edward K. Ream
Feb 9, 2017, 9:16:18 AM2/9/17
to leo-editor
On Wednesday, February 8, 2017 at 6:17:15 AM UTC-6, Edward K. Ream wrote:
Revs fdb0e9c and 2b2fffea complete work on the essentials of the demo.py plugin.
I spent all day polishing the plugin. Now it's time to start using it!
Rev cf424c5 completes the demo's docs, demo.md, for now. This may jiggle a bit, but the big picture will not change.
Edward
Edward K. Ream
Feb 10, 2017, 7:31:49 AM2/10/17
to leo-editor
On Thursday, February 9, 2017 at 8:16:18 AM UTC-6, Edward K. Ream wrote:
> Rev cf424c5 completes the demo's docs, demo.md, for now. This may jiggle a bit, but the big picture will not change.
> Rev cf424c5 completes the demo's docs, demo.md, for now. This may jiggle a bit, but the big picture will not change.
I spent yesterday developing just a few "real" slides. This helped debug demo.py. The documentation in demo.md reflects the latest work.
I am confident that little will change in demo.py:
1. There is a clear separation between the Demo class and the graphics classes. The Demo class runs the demo, provides a few helper methods for demo scripts, and a few utility methods for graphics classes. That all.
2. Top-level scripts can easily provide new graphics classes by overriding graphics classes in demo.py. For example, a new ShowKey class would override Label to highlight a keystroke in a different style and location. Just a few lines of code.
In short, demos won't need more help from the Demo class.
Edward
I am confident that little will change in demo.py:
1. There is a clear separation between the Demo class and the graphics classes. The Demo class runs the demo, provides a few helper methods for demo scripts, and a few utility methods for graphics classes. That all.
2. Top-level scripts can easily provide new graphics classes by overriding graphics classes in demo.py. For example, a new ShowKey class would override Label to highlight a keystroke in a different style and location. Just a few lines of code.
In short, demos won't need more help from the Demo class.
Edward
Reply all
Reply to author
Forward
0 new messages