← 返回首页
Adjust for PyGfx's new ticks by almarklein · Pull Request #910 · fastplotlib/fastplotlib · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

Adjust for PyGfx's new ticks#910

Merged
kushalkolar merged 4 commits into
mainfrom
tickmarks
Oct 10, 2025
Merged

Adjust for PyGfx's new ticks#910
kushalkolar merged 4 commits into
mainfrom
tickmarks

Conversation

Copy link
Copy Markdown
Collaborator

A lot of screenshots in fpl will need to be updated because of this upstream change.

By changing tick_marker and tick_size, we can also get this, let me know what you prefer:

github-actions Bot commented Oct 9, 2025
edited
Loading

Copy link
Copy Markdown

📚 Docs preview built and uploaded! https://www.fastplotlib.org/ver/tickmarks

Comment thread fastplotlib/graphics/_axes.py Show resolved Hide resolved
Comment thread fastplotlib/graphics/_axes.py Outdated Show resolved Hide resolved

Copy link
Copy Markdown
Member

Nice! I think keep the both sided ticks

kushalkolar commented Oct 9, 2025
edited
Loading

Copy link
Copy Markdown
Member

Let's merge this and then rebase #906 on main, and then update screenshots later? Because the selector line thickness has changed in #904 and has to be merged too which changes screenshots 😅 . Or create a temporary "dev" branch.

Copy link
Copy Markdown
Collaborator Author

Let's merge this and then rebase #906 on main, and then update screenshots later?

I mostly created this to update the screenshots due to the new PyGfx 😅, so that the new screenshots in #906 were only for the changes in that pr. But yeah, we should get things merged one way or another.

Regarding the screenshots, one thing I don't understand is that that in a screenshots-build like this one, there's two artifacts, which both contain all screenshots that are also in the repo (via LFS). Which one should I pick?

BTW: Is the imgui bump in Pygfx / wgpu a problem for FPL?

kushalkolar commented Oct 10, 2025
edited
Loading

Copy link
Copy Markdown
Member

Regarding the screenshots, one thing I don't understand is that that in a screenshots-build like this one, there's two artifacts, which both contain all screenshots that are also in the repo (via LFS). Which one should I pick?

So one is supposed to have screenshots that have imgui elements (such as the toolbar), and the other is supposed to have screenshots without imgui elements (to make sure that everything still functions correctly without the optional imgui install). But now I realize that the imgui screenshots still get uploaded even in the non-imgui artifact because they exist in that dir. So in the screenshot regenerate action I should add a rm examples/screenshots before generating the screenshots.

BTW: Is the imgui bump in Pygfx / wgpu a problem for FPL?

Nope! I updated the fonts changes here: f1746be

And now in optional dependencies I let wgpu handle imgui version:

imgui = ["wgpu[imgui]"]

I wonder if it would make sense to do this for pygfx too?

Hide details View details kushalkolar merged commit 75ff892 into main Oct 10, 2025
28 of 52 checks passed
kushalkolar deleted the tickmarks branch October 10, 2025 23:31

Copy link
Copy Markdown
Collaborator Author

I wonder if it would make sense to do this for pygfx too?

PyGfx does not depend on imgui; only some examples do.

Copy link
Copy Markdown
Member

I wonder if it would make sense to do this for pygfx too?

PyGfx does not depend on imgui; only some examples do.

It's an optional dependency:

https://github.com/pygfx/pygfx/blob/37cdd2664020c52380e44fc37c43129882b76f4d/pyproject.toml#L43

Might be better to let wgpu handle it?

Copy link
Copy Markdown
Collaborator Author

Ah, I see what you mean now. Yeah, would be nice to use wgpu[imgui] in pygfx/pyproject.toml too.

kushalkolar mentioned this pull request Oct 19, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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

Footer

© 2026 GitHub, Inc.