Made Scheduler independent from Klamscan's DirectoryList (solves #20) #24

Merged
MicheleC merged 1 commits from issue/20 into master 3 years ago
Collaborator

This solves issue #20.

Signed-off-by: Mavridis Philippe mavridisf@gmail.com

This solves issue #20. Signed-off-by: Mavridis Philippe <mavridisf@gmail.com>
blu.256 added the PR/rfc label 3 years ago
blu.256 added 1 commit 3 years ago
7f98cf0f62
Made Scheduler independent from Klamscan's DirectoryList.
Owner

Hi Philippe,
it looks good and work well. A couple of comments to discuss together.

  1. IMO, after scheduling a scan, it would be good to deselect all items on the directory list so the user can immediately select a different folder for a different scheduled scan. What do you think? This can be done in a separate PR, eventually.

  2. If the user select a folder in the main window and then press "Schedule" (which is the behavior before this PR) it would make sense to open the new schedule window while retaining the initial folder selection (like the old code), meaning those folders would be automatically selected on the left directory list. What do you think?

Hi Philippe, it looks good and work well. A couple of comments to discuss together. 1. IMO, after scheduling a scan, it would be good to deselect all items on the directory list so the user can immediately select a different folder for a different scheduled scan. What do you think? This can be done in a separate PR, eventually. 2. If the user select a folder in the main window and then press "Schedule" (which is the behavior before this PR) it would make sense to open the new schedule window while retaining the initial folder selection (like the old code), meaning those folders would be automatically selected on the left directory list. What do you think?
Poster
Collaborator

Hello Michele,

Apropos 1: I think this would make sense only if we had the same behaviour for the directory list in the main window. That's a good idea. So, I'd suggest to leave this for a separate PR which would modify both directory lists' behaviour.

Apropos 2: I think that this could be potentially confusing, especially for those who use KlamAV for the first time, but we could make it work.

Well, currently we have two ways of invoking the Scheduler dialog: no. 1 is through the Scan tab and no. 2 is through the menu bar on the top. They both use the same slot. So, we could actually pass the directories from the main window's dirlist only when the Scheduler was invoked through the Scan tab's "Schedule" button.

I still think that this would be somewhat confusing, though. What do you think?

Hello Michele, Apropos 1: I think this would make sense only if we had the same behaviour for the directory list in the main window. That's a good idea. So, I'd suggest to leave this for a separate PR which would modify both directory lists' behaviour. Apropos 2: I think that this could be potentially confusing, especially for those who use KlamAV for the first time, but we could make it work. Well, currently we have two ways of invoking the Scheduler dialog: no. 1 is through the Scan tab and no. 2 is through the menu bar on the top. They both use the same slot. So, we could actually pass the directories from the main window's dirlist only when the Scheduler was invoked through the Scan tab's "Schedule" button. I still think that this would be somewhat confusing, though. What do you think?
Owner

Hi Philippe,

@point 1: separate PR sounds good to me 👍

@point 2: I was talking specifically about the case when "Schedule" was invoked from the "Scan" tab button (hadn't spotted the menu entry). After thinking about your comment and considering that 1. there are two ways to call the schedule dialog and 2. klamAV is a new addition to TDE (== there are no active previous users), I think your implementation makes sense. We open the dialog and all scheduling related activities happen within such dialog. The dir list on the "Scan" tab will be used only for scanning. In such case, in the new PR for point 1 we will reset the selection only in the dir listing inside the "schedule" dialog, not the one in the main "scan" tab.

So if all ok for you too, I can merge this PR as is.

Hi Philippe, @point 1: separate PR sounds good to me :+1: @point 2: I was talking specifically about the case when "Schedule" was invoked from the "Scan" tab button (hadn't spotted the menu entry). After thinking about your comment and considering that 1. there are two ways to call the schedule dialog and 2. klamAV is a new addition to TDE (== there are no active previous users), I think your implementation makes sense. We open the dialog and all scheduling related activities happen within such dialog. The dir list on the "Scan" tab will be used only for scanning. In such case, in the new PR for point 1 we will reset the selection only in the dir listing inside the "schedule" dialog, not the one in the main "scan" tab. So if all ok for you too, I can merge this PR as is.
Poster
Collaborator

Hi Michele,

I think it's all okay and this PR can be merged now. :)
Considering the last release of KlamAV was 12 years ago, it's safe to assume that nobody would miss the old behaviour (which might have been done this way because of a limitation of directorylist that was solved with commit d7f74c30f3).

Hi Michele, I think it's all okay and this PR can be merged now. :) Considering the last release of KlamAV was 12 years ago, it's safe to assume that nobody would miss the old behaviour (which might have been done this way because of a limitation of directorylist that was solved with commit d7f74c30f3).
Owner

Please can you do rebase to current head to allow keep your gpg key when merging?

Please can you do rebase to current head to allow keep your gpg key when merging?
blu.256 added 2 commits 3 years ago
aee7571c5b
Translated using Weblate (Russian)
96e6a702e1
Translated using Weblate (Greek)
Poster
Collaborator

Whoops, I think I did it wrong. Time to read the man pages again, I guess...

Whoops, I think I did it wrong. Time to read the man pages again, I guess...
blu.256 force-pushed issue/20 from 96e6a702e1 to 8af10422f0 3 years ago
Owner

Checkout the branch, then "git rebase -S origin/master" followed by a forced push to the branch. Before the push, you can use git log to make sure you did the rebase correctly (for example "git log HEAD --oneline -n 10 --decorate")

Checkout the branch, then "git rebase -S origin/master" followed by a forced push to the branch. Before the push, you can use git log to make sure you did the rebase correctly (for example "git log HEAD --oneline -n 10 --decorate")
Owner

Or you can use the commit graph on TDE after the push.
https://mirror.git.trinitydesktop.org/gitea/TDE/klamav/graph

Or you can use the commit graph on TDE after the push. https://mirror.git.trinitydesktop.org/gitea/TDE/klamav/graph
blu.256 removed the PR/rfc label 3 years ago
MicheleC merged commit 8af10422f0 into master 3 years ago
MicheleC deleted branch issue/20 3 years ago
MicheleC added this to the R14.0.10 release milestone 3 years ago
Owner

Thanks for the great work!

Thanks for the great work!
The pull request has been merged as 8af10422f0.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/klamav#24
Loading…
There is no content yet.