-
Notifications
You must be signed in to change notification settings - Fork 138
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
feat: exclude gui #1742
feat: exclude gui #1742
Conversation
"fm:/snap/chromium/*/.local/share/" | ||
], | ||
"tags":["application:chromium", "type:browser", "os:linux"], | ||
"author": "Divi" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the author
key needed for anything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, only to attribute the author.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does that make sense? Contributors might modify presets in the future. Furthermore since the author isn't shown in the GUI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@m3nu I had the same thought regarding edits and revisions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've now tested the current WIP. I like the direction this is going.
My suggestions:
- Let's remove the
Raw
tab. The combination ofCustom
to enter andPreview
to view covers all use cases ofRaw
as far as I can tell - Reorder to
Presets
,Custom
,Preview
- Stop adding the
fm
prefix and link to https://docs.python.org/3/library/fnmatch.html. That way we avoid overwhelming the users
I am fine with the other points and will wait for other reviews, but I think the Raw tab might be useful for adding multiple patterns together, for example just pasting them in from somewhere, or sharing a list of patterns between users (copy from the preview tab and paste it in the raw tab). I'd prefer the raw tab to quickly add patterns that I'll always need instead of adding patterns again and again through the custom tab. But that's just one reason to support the Raw tab, I'm open to feedback. |
I forgot about that use case. It's probably fine to keep it then One thing that I've just noticed is that Preview looks a bit too similar to the input tabs. |
That is a good idea GUI wise, however our preset json files should keep the prefixes. We should also support adding non-fm-style patterns. |
This is just shown in the Preview tab, which should show what gets passed to borg directly anyway.
It's supported, anything that you can put inside a Borg exclusion file is supported (it's visible for the custom presets right now too). |
I still feel that dropping the fm prefix also in the backend is the sweetspot here. It is the default, so the behavior doesn't change, it still allows other styles to be specified and we don't need logic to hide complexity from the user. |
Oh okay, that sounds good. I thought I'll have to hide it from the user or something. But yes, I can remove it entirely and use prefixes only for the other types (I don't know many use cases so I'll probably just leave it for later). |
Well borg changed the default style in the past afaik. |
Maybe you can help here @ThomasWaldmann: |
@Hofer-Julian There is currently no change planned. But I recently opened a ticket about "patterns docs and reality", so there might be some work on that in general for borg2. |
Thank you, @ThomasWaldmann! (that's the link for the people who are curious too borgbackup/borg#7634) That sounds like @real-yfprojects suggestion to specify the
@diivi I think you don't have to go out of your way to hide the prefix from the user |
How do we handle changes to the presets in the future? The user might wonder that something is suddenly excluded or included. Or he won't notice at all. |
I would expect that all patterns are disabled per default. |
I think they mean the case where I enable a preset and then later someone changes that preset from Vorta source to add/remove a pattern. I won't know which files are excluded. I think they can just check the preview tab for the final exclusions, as they should. |
Requiring users to recheck their excludes after every update isn't very user friendly, is it? |
True, and for scheduled backups people might not even check the preview tab. I don't really have a solution in mind though :/ |
Possible solutions include:
Combinations of these could make sense as well. |
Screencast.from.25-08-23.02.17.33.AM.IST.webmWorks on my end with correct distinction. |
@jetchirag can you help me figure out where and how I can move the 2 tests for this feaure? I put them in the tests folder to start, but after your PR got merged they should probably be changed a little and go inside one of /unit or /integration directories. |
Just noticed that all my exclude rules went missing after testing this PR. I have some backups of my settings, so no problem. Let's just make sure this doesn't happen for real users. |
@diivi Since this is only testing the interface, you can simply move it to |
@jetchirag Just moving these files to the =============================================================== FAILURES ===============================================================
___________________________________________________ test_exclusion_preview_populated ___________________________________________________
CALL ERROR: Exceptions caught in Qt event loop:
________________________________________________________________________________
Traceback (most recent call last):
File "/home/divyansh/Desktop/vorta/src/vorta/views/schedule_tab.py", line 106, in <lambda>
self.app.scheduler.schedule_changed.connect(lambda pid: self.draw_next_scheduled_backup())
File "/home/divyansh/Desktop/vorta/src/vorta/views/schedule_tab.py", line 175, in draw_next_scheduled_backup
status = self.app.scheduler.next_job_for_profile(self.profile().id)
File "/home/divyansh/Desktop/vorta/src/vorta/store/models.py", line 238, in profile
return BackupProfileModel.get(id=self.window().current_profile.id)
RuntimeError: wrapped C/C++ object of type ScheduleTab has been deleted
__________________________________________________________________________ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking all good, but the implementation can be enhanced. Currently exclude_dialog.py
and exclude_if_present_dialog.py
share a lot of code -> redundancy. For example you don't have to maintain to implementations of MandatoryInputItemModel
. Instead you can reference the same class in both files. Regarding the duplicate code in ExcludeDialog
and ExcludIfPresentDialog
you can inheritance to fix that. Move the duplicate code into a common super class and add the custom behaviour like different ui strings by overriding methods in the subclasses.
I tried doing this first, but got stuck with multiple inheritance - https://stackoverflow.com/questions/3277367/how-does-pythons-super-work-with-multiple-inheritance. In my case the exclusion dialogs had three classes to inherit from - (ExcludeDialogBase, ExcludeDialogUi, ExclusionDialogBase - which is the superclass). But I could not ininitialise all three with the same params. And qt forces me to use Also, I tried moving the Do you have an example of Qt widget superclasses in the Vorta codebase? |
You can have a look how @jetchirag has done it in #1749 for |
Is this still being worked on or abandoned? If the latter, we would need to see if we can finish the work somehow. |
I'll resume this, got a little busy with course work. I have exams during the first week of Ocotber, so I'll try to get this merged after that. I'll see if I can take out an hour everyday to complete this before that. |
Great! Any help, let us know here. Would love to see this included in the next release. |
I'm getting some errors with changing the presets list in the exclusion dialog, probably made an error in extending the Base Class. Will keep investigating. |
Hey Divi, Can we merge a simplified version of this with the original scope? I know we changed the scope last minute by including managing those "Exclude if present" files and then asking for subclassing those (both are correct in the long-term). If this is proving too hard (it's also a very niche feature), I'd just skip it and do a new branch and PR with just file exclusions, as originally planned. Same as what you present in your results: https://github.com/diivi/GSoC23-PythonSoftwareFoundation#project-achievements Let me know what you think. We can then add "Exclude if present" later or the few users who rely on it can use CLI args. |
Yup, sorry I've been a little busy with college and my internship hunt. I'll try to revert to the original approved version when I get a chance. |
@diivi , can you revert this to the exclude GUI only state? With the "exclude if present" text area field removed for now (but data settings still there). I think this would be a good starting conclusion of the project you also worked hard on and probably want to see merged and maintained. If you're busy and already left for new endeavors, I'll make the change some time after Wednesday next week. Thanks! |
Description
Progress updates for #907 will be added here. This is the base implementation which will allow the user to add exclude rules, select exclude presets to include, and edit/copy/paste the exclusions from a "Raw" tab.
TODO:
Related Issue
#907
Motivation and Context
Makes it simpler for the user to add excludes with a more intuitive interface.
How Has This Been Tested?
Testing this manually for all scenarios that I can think of.
Screencast.from.21-08-23.01.12.55.AM.IST.webm
Screenshots (if appropriate):
Types of changes
Checklist:
I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.
Follow ups