Sounds sensible. How should we go about documenting which dependencies are actually necessary?
Perhaps the problem with the dependencies is minor if most users and developers get FEniCS either via a package manager or via fenics-install.sh? -- Anders Mon Jan 19 2015 at 6:53:40 PM skrev Jan Blechta <[email protected] >: > So 3rd party GUIs are now possible but with removal of Qt and without > newly developed interface this possibility would be loosed. This speaks > for not removing Qt (if not necessary) unless the interface is > reimplemented. > > Jan > > > On Mon, 19 Jan 2015 18:46:11 +0100 > Joachim Berdal Haga <[email protected]> wrote: > > > It requires Dolfin with Qt; it just reparents the plot window. Since > > the window (widget) is fetched from Qt directly, it does not require > > that the plot widget (or contents) are exported to Python. > > > > The alternative implementation (exposing VTK actors instead) would > > probably require exposing those to Python. > > > > Regards, > > Joachim > > > > > > > > On 19 January 2015 at 18:37, Jan Blechta <[email protected]> > > wrote: > > > > > 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 >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
