python-tksvg
python-tksvg copied to clipboard
TkinterEP
Backport upstream changes
@RedFantom
-
It would be nice if you enabled issues on this fork, so I don't need to make a pull request to ask something :D. I know at least two person who would have opened one.
-
It would be good to add a CI to build wheels with macOS binaries (I can work on that), because it's currently quite hard to install this on a mac. The upstream has also added a Github action to build binaries for various platforms.
Would you also make a PR with better documentation?
Actually, what's the issue with documentation? It's the same as tkinter.PhotoImage just named differently.
From the README:
Using the library has been made as similar as possible to using a normal tk.PhotoImage. Simply create an SvgImage instance and the tksvg library will automatically be loaded for you.
I would mention that its actually built on top of the PhotoImage class and simply adds the functionality of svg's.
@rdbende : Okay, Issues are now enabled! Of course I would welcome a PR which adds automatic building for mac as well.
Unfortunately since I built the CI system for this repository, Travis-CI changed their policy for open-source repositories, hence why it is no longer enabled. Perhaps this can also be migrated to the GitHub Actions system?
Currently I have very little time, as you have probably noticed 🙈 , so it is unlikely I will get around to it anytime soon. I'm not even sure how to prioritize the long todo-list at this point.
Regarding documentation, @Moosems , adding documentation with sphinx should be pretty trivial, but I didn't add it in the first place because indeed SvgImage has pretty much the same interface as PhotoImage. Do you think it would add something to have a (single) RTD page?
I would simply make a piece in README and explain the zoom and that it's quite literally built on top of the PhotoImage class. After that, I'd say it's documented sufficiently and any questions regarding the inner workings (tksvg) can be routed to the origin repo :D.
What do you mean under "we"? Me or you? lol I do plan to work on it, but not now.
Pacman can be completely removed, in fact, the appveyor CI should just become a GH action.
Unfortunately since I built the CI system for this repository, Travis-CI changed their policy for open-source repositories, hence why it is no longer enabled. Perhaps this can also be migrated to the GitHub Actions system?
I think only the Pypi publisher one. Then we would need 3 GHAs:
- Run unittests with Nose
- Build binaries
- Publish to Pypi
I also think you should separate it to PRs. One for the builds, and one for the test and Pypi stuff.
Looking at the appveyor, why the flip does it even exist?
I am used to using AppVeyor / MSYS2 for building Windows-compatible binaries. If you have an idea for setting up a build system using VC++ on GitHub Actions, feel free to open a PR / issue with some details on how to include and link the Tcl and Tk development files. Edit: This file has some hints... Now to build a Python package...
GitHub Actions already builds Linux binaries, but is not yet used for CI. That is something which could be addressed in another PR.
If this PR has the CI-related stuff removed (force-push is acceptable to me) and PR #4 is merged, then we can merge this one too.