On Sat, 17 Jan 2015 00:06:43 +0100 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? Yes, I think that there is no other advantage than a possibility of closing plot windows in DOLFIN build with Qt. > > > > >> 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! Yes, there should be a way having such an interface without Qt dependency but this would have to be developed by somebody. If we just remove all Qt related stuff we loose the interface. So I'd vote for not removing it unless it it requires further maintenance. > > > > > 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. Having documented what every dependency does (in few lines) seems natural to me. One who should be responsible is naturally the one who implements/changes/removes a functionality connected to a dependency. I can even take care of introducing it in the case that other developers agree to maintain it in accordance to changes made by themselves. Jan > > 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
