Flogging away at pyqtdeploy; Design issue with help

I found another blogger who is working in PyQt5 and experimenting with pyqtdeploy, and at a much more sophisticated level than I'm at. Contacted him and started a conversation about pyqtdeploy. In the meantime I have apparently exposed a couple of bugs, but as usual Phil at Riverbank is quick to acknowledge and fix them.

Unfortunately he puts the fixes in a mercurial repository. That's unfortunate because I don't know mercurial, so I'm not quite sure how to download (in git lingo, "clone") the current dev snapshot.

Soldiering on with the distributed version, which is installed with pip. Unfortunately it fails with a traceback during its "build" phase (when it byte-compiles? anyway "freezes" all the python modules). This was the second of the traceback bugs I reported. It is triggered by some slight change in the many options of the UI. It popped up yesterday. Then I used Time Machine to get back to an early version of my .pdy (project) file and it went away. Then I did some editing on the list of included standard modules and it has come back.

So now I get to figure out how to clone a mercurial repository, sigh.

Turning from that, I thought I would spend a more pleasant hour implementing the last PPQT module needed before it is alpha-test ready, namely the Help module. And here I hit a snag.

I was rather proud of the Help in version 1. I used a WebKit browser instance to display a quite detailed and well-organized (if I do say so) manual for the whole program, in hand-made HTML. For V2, I envision writing the Help material using something like the MkDocs package, a little less trouble to write and edit than raw HTML, but generally the same approach: a complete manual that can be searched or (if opened in a real browser) printed.

The Help panel was the rightmost tab in the panel tabset. This was a somewhat awkward UI because if you wanted help on, for example, the Word panel, you had to click away to the Help panel to read, which covered up the Word panel. This was one motivator for implementing drag-out panels for V2.

Well, I opened up the stub for helpview.py and read the docstring I put there months ago when I created it.

Create and manage the display of the Help file.
Instantiated from mainwindow.py and given the path to help.html at that time.

And realized, I'd never really thought this through. In V1, Help was just another tab in the tabset. But in V2, we allow multiple open books which, as I've noted more than once, changes everything.

All the tabs in the tabset are book-unique. Created by the Book, individual to the Book, and hidden or displayed along with the Edit panel for that book. Bring a different book to the front and the whole right-side tabset is cleared and repopulated with that book's functional tabs—in the sequence the user left them, with the tab open that was open when that book was hidden.

Ok, then, but Help is not a book-unique function. So a Help panel doesn't fit well into that scheme. That was my first thought. As something apart from the current book, a hypothetical Help tab would have to be a special case. When the mainwindow make a book's tabs visible, it clears the tabset and repopulates it. It would have to remember to save the Help panel widget and put it back into the tab bar afterward.

Or, my second thought, do not put Help into the tabset. Make it an independent window. File>Show Help would be a menu item with a toggle value. When on, there would be a separate Help window the user can drag about, push behind, minimize or whatever. If the user closes it, or toggles File>Show Help, it goes away.

Or, my third thought, Help could be made Book-unique. Each Book could instantiate a Help panel just as it instantiates a Word panel or Chars panel etc. The Help panel would go into the tabset. On the plus side, each book's Help could be at (a) a different position in the tab bar, if the user dragged it around; (b) open to a different page of material. On the downside, this would bring back the problem of Help hiding the panel about which you want help. So, back to thought #2. If I do it that way I can put off implementing drag-out tab panels for quite a while, maybe forever.