Various discussion boards for XnView and related products
https://newsgroup.xnview.com/
this is ridiculously unusable approachm.Th. wrote: Sun Nov 19, 2023 6:23 pm It is much better to implement it through RMB menu on the root node of each group - that is „Rating”, „Color” and „Albums”. We need a decisive action from the user's part in order to display them.
Here the problem is that it isn't discoverable, but a tooltip can fix that.
it must be magic how other apps (Capture One, Lightroom, etc) have implemented this techniquem.Th. wrote: Sun Nov 19, 2023 6:23 pm Trickier to do for Albums because for many albums and many photos it can be slow.
It is not magic. I have been a DB/UX programmer for more than 30 years now. It is an aggregate SQL query on DB and knowing exactly the underlying DB schema on both XnView and Lr, I know what I am saying. Do you know?it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..
Harsh words. Care to explain?this is ridiculously unusable approach
rly? hope you're a better db than UX "programmer".m.Th. wrote: Sun Nov 19, 2023 7:48 pmIt is not magic. I have been a DB/UX programmer for more than 30 years now. It is an aggregate SQL query on DB and knowing exactly the underlying DB schema on both XnView and Lr, I know what I am saying. Do you know?it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..
Code: Select all
XnView.db
SELECT albumid, COUNT(*) FROM albumslink
SELECT rating, COUNT(*) FROM images GROUP BY rating
SELECT color, COUNT(*) FROM images GROUP BY color
I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.m.Th. wrote: Sun Nov 19, 2023 7:48 pm Bad Lr design decisions hinder the size of catalogs which is also a common problem for Lr.
You're missing the point.m.Th. wrote: Sun Nov 19, 2023 7:48 pm At startup, DB/computer is hammered by a lot of requests especially because of the Thumbnails engine/browser. Parallelization here actually can make the things slower than faster, if we are talking about enough queries and data.
Deferring the queries over DB is the way to go IMHO.
Explain why clicking on every Rating/Color/Album to check its counter is bad idea?m.Th. wrote: Sun Nov 19, 2023 7:48 pmHarsh words. Care to explain?this is ridiculously unusable approach
Sorry, but you are overly aggressive. I still expect some links from you about UX principles WRT Lr, but besides that, it isn't appropriate to make continuous attacks „ad hominem”.rly? hope you're a better db than UX "programmer".
The first one is problematic because in albumslink table is a m:n relationship which in some cases will explode the table's cardinality.now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds
Sorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.You're missing the point.
I'm not talking about multiple simultaneous queries at "startup time".
App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
yes. Thinking that your user case is the only one. Is not. I am not complaining also about this, but this issue is (was?) a common one in communities.I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.
I didn't say this. Re-read, please. I said „on the root of each group”. That is on the nodes labeled „Rating”, „Colour Label”, „Album”.Explain why clicking on every Rating/Color/Album to check its counter is bad idea?
Which is the main purpose in your opinion and how often do you look at them? (especially at the counter(s) of (an) album(s))against main purpose of such counters
I encourage you to go and re-read mentioned topic, starting from your offtop about app design/speed/bug that ended up with Photoshop-PowerPoint comparison. I have nothing to add there.m.Th. wrote: Wed Nov 22, 2023 9:10 amSorry, but you are overly aggressive. I still expect some links from you about UX principles WRT Lr, but besides that, it isn't appropriate to make continuous attacks „ad hominem”.rly? hope you're a better db than UX "programmer".
There are UNIQUE("AlbumID","ImageID") constraint and cascade deletion. What "some cases will explode the table's cardinality" are you talking about.m.Th. wrote: Wed Nov 22, 2023 9:10 amThe first one is problematic because in albumslink table is a m:n relationship which in some cases will explode the table's cardinality.now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds
Code: Select all
SELECT albumid, COUNT(*) FROM albumslink GROUP BY albumid
you didn't quote the whole paragraph on purpose, did you?m.Th. wrote: Wed Nov 22, 2023 9:10 amSorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.You're missing the point.
I'm not talking about multiple simultaneous queries at "startup time".
App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
user0 wrote: Mon Nov 20, 2023 7:39 am App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
When data is ready, it will be shown in counters.
If user is lightspeed fast and clicks on any filter while some counters are pending, their execution is delayed until user's request is completed.
Google says people have no issues with 1M photos in catalog of current Lr. Those who complain about "CatAlOg SiZe" don't realize that there are many other things that can slow down Lr.m.Th. wrote: Wed Nov 22, 2023 9:10 amyes. Thinking that your user case is the only one. Is not. I am not complaining also about this, but this issue is (was?) a common one in communities.I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.
Besides that, 100k files is a LOW number of files.
FYI, statistically speaking a wedding photographer shoots ~100k photos / year. Usually, there are two of them. A sports photographer shots even more/year (especially if we have a major sports event in his/her field). A war/crisis photographer even more (depending on assignment).
Thats the issue, a) there shall be option to switch off auto-import and b) Catalog shall be browsable.m.Th. wrote: Wed Nov 22, 2023 9:10 am However, the most important part is (again) XnView MP is very different than Lightroom. Lr is NOT a multimedia file browser. You NEED to do an „Import” there in order to work with the files.
In XnView MP every folder you look at, it gets scanned and, so, the DB grows much more quicker than in the case of Lr.
Manual import adds no drawback to this process.m.Th. wrote: Wed Nov 22, 2023 9:10 am One of the main use cases of XnView MP is to quickly have the files on the SSD, select/tag them - Batch Convert them (it has the fastest Batch Conversion engine for professional news photographers AFAIK - yes, I searched) and publish them.
It does not make your idea any better.m.Th. wrote: Wed Nov 22, 2023 9:10 amI didn't say this. Re-read, please. I said „on the root of each group”. That is on the nodes labeled „Rating”, „Colour Label”, „Album”.Explain why clicking on every Rating/Color/Album to check its counter is bad idea?