First off, hooray for first post. Hope it doesn't become a long one. XD
Second off, I'll clarify on the subject, I'll explain the scenario I'm in, because either of the features in the subject text would work for my case. However, both may be used in different ways to be very useful.
Simply put, I want a path folder format to force thumbnail view when viewing album folders, but not when viewing inside those folders. Currently, with the way my music collection is structured, this is impossible to do in a future-proof way, meaning I do not want to hard-code separate paths for each main album folder, in which I have plenty because of my OCD-fantasm (Hallelujah -.-).
Here is my actual structure, with some extra examples at how impossible this is to do currently: pastebin.com/72eTdN02
So, two ideas can be implemented to fix this.
Implement a file/folder filtering exclusion option to force DOpus to disallow the using of the folder format if any of the listed folders/files exist in the current folder. (Of course this would need to have a list and/or regex/wildcard options, but preferably a list with regex/wildcard options)
Implement a simple 2-part feature for the Path Format dialogue. A: A checkbox to always give priority to a Content Type Format if one exists for the current folder. B: A number-only textbox to specify a priority in integer form for what folder formats take precedence.
Other ideas may even be able to improve on mine. Perhaps combining certain features or finding another way to make this work better for someone else's case may be useful as well?
I would honestly like to see this implemented. It is frustrating as my current folder formatting has thumbnails across my entire music collection. If I open an album, BAM! I get a huge posterboard of thumbnail'd FLAC music files with album art.
You could do this using scripting, having the OnBeforeFolderChange or OnAfterFolderChange look at the folder being changed to, apply whatever logic you want, and then change to thumbnails mode if desired.
I guess the issue is, that DO currently does not take the number of folders/files into account, when the folder format system trys to detect the content-type, so a single image in a folder containing 40 more folders, would still give you thumbnails view e.g.
Consider testing the OverrideFormats add-in linked below. It allows you to activate a viewmode or format based on the number of folders/files, path or drivelabel. I can add checking existence for specific files or folders, but maybe you already get along with it how it is. I'd suggest testing against a path and wether there are more files than folders present and let the overrrider switch to your prefered view mode (details in this case if I understood you correctly).
Problem is, if every esoteric situation was handled natively, using the native folder formats system would be no less complex than writing a script, and people would have to battle that complexity when doing common things as well as esoteric ones.
Scripting is thus the ideal solution for a lot of these problems. (Of course, we may still add to what folder formats can do without scripting, where it makes sense.)
I'm with you when it comes to adding a fullscreen dashboard with switches and options to define a folder format, that's not everyones taste and probably no good even for more experienced users. But I think, reusing something like the filter- or seach-query-editor to setup conditions, which must be met before a folder format applies, could be a solution to cover these esoteric sitations. Complexity would be up to the user with that at least.
Additionally, most folder format related "flaws", don't get me wrong I like folder formats, are not very esoteric. The number of files or folders in a folder for example, is something that should have an influence on the format chosen by DO. To me at least, that it is much more significant, than what subfolders contain (which is something DO already tries to detect).
Scripting would be an ideal solution, if it would not disable the complete event-chain. If you use OnBeforeFolderChange to jump in and override a format, any addins using OnAfterFolderChange will not be triggered. I understand that precaution taken here, but it seems not required. Using OnAfterFolderChange on the other hand, to keep the event-mechanics untouched, results in a nervous display, which is annoying whenever you enter a folder showing "details" by default, and a fraction of a second it switches to "thumbnails" for example.
The OnBeforeFolderChange event alternatively could support some properties to override the complete format or just parts of what will be chosen by DO (viewmode or columns e.g.), that would be really neat and elegant. Currently a scripted solution has drawbacks and not using scripting has drawbacks too.
Neither of those things would work to solve this problem, or any others that have come up which I can think of. Filters work on the item in question and have no concept of child items or counting types of child items.
Perhaps the Content Type system could be expanded slightly. I'm not sure, though. People already found it confusing as it is, and kept asking why the format changed (even with a help bubble appearing when it did), to the extent we disabled it by default.
Seems like most cases involving counts of sub-folders are to eliminate intermediate levels in a hierarchy, which can often be done using the existing regexp formats (but not in this thread's case as the irregular hierarchy is probably impossible to define as a regexp).
Are there many cases where people would want two separate scripts to both affect the same folder, one before and the other after the change? We might be able to make changes there if it's the only thing stopping scripting from being the right solution.
I do not have that option enabled for images, but I have for the "music" type content. I tried around another time and at first it looks like that option would be ok for browsing my images. But I remember several situations where the format system failed because of other filetypes mixing in or the threshold in combination with subfolders was hard to find.
Imagine a folder containing 1 folder and 1 image, thumbnail view quite ok. Now image 100 folders and 100 images, same ratio, but for that many folders, I'd prefer details view. I also prefer details when there are a thousend and more images, that amount just takes to much time to render thumbnails/scroll through.
Not sure if these cases are the esoteric ones, but I was able to handle them with just 2 lightweight expressions in my OverrideFormats-thing.
[code]#use details view for more than 3 folders
folderCount>3 && setView('details')
#use details view for more than 1000 files
fileCount>1000 && setView('details')
[/code]
I guess that's something which also fits into an imaginary format-rule editor, but I'm ok with how it works by script curently, despite that cut-off events-thing of course, as I need to use GO NOSCRIPT in OnBeforeFolderChange for this to work. o)
Seeing as the extension is a more indirect fix, I too, feel it needs to be added natively in some way, some day.
So, just to make sure, did anyone see my second idea for adding native support for this? I feel it might be the easiest to code (based on my coding knowledge, but I do not know a lot), and would be, at the lowest level, both a simple checkbox and a single textbox for each Path Format. I rewrote my OP post below for idea 2, to fix any shady statements, and I also expanded on it a bit (found out I couldn't edit my post later, which I usually depend on to fix my statements that are confusing, because they often are confusing xD):
If this is possible, I feel this may eradicate the both the issue with subtlety and getting the proper results, but what do you all think?
