Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save position of dockwidgets regardless of closing the application #305

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pominov
Copy link
Contributor

@pominov pominov commented Jun 29, 2022

Make it possible to save the dockwidget positions when the
KImageAnnotator is destroyed as subwindow of another application before
closing the application

Make it possible to save the dockwidget positions when the
KImageAnnotator is destroyed as subwindow of another application before
closing the application
@DamirPorobic
Copy link
Member

I'm not sure if this is goring to work. I think I have tested this options to persist in the destructor but it didn't work that well. I need to do bit of testing on this PR the I'll get back to you.

@pominov
Copy link
Contributor Author

pominov commented Jul 1, 2022

Thanks. I don't know why it won't work. I'm tested it too on kImageAnnotator-example and spectacle. I wanted to use the kImageAnnotator in the gwenview as modal dialog and faced with the fact that if I delete it before I close the application - the positions of the widgets are not saved

@DamirPorobic
Copy link
Member

I think the reason "why" it's not working in your case is that the application is Gwenview or Spectacle and you open the kImageAnnotator just as a window and close it without the main loop of qApp still running and not quitting.

Can you try replacing the qApp::aboutToQuit signal with this::destroyed, like this:

connect(this, &QCoreApplication::destroyed, this, &AnnotationWidget::persistDockWidgets);

Without the method call in the destructor.

@pominov
Copy link
Contributor Author

pominov commented Jul 14, 2022

It doesn't make sense. Because I'm deleting annotation window and not deleting qApp. Signal QCoreApplication::destroyed will not be emmited.
I think destructor is the optimal solution.

@DamirPorobic
Copy link
Member

Sorry, my bad, I meant &AnnotationWidget::destroyed of course as this one is being destroyed.

@pominov
Copy link
Contributor Author

pominov commented Jul 14, 2022

Sorry, my bad, I meant &AnnotationWidget::destroyed of course as this one is being destroyed.

In fact this is the call of destructor. No problem, i can change to signal/slot

@pominov
Copy link
Contributor Author

pominov commented Aug 2, 2022

I checked your version with connect. This will crash the program because the signal is emitted in the QObject's destructor when the AnnotationWidget's destructor has already completed and we cannot call its methods. But the call in the destructor of the AnnotationWidget's itself is the norm, because field mConfig is valid until the AnnotationWidget's destructor completes

@DamirPorobic
Copy link
Member

The issue with the destructor is that will only be called with a graceful shutdown, if the application finishes unexpectedly the position would not be saved. That's why it was not in initially in the destructor, it was quit the usualy use case while testing the app. Maybe this is not that big issue.

@pominov
Copy link
Contributor Author

pominov commented Aug 22, 2022

if the application terminates unexpectedly, the signal from qApp will also not be sent and processed. In this case, there is a chance to save something only by catching the exception. But that's out of the scope of this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants