BTW In reading through my notes right now, one was for Opus 8.2.2.5, 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.
If you want to reset to default from a Content Type format then using the Content Type drop-down is a good way to do it. Just select as shown in the screenshot.
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.
Set FORMAT=!defaultThe raw commands below will reset the file display to the Folder's own Folder Format, and the Custom Default Format respectively.
Set FORMAT=!folderSet FORMAT=!customHowever, 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 8.2.2.5. 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 8.2.2.5 issues in 9.0.0.8, 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.
That doesn't sound like a bug (but there may be room for improvement all the same).
See the Changes to the Default Formats section of the Folder Formats FAQ.
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".
When is a lock locked when it is not locked?
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:
[ol]
[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]
[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]
[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]
[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]
[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]
[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.
kenalock, I mostly agree with you.
I think the notion of Current format should be introduced (meaning any saved format with modification), but just for the discussion.
Anyway, a state change graph would be very useful, both for understating folder formats and for detecting inconsistences. Any volunteers? 
X.
I think Ken has worded it quite well.
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.
So if you view C:, add an extra column (say Creation Time) and then double-click on Windows to view C:\Windows, you would be happy for that column that you just added to be removed?
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.
I'll answer for myself- well, yes I would.
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.
X.
Absolutely! If the user wanted the Creation Time column displayed all the time, they would've already added it to the applicable Folder/Content Type/Default Format. If the user wanted the Creation Time column displayed only during the current Opus session (i.e. the life of the current Folder Tab), they can enable Format Lock, conveniently located in the Status Bar (and in my case also by hotkey sequence).
Consider this modified example:
The user lists C:, governed by the Local Drive Default Format, and subsequently adds the Creation Time column and does not enable Format Lock. In the same file display, the user proceeds to C:\Music, governed by the Music Content Type Format (which does not include Creation Time). Today, Opus discards the Creation Time column.
So why should this behavior be any different if the next folder listed is governed by the Local Drive Default Format? The user already made their choice, when they enabled and configured Local Drive Default Format, that means they wanted to use that format. It simply is not intuitive to give the user discretion to enable and defined a Default Format, then turn around and ignore that preference in everyday use. If you are going to automate a behavior, it should be for the 80% majority, not the 20% minority.
The more familiar a user gets with Opus Folder Formats, the less intuitive this temporary Default Format monkey business becomes. It is really not intuitive to treat folders governed by Folder and Content Type Formats one way, but those governed by Default Formats a different way. Folder Format-savvy users will implicitly expect the format to change upon listing a new folder, unless Format Lock is enabled.
The novice Opus users stand even less of chance of figuring this out intuitively. Users migrating from Windows Explorer will have one of two expectations:[ol][li] The format changes for each new folder listed, unless:[/li]
[li] The user has saved a format for all folders.[/li][/ol]
The thing that usually trips up new Opus users (regarding folder Options/Formats/View Mode) is that, in Opus, they must explicitly save the format for the current folder from the Folder Options dialog. This is in contrast to Windows Explorer, which saves so many hundred (400?) folder formats automatically, the least used folders automatically bubble off the format list, the most used remain on it. But the issues we have been discussing in this thread have no bearing on this migration issue one way or the other. So that is part of their growing pains when migrating to Opus.
I understand why the current behavior is there—it's well intended. If I remember correctly, this behavior made sense back in the Opus 6 which pre-dates Default Formats and Content Type Formats. All we had in Opus 6 were Folder Formats and a default set of Folder Options in Preferences. But with the advent of Default and Content Type Formats, I'd be happy to see the temporary format go the way of the dinosaur.
Another point of confusion related to this issue is the View Mode = Auto setting inside a Lister Style. I've looked long and hard in the documentation, but what this specific option actually does isn't really explained anywhere.
What it implies to me, is that the Lister Style should not apply any View Mode changes, but should instead let the Folder/Content Type/Default Format applicable to the listed folder dictate the View Mode. The only exception would be if the Lister Style's own Folder Format also saved a View Mode. (I'm not this is saying how it works or should work, I'm saying this is what would make sense to me, in the lack of any documentation on this setting.)
While we are having such a good discussion. 
The Content Type field, which allows you to apply different Content Type Formats has an option named .
This option resets the file display's Folder Options to the Custom Default Format. I believe it would be far more useful and intuitive if this option would reset the file display's Folder Options to either the applicable Folder Format (if one exists and is enabled), or the applicable the Default Format for the listed folder. (In other words, the same as the default Folder Format Precedence, but skipping all Content Type Formats.)
I also believe an option should be added to this list named , which would simply reapply the applicable Folder/Content Type/Default Format as if the folder had just been listed for the first time.
What do others feel about this?
Ken, I agree with you on every topic - including your added post. In fact I've been somewhat frustrated by the current implementation of the Content selector gadget. I agree with your suggestion here.
As far as the View Mode in the Lister Style, the whole thing that makes absolutely no sense to me at all is the fact that this option can be switched on or off. All the options in a Lister Style act as an optional override - as in they only act if you enable them first. So if you don't wish there to be any change in the Style's view mode then you simply don't enable it. This method of "overriding" is great! Yet when you enable View Mode and put it on Auto there is an inherent suggestion that you are not selecting a specific view mode but that an applicable one will be selected for you. What other applicable mode could possibly be selected other than the one dictated by Folder, Current and Default Formats? This is the only thing that makes sense yet it does not appear to function that way.
On the issue of Folder Formats, I think the only way to resolve it is as follows:
It appears there are two methods in Opus of locking the Format of the Lister. There is a visible manual lock and an invisible "auto" lock. There can be no doubt about this.
What I suggest is either of two things:
[1] The Format Lock have 3 modes instead of 2, ie Off, Manual and Automatic.
[2] The Format Lock remains the same (ie On and Off), yet there is an option in Preferences called "Automatic Format Locking", which can be enabled and disabled.
In both cases above you have the option of disabling the current hidden automatic format locking that is causing me and others so much grief.
I think the above is a simple solution to a complex problem. I understand that others like this automatic format locking and so that's why I suggest that it be transformed into an option instead of being hard coded on.
This is one if the issues that I was trying to figure out in my testing. But now I'm inclined to believe that the temporary format behavior Leo shed new light on might really be the cause of confusion with View Mode = Auto. That is to say, if you applied a Lister Style with View Mode = Auto, to a file display listing a folder to which a temporary format has been applied, then quite possibly this setting correctly does nothing, since the applied Format will not change.
What we need going forward is to clearly understand what View Mode = Auto is intended to do in a Lister Style, then to ensure that this behavior is also intuitive and documented. And finally, if our suggestions are implemented (i.e. dispense with the temporary format), I believe View Mode = Auto would (or should) then poll the applicable Format to the listed folder and use that View Mode.
If anyone else has better understanding of how View Mode = Auto works today, or a more intuitive suggestion how it should work, please speak up!
I disagree with adding a Preference option. From a coding perspective you cannot make logic simpler, by adding another option to already complicated logic. From the user's perspective, I believe the additional Preference option would further complicate an already complicated topic—trying to understanding of how Formats, even more than the current behavior by itself does. A user could play around with that preference option and all of sudden Opus is broken to them—they would have the same experience you did at the start of this thread.
And, I have yet to hear anyone say (not even Leo) they are a proponent of the current temporary format behavior. In fact, I think even Leo said he would like to see it changed as well. So, I think this is really a situation where addition through subtraction makes more sense.
Again, I'm not saying that the temporary format feature is bad, I'm saying that it is really a relic from a time when Content Type Formats and Default Formats (and even the current manifestation of Folder Formats) did not yet exist. And I further believe that this feature (which was once the best thing we had) no longer fits well into the new Formats metaphor, and confuses users needlessly. There are already simpler ways in Opus for the user to accomplish the same thing.
For any casual Opus users reading this topic please get involved and add your input and thoughts. Those of us participating are curious as to what others affect. and when I submit to the official request(s), I'm going to be linking to this thread.
Ken, you have more knowledge of how things used to be and how they relate to this "temporary format". If indeed it does exist, it appears we are both saying here that its scope should be limited to the current viewing folder, with bold+italic+underline emphases on the word "temporary" This is where the Format Lock comes into play, as it temporarily stops this Temporary Format from being reset, as should normally happen when you browse to a different folder. So in this sense, probably from a programing point of view, the Temporary Format has its place but it has been designed to inherit changes made to it without the Format Lock being activated. This is where the logic falls apart.
Currently the Temporary Format logic is faulty and I believe that the Temporary Format should never inherit changes unless I specifically tell it to, using the Format Lock (but hey I'm going over old stuff here). Whether they chose to continue an optional "automatic" lock, is not my place to say, although I do agree that it is something that would only serve to confuse and complicate the programming logic so much that it would attract bugs (as it is currently doing). The paradigm isn't working.
I've done some experimenting with the Lister Style - View Mode. From what I can tell at this stage, it appears to be working on my setup except in the instance where a folder has been formatted using a Content Format with a view mode of Thumbnails.
What I've tried doing is changing the "Custom" Default Format to all sorts of View Modes and then applying my "Normal" Lister Style that uses a Style View Mode of Auto. It appears that in all cases, except for Thumbnails, the view mode is correctly set - using Default, Content and Folder Formats. So, if I open a folder full of pictures, where I have it set to display thumbnails as per Content ("Images"), and then I immediately apply my "Normal" Style, it reverts to the view mode set in the Default Format "Custom", which in my case is Details. So this appears to be the bug.