wish: config list of "preferred dirs" to control select

[Rufus Laggren]

When dealing with 100k++ number of files it would GREATLY, HUGELY help if one could build, on the fly, a list of "preferred dirs". When activated (various ways possible) the "preferred dirs" feature would, when a "preferred dir" existed in a group, automatically select dupes (lines) within each group which did NOT contain the "preferred dir". When the "preferred dirs" feature left more than "n" line(s) unselected in a group (multiple files w/same "preferred dir", or multiple "preferred dirs" in same group) those groups would (optionally, set in preferences) be highlighted for easy identification for further selections; alternatively, groups with n unselected lines or less (see below), based on "preferred dirs", could be hidden or auto-collapsed which would leave normal groups, or those w/too many unselected lines, visible for normal editing. Thinking about it, the second options seems cleaner, less "busy", an easier interface to work with. A group could not be highlighted, hidden or collapsed unless it contained "preferred dirs".

There are probably other useful perversions of this idea possible but I only can visualize the above at this point. The "n" number maybe could be made part of processing each group and serve additional functions but I have not tried to evaluate that, especially not knowing the logic flow you use.

The preferences setting could:

1) Enable/disable the feature.

2) Spec n where "number of unselected lines" > n either causes highlighting, or disable hide/collapse for that group. Default n=1.

3) Select highlighting, hide/collapse, or "no special display" for groups altered by this feature.

Usage: On the fly, when working with a group, one could rt-click on the _unselected_ line(s) and add the dir on that line to a "new preferred" list; when satisfied, the "new preferred(s" would be posted to the active "preferred dirs" list. (The rt-clk context menu could have the top choice "add single dir" and the second choice "add multiple dirs" so that the common(?) case where there is only one "preferred dir" would be quick and easy.) The new items would be active immediately in the current session. If no "preferred dirs had been defined yet for this session or if a list had not been loaded, the "add dir" click would open a "new list" dialog. Once defined or loaded for a session, that "preferrred dirs" list would be used automatically for all succeeding processing (dupe selection) until the "preferred dirs" context menu or dialog was invoked again (by rt-clicking on an unselected line). Ideally a config file containing this list and other options defined for this session could be automatically associated with a saved search and loaded, eg. from the "File" menu.

It would be greatly helpful if the auto-selections would be immediately applied. This instant clutter reduction would greatly speed and simply subsequent selection process resulting in a huge time savings.

Fslint is a fine, Fine tool. It's just that wading into gigabytes of overgrown data directories, screwed up with multiple overlapping restores or syncing runs over years, using slightly (or greatly) differing directory structures is still a really, really bad job. In the job I'm just completing (which inspired this post) there were 200k++ files w/an average of 4 dupes; there were dozens in some cases but those are special. Unfortunately the first/last choices just didn't work at all for this job.

A perversion of this filter which just occurred to me would be a "must retain" list. It would need to be built from a gui by clicking high (or low) on the directory tree, though - else the build for a new job would probably be prohibitive for the user.

Regards

Rufus
(sorry if there is a better place to post suggestions - didn't see it right off.)

[Pádraig Brady (p-draigbrady)]

On 31/03/17 10:19, Rufus Laggren wrote:
> Public bug reported:
>
> When dealing with 100k++ number of files it would GREATLY, HUGELY help
> if one could build, on the fly, a list of "preferred dirs". When
> activated (various ways possible) the "preferred dirs" feature would,
> when a "preferred dir" existed in a group, automatically select dupes
> (lines) within each group which did NOT contain the "preferred dir".
> When the "preferred dirs" feature left more than "n" line(s) unselected
> in a group (multiple files w/same "preferred dir", or multiple
> "preferred dirs" in same group) those groups would (optionally, set in
> preferences) be highlighted for easy identification for further
> selections; alternatively, groups with n unselected lines or less (see
> below), based on "preferred dirs", could be hidden or auto-collapsed
> which would leave normal groups, or those w/too many unselected lines,
> visible for normal editing. Thinking about it, the second options seems
> cleaner, less "busy", an easier interface to work with. A group could
> not be highlighted, hidden or collapsed unless it contained "preferred
> dirs".
>
> There are probably other useful perversions of this idea possible but I
> only can visualize the above at this point. The "n" number maybe could
> be made part of processing each group and serve additional functions but
> I have not tried to evaluate that, especially not knowing the logic flow
> you use.
>
> The preferences setting could:
>
> 1) Enable/disable the feature.
>
> 2) Spec n where "number of unselected lines" > n either causes
> highlighting, or disable hide/collapse for that group. Default n=1.
>
> 3) Select highlighting, hide/collapse, or "no special display" for
> groups altered by this feature.
>
> Usage: On the fly, when working with a group, one could rt-click on the
> _unselected_ line(s) and add the dir on that line to a "new preferred"
> list; when satisfied, the "new preferred(s" would be posted to the
> active "preferred dirs" list. (The rt-clk context menu could have the
> top choice "add single dir" and the second choice "add multiple dirs" so
> that the common(?) case where there is only one "preferred dir" would be
> quick and easy.) The new items would be active immediately in the
> current session. If no "preferred dirs had been defined yet for this
> session or if a list had not been loaded, the "add dir" click would open
> a "new list" dialog. Once defined or loaded for a session, that
> "preferrred dirs" list would be used automatically for all succeeding
> processing (dupe selection) until the "preferred dirs" context menu or
> dialog was invoked again (by rt-clicking on an unselected line). Ideally
> a config file containing this list and other options defined for this
> session could be automatically associated with a saved search and
> loaded, eg. from the "File" menu.
>
> It would be greatly helpful if the auto-selections would be immediately
> applied. This instant clutter reduction would greatly speed and simply
> subsequent selection process resulting in a huge time savings.
>
> Fslint is a fine, Fine tool. It's just that wading into gigabytes of
> overgrown data direct...

[Rolf Leggewie (r0lf)]

It sure sounds awfully complicated. Please don't overengineer this. It absolutely sounds like this could already be achieved by bind-mounting.

[Rufus Laggren (rlaggren)]

> accomplished with "bind-mounting"...

OK. Not familiar w/that wording/concept. Will investigate when next I'm
looking at a big file-pile job.

Rufus

On 04/22/2018 02:09 AM, Rolf Leggewie wrote:
> ** Changed in: fslint (Ubuntu)
> Importance: Undecided => Wishlist
>
> ** Changed in: fslint (Ubuntu)
> Status: New => Confirmed
>