I suggest here an alternate way to set the number of thumbnails shown in a row
rather than the slider we have now.
A slider suggests a continuous varying value but the current functioning of the slider is in steps.
It actually changes the number of thumbnails per row.
(https://www.photools.com/community/index.php?action=dlattach;topic=9176.0;attach=22050)
Easier to understand would be a PLUS/MINUS functionality which allows us to increase/decrease the number of thumbnails.
(https://www.photools.com/community/index.php?action=dlattach;topic=9176.0;attach=22052)
PLUS Icon: Increase the number of thumbnails (like clicking to the left of the slider)
When the maximum number that can be shown is reached the icon turns red. Clicking the red PLUS icon will
increase the number of thumbnails but information will be lost. This additional functionality may be hard to implement.
MINUS Icon: Decrease the number of thumbnails.
Like clicking to the right of the slider but when the 1:1 setting is reached the icon will turn red.
When the red MINUS icon is clicked it will reduce the number of thumbnails further.
This will be good if the user has selected to enlarge thumbnails.
1:1 Icon: Each thumbnail is shown full width (1 pixel on screen one pixel in thumbnail)
This will also make the MINUS icon turn red.
This sounds for me very good.
+1
1. Consider tabular layouts.
2. New file window types will appear in IMatch at some time, which use (react on) this slider in different ways.
+1 die the Initial request
+1 for the request
+1 - Something I would definitely use.
I would rather appreciate the slider to do the action promised by it's tooltip, IOW to set the item size instead of the number of rows!
I routinely change the size of the windows and I would prefer to get a (nearly) constant size of thumbnails instead of a constant number of rows!
That's how my other tools work, e.g. DxO Photolab or Faststone Image Viewer.
Photolab resizes the thumbnails to fill the space completely, but dynamically calculates the number of rows to achieve the selected size as good as possible.
Oliver
+1 for the original request, but reversed: "+" meaning larger thumbnails and "-" meaning smaller ones.
I still don't see the advantage of setting a number of rows instead a certain size of thumbnails.
For comparison / demonstration, I made now a screencast how the Photolab browser does it (see attachment).
In contrast to DxO Photolab, the FastStone browser does no "realtime" changes during a window resize, and it doesn't tweak the thumbnail sizes to fill the window.
Both features are a matter of taste, I think the DxO Photolab version is pretty good but FastStone is also o.k.
The essential difference to the IMatch file window is that both keep the thumbnail size "constant".
I assume the difficulty with a continuous change of thumbnail size would be the display of the various icons and the
need to be able to click those icons. Photolab does not have this requirement.
Quote from: ubacher on July 22, 2019, 12:20:55 PM
I assume the difficulty with a continuous change of thumbnail size would be the display of the various icons and the
need to be able to click those icons.
So you support my suggestion, and not keeping the current IMatch implementation of "constant number of rows"?
Remember that the current IMatch "constant number" implementation already has a
much larger change in size. That's exactly what I want to avoid by setting "constant size" instead.
Oliver
Buttons or Slider, I don't care.
What about Ctrl + Mouse wheel? Like in Windows Explorer, ACDSee, LR,...
You can change the file window thumbnail size using the slider with the mouse or the keyboard (click the slider, then use the cursor keys for finer control).
IMatch telemetry shows that the thumbnail size is changed in less than 1% of all sessions. Most users apparently set it once (maybe once per layout they use) and that's it.
Not worth implementing additional modes of operation for this small feature.
The file window in IMatch is rather complicated and optimized to the hilt.
The ability to display 50,000 or 100,000 files (!) (even 500,000) quickly, even if the user displays tons of custom metadata or even complex variables is a real challenge.
Try to display 50,000 files in Lr or Windows Explorer to see what I mean...
And to make all this magic work, IMatch does some real clever things and these clever things may require some minute 'limitations'. For example that the thumbnail panels cannot be resized pixel-wise but only in certain steps. This makes some things less complicated internally, and this results in better performance.
I am new to IMatch so I don't know how all functions interact. I just can make suggestions.
Quote from: busbahnhof on November 07, 2019, 08:44:36 AM
I am new to IMatch so I don't know how all functions interact. I just can make suggestions.
And that's good of course!
New users bring fresh ideas or have different user interface expectations because they have used other applications before.
The feature request board is meant to 'vent' ideas and suggestions. I'm open to everything.
But not everything suggested can be implement for technical reasons.
And some things would only useful for a handful of users and thus would not be economical or reasonable to implement.
I can implement a feature useful for the majority of users in the same time, after all.
On the other hand, sometimes 'niche' features are quick to implement, test and document. And then I add them anyway. And suddenly, many users like it...
If in doubt, always post a feature request. Other users can comment and +1 the request to show their support.
If a request is discussed often or many users quickly +1 it, it moves up on my to-do list.