warning if no files are shared

[hboetes]

Sometimes, for whatever reason, I don't share files at startup. A share may be inaccessible, or the database may have become corrupted. And I don't notice until I download something from someone who has a leech plugin. I'd rather get a warning from nicotine+

Therefore I'd like to request showing a warning at start-up, if no files are shared.

[slook]

If this gets implemented as a "popup notification" then it must be off by default (or only appear in the case of a scanning error), because messages from Leech Detectors is already bad enough for nagging, we don't want to add to that situation.

Perhaps a popup would be okay in the event of "Errno 2", however using OS notifications for error messages is a very bad idea if something happens that cause the whole screen to get filled up with them (say for example, if there are many offline folders).

15:05:41 Error while scanning folder /media/USER/Music: [Errno 2] No such file or directory: '/medi...'...
15:05:41 0 folders found after rescan
15:05:41 Finished rescanning shares 

It would be useful if the last two entries were the other way around, or combined into one line, so that the count would stick on the Statusbar after a manual rescan, but startup scanning happens way too fast if there are 0 folders so it's wiped out by other startup messages.

[hboetes]

Right, not a system-notification, nor a "pop-up", since both interrupt the work-flow and are annoying.

On the other hand, not sharing files is something important. For example, the N+ icon dot could go red.

[slook]

the N+ icon dot could go red

It is a valid idea, however the user is likely to wonder why it looks like they are disconnected when they are not.

I think we should stick to improving the log system and what text is displayed and remains visible on the Statusbar, these are areas where improvements are less prone to introducing strange application behaviour.

[hboetes]

Having a clear message in the status bar sounds like a good plan indeed.

[slook]

Changed the log output of the scanner to this:

Perhaps we will append the number of errors encountered, but I don't think that information is counted at the moment.

[slook]

Startup performance is hindered by 'Scan on startup'. When launching from terminal, the initial stage of the scan process begins on the console before the GUI window is rendered. This creates a noticeable delay with the feature enabled vs disabled.

It makes me wonder if there should be an arbitrary few seconds delay to begin the scan process, this would both speed-up application launch and also ensure the "Rescan complete: nn" message is always last in sequence so it has a higher chance of sticking on the Statusbar.

Pending transfers should not be allowed to begin if there is a scan pending or in progress, because the file stats might not be accurate.

[hboetes]

Having a slowly pulsing "0 files shared" with a red background in the status bar(at the bottom right) sounds like a warning I'd like to receive. So the background would cycle between the normal bg and dark red in various shades, let's say 6 shades.

Like in this code:

while : ; do for i in {5..9} {9..5} ; do notify-send -t 500 -h 'string:bgcolor:#'$i$i'0000' -h 'string:fgcolor:#ffffff' 'battery at 10%';sleep 0.5; done; done

[slook]

That sounds pretty :) perhaps the progress bar widget could be made to do something similar with some style property.

In the case of 0 folders perhaps it could stay visible (the widget is under-used imo), and the "Scanning Shares" label be updated with the folder count, or the number of errors.

As a sidenote I have found that Scan at startup is done before login, which means stats don't get sent to the server at this point.

Edit: I've drafted a couple of changes which make the progress bar stick if there is a serious scanning error or there are 0 folders...

[mathiascode]

It would probably make sense to only allow a rescan if all the main shared folders are accessible, to prevent this issue from happening in the first place.

The best way to tell the user when this happens still needs to be explored, but the easiest route would be a message dialog that lists the folders that are inaccessible.

[slook]

It would probably make sense to only allow a rescan if all the main shared folders are accessible

I disagree, consider if a user may intentionally leave external drive(s) powered off or may routinely roam away from their home LAN/NAS, in which case it would be undesirable to entirely block rescanning of other locally available storage devices.

the easiest route would be a message dialog that lists the folders that are inaccessible

The importance of the shared folder status might warrant a permanent status bar widget icon/folder-count, that could be the parent of a popover containing a listview of folders/file-counts/statuses. Then it could be popped-up in the case of an error or zero-folder count without causing a severe interface blockage.

folder-publicshare-symbolic

media-eject-symbolic

drive-harddisk-usb-symbolic

drive-removable-media-symbolic

Such a popover might contain small buttons for "Rescan Shares" and "Configure Shares..."

[mathiascode]

It would probably make sense to only allow a rescan if all the main shared folders are accessible

I disagree, consider if a user may intentionally leave external drive(s) powered off or may routinely roam away from their home LAN/NAS, in which case it would be undesirable to entirely block rescanning of other locally available storage devices.

It's problematic in cases where the drive being unplugged wasn't intentional, or you forgot about it. The shares database is rewritten before you realize that the drive isn't mounted, requiring a rescan from scratch for all files in that folder.

One option could also be to add a "force rescan" button in the dialog, in case the user still wants to rescan their shares.

[slook]

the drive isn't mounted, requiring a rescan from scratch for all files in that folder

Good point, that could be long. Of course there is only one database for all the shares.

Are you saying to first check to verify the presence of each shared virtual folder path on disk, and then prompt with a dialog detailing the status of missing folders? This does sound like a good idea.

If so, the proposed "Force Rescan" button might be ambiguous for a "Retry" or "Refresh" function that simply performs an initial presence check again.

[hboetes]

Of course there is only one database for all the shares.

Now that you mention it, perhaps create a DB per share? So in case a share is not online it doesn't get lost, it's just not available, just like the FS.

[slook]

That would be the most ideal solution in the long run, but unfortunately that is far beyond the scope of this issue.

[mathiascode]

Are you saying to first check to verify the presence of each shared virtual folder path on disk, and then prompt with a dialog detailing the status of missing folders? This does sound like a good idea.

Exactly. This should only require a os.access() call per virtual folder path, so it should be quite fast.

Now that you mention it, perhaps create a DB per share?

This is something I've had in mind, but it requires a lot of work and rethinking how we do certain things.

[slook]

It would probably make sense to only allow a rescan if all the main shared folders are accessible, to prevent this issue from happening in the first place.

This actually does make sense, but there still might be use cases for continuing with offline shares in certain scenarios. A function for Refresh/Retry is going to be needed as well as Force Rescan, to enable the user to mount their drive on the fly.

The best way to tell the user when this happens still needs to be explored, but the easiest route would be a message dialog that lists the folders that are inaccessible.

In PR #2210 the missing folders are logged and also could be available for populating the content of a message box. Such a message dialog will be unavoidably obstructive, but it is a necessary step that will help us develop a better non-blocking solution.