On Sat, 17 Jan 2015 15:18:50 +0100 Joachim Berdal Haga <[email protected]> wrote:
> I can provide a bit of history, at least. Originally the Qt support > was meant to support embedding the plotting widget in external GUIs > (meshbuilder, Dolfin GUI applications for teaching, etc.). However, it > turned out that the VTK built-in window-manager interaction is (or > was, at the time) really primitive, and it was impossible to get > simple things like closing windows to work reliably across platforms. > Hence, Qt was used also for the "simple" plot window. Since Qt is > commonly installed already on workstations, and cluster-installations > don't need a plotting window anyway, I considered it a reasonable > dependency. (Rightly or wrongly.) > > Now, as Anders pointed out, these GUIs haven't materialized yet. One > under-communicated aspect (because it wasn't considered back then) is > that this can be done in Python, too, using PySide or PyQt. Just for > fun I've attached a small demo that creates a Python GUI application > for the Poisson demo, using PySide. Note: This is not meant to be > included as a Dolfin demo, it is just thrown together to show that it > can be done. Bummer, I haven't succeeded installing PySide using pip to try it. Does it need DOLFIN built with Qt? If not, it is then a good argument for removing Qt dependency from DOLFIN. Jan > > Benjamin: It is probably as easy as you suggest. The reason it is > like it is now, it that we (or I) ended up using Qt for the simple > plot window anyway, for stability reasons; and then it's even easier > to embed the window in another application. > > Regards, > Joachim. > > > On 17 January 2015 at 09:12, Garth N. Wells <[email protected]> wrote: > > > > > On Fri, 16 Jan, 2015 at 11:06 PM, Benjamin Kehlet > > <[email protected]> wrote: > > > >> 2015-01-16 16:00 GMT+01:00 Jan Blechta > >> <[email protected]>: > >> > >>> On Fri, 16 Jan 2015 12:55:35 +0100 > >>> Benjamin Kehlet <[email protected]> wrote: > >>> > >>> I agree with Garth and Jan that Qt should be removed. The Qt > >>>> > >>> > >>> I didn't say whether Qt should be removed. > >>> > >> > >> Ah, I see that now. Sorry. > >> > >> I don't think that there's a > >>> strong need to remove it unless it requires in a future any > >>> maintenance which nobody wants to do. > >>> > >>> With a removal, VTK plots will loose a capability of closing a > >>> window. > >>> > >> > >> I didn't know that. What functionality is it that the Qt-based > >> plotting provides? Closing plotting windows programmatically? > >> > >> > >>> functionality was added to make it possible to reuse the > >>> plotting > >>>> functionality in third party Qt applications, but this is > >>>> (apparently) not used at all. The plotting code should really be > >>>> kept as minimal as possible. > >>>> > >>>> If someone wants to embed the plots in Qt (or another GUI > >>>> framework), it is better to expose the what is needed to do that > >>>> outside of Dolfin. (I haven't looked into this, but it may be > >>>> possible already by using VTKWindowOutputStage). > >>>> > >>> > >>> This is exactly what is done. There are few #ifdef HAS_QVTK > >>> switching between vtkRenderWindowInteractor implementation and > >>> QVTKWidget implementation. If we remove Qt, QVTK (I'm not sure > >>> how coupled are these two dependencies; anyway DOLFIN requires > >>> both or none) then this interface will be gone. > >>> > >>> Code in plot-qt demo is just application using this interface. > >>> > >> > >> My point was that I imagine it would be pretty simple to adjust the > >> interface so that applications can do this outside Dolfin. An > >> application could maybe do somethin like this: > >> * Create a dolfin::VTKPlotter object. > >> * Grab a reference to the vtkRenderWindow object from the > >> dolfin::VTKPlotter object an connect it to whatever GUI framework > >> it uses. > >> * Plot the dolfin object to the dolfin::VTKPlotter. > >> > >> or (a bit more low level) > >> * Create a dolfin::GenericVTKPlottable object from the dolfin > >> object it would like to plot. > >> * Grab a reference to the vtkActor object from the > >> GenericVTKPlottable. > >> > >> In both cases the plotting code in Dolfin is reused, but Dolfin is > >> unaware of the GUI framework and linking, find_package() etc. is > >> done (and maintained) on the application side. > >> > >> Joachim: Shout if I'm missing anything essential here! > >> > >> > >>> Finally, the apparent confusion of new users by enormous number > >>> of useless dependencies is rather problem of documentation. There > >>> should be clearly stated: > >>> > >>> 1. What is dependency for. > >>> 2. Which dependencies are recommended to have useful DOLFIN. > >>> > >> > >> Good point, but maintaining documentation also requires work. This > >> is maintenance that no one is eager to do and should be minimized. > >> > > > > I don't think documentation is the solution. It helps, but if > > someone needs to make a decision at that level before they can get > > started it's already too late. A new user is unlikely to understand > > the full implications of having or not having an optional > > dependency, and err on the side of caution and enable it. I know I > > do. > > > > Cutting dependencies that offer little reduces maintenance, > > simplifies testing (fewer combinations to consider) and simplifies > > installation approaches like Hashdist and containers/VMs that have > > fewer dependencies to worry about supporting. > > > > Garth > > > > > > > >> Benjamin > >> > >> > >>> Jan > >>> > >>> > >>>> Regards > >>>> > >>>> Benjamin > >>>> > >>>> 2015-01-15 21:33 GMT+01:00 Anders Logg <[email protected]>: > >>>> > I would vote for keeping the Qt functionality for a while > >>>> > longer. It was added in case we would later needed (for users > >>>> > that want to wrap DOLFIN plots inside applications). > >>>> > > >>>> > But I agree with needing to reduce the number of dependencies. > >>>> > > >>>> > -- > >>>> > Anders > >>>> > > >>>> > > >>>> > Thu Jan 15 2015 at 5:28:36 PM skrev Garth N. Wells > >>>> > <[email protected]>: > >>>> >> > >>>> >> It would be nice if we can reduce the number of optional > >>>> >> dependencies in DOLFIN - it's confusing for users to know > >>>> >> which optional dependencies they really should have, e.g. > >>>> >> PETSc, and which they very likely do not need, e.g. QT. > >>>> >> > >>>> >> Garth > >>>> >> > >>>> >> On Thu, 15 Jan, 2015 at 3:18 PM, Jan Blechta > >>>> >> <[email protected]> wrote: > >>>> >> > Garth suggested removing Qt dependency. Here are some > >>>> >> > facts to be considered > >>>> >> > > >>>> >> > 1. DOLFIN links to libQtCore, libQtGui > >>>> >> > - cost: > >>>> >> > - linking problems, recently on support mailing > >>>> >> > list but rather rare > >>>> >> > - size of libdolfin.so, Release build type, with > >>>> >> > everything except PaStiX and slepc4py: > >>>> >> > - with Qt 8M > >>>> >> > - without Qt 8M > >>>> >> > - memory footprint after "from dolfin import *" > >>>> >> > VIRT RES SHR > >>>> >> > - with Qt 751M 101M 39M > >>>> >> > - without Qt 679M 97M 48M > >>>> >> > This is rather negligible. > >>>> >> > - advantages: > >>>> >> > - Plot window can be closed! > >>>> >> > > >>>> >> > 2. there is plot-qt demo demonstrating how interactive > >>>> >> > widget allowing > >>>> >> > - basically what usual VTK plotting does > >>>> >> > - plus reporting some numbers on mouse hover > >>>> >> > - plus marking cells by clicking on them > >>>> >> > for the prize of 252 lines of C++ code (without > >>>> >> > comments and blank lines). According to git log in that > >>>> >> > directory, it seems that the code is not fragile and did > >>>> >> > not need maintenance nearly at all so far. > >>>> >> > > >>>> >> > Similarly, Qt, QVTK related code in dolfin/plot is > >>>> >> > rather minimal and does not require much maintenance. But > >>>> >> > this isn't so straightforward to check. > >>>> >> > > >>>> >> > Jan > >>>> >> > >>>> >> _______________________________________________ > >>>> >> fenics mailing list > >>>> >> [email protected] > >>>> >> http://fenicsproject.org/mailman/listinfo/fenics > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > fenics mailing list > >>>> > [email protected] > >>>> > http://fenicsproject.org/mailman/listinfo/fenics > >>>> > > >>>> _______________________________________________ > >>>> fenics mailing list > >>>> [email protected] > >>>> http://fenicsproject.org/mailman/listinfo/fenics > >>>> > >>> > >>> _______________________________________________ > >> fenics mailing list > >> [email protected] > >> http://fenicsproject.org/mailman/listinfo/fenics > >> > > > > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
