MatthewFlamm

Results 336 comments of MatthewFlamm

Precision issues with big number using MultipleLines

`MultipleLines` uses `vtkLineSource` under the hood. There is a [Get/SetOutputPointsPrecision method](https://vtk.org/doc/nightly/html/classvtkLineSource.html#afbd055f90c46a4c111efaecce278d3b3) that might be useful to look into. By default, this is set to single precision. See https://github.com/Kitware/VTK/blob/758cea2c9d5209f8d638de5f2998b2e9aca50e1c/Filters/Sources/vtkLineSource.cxx#L37

Problems with point selection in the newer pyvista versions

I don't have a lead, but with a complex problem like this, I would suggest trying `git bisect` on a cloned repository of pyvista. This can lead you to the...

Need to speed up the Documentation build in CI

The v4 upload_artifacts is supposedly much faster, this is currently taking >30 minutes on some PRs. This is not the majority of time but any decrease would help. Another thought...

Fix the problem of Flaky tests in CI

> `tests/plotting/test_widgets.py::test_affine_widget` in Linux Unit Testing (3.10, 9.2.2) raise vtk error happen in #5336. We should list it as flaky. I'm wondering if this is a vtk 9.2.2 problem as...

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

> @MatthewFlamm, I haven't looked at this in depth at all but I want to make sure you are aware of a use case where downstream projects subclass Theme to...

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

One potentially painful change however is if these users subclass one of our subclasses. `MyTheme(DarkTheme)` for example. This PR will still be a problem for that use case.

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

This PR does _not_ prevent maintaining a custom Theme. It will continue to support maintaining a custom subclass of Theme but not a built-in subclass of Theme. That is users...

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

Making this PR draft to address some of the discussion here. 1) More explicit documentation around custom theme maintenance. 2) Allow instantiation via `Theme.__init__` via - `**kwargs` - `theme_dict`

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

There is one more related issue that causes problems with the proposals of having dictionary or kwarg cascade of information through the configurations. `_SliderConfig` works differently than all the other...

Make built-in themes class methods, deprecate built-in classes; simplify to `slider_style`; allow registering default themes.

Coming back to this again. `slider_styles` is only consumed in `add_slider_widget`. Slider config styles works backwards compared to all the other configuration in the themes. That is the default behavior...