search

brandon-rhodes / python-typesetting

A Python library letting you invoke TeX-inspired typesetting algorithms
https://www.youtube.com/watch?v=e7RVO0Sqr4s
158 stars 12 forks source link

Consider allwing Qt implementation to be passed in as an argument. #8

Closed tritium21 closed 4 years ago

tritium21 commented 5 years ago

I am working on a project that deals a lot with converting markup to human-enjoyable output, and typesetting looks to be exactly what I need for PDF creation.

One small hitch - It's already a Qt application, and it uses PyQt5. I could switch to Qt for Python (...which is PySide2, because name symmetry is not something the Qt Company apparently believes in?), but there are API differences that I would run into, that from my look at your code, you would not.

An alternative to passing the Qt implementation in would be to use AnyQt - another level of indirection that allows the library user to choose the Qt implementation. As a library author it would involve switching imports to AnyQt. If the library user has not already imported a Qt implementation (the default use case, I would assume), it will import the first Qt implementation it finds. If the library user already has Qt imported, it will proxy to that implementation.

Were I able to rate the severity of this request, I would consider it a low priority issue. I can always fork-and-vendor if I need to.

tritium21 commented 5 years ago

Related to this, you create a QApplication object and do nothing with it, which makes sense for your use case. However if the library is used in an actual Qt application, two QApplication objects can cause issues.

Perhaps put creation of a QApplication object behind an if statement branching on a boolean keyword-only argument that defaults to True?

brandon-rhodes commented 5 years ago

I think that a switch to having Qt passed makes sense and would not be too difficult! I'll keep this issue open for the next time I dive into the code (hopefully later this year?), as I'll need to refactor my personal project that uses this repository at the same time; but the other project will provide an assurance that the mechanisms all really work after the switch.

Thanks for the clear explanation of your use case!

brandon-rhodes commented 4 years ago

@tritium21 — In case you look at the project again sometime, I have refactored everything Qt-specific into a single module typesetting.writer_qt and because of your advice I have opted for the new code to not create its own QApplication but instead to ask the user to do it if one has not been instantiated yet.

To use another version of Qt, I think you can simply make your own copy of examples/pylondinium/typeset.py, import the other Qt implementation at the top, and make any edits necessary for compatibility. Hopefully that meets your use case; I’ll watch for comments here in case you have feedback or more ideas!

tritium21 commented 4 years ago

Thank you very much!

brandon-rhodes commented 4 years ago

Be warned that the API might still change a bit before things get stable; in particular I'm still looking askance at the dict-of-fonts and wondering if it really needs to be passed around everywhere. We’ll see.