RPI4 font preferences not maintained between starts of OSCAR

[Crimson Nape]

Is the font variable ever initialized to PibotoLt during startup? I'm wondering if it may be a timing issue, where it has read the xml file before the font variable is initialized by the system.

[GuyScharf]

Phil,

Have you rebuilt with the latest updates to common.cpp? (I updated it twice.) It looks somewhat like OSCAR is failing to find the font in the list of installed fonts. The update I made would spell out in the log more exactly what the startup font setting would do.

But I still have no explanation why the font size would change to 12. A reset should set it to 10.

[GuyScharf]

Is the font variable ever initialized to PibotoLt during startup?  I'm wondering if it may be a timing issue, where it has read the xml file before the font variable is initialized by the system.

A timing issue is my best guess too, but so far I've not figured out what it is.  PibotoLt is the system font, so QT would initialize the application font to that. Then we replace the application font with one of our choosing. The messages that are shown during that substitution process are all normal. And of course it works fine on all other platforms.

I can, and will if necessary, start shotgunning attempts to bypass the suspected timing issue. But build times on RPi are long, so I am focusing first on diagnostics so I don't have to make too many guesses.

[Crimson Nape]

While I'm sitting in the bleachers another thought came to mind, are other parameters in the xml file being acquired and updated? Basically, is the xml file even being accessed/opened this early in startup?

Changing something like, RightSidebarVisible, UserEventPieChart, and CalendarVisible, to see if it picks these up.

[GuyScharf]

Interesting idea, especially if something is threaded that I don't know about. My latest diagnostics should reveal if that were the case. I'm waiting to see a log with the latest tests.

[happydreams]

@pholynyk Phil has captured what happens.  That's what I see.  Sorry I had to go out for a while.  Hadn't intended this to be such a vexing puzzle.  Of course, no one would have know if there was an issue if it wasn't reported.  

Why would this OS/platform be that different from the others?  Raspi OS is basically Debian.  The OS packages a Debian help section.  This doesn't happen on Ubuntu or other Debian flavors on a PC does it?  Actually that might be an interesting test.  Does it work the way you expect, in actuality, or is it just close?  Wish I could help with this, but my GUI programming is quite limited.  I've done wxWidgets, and wxPython in the distant past, but no QT.

[GuyScharf]

Why would this OS/platform be that different from the others?

That is the question! OSCAR code is the same. But is QT? I don't know. Also, the CPU is slower than most, isn't it? That could lead to a timing problem that we would not otherwise see.

I'm still working on adding more diagnostics.

[GuyScharf]

Phil and/or happydreams:

I have merged a new version of common.cpp into the repository. Please rebuild, run, and send me the log.

With this change, when the program looks up a font and doesn't find it, it will dump the entire list of font families. I'm hoping that will show something useful.

For example,

Code:

validateFont found 257 installed font families
"Nobody font" 10 not found, substituting "MS Shell Dlg 2" 10
"Agency FB"
"Algerian"
"Arial"
"Arial Black"
... and on and on for 257 lines!

[Crimson Nape]

While it may be a Debian flavor, it operates on a different processor. This could be how the code is executed on the processor, little endian versus big endian for example. Note, Arm and x86 processors are little endian by default. Another "fly-in-the-ointment" is Qt. It has on occasions produced some surprises of its own. The previous examples are just speculations, but are good reasons to keep an open mind.

[happydreams]

Ok, built it and ran it.

Here's the important bits.

Code:

00187: Debug: OSCAR 1.2.1-alpha.0+master-142220c1 (linux arm)
00188: Debug: Built with Qt 5.11.3 on Jan 15 2021 14:18:31
00188: Debug:
00188: Debug: Operating system: Raspbian GNU/Linux 10 (buster)
00188: Debug: Graphics Engine: OpenGL ES 3.1 Mesa 19.3.2
00188: Debug: Graphics Engine type: OpenGL
00188: Debug:
00188: Debug: App key: OSCAR-master
00188: Debug: AppData folder already exists, so ...
00188: Debug: Using /home/pi/Documents/OSCAR_Data as OSCAR data folder
00190: Debug: Logging to /home/pi/Documents/OSCAR_Data/logs/debug.txt
00191: Debug: Opening  /home/pi/Documents/OSCAR_Data/Preferences.xml
00193: Debug: validateFont found 244 installed font families
00197: Debug: Application font set to QFont( "PibotoLt,9,-1,5,50,0,0,0,0,0" )
00197: Debug: Application font reads back as QFont( "PibotoLt,9,-1,5,50,0,0,0,0,0" )
00197: Debug: system font is "PibotoLt"
00198: Debug: Opening  ":/docs/channels.xml"
00198: Debug: Processing xml file: "channels" "en" "1.0"

56672: Debug: Application font set to QFont( "PibotoLt,9,-1,5,50,0,0,0,0,0" )
56672: Debug: Application font reads back as QFont( "PibotoLt,9,-1,5,50,0,0,0,0,0" )
56672: Debug: system font is "PibotoLt"
56764: Debug: Number of months for stats (trim to 12 max) 67
56936: Debug: Page change time (in ms): Unload = 0 Load = 181 Other = 1

Umm, seems to be basically working.  You must have fixed something.  To be honest, I'd really like to decouple the AHI=xx.xx from the rest of the fonts, but it is better - at least it obeyed the file.  AHI is too large.  Don't know, is it possible to do fontsize+2 instead of 4 for the RPI4?  I know this gets into mucking with the look and feel, but far too much space is devoted to AHI and machine (in my opinion) to the detriment of the other diagnostic info.  Here's what my display looks like.  I think the base fonts are borderline hard to read now.
Fontsize=9
   
Original was with Fontsize=12
   
Thinking about the limited display on the left hand side, it seems to me that taking 4cm total vs 22 cm of total vertical height, for AHI + machine settings is a lot, considering the amount of actual unique daily data that has to be displayed.  If it was me (and maybe I will dare to try it) I'd put 
ResMed AirCurve 10 VAuto on one line and PAP Mode: VPAPauto PS 4.2 over 9.4-15.0 (cmH20) on the other to save vertical space. 

I think what is here (OSCAR) is awesome, but maybe it could use a tweak or two.  Guess that's a personal preference.  I can tell you, I can't wait to get a real PC again.  Wouldn't want to develop for a living on an RPI4!  Too slow - even when overclocked.