I use folder content detection so, for example, my pictures folders always appear in thumbnails view.
Now, I have a Lister Style I call "Normal", which I use if I've been using other modes, such as Film Strip etc. In this Lister Style "Normal", I have the View Mode option enabled and set to "Auto".
The hope was that I could use this "Normal" Lister Style to reset everything back to the default state, where Folder Content Detection took over. This appears to work for all View Modes except thumbnails unless I specifically save the Folder Format as thumbnails for that folder.
Example where my "Normal" Lister Style works:
o Create a new folder on my Desktop and copy some mp3s into it.
o Open that folder and it is shown using my Music Folder Content detected format - Details Mode with some specific columns.
o Change the mode to List View.
o Apply my "Normal" Lister Style.
o The view mode changes back to Details, as per Folder Content detection.
Example where my "Normal" Lister Style does not work:
o Create a new folder on my Desktop and copy some images into it.
o Open that folder and it is shown using my Images Folder Content detected format - Thumbnails mode.
o Change Mode to List View.
o Apply my "Normal" Lister Style.
o The view mode changes to Details mode, which is incorrect as thumbnails view is the Content Type Format view mode.
How to "fix" this:
o Re-open the folder on my desktop that contains the images, from a brand new Lister, and it should appear in thumbnails view as normal. Then open the Folder Format options window and save this specific format for this folder.
o Now change the view to List mode and then apply the "Normal" Lister Style and it will change back to thumbnails.
So from all this, it appears as though the "Auto" View Mode in a Style is not working correctly with Thumbnail View Mode for Automatic Content Type Formats. Unless of course I have totally misunderstood something.
Another thing. If I'm viewing a folder formatted with Content Detection and this Folder Type Content has a lister background image set, and I change view modes and then go to another folder that falls under the "Custom" Default Format, the background image from the previous Folder Content Type remains visible until I go to a folder with another lister background. I have even specifically told my "Custom" Default Format to have No Image. Everything else changes to the Custom Default Format but the image remains.
There is a known issue that both Leo (Nudel) and I have reported that displays this exact behavior. However, our issue was when the subsequently listed folder was a Windows namespace (virtual folder) like: My Computer, Control Panel, Printers and Faxes, et cetera. Are you seeing this behavior with a normal folder path? Please provide more detailed information, and I will try to recreate the issue.
As to the other things you've seen at the top of this thread, I've seen some of those as well. I have a lot of notes on it, I have to go dig them up.
Okay, I have found two unsubmitted issue reports that I started writing a few months back, both of which are related to your first post. From what you have described so far, you are trying to use Content Type formats exactly the same as I was back then. I didn't have enough time to look deeper into the issues, so I just jotted down a couple of quick things to look for in the future. I then disabled Content Types and Background images in my Opus configuration shortly after, so the issues haven't bothered me since then. (I enable my Content Type Formats manually when I want to use them.)
In my notes, I left myself a reminder that I needed to do a lot more testing, observation, analysis, and come up with some reproducible steps, and some concrete suggestions. I believe there are actually a few intertwined issues here.
So I would like you to work closely with me to ensure that we get all the facts straight, and they we each can reproduce everything that the other has seen. (Or if not, we will learn what is and is not an issue.) I will then compile everything into a formal issue report and submit it to GPSoftware.
This would go a lot faster if you and I could IM (or IRC) each other while we try some things. I'm in U.S. Eastern Time Zone, but it's nothing for me to work all night. Is there a time that you are online when we could spend some time looking at this?
In the mean time, I will compile my notes and post them here.
I am not using a Namespace. When I access my "Desktop", I access the actual folder, ie "Go /desktopdir". This folder is actually retargeted as "E:\Desktop" but this is not important, as I can replicate the behaviour on any partition.
If you follow the steps I have listed above you should be able to recreate the issue. I have Folder Formats set up in the following manner.
I have a couple but they do not conflict in this case as they do not have the option "Use as the default format for all sub-folders" checked, except for E:\Pictures, which is the target of "My Pictures". In any case this does not appear to affect the issue, according to my tests that I have done from various partitions.
It's very easy to re-create. In fact I simply have to open a folder with images in it, where Opus detects the Images Folder Content Type and shows thumbnails. If I change view to say List Mode and then apply my "Normal" Lister style, it displays it in Details Mode instead of thumbnails. In fact then whatever folder I then go to that isn't customised or have a recognised folder content, it shows the custom lister background image associated with my Images Folder Content Type from that point on until I close the Lister and re-open it.
BTW In reading through my notes right now, one was for Opus 22.214.171.124, which is why I never submitted the issue—Opus 9 came out soon after I noticed it, and I wasn't using that part of Opus much. The related Preferences are ll in different locations now, so I have to go back and try to recreate everything.
I use a hotkey sequence to accomplish something similar to what Leo suggests above. Whereas, selecting , in the Content Type Field always resets the file display to the Custom Default Format, The raw command below will reset it to the applicable Default Format for the listed folder.
The raw commands below will reset the file display to the Folder's own Folder Format, and the Custom Default Format respectively.
However, all this aside, there are issues in this area. Sinx and I worked together on this last night, over IM. We uncovered two bonafied issues with the interplay between Content Type Formats, View Mode, and Lister Styles. I can recreate one issue on Vista 32-bit (I still need to test it on XP). The other issue seems to only affect Vista 64-bit; Sinx can recreate, but I get different (and correct) results. We verified by screen grabs, that our related settings were identical.
I also have two or three closely related issues for which I recorded extensive notes about Opus 126.96.36.199. However, it wasn't clear to me back then how to reliably trigger the issues, or if it was something I might have configured wrong. So I choose not to report them, because I wanted to check my configuration, observe and document more, and let the pattern emerge. But, I ended up disabling my Content Type Formats shortly after (for no reason other than I was constantly working on the same type of work all the time). So of course, I have observed nothing on the issue, since the triggers are no longer in my flight path. When I read through Sinx's experience above, it all came back to me.
Sinx and I took some good notes last night, and I need go through my old notes and try to recreate the 188.8.131.52 issues in 184.108.40.206, and find out which ones still apply. I also want Sinx to review them all and test them on his Vista 64-bit install, since something seems to work differently there. Once we have all this done. I will file the report(s).
Manually resetting the folder format was not really the issue here, as Ken and I discovered, although I actually did want to know what the RAW command for resetting was.
In fact it's almost like Opus is locking the Content Folder Format when the lister is not actually locked - under certain situations.
As far as I can tell (and the way I would want it to work) is that Opus should format each folder you go to like it was the first folder you went to when you opened a lister unless you engage the lister lock. At the moment it is "locking" Content Folder Formats once you browse to one and then change View Mode. As soon as you then browse to another folder that doesn't have any specific Content or Folder format set, things go wrong and you will see parts of the last folder's Content Format displayed in the current folder, like background.
The order of priority between formats, if I understand correctly, is that Folder formats take precedence over Content Formats, which take precedence over Default Formats. It appears as though Default Formats are being ignored under these circumstances described.
I believe this is how things should work as well. To do anything different, only confuses things for people trying to learn and use all the various related features, including: Lister Styles, Folder Formats, View Modes, the Content Type Field, and Format Lock.
Just a quick update, I'm still working this issue report. I've installed Opus in Virtual PC 2007 and made a few changes to the out-of-box configuration—the settings Sinx and I played around with last night that help expose the issue. I'm also creating a toolbar which scripts and narrates the different test cases in a Command Prompt. So far, the issues we saw last night are all confirmed. What's more, is that I'm seeing some more issues. I'm trying to find out which issues are the same with different triggers and which are different issues. But they are all closely related.
When I get through my analysis here, I will package up the whole configuration and send it to Jon so he can walk through and see exactly everything that Sinx and I have seen.
Let's say you have a content format and a default format and just call them Content and Default. If you're viewing a directory which matches both Content and Default then Content will be used. (If that isn't obvious to anyone reading, have a read through the FAQ and come back to this post.)
So you're in a lister where Content and Default match, and Content has been applied. If you then change the format in some way, such as changing the view mode, then you are no longer using the Content format. You've created a temporary format on-the-fly in a lister where Default matched. (Your temporary format happens to be derived from Content but that doesn't change anything; you're using a temporary format now and Content is out of the picture.) If you now change directories to another one which matches the same Default then your temporary format will continue to be used, as per the rules under Changes to the Default Formats in the FAQ.
Could this be improved? Maybe. You could argue that Opus shouldn't do this if you start from a Content Type format but how many on-the-fly changes are needed before you are no longer considered to be editing the original Content Type format? (See: Ship of Theseus)
Maybe the whole Changes to default formats thing should be dropped altogether? I'm not sure. Personally, I'd be happy if Opus started from scratch every time I changed directories and ignored all existing context. If I wanted to make a change and keep it then I would explicitly enable the format lock. I don't know if that would be best for everyone, though. If you add a column and then change directories, and no other formats are involved, then you might expect that column to stay there which is what the current system gives you.
In my opinion, it only serves to confuse people if they are viewing a folder formatted via Content Format and they change something like view mode and then proceed to another folder and their current format stays, such as a background. This is just asking for confusion. However, if you said to someone that if they wanted to do that they had to engage a lister lock first then it is very straight forward to understand.
If someone uses Content Formats, it's because they desire formats to change dynamically between folders, depending on what they are viewing. The current behaviour defeats the whole purpose of having Content Formats. In fact if this is the way Content Formats are designed to behave then I find it quite useless and totally confusing, imho. I find myself asking what the heck is the lister folder lock for anyway? From my perspective it is just not logical.
Also, I find it quite confusing that when I apply a Lister Style with a View Mode set to Auto, it immediately (without any other interaction) changes to a different view mode than currently displayed via my designated Content Format (eg, Thumbnails view changes to List view).
The logic here also fails when you open a folder formatted via a Content Format and you apply a Lister Style that has Format Locks specifically set to off. Now I know what the folder lock is for in this case but the point is that the logic is broken. If I apply my style at this point that doesn't have a specific Folder Format specified in the Style and then browse to another folder (without Content or Folder Format) then the lister inherits the current format - thus the format is essentially locked, in my understanding of the word "lock".
While I understand that this behavior is by design, I couldn't disagree more with the design. This design requires improvement for the following reasons:
[li] This behavior is not very intuitive by any measure of the word, even after one has read the Opus Manual and FAQs. This behavior makes less sense when a much more intuitive means to retain a temporary format exists by simply enabling Format Lock.
[li] When the user first starts off in a new Lister (or Folder Tab) a pre-configured Folder/Content Type/Default Format will applied according to a logical order-of-precedence. But should the user change subsequently change Folder Options on-the-fly (changes View Mode, adds a column, whatever), the whole Format order-of-precedence changes so as to disregard the Default Format. I have problems with this.
Why did the user even take the time to enable and configure my Default Format's so they could be ignored?
Why when the user changes the current Folder Options (the temporary format), which is the result of an applied Content Type Format, does an unapplied Default Format get changed?
[li] This "rule" is actually self-contradicting. On one hand it says Folder Formats are applied thusly (top-down from Preferences as discussed above). However, if the user should change anything in Folder Options, then rule changes how it applies itself, by chopping the Default format off the order-of-precedence, to replace it with a bastardized Content Type Format. This is inconsistent behavior by-design, and doesn't help anybody learn and adopt this part of Opus easily.
[li] This behavior is not at all intuitive to anyone migrating from Windows Explorer. If you add new column or change View Mode in Windows Explorer on-the-fly, without saving the Folder View in Tools - Options - Apply to All Folders, then immediately list a new folder, the changes will not appear in the new folder's listing.
[li] This behavior not only is the Opus Default, but its quite unpopular and there is no way to disable it if the user does not like it.
[li] The quoted description above (and #6 on the Folder Formats FAQ) is not entirely accurate. Opus does not recognize most Default Formats after the user is relegated to the temporary format. If the user starts off by listing a Local Drive folder (whose default format is in Details), then changes View Mode to List View, then lists a CD-ROM or floppy drive in the same Folder Tab, the View Mode will remain that of the temporary format, instead of applying the Removable Drives Default Format. This also seems to be the case when subsequently listing a folder on a network drive (but I’m testing in VPC so that may be why). [/li][/ol]
If the experts don't like it, and the novices can't understand it, and it doesn't make much sense anyway, I'd say it is time to change it.
This is a problem that needs to be addressed. The concept of Default, Custom and Folder Formats is extremely useful, it's just that the current logic/implementation along with the folder lock is not consistent.
IMO, the folder lock should be the only mechanism that locks the current format - there should be no other hidden assumptions.
I understand completely what you are saying Nudel, and please, I'm not being rude, but I think you might be missing the point here. The point is that yes, I would want the column to disappear unless I switch the Format Lock on. This must be understood as the key issue to all that I am saying and I think Ken agrees. The Format Lock should be the only thing that "locks" the format. To do anything else leads you down the road of making assumptions and this is a dangerous path that ends in a mess of ill-formed logic. One that I believe DOpus has already headed down, unfortunately.
After switching directory, a format for target directory should be used. If it's not explicitly specified (Folder format), Content format is used (if automatic content detection is on), or then one of the Default formats.
UNLESS format lock is on, of course.