On Tue, Jan 1, 2019 at 10:09 PM Alan W. Irwin <alan.w.irwin1...@gmail.com>
wrote:
> On 2018-12-31 11:44-0800 Alan W. Irwin wrote:
>
> > On 2018-12-31 11:28-0800 Alan W. Irwin wrote:
> >
> >> [...] by the following temporary changes to
> >> qt_example:
> >>
> >> argc = 1;
> >> QApplication a( argc, argv );
> >> // Must construct an instance of PlotWindow after QApplication.
> >> PlotWindow * win = new PlotWindow( Argc, Argv );
> >>
> >> // Clean up Argv now that we are done with processing arguments.
> >> for ( int i = 0; i < Argc; ++i )
> >> {
> >> delete[] Argv[i];
> >> }
> >> delete[] Argv;
> >>
> >> delete win;
> >> return 0;
> >>
> >> So the QApplication never gets explicitly used in this experimental
> >> version of the code whose job is simply to test the PlotWindow
> >> constructor and destructor without actually using the PlotWindow
> >> instance for anything. An additional important part of these
> >> experiments is to make some changes to the destructor such as calling
> >> plend from there. And now I am going to test the effect of the
> >> Qt::WA_DeleteOnClose attribute as well.
> >
> > P.S. Something that just struck me is the above experimental code and
> > also the normal version of this code create the "a" instance of
> > QApplication on the stack. So that instance should automatically be
> > deleted when the above code or the non-experimental version of this
> > code return from qt_example main routine. So setting the above
> > attribute seems like overkill and, in fact, might cause a double free.
> > So at this stage I am hoping that not setting this attribute (as you
> > tried in your own experiment) is the key step required in fixing the
> > qt_example memory management.
> >
> > More later.
>
> Hi António:
>
> A google search for "qapplication delete "WA_DeleteOnClose"" (without
> the outer quotes) showed what appeared to be mass confusion about
> deleting qApps, but one of those discussions
> <
> https://stackoverflow.com/questions/3153155/when-setting-the-wa-deleteonclose-attribute-on-a-qt-mainwindow-the-program-cras
> >
> does contain the following advice:
>
> "Remember that your main window destructor should run only once. That is
> to say that it should run either because of a stack unwind, or because of
> WA_DeleteOnClose, not both."
>
> The documentation at <http://doc.qt.io/qt-5/qt.html#WidgetAttribute-enum>
> of this attribute
> says the following:
>
> "Makes Qt delete this widget when the widget has accepted the close event
> (see QWidget::closeEvent())."
>
> which seems consistent with the advice. However, the only mentions of
> closeEvent in
> our entire code base are the following:
>
> software@merlin> find . -type f |grep -v .git |xargs grep closeEvent
> ./bindings/qt_gui/pyqt4/plplot_pyqt4.sip: void closeEvent(QCloseEvent
> *event);
> ./bindings/qt_gui/plqt.cpp:void QtPLWidget::closeEvent( QCloseEvent* event
> )
> ./bindings/qt_gui/pyqt5/plplot_pyqt5.sip: void closeEvent(QCloseEvent
> *event);
> ./include/qt.h: void closeEvent( QCloseEvent* event );
>
> So closeEvent is defined but never explicitly used in our code. So to
> help with my Qt education is this a case where closeEvent is
> essentially a callback that Qt demands must be defined and then it
> uses it internally for its own purposes (e.g., when a user closes a Qt
> GUI)?
>
closeEvent is a protected function that is in qt_example case called when
you click in the X in the window application that closes/ends.
One may redefine it if needs extra actions to be performed before close the
window. Must of the times it is redefined to prompt to the user if he in
fact wants to close the window.
citing qt documentation
By default, the event is accepted and the widget is closed. You can
reimplement this function to change the way the widget responds to window
close requests. For example, you can prevent the window from closing by
calling ignore() on all events.
cheers
>
> Regardless of your reply to that "Qt education question" it appears to
> me that to avoid double frees we must either drop this attribute or
> else create the qApp on the heap and not delete it explicitly.
> However, the above experimental code never gives the user the chance
> to close the GUI so closeEvent is likely never called and setting the
> attribute or not should make no difference for that experimental case.
> However, once I have figured out how to cleanly delete PlotWindow with
> the above experimental version of the code, then I plan to follow up
> by using that delete method in the non-experimental version of
> qt_example and look at valgrind results in that case (where setting
> the attribute would matter) with the qApp created on the stack (as in
> the original version of qt_example), and the above attribute dropped.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
--
António Rodrigues Tomé
Universidade da Beira Interior
Instituto D. Luís (lab associado)
email address:
art...@gmail.com
art...@ubi.pt
http://www.researcherid.com/rid/A-5681-2013
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
