Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP]: Use demo.py to implement tutorials #710

Closed
wants to merge 8 commits into from

Conversation

shoeb-github
Copy link
Contributor

xref: #696

This is an implementation of tutor.py using demo.py.

The approach is to extend the DemoPath class to also parse file extensions other than .py like .rst, .htm. However, this does not look clean. It is probably better to do this unification as outlined in issue #24 of ETS examples.

Things that don't work:

  • no support for .desc, .swf files.

To do:

  • Add next, previous buttons in the UI to navigate the tutorial directory structure.

@corranwebster
Copy link
Contributor

Rather than subclassing, how much of this functionality can be merged into the demo.py classes? In other words, can we enhance the demos with tutor functionality without breaking them?

Or alternatively, how much functionality can we drop from the tutor.py code?

Also, I don't think we have any actual tutorials using videos or similar, so we can drop support for a lot of the file formats without losing anything.

# Check if there is a corresponding .rst (restructured text) file:
dir, base_name = os.path.split(path)
rst = os.path.join(dir, os.path.splitext(base_name)[0] + '.rst')
return self._parse_htm_file(path, name)
Copy link
Contributor

@corranwebster corranwebster Jan 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just does infinite recursion? (it looks like the original version did as well)

I think we can just remove this.

No htm vs. html


def _path_changed(self, path):
""" Creates the appropriate section based on the value of the path.
def _parse_avi_file(self, path, name):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be safely removed.


def _add_mov_item(self, path):
""" Creates a description item for a QuickTime movie file.
def _parse_mov_file(self, path, name):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed


def _add_jpg_item(self, path):
""" Creates a description item for a JPEG image file.
def _parse_mp3_file(self, path, name):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed.

name, ext = os.path.splitext(name)

# If we have a handler for the file type, invoke it:
method = getattr(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to do a bit better of a refactor, replacing "magic method names" with a dictionary mapping file extensions to factory functions would likely make the code much cleaner, and might allow something like having a tutorial be the same base class as a demo but with a slightly different set of registered file handlers, assuming you can't get the codebases completely aligned.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The factory functions could be class methods on the appropriate classes being created.

def _create_html_item(self, **traits):
""" Creates a platform specific html item and adds it to the list of
descriptions.
def _parse_wmv_file(self, path, name):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can safely be removed.

@shoeb-github
Copy link
Contributor Author

Rather than subclassing, how much of this functionality can be merged into the demo.py classes? In other words, can we enhance the demos with tutor functionality without breaking them?

Or alternatively, how much functionality can we drop from the tutor.py code?

Also, I don't think we have any actual tutorials using videos or similar, so we can drop support for a lot of the file formats without losing anything.

I think it is possible to add this functionality to the demo without altering the demo functionality.

@shoeb-github shoeb-github mentioned this pull request Jan 6, 2020
@shoeb-github
Copy link
Contributor Author

closing in favor of #712`

@shoeb-github shoeb-github deleted the maint/696_unify_demo_tutor branch January 8, 2020 17:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants