* Display Preferences for Media Window in Boot Camp

[dhwalt]

MacOS 10.15.4 with Boot Camp
Windows 10 Pro, vers.10.0.18363 Build 18363
Family Historian v.6.2.7

Recently moved from a PC to a 5K iMac and there have been few issues other than a failure to remember user selected sizing - View All Media - Media Records panel. Other panels such as the Records Window - Individual Records can be user adjusted and the new sizing is remembered from session to session. Is this something associated with the Boot Camp environment or is there a user preference that needs to be ticked?

Thanks David

[tatewise]

David, are you talking about the vertical divider between Media Records on the left and Media thumbnails on the right?
In my native Windows 10 FH V6.2.7, the horizontal position of that vertical divider is remembered from session to session.
Those window & pane, position & size parameters are saved in the Windows Registry so should work in your setup.
There are no FH preference settings that govern that behaviour.

I don't think you are talking about migrating all those settings from PC to iMac, which would require the Backup and Restore FH Settings Plugin.

BTW:
It is my understanding that you cannot run Boot Camp Windows and MacOS simultaneously.
I believe you have used Linux Mint + Crossover with FH in the past.
Are you aware of all the how_to:family_historian_on_imac_ipad_android_etc#apple_mac|> Apple Mac options?

[dhwalt]

Thanks for the quick response!

1. Yes, the vertical divider position is lost and moves left to display a Partial filename. I confirm same as yourself - native Windows then the divider position is remembered.

2. I did use your Backup and Restore FH Settings Plugin to have my plugins transfer.

3. BTW
3.1 Correct - It is Boot Camp Windows or MacOS not both. Boot Camp has a system tray icon for restart Windows to MacOS. Swapping back from MacOS to Win10 is more problematic - I use the Startup Disk preference pane to avoid entering a WiFi password on every reboot.
3.2 Linux + Crossover was not a good combination even compared with MacOS + Crossover. I went back to Windows on my laptop dropping Linux.
3.3 I have Wine on my iMac MacOS partition.

[tatewise]

That is a bit odd. It would seem it may be a side-effect of Boot Camp.
I can only suggest trying to re-install FH V6.2.7 and see if that fixes things.

Have you considered running a Virtual Machine such as Oracle VirtualBox which is free, or one of the commercial products such as Parallels Desktop or VMware Fusion?
Then Windows and MacOS can coexist.

[dhwalt]

This does look as if it is associated Boot Camp vs. Registry:

Uninstalled then reinstalled back to the FH 6.2.7 update without change in the sizing issue.

On my PC exported the Calico Pie group from the Registry as a patch. Moved it to Win10 on my iMac. Exported the same key on my iMac as a backup then applied the native patch to the Win10 Boot Camp registry version. No change in the sizing issue other than the obvious change 2K settings displayed on a 5K panel.

Even odder behaviour - First click on View All Media then the Media Records panel defaults to the leftmost position, partially hiding the file titles. Second click on View All Media then the correctly sized Media Records Panel is displayed. Repeated clicks give the user set panel width but the first click is always at its leftmost position. Close all the opened Media view tabs and the process repeats when 1st clicked...

An annoyance but not a show stopper!

[tatewise]

FYI: There are two Windows Registry sets of keys:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Calico Pie
Computer\HKEY_CURRENT_USER\Software\Calico Pie
I believe it is the latter HKCU set that holds the window & pane, size & position settings.

[dhwalt]

Applied both patches but no change in the divider position behaviour. Lost on the 1st selection and OK after that.

Should have added that there are numerous other FH/Calico registry entries (which I am leaving alone!).

[tatewise]

Is it worth reporting the problem to the Apple Boot Camp team?
I don't see how it can be a Windows 10 or FH problem.

The fact that on 1st attempt the imported settings seem to upset the pane parameters and then reset to always use default settings suggest to me that Windows Registry key is being mishandled somehow.

