Indicator added to be able to see/identify what files have already been downloaded when viewing a User's files/share

[DeathStalker77]

Describe the solution you'd like

When I am viewing a User's files - whether from SEARCH Results or BROWSE FOLDER/FILES - there should be an indicator (or color) that shows what files I have downloaded from them previously.

Many of us re-organize our content, so we have no idea WHO we have downloaded from in the past, as the files are no longer under a User Name folder.

This feature would help eliminate the potential for downloading duplicate files.

This could also be expanded (maybe via file hashes) to include the SAME file/s from other users as well!

Additional context

Add any other context or screenshots about the feature request here.

[slook]

This suggestion is valid and obviously desirable, however it has been investigated before and any method that is currently available of tracking this data is not performant enough to be processed from within the main interface thread.

As a compromise, it would be viable to add a volatile indicator that remains for each search session as suggested by another user in #2145 (comment) ... it essentially is a case of changing the visual style (to italic for instance) of the row text on double-click/enter activation.

[DeathStalker77]

@slook - why not just create an additional DB file to store the entries in? You could easily store the files by string or hash. A simple columnar table would seem to suffice. The 2nd part would be a compromise, but if you could do italics, why not color/highlight? Thanks!

[slook]

@DeathStalker77 - because we cant just wang stuff in willy nilly and hope for the best, the project has thousands of users who need the program to run reliably and not just be crashing all the time due to bugs that nobody has the time to fix, since currently there is only really one active lead developer, Mat, who has the knowledge, skill and dedication to implement all this stuff properly, whilst also keeping the rest of the code base maintained so that it will run on modern platforms (with Python 3, i.e. newer than Windows XP). Frankly it's amazing that we even have N+ at all, something like this project is not ordinarily possible.

For every new feature, there is a bunch of work that must be done before, during and afterwards. For the additional DB that you are proposing, it would fundamentally change the core workings of several modules, of course leading to unexpected issues to resolve and follow-up feature requests that have the potential to be never ending. For example, in this case I could see that after implementation row highlights it could then seem to become desirable for the search module to have a closer integration with the transfers module like having inline progress bars, then perhaps somebody will then want the ability to pause/resume from the search interface, be able to see the speed, change the destination folder path, etc. All these things would be lovely, yes, but this extra complexity all comes with a high cost of time and effort on the part of the dev(s) who have the guts to undertake this heavy work (both now and in the future). [end of rant!].

store the files by string or hash

Sadly the remote peers on the network, that the client is forced to be compliant with, don't expose file hashes within search result responses, so there is no data available that could enable such a comparison to be made. Hence, the original path data would have to be stored in a giant database of some sort such as is proposed herein.

why not color/highlight?

I agree an alternate row highlight style, other than the normal user selection highlight, would be a nice thing to have to better indicate client activities. My understanding is that sort of thing is not worth spending the time and effort on until the migration from the deprecated GtkTreeView widget in GTK 3 to the new GtkColumnView and GtkListView widgets in GTK 4 is fully completed (i.e. probably after 3.3.0, 3.4.0 or 4.0+). Until then, this feature request will unfortunately be blocked.

could do italics

Meanwhile, this could be a good step in the right direction. However the font rendering of italics looks ugly on some systems.

[DeathStalker77]

I can certainly understand any aspect of this being delayed by the necessary transition work from GTK3 to GTK4 - clearly, we would want all of that completed & debugged before implementing new features from that framework.

With respect to the hash - I was referring to the hash being generated by the local downloading client, not being received from the uploading client.

I understand where you are going with the "other desirable features" list - again, as a product owner, you always have a backlog of items, it's simply a matter of prioritizing them efficiently.

I would like to understand more, about how adding a new "tracking db" would "fundamentally change the core workings of several modules" - perhaps you could DM me with that info? Again, while I am not a coder, I am a certified Product Owner (PSPO II), and a "developer" - and this is what I do for a living. And I cannot agree more that I wish we had more qualified people stepping up to the Dev plate to help out!