New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Qt Functionality out of pyvista #614
Comments
pyvista
I didn't check the design in Whatever is decided, I would prefer to do it incrementally. It gives more space to adapt/fix what is unexpected. |
My thoughts: We should strip down the My goal is to make the I also have a handful of ideas for demo applications to show this off, so when I get the time, I'd really like to lead the charge on this... but it may be a while... |
+100 on this
Also this sounds awesome |
Agreed. Does this mean moving toolbars and all but the most basic of menus out of |
Maybe.... I like the toolbars... It might be nice to keep the camera toolbars in the QtInteractor class so both guis can use them
At the moment, that's what I am thinking.
import pyvista as pv
from PyQt5 import Qt
import numpy as np
# prototype of PyVista's `MainWindow` class
class MainWindow(Qt.QMainWindow):
def __init__(self, parent=None, show=True):
Qt.QMainWindow.__init__(self, parent)
vlayout = Qt.QVBoxLayout()
# add the pyvista interactor object
self.plotter = pv.QtInteractor(self.main_frame)
vlayout.addWidget(self.plotter.interactor)
self.main_frame.setLayout(vlayout)
self.setCentralWidget(self.main_frame)
# simple menu
exit_button = Qt.QAction('Exit', self)
exit_button.setShortcut('Ctrl+Q')
exit_button.triggered.connect(self.close)
self.file_menu.addAction(exit_button)
if show:
self.show()
@property
def main_menu(self):
if not hasattr(self, "_main_menu"):
self._main_menu = self.menuBar()
return self._main_menu
@property
def file_menu(self):
if not hasattr(self, "_file_menu"):
self._file_menu = self.main_menu.addMenu('File')
return self._file_menu
@property
def main_frame(self):
if not hasattr(self, "_main_frame"):
self._main_frame = Qt.QFrame()
return self._main_frame
def add_menu(self, name):
return self.main_menu.addMenu(name)
def add_action(self, title, callback, holder):
action = Qt.QAction(title, self)
action.triggered.connect(callback)
holder.addAction(action)
return action
# What a user would wright
class UserWindow(MainWindow):
def __init__(self, *args, **kwargs):
super(UserWindow, self).__init__(*args, **kwargs)
# allow adding a sphere
self.mesh_menu = self.add_menu('Mesh')
self.add_action("Add Sphere", self.add_sphere, self.mesh_menu)
def add_sphere(self):
""" add a sphere to the pyqt frame """
sphere = pv.Sphere()
self.plotter.add_mesh(sphere)
self.plotter.reset_camera() Then |
We were considering adding additional features to
BackgroundPlotter
like adding in a tree view. Should we simply move these to thepyvista-gui
? Having a Paraview-esque GUI might be the direction we can movepyvista-gui
in, rather than simply making it a plug and play module for other programs.With my closed source project, there are too many variations and some of them require monkey patching the GUI to such a degree that it creates extra work. Why not go with @GuillaumeFavelier 's suggestion and have advanced functionality for the
BackgroundPlotter
inpyvista-gui
.To tell you the truth, with the problems we had with
BackgroundPlotter
, I'm half tempted to move it all topyvista-gui
. We can then control thePyQt5
version and do better testing there.pyvista
is becoming a bit of a monster these days and it might be better to split it up.@pyvista/developers, thoughts? Might open a separate thread on slack/gitter.
The text was updated successfully, but these errors were encountered: