[Enhancement] Added setting to run vorta in background

[DaffyTheDuck]

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):

1. Added Background Group Checkbox
   

2. When Checked Asks For The Following Option
   

3. 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)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING guide.
• I have added tests to cover my changes.
• 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.

[DaffyTheDuck]

Hi!

1. 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)
2. 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 😄

[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 😃

[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.

[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.

Oh informative 😄

[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

[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

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 🤔

[real-yfprojects]

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

[DaffyTheDuck]

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 😅

[real-yfprojects]

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

[DaffyTheDuck]

Hi! There's still 1 test which fails 😓

[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?

[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?

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"

[real-yfprojects]

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.

[real-yfprojects]

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

[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!

[DaffyTheDuck]

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 😄

[m3nu]

Still planning to rebase this to Qt6, @DaffyTheDuck ?

[DaffyTheDuck]

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 😄

[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 😅

[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

[DaffyTheDuck]

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 ?

[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.

[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.

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

[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.

[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.

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 ??

[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.

[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.

Done! Thank you very much :)

[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 😓