By trial & error it seems that the specific Windows Registry key value that controls the Media Window divider position is:
Computer\HKEY_CURRENT_USER\Software\Calico Pie\Family Historian\2.0\Preferences\Window Split 1
Small values such as 100 position it near the left edge, and large values such as 640 position it at the right edge on my 1600 pixel wide screen. ( 640 hex = 1600 decimal )
It would be interesting to see the values in that Windows Registry key with Boot Camp in charge.

BTW:
It is all those Calico Pie registry values that the Backup and Restore FH Settings Plugin manages, as well as all the C:\ProgramData\Calico Pie\ folders & files.

[mjashby]

While I don't use Boot Camp, I'm not convinced that the issue described is caused by that mode of working because the scenario is identical in a Windows Virtual Machine on VirtualBox when using the 'View all media' window , i e. the text column shrinks back to the original size when you leave one project and switch to another. Conversely, you could describe the behaviour as the Graphics Display Window and images increasing back to their original sizing, squeezing the Text list back to where it originally was, as the additional space for the text column is only gained by auto-shrinking the size of the images in the display window.

With a VM, the image display is obviously controlled by the capabilities of a Virtual Graphics Card as it cannot make use of the Mac's onboard GPU(s), so there is little that can be done to test if any issues have anything at all to do with Graphics Drivers. I do note that Apple recommends that Bootcamp Users who install Windows; and have onboard AMD GPU's, i.e. most models released in the last 5 years+, should visit the AMD site to update the Graphics Drivers in the Windows installation to the latest available version, so it might be worth trying that if it has not already been done.

Mervyn

[tatewise]

@Mervyn ~ Don't go assuming that switching Projects in the same FH session is the same as starting a new FH session.
FH has a habit of not always updating 'things' as soon as they are changed, or even when you expect it to.
So in native Windows 10, if the Media Window divider is adjusted, and you switch Projects, then the original divider position is restored in the Media Window of the new Project.
BUT if after adjusting the divider, you switch to another window, before switching Projects, the new divider position sticks.
That is because FH updates the Windows Registry when it switches windows, but not when switching Projects.

So you haven't emulated the same scenario as Boot Camp. You must close FH and open it to start a new session to see if the adjusted Media Window divider position has stuck. FH always saves its Windows Registry settings when it closes.

[mjashby]

Mike,

I am not basing my on pure assumptions. Since my last posting I have re-tried several full shutdowns and startups of Family Historian, with no change in FH behaviour at any point; i.e. the column settings in the 'View all media' window are always lost. However, I have also extended testing further by carrying out the same range if tests with a Wine/Crossover implementations of Family Historian on MacOS, which does, of course, have direct access to the Mac's Graphics Chip/Graphics Drivers; and in those tests, the 'column settings' are consistently retained, surviving project switching, complete FH shutdown and restart; and computer shutdown and startup. For completeness I have repeated all tests on three different Mac Computers with different Versions of MacOS with the same results every time. However, with a Linux Virtual Machine, running on both a Mac and Windows computer, with a Wine FH installation, the FH column setting were again lost. The only difference with that test is that there is again no direct access to the MacOS/Window's PC Graphic Chips/Drivers, because the Wine.app is running in a VM.

Given those facts I would be interested in any alternative suggestions that could explain such strange, yet consistent, behaviour, other than the possibility that the most likely explanation is some weird interaction/glitch with Graphics Driver access (whether real or virtual).

I have absolutely no intention of testing a Boot Camp Windows installation personally. However, my suggestion about updating the Windows Graphics Drivers in that scenario was based directly on Apple's own very clear advisory notice to Boot Camp Users who install a Windows OS; and was purely to enable testing of whether updating the Windows Graphics Driver installation makes any difference.

Mervyn

[tatewise]

Mervyn, thank you for that intensive assessment.
My earlier comment was based on the fact that closing & opening FH or the PC was not mentioned, and I could repeat the loss of divider position you described in a thoroughbred Windows system when only switching Projects.

I note that you now mention Column settings as opposed to the Divider position in the Media Window.
Is that deliberate that you are adjusting the text Column widths on the left?

It is highly likely that the Graphics Driver is the cause of the problem, but why only for the Media Window divider?
There is a history of misbehaving graphics in the Report Window, Map Window, etc.

