Keyboard Type Display Type in Dark Mode

[Cliff G]

First of all, thanks for a immeasurably useful tool.

With this note, I would like to report what appears to be a display bug.

When running in MacOS dark mode I run into the issue that only the selected keyboard layout is displayed.

[Gé van Gasteren]

On Wed, Feb 28, 2024 at 10:19 AM Cliff G <monta...@gmail.com> wrote:

When running in MacOS dark mode I run into the issue that only the selected keyboard layout is displayed.

I can confirm this behavior.

@John: I may have a quick-and-dirty workaround for a different issue reported earlier, that a new keyboard layout is displayed with scrollbars visible.

Switching Zoom mode corrected the situation every time I’ve tried it, so far.

So my idea is that you could fix this by adding one line of code: to first open such a new window at 75%, then switch to the percentage set in the Settings.

[John Brownie]

Again, thank you for pointing out the bug! For some reason the background of the list was set as a custom colour, white, rather than the default background colour. So it was an easy fix.

I suppose it might work, but I haven’t been able to see why the problem exists. I’ve tracked it further, and my initial response was wrong. It’s nothing to do with the scroll bars, it’s just that something in the system decides to change the window size after I have set it correctly just before it appears. It’s not predictable, but often it’s exactly 24 pixels shorter, and the width may be some other value than what I set. The simplest work-around, which is not particularly nice, is to immediately click on the zoom control and keep the current scale factor. Whether I can work out a way to do this in code is another matter…

Apart from this bug, I have fixes for all the things that Oleksandr mentioned (though the XML compiler issue is beyond my control), so I could put out a new version soon, I guess. Anyone have other issues that I should address before doing that?

John

[Gé van Gasteren]

On Wed, Feb 28, 2024 at 2:18 PM John Brownie <john_b...@sil.org> wrote:

 It’s not predictable, but often it’s exactly 24 pixels shorter, and the width may be some other value than what I set. The simplest work-around, which is not particularly nice, is to immediately click on the zoom control and keep the current scale factor. Whether I can work out a way to do this in code is another matter…

Just a guess: could it have something to do with the difference between window size in Full Screen mode and normal mode? And the visibility or otherwise of scrollbars (only for the width) ?

Apart from this bug, I have fixes for all the things that Oleksandr mentioned (though the XML compiler issue is beyond my control), so I could put out a new version soon, I guess. Anyone have other issues that I should address before doing that?

That’s good news! 

I just have one little thing, but then, you may not want to include a new manual version at this point:

The above is a partial screenshot of page 11 in the PDF manual ;-)

[John Brownie]

On 28 Feb 2024 at 17:15:04, Gé van Gasteren <gevang...@gmail.com> wrote:

On Wed, Feb 28, 2024 at 2:18 PM John Brownie <john_b...@sil.org> wrote:

 It’s not predictable, but often it’s exactly 24 pixels shorter, and the width may be some other value than what I set. The simplest work-around, which is not particularly nice, is to immediately click on the zoom control and keep the current scale factor. Whether I can work out a way to do this in code is another matter…

Just a guess: could it have something to do with the difference between window size in Full Screen mode and normal mode? And the visibility or otherwise of scrollbars (only for the width) ?

I am still in the dark as to what the exact cause of the problem is, but it’s nothing to do with scroll bars, as far as I can tell. It seems that, when I calculate the size of the window, one of the figures I get fed from the system can vary by 24, so the height of the window varies, sometimes 24 pixels too small.

Apart from this bug, I have fixes for all the things that Oleksandr mentioned (though the XML compiler issue is beyond my control), so I could put out a new version soon, I guess. Anyone have other issues that I should address before doing that?

That’s good news! 

I just have one little thing, but then, you may not want to include a new manual version at this point:

The above is a partial screenshot of page 11 in the PDF manual ;-)

Do you mean the page numbering? I can change that easily enough.

John

[Gé van Gasteren]

On Thu, Feb 29, 2024 at 3:43 PM John Brownie <john_b...@sil.org> wrote:

I am still in the dark as to what the exact cause of the problem is, but it’s nothing to do with scroll bars, as far as I can tell. It seems that, when I calculate the size of the window, one of the figures I get fed from the system can vary by 24, so the height of the window varies, sometimes 24 pixels too small.

Isn’t the menu bar 24 pixels high? That’s what led me to think of full-screen mode or otherwise. Or maybe there is some "pre-processing" done by a routine that determines whether the window is going to be on the "main display" or on an "extended display" without a menu bar?

Do you mean the page numbering? I can change that easily enough.

It’s not a big thing, but yes, it trips me up sometimes, e.g. when I don’t click on a TOC entry but (try to) scroll to a page.