Make palette status management consistent among views

Pat91 · November 27, 2023, 12:38pm

Hi,

[This request is also related to the Solo mode request but it’s not exactly the same problem. Hence a different request]

I recently spent some time looking at the structure of the workspace XML files, trying to understand why the expanded/collapsed state of the palettes was not recorded as expected when quitting DPL or when saving a workspace. Under Windows, the workspace files are stored in C:\Users\User\AppData\Local\DxO\DxO PhotoLab 7\Workspaces. The following is what I have observed during these tests.

The state of a palette is recorded in a Rollup section that contains 4 parameters :

       <IsExpanded>true</IsExpanded>
       <IsAdvancedExpanded>false</IsAdvancedExpanded>
       <Id>c45bf8fe-77be-4881-9aad-e2f0b537d3f5</Id>
       <IsFavorite>true</IsFavorite>

The ID is a universally unique identifier specifying a given palette. The other parameters are self-explanatory. There is no simple way to determine which palette is specified by which ID. Only if you are curious : This can be done by creating a copy of the workspace file, changing the Favorite state of only one palette, saving the workspace under another name, comparing the 2 files and noting which Rollup section has changed.
The IsFavorite value is recognized throughout the application wherever the palette is displayed, which is correct and expected.
The isExpanded and isAdvancedExpanded values are only taken into account when the palette is displayed in the global tab (enabled when no Smart workspace button like Light, Color, Detail, etc. has been enabled. When recording the workspace, only the expanded/collapsed state the palette has when displayed in the “global tab” is taken into account and recorded.
The expanded/collapsed state of a given palette is therefore stored in two different places in memory. Otherwise, this state would be the same whatever the viewing context of the palette. Storing the same info in 2 different places is no good programming practice.

IMHO, points #4 and #5 are characterizing a bug and are not consistent with point #3. The expanded/collapsed state should be unique allover the application and honored whatever the viewing context of the palette. This way, when loading a workspace or when relaunching DPL, the palettes would be restored in the state they were in when saving the workspace or when quitting the program, whatever the viewing context where they are displayed.

Franky · November 27, 2023, 12:47pm

The problem is also that it works for some and not for others.
For me, I find my palettes in the same state when opening PL.

Pat91 · November 27, 2023, 1:13pm

As explained above, it depends on the viewing context. The state of the palettes is correctly restored when none of the buttons at the top of the right tab is enabled (Favorite corrections, Active corrections, Light, Color, Detail, Geometry, Watermark & Effects). Otherwise, the isExpanded and isAdvanced Expanded settings in the workspace file are ignored and all palettes are systematically expanded.

platypus · November 27, 2023, 1:26pm

Workspace settings are stored in at least three files on Mac, e.g.

config of a custom workspace: naming the palettes, their sort order and initial status (open, shut)
File: ~/Library/Application Support/DxO PhotoLab v7/Workspaces/Test_1.dopworkspace
state of the custom workspace - and this file’s content is almost identical to the ws config file’s - unless the current state differs from the initial state.
File: ~/Library/Preferences/com.dxo.photolab7.workspace.plist
state of palette filtering
File: ~/Library/Preferences/com.dxo.photolab7.plist

Palette filters don’t rewrite the first two files, only the third (general DPL settings) file is touched, filter settings (and whatnot) is encoded in binary.

There’s some logic in this structure, but if DPL does not address the correct file and object in the file, the workspace will e.g. revert to something that wasn’t set the last time. I’d call that a bug, but current DPL 7.1.1 does not seem to be affected.

nicolas-p · November 27, 2023, 2:18pm

thank you for the job!

If it’s a bug, it deserves a fix.
Have you thought about opening a ticket with DXo?

I’m not sure they read the forum all the time.

this is a matter of contact with the team that manages this

Pat91 · November 27, 2023, 2:25pm

Still 7.1.0 under Windows.

Same structure under Windows. The problem is that the expanded/collapsed state of the palettes in the filtering modes isn’t recorded anywhere. This is where the inconsistency lies. The expanded/collapsed state of the palettes in the various viewing contexts (unfiltered or filtered modes) should be kept in sync instead of storing them separately : one single place for storing this information => less trouble.

platypus · November 27, 2023, 3:32pm

That info is stored. On Mac, it can be found here:

Notes: Check the path…and that there is a status entry for “collapsed”, but not for “expanded”, nevertheless I can replace the value “true” by “false” and the palette will be expanded.

Pat91 · November 27, 2023, 4:12pm

I have tested under Windows. When I change a palette’s expanded/collapsed status, close DPL and compare the workspace file (MyWorkspace.xml) and the current state XML file (__$$Customize.xml) with their copies made before launching DPL, I can see that if the change has been made in the non filtered mode, the information about the expanded/collapsed state is recorded (and restored upon relaunch). The change is recorded in MyWorkspace.xml if I saved the workspace or in __$$Customize.xml if I made the change without saving the workspace.

If the change has only been made while viewing the palette in one of the filtered modes, both files are left untouched after quitting.