Have you been able to inspect the Windows Registry key values for Window Split 1 that I mentioned earlier?

Dows the Knowledge Base need any extra advice regarding Graphics Drivers for any of the environments such as Crossover, POL, POM, Oracle VirtualBox, Boot Camp, etc?

[dhwalt]

Thanks for this feedback. I hope below makes Sense:

When Boot Camp completes Windows updater finds the relevant/most recent AMD video drivers and installs them.

At 20 May 2020 Device Manager AMD driver details were Radeon Pro 580, 26.20.13001.53002 dated 8 Jan 2020.

On the AMD update website - Boot Camp Unified Driver R3 for Windows 10 released 23 March 2020, 19.30.01.53. Downloaded this and ran the installer which informed me that 26.20.13001.53002 was current and installed. To be certain uninstalled and reinstalled. Ran FH and Media Window divider behaviour is unchanged - the divider on 1st run ignores user set positioning.

Device Manager identifies the monitor as Generic PnP, driver 10.0.18362.693, 21 June 2006. Tried an update but nothing available.

Registry
FH not loaded or running Window Split 1 = 364
FH loaded Window Split 1 = 364

Tried various numbers such as 400 and they are remembered across full shutdowns and re runs for FH and Boot Camp.

Tried moving the divider and rechecking Window Split 1 - it changes to whatever position the user sets the divider. NOTE 1st run of the media window ignores this setting and it is always 2nd run or later that uses Window Split 1. Windows Split 1 appears not to be used for setting the 1st run divider position. Is that a bug or is it some other registry key that fails to be read?

'I note that you now mention Column settings as opposed to the Divider position in the Media Window.
Is that deliberate that you are adjusting the text Column widths on the left?'
* I have tried moving the divider and altering columns (went as far as removing all but the default column). No change and the divider on 1st run ignores user setting.

[tatewise]

Just to be clear, I think you are saying the Media Window divider position and the Window Split 1 key value are working perfectly in tandem, and preserved from FH session to session, but with one exception.
The singular exception is that the 1st time the Media Window is opened the divider is incorrectly positioned.
So if the Media Window is closed and re-opened in the same session its divider is positioned correctly.

Are the Column widths similarly preserved, and do they also suffer the same 1st time exception?
( Adjusting the Column widths just explores the scenario further involving more graphics and registry values. )

The fault would seem to be nothing to do with reading and writing the Windows Registry key values.
I suspect they are only read once at the beginning of the session, and only written when switching windows or sessions.
It appears to be an initialisation glitch somewhere between FH, Windows 10, Boot Camp, and the Graphics Driver.

[dhwalt]

That is correct.

'So if the Media Window is closed and re-opened in the same session its divider is positioned correctly.'
*If closed then you are back to the 1st time exception scenario BUT if there are several instances of the media window then closing one has no effect AND to complicate matters, several open and the 1st is closed then even with the correct divider user set position on the others then the next window opens as a 1st time exception.

'Are the Column widths similarly preserved, and do they also suffer the same 1st time exception?
( Adjusting the Column widths just explores the scenario further involving more graphics and registry values. )'
*Column widths have the same 1st time exception - they contract to their minimum value and move left. A 2nd instance of the Media Window and column widths + divider are as the user set them.

[tatewise]

Just one more clarification. I think you said earlier that it is only the Media Window that suffers this problem.
Considering all the multiple Columns and multi-pane dividers in various FH windows, do all those others work correctly?

If it is only the Media Window, then perhaps it is the grid of image thumbnails that complicate matters.

[dhwalt]

Correct - It is only the media window. Others work correctly.

At a loss to explain this behaviour - if the 2nd instance is correct then why should the 1st instance ignore user set divider position? On a PC I just accepted that the Media Records pane behaved!

[dhwalt]

Ref. this comment
'If it is only the Media Window, then perhaps it is the grid of image thumbnails that complicate matters.'
*Started an empty Project - one individual, no media, no sources, no places, no families, no notes i.e. no thumbnails.
Same Media Records divider behaviour as previously described even with an empty title list and no thumbnails.

To confirm - this is Media - then View All Media from the Navigation Bar.