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
