vorta [Enhancement] Added setting to run vorta in background

Description

When closing vorta a popup will be displayed whether to continue running in the background or not, according to users response the application will close or will stay in the system tray

Related Issue

Closes #1582

Motivation and Context

Gives the user control of the background activity (whether he/she wants to continue the process) through the checkbox added in the mics tab

How Has This Been Tested?

Machine: Ubuntu 20.04 Python Version: 3.10.6 Borg Version: 1.2.0

I've tested this on my local environment installed by following dev guidelines mentioned here

Screenshots (if appropriate):

Added Background Group Checkbox
When Checked Asks For The Following Option
If Checked Don Not Show This Again The Background Question Checkbox Unchecks (Big Thanks To @real-yfprojects)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING guide.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.

Mar 01 '23 17:03 DaffyTheDuck

Hi!

Actually the previous commit got discarded when I rebased the content with my fork with the old changes still with me (I'm still figuring it out how this happened)
I've not checked the All new and existing tests passed. since on my machine the pytests are failing (I guess this change is non-breaking 🤔 ), I've tested the changes which are working

Since this is the first time with pytests I would love to hear suggestions from Mentors 😄

Mar 01 '23 17:03 DaffyTheDuck

Hi! Just out of curiosity! Why do the tests take time to report? like when I worked with an organization previously there they used a ci tool called Travis where you could see the tests running and it used to report the test results within minutes 😃

Mar 03 '23 08:03 DaffyTheDuck

Because the tests won't run automatically for new contributors and need manual approval first.

After your first contribution, they will run automatically for you and will finish in about 1-2 min.

Mar 03 '23 10:03 m3nu

Because the tests won't run automatically for new contributors and need manual approval first.

After your first contribution, they will run automatically for you and will finish in about 1-2 min.

Oh informative 😄

Mar 03 '23 11:03 DaffyTheDuck

The tests fail due to a different issue now: peewee doesn't support connecting multiple methods with the same name. You will have to disconnect the signal after each test. peewee docs

Mar 03 '23 12:03 real-yfprojects

The tests fail due to a different issue now: peewee doesn't support connecting multiple methods with the same name. You will have to disconnect the signal after each test. peewee docs

Hi! I've added the disconnect method mentioned in docs, which results in 2 test failures (autostart and test_create) because it exceeds time. Is something wrong on my side (like my approach is wrong or something?) because all other tests passes but these two fails 🤔

Mar 03 '23 17:03 DaffyTheDuck

I can't tell you because you didn't push your changes.

Mar 03 '23 22:03 real-yfprojects

You will have to disconnect the signal after each test. peewee docs

Hi! I could not get this actually, I'm figuring out where to call the disconnect mentioned in docs, do I have to modify the tests ? because I tried putting it in mics tab when the checkbox is updated then disconnect but it results in a small bug 😅

Mar 04 '23 11:03 DaffyTheDuck

No, you have to add it to the test setup. There is a fixture in conf.py.

Mar 04 '23 11:03 real-yfprojects

Hi! There's still 1 test which fails 😓

Mar 05 '23 06:03 DaffyTheDuck

@DaffyTheDuck @m3nu @real-yfprojects what do you think about implementing a setting for running the application in the background directly, instead of a setting to prompt the user each time they close the window?

Mar 16 '23 21:03 bigtedde

@DaffyTheDuck @m3nu @real-yfprojects what do you think about implementing a setting for running the application in the background directly, instead of a setting to prompt the user each time they close the window?

It's not actually prompting each time it's upon the user, he can choose to show or hide the dialog, I opened this PR because I thought some users might be using Manual Backup all the time (like me) so for them keeping the application running in background might not be an option, and in current version, if you chose the option don't show this again on the dialog and close the application there's no option to bring that dialog back in mics tab (it might be elsewhere but from a prospective of a new user he'll be looking into mics tab for that since most of the settings are there)

There are other cases too, like once you do the manual backup and on other day you want a scheduled backup for some reason the application will keep closing since you chose the don't show this again and No as option in that "Keep In Background Dialog"

Mar 17 '23 02:03 DaffyTheDuck

what do you think about implementing a setting for running the application

I wanted to add this option additionally to the changes of this PR. I decided to open an issue for that once this is merged.

Mar 17 '23 15:03 real-yfprojects

This has to be rebased onto master and upgraded to PyQt6 @DaffyTheDuck. Maybe @i1sm3ky can guide you through that.

Apr 29 '23 17:04 real-yfprojects

This has to be rebased onto master and upgraded to PyQt6 @DaffyTheDuck. Maybe @i1sm3ky can guide you through that.

Yes, I'm more than happy to help. Just LMK if you face any issues while upgrading or want to know where to start!

Apr 29 '23 17:04 i1sm3ky

This has to be rebased onto master and upgraded to PyQt6 @DaffyTheDuck. Maybe @i1sm3ky can guide you through that.

Yes, I'm more than happy to help. Just LMK if you face any issues while upgrading or want to know where to start!

Sure 😄

Apr 30 '23 02:04 DaffyTheDuck

Still planning to rebase this to Qt6, @DaffyTheDuck ?

Jun 09 '23 11:06 m3nu

Still planning to rebase this to Qt6, @DaffyTheDuck ?

Hi! Yes! I was just freed the day before yesterday, I'll start with this again from tomorrow 😄

Jun 11 '23 12:06 DaffyTheDuck

Hi! @real-yfprojects , I had some doubts about the conflicts in conftest.py is the peewee issue which was faced during the initial stage solved ? If I recall correctly you raised an issue in the official repo. Now actually I'm unable to find it 😅

Jun 12 '23 10:06 DaffyTheDuck

Its coleifer/peewee#2687 Since its fixed we can either pin peewee to the version it was fixed in and remove the workaround

Jun 12 '23 19:06 real-yfprojects

Its coleifer/peewee#2687 Since its fixed we can either pin peewee to the version it was fixed in and remove the workaround

Done with the conflict locally! But before pushing I want to test it :) . Running the dev version produces the following error

qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, vnc, offscreen, minimalegl, xcb, vkkhrdisplay, linuxfb, wayland-egl, wayland, minimal.

[1]    9013 IOT instruction (core dumped)  vorta

I've updated every requirement since it was inactive for more than a month, am I doing something wrong ?

Jun 14 '23 09:06 DaffyTheDuck

How did you install PyQt? From distro packages or from PyPi? This error is often related to that. Or maybe the Python env has an old PyQt version? Maybe start over with the virtual env? Also, you're running this with a window manager? It won't work on a headless system.

Jun 14 '23 10:06 m3nu

How did you install PyQt? From distro packages or from PyPi? This error is often related to that. Or maybe the Python env has an old PyQt version? Maybe start over with the virtual env? Also, you're running this with a window manager? It won't work on a headless system.

Hm, still giving the same message, I'll change the windows manager to test again, should I solve the conflicts here using github ?

Jun 14 '23 11:06 DaffyTheDuck

The Github interface is pretty basic. There are better local tools. And it's better practice to do it locally. Just be careful not do add any unintentional changes while resolving conflicts.

Jun 14 '23 11:06 m3nu

The Github interface is pretty basic. There are better local tools. And it's better practice to do it locally. Just be careful not do add any unintentional changes while resolving conflicts.

Hmm! the vscode conflict solving made it worst by discarding my commits, I still have the change on my local machine, any way I can reopen this PR ??

Jun 14 '23 12:06 DaffyTheDuck

Hmm! the vscode conflict solving made it worst by discarding my commits

Then you are doing something wrong.

I still have the change on my local machine, any way I can reopen this PR ??

Just push the local branch to this branch of the fork. Then click the Reopen button here on Github.

Jun 14 '23 16:06 real-yfprojects

Hmm! the vscode conflict solving made it worst by discarding my commits

Then you are doing something wrong.

I still have the change on my local machine, any way I can reopen this PR ??

Just push the local branch to this branch of the fork. Then click the Reopen button here on Github.

Done! Thank you very much :)

Jun 15 '23 09:06 DaffyTheDuck

Hmm! the vscode conflict solving made it worst by discarding my commits

Then you are doing something wrong.

Yes, after searching on internet I understood that I mistakenly pushed the incoming changes to the working branch instead of master then rebased it overwriting the changes 😓

Jun 15 '23 09:06 DaffyTheDuck