DO11: Internal config file inconsistencies

Again, I'm going to disclaim that I'm "looking" at the raw files for reference and comparison, and not messing around with them myself :slight_smile:...

That said, I've noticed a few inconsistencies while inspecting that I wonder if you think should be looked at for the purpose of tidying up to protect against something going wrong in other scenarios, nothing seems to have actually broken so far as a result from what I've seen:

  1. In reworking my FileTypes customizations... I noticed that in some cases, the 'Position' value of adjacent keys got screwed up. I know that the order in which the entries actually appear in the OXR file itself doesn't matter, but I'm seeing several times now where the item at position 3 for a given filetype then has another position=3 item with the next one being position=5. So, there was a second position=3 instead of =4. Again, I haven't seen it actually cause the order of the items in the menu to get messed up - though it seemed like Opus was probably favoring whichever entry did in fact appear first in the file in the case of such duplicate position values...

  2. In reworking my hotkey assignments, I've noticed that for any hotkey that I modified to run my own commands (instead of the defaults you shipped with), certain other data for the original hotkey remains though it seems like it shouldn't. Again, it doesn't seem to cause any actual breakage and nobody else would probably care, just curious if it's something that should be tidied up. For instance, the hotkeys.oxc file contains a list of what I assume are default 'internal' hotkey names in the tag. These tie to the defkey value some of the hotkey definitions have:

Example:

<key defkey="prevtab1" disable="no" hotkey="ctrl+pageup" hotkey_type="local"> <label>Copy to parent folder</label> <function type="normal"> <instruction>copy to ..</instruction> </function> </key>
...where I modified the "ctrl+pageup" hotkey to run copy to .. instead of the tab select command or whatever had been default. But it still retains the "prevtab1" value.

Pathological curiosity ? Yeah, probably :slight_smile:... just wondering if these are things waiting to break something in some other scenario.

  1. What are the steps to reproduce that?

  2. Is intentional and enables us to add new default hotkeys in the future, while knowing which ones the user has already had added & possibly chosen to remove.

I'll see if I can repro the first. I only noticed it after quite alot of filetype modifications (again though, all 'legit' in the filetypes editor, and not messing around with the RAW file).

I will say that I noticed it after making a long list of adding filetype context menu entries... to the point where I tripped up on what I think is a minor bug in the editor which make me wonder if it's related. That is, once I've added enough context menu items so that the filetype editor shows the vertical scroll bar, I can no longer drag new items (placed at the bottom) higher up in the list than the top of the set of currently visible items. So I have to drag the item to the top of the visible portion of the list, scroll up so the item is now at the bottom, drag it a bit further up, scroll again, etc. It was after a lengthy round of doing this that I compared and noticed the position dupe value.

I only have some tab groups and a few toolbars to rebuild on v11. Once done, I'll save off my config and redo the filetype stuff from a clean v11 install to see if I can repro...

Most of what I've reported so far is minor cosmetic type stuff noticed while rebuilding my config... I'll do better once I get my confgig down.