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

nextslide-directive after sub-Header goes wrong #102

Open
AlbertMietus opened this issue Jul 23, 2015 · 5 comments
Open

nextslide-directive after sub-Header goes wrong #102

AlbertMietus opened this issue Jul 23, 2015 · 5 comments

Comments

@AlbertMietus
Copy link

BUGDEMO

Note: For this demo the conf should contain slide_levels = 2

AutoSlide

Use only as sub-header, not as nextslide header

echo h3

.. nextslide::
:increment:

This should be on a new slide, named AutoSlide (2), not of the last h3

@AlbertMietus
Copy link
Author

This bug is related to #100, as it is only visible when that one is (partially) fixed.
I'm working on a fix, see my fork (still busy)

AlbertMietus pushed a commit to AlbertMietus/hieroglyph that referenced this issue Jul 23, 2015
AlbertMietus pushed a commit to AlbertMietus/hieroglyph that referenced this issue Jul 28, 2015
…) when using headers above auto-slide-level (bug nyergler#100)
AlbertMietus pushed a commit to AlbertMietus/hieroglyph that referenced this issue Jul 30, 2015
AlbertMietus pushed a commit to AlbertMietus/hieroglyph that referenced this issue Aug 2, 2015
@AlbertMietus
Copy link
Author

Fixed #100 and #102 in my branch (now on AlbertMietus::master branch). Please test!

@nyergler
Copy link
Owner

nyergler commented Aug 3, 2015

I read through the diff between your master branch and master in this repo. Overall it looks reasonable. A few things I noticed generally:

  • It looks like you have a test case Sphinx project that you were using to work from; it'd be great to include that in the automated test suite with programmatic assertions so I don't introduce regressions in the future :). See https://github.com/nyergler/hieroglyph/blob/master/src/hieroglyph/tests/test_directives.py for examples of invoking the Sphinx machinery in a unit-style test, and also invoking the entire builder. https://github.com/nyergler/hieroglyph/blob/master/src/hieroglyph/tests/test_directives.py#L145, in particular, specifies a test directory to run with, and then the individual tests open up the output and make assertions about it. Happy to help guide that, but having these tests runs in an automated fashion is high on my priority list these days.
  • Love the new documentation, thank you.
  • Looks like you changed some scroll behavior in the CSS, just wondering what that addressed. I don't object, just been trying to limit how much I touch the imported upstream CSS/JS (although it's sort of a losing battle).

Want to take a run at automating the test assertions and open a PR?

@AlbertMietus
Copy link
Author

Thanks.

An some answers

Tests

I used and added those tests for two reasons: Firstly, I didn’t understand the test-suite; so, some guidance will help. And secondly, I didn’t what to test (only) at unitlevel (which, as far as I understand, the existing test did). I wanted to improve the result: the looks of the slides. So I created a (mini) hieroglyph project to and made sure the slides come out nicely.

However, if that can be done; please help!

CSS

Yeah, I made some changes to the CSS; for the same reason as above: the result counts. The “new” H3 level sub-header wasn’t properly shown, so I had to to make it …

About the scrolling: I had a long though about it. But a the end I decided that it was needed. Let me shown the link of thought:

  1. Slides should have to have to much info (lines) on it
  2. But sometime the have. While the author wrote to much, or while a line is wrapped — the later is hard to predict
  3. So, what if the slide doesn’t fit ?
  4. Everything is better than hiding that info. The best way is fix/shorten the text, but the tool can’t do that. Scaling, (text and/or whitespace) are standard solution (in office tools)
  5. Scaling whitespace is nice, but to hard (for me). Scaling text is promised in (some) google slide-styles. But not always available (eb the slides theme)
  6. It should have any effect on well designed (fitting) slides
  7. Auto-scrolling is easy to implement, fit the above conditions and is kind of natural on web-pages

Firstly, I implemented it in my local css-style. But decided it is more general and made it public.

An alternative is, to make it (scroll/scale/as-is) a config-option. Hoever, that would need extra infra-structure to parse/render the “static” pages too. Which by itself would be handy; by example to set the geometry (width/height) of the slides. But for now: to much.

Docs

Started on that, specially for (GIO) slides2. But it is done and should be in the master branch yet. But copy and use anything you like (see my DOC-gio_slides branch)

Pull Request

Please guide with the test automation, and I will make a PR (when it passes all test)

Also, please run this version on existing projects/slide-desks, to make sure nothing is broken. Yes, I like quality:-)
--Groetjes
ALbert Mietus

@AlbertMietus
Copy link
Author

A bit of refinement is done around the scrolling option. It's available in my GAM-dev branch. Didn't merge it to master yet

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

No branches or pull requests

2 participants