System font formatting properties affect the document inside the editor in Qt based desktop environments

[videosmith]

Bug Description
AppImage and .deb versions look different in font style and menus. 'About' pages identical content. Same resolution on both 1920x1080

First screenshot from Debian (Intel), second Raspberry Pi 400

Steps to Reproduce

1. Run both versions in their respective environments.

Expected behavior
Should be identical on both platforms

Screenshots (optional)

Device information

• QPrompt Version: QPrompt 1.1.0-rc-1 (07/27/2022)
• Operating Systems: Raspberry Pi 400 64 bit Bullseye, latest updates/Debian Bullseye 64 bit (Intel) latest updates

[Cuperino]

For icons, QPrompt follows the Freedesktop Icon Naming Specification, in which icon are specified as categories and the operating system takes care of supplying those icons for a consistent user experience across all of your programs. This is a feature of the Linux desktop and a few other free operating systems, which results in the same version of QPrompt showing different icons across different distributions.

On v1.0, no icons where shown when the operating system couldn't supply icons. Now QPrompt brings its own icons, but these are replaced with system icons when they're available. I could make it so QPrompt doesn't ever use system icons, but this would mean not respecting the Freedesktop specification.

With icons, so far I've been inclined to follow the specification. Please state your argument regarding why should icons be the same across all operating systems. I have my own arguments in favor and against, but I think it would be best for the future of the project if users opinions where publicly stated.

For your system's icons to match those included with QPrompt, the system must be configured to use the breeze-icons or breeze-icons-dark set of icons. Please note that containerized apps (Snap, AppImage, and Flatpak) sometimes don't respect system icon configurations because of limitations with the container technology that are being overcome.

[videosmith]

The icon selection is not essential to me as long as they are all represented somehow.   My primary concern is the fact that one distribution (RPi deb) still shows WYSIWYG and the other does not leading me to believe the two distributions may not be in sync?   Also the RPi 'deb' distro appears to open your welcome file in Bold (even though the Bold icon is not highlighted)... if I select some text and click the Bold attribute twice, the font redecorates to Normal as well as the font size appearing larger than that of the deb AppImage (intel) distribution... even the Reading Region cursor appears larger. Is this also the case at your end? On Friday, July 29, 2022 at 12:24:35 PM EDT, Javier O. Cordero Pérez ***@***.***> wrote: For icons, QPrompt follows the Freedesktop Icon Naming Specification, in which icon are specified as categories and the operating system takes care of supplying those icons for a consistent user experience across all of your programs. This is a feature of the Linux desktop and a few other free operating systems, which results in the same version of QPrompt showing different icons across different distributions. On v1.0, no icons where shown when the operating system couldn't supply icons. Now QPrompt brings its own icons, but these are replaced with system icons when they're available. I could make it so QPrompt doesn't ever use system icons, but this would mean not respecting the Freedesktop specification. With icons, so far I've been inclined to follow the specification. Please state your argument regarding why should icons be the same across all operating systems. I have my own arguments in favor and against, but I think it would be best for the future of the project if users opinions where publicly stated. For your system's icons to match those included with QPrompt, the system must be configured to use the breeze-icons or breeze-icons-dark set of icons. Please note that containerized apps (Snap, AppImage, and Flatpak) sometimes don't respect system icon configurations because of limitations with the container technology that are being overcome. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[Cuperino]

My primary concern is the fact that one distribution (RPi deb) still shows WYSIWYG and the other does not leading me to believe the two distributions may not be in sync?

I totally missed that! I accidentally uploaded the beta-7 build again for the arm64 deb package instead of the new rc-1 build. I've fixed it now.
https://github.com/Cuperino/QPrompt/releases/download/v1.1.0-rc-1/qprompt-main-0fbee21-linux-aarch64-gcc.deb

The icon selection is not essential to me as long as they are all represented somehow.

I see... Then I'll keep the integration with Freedesktop icons for now. I have no problem in removing it, but it comes with other perks, such as different variations being used depending on the UI's scaling factor.

Also the RPi 'deb' distro appears to open your welcome file in Bold (even though the Bold icon is not highlighted)... if I select some text and click the Bold attribute twice, the font redecorates to Normal as well as the font size appearing larger than that of the deb AppImage (intel) distribution... even the Reading Region cursor appears larger.
Is this also the case at your end?

I will have to test this on a Debian Gnome system since I'm using Debian KDE to do the builds. I've noticed that different fonts are chosen for the UI in some distributions, possibly a similar kind of integration provided by the Qt or Kirigami framework. That is a good thing because it ensures QPrompt will use a font that is compatible with whatever language from the translations is being shown.

The font from the editor, however, shouldn't be affected as that uses the DejaVu font I've included with the program for a consistent output across all OS, and a different font can be used for languages incompatible with DejaVu.

Font strength should also go unaffected, so that's clearly a bug that needs to be addressed. I didn't do any changes to document handling in rc-1, so I'm sure the bug affects it too. I'll take a good look at it on Monday.

[Cuperino]

The issue did not occur to me by default on Debian Gnome. I was able to replicate the issue by deliberately configuring the distro to display text in bold. This only had an effect in desktop environments that have integration with KDE apps. Configuring the Gnome desktop to show text in bold had no effect over QPrompt.

The workaround is configuring your Linux desktop to not display UI text in bold.

I tried requiring QPrompt's document CSS to use a normal font strength as the default, but the OS's setting keeps coming through... We need a different solution to fix this issue. I'm deeming it low priority for now.

[videosmith]

Not sure if its me/my gear, however the mouse wheel scrolling through text in edit mode appears to behave differently in the 1.1.0 beta vs. The1.0 release. This is difficult to describe, however when using the mouse wheel in 1.0 edit mode, the script appears to roll at the same velocity as the wheel input, as it behaves in word processors. In 1.1.0 it seems to act like a sloping velocity change dependent on the speed of the wheel input and rolls farther on a fast wheel scroll than a slow one, overshooting when I stop turning the mouse wheel.  Am I making sense?

[videosmith]

Had to send the previous message through email because could not save on GitHub from my phone for some reason.

[Cuperino]

Not sure if its me/my gear, however the mouse wheel scrolling through text in edit mode appears to behave differently in the 1.1.0 beta vs. The1.0 release. This is difficult to describe, however when using the mouse wheel in 1.0 edit mode, the script appears to roll at the same velocity as the wheel input, as it behaves in word processors. In 1.1.0 it seems to act like a sloping velocity change dependent on the speed of the wheel input and rolls farther on a fast wheel scroll than a slow one, overshooting when I stop turning the mouse wheel. Am I making sense?

You are making sense and this has nothing to do with your gear. Between v1.0 and the more recent betas, there have been changes done to the underlying libraries that add some kind of inertia to text scrolling. These changes were being masked by QPrompt because QPrompt used to take over the wheel event at all times. This caused a series of bugs in macOS that led to undesirable behavior, so now QPrompt toggles between its own wheel behavior and the underlying libraries as needed.

QPrompt v1.1 RC-1 toggles between the native wheel and QPrompt's own implementation as you switch between edit mode and all other modes respectively. This reveals the flickable text's inert default behavior, which varies slightly between operating systems and is most sloppy on Windows and Linux. On Windows the effect of a single scroll tick varies drastically depending on how close or far apart in time was the delay between the last tick and second to last tick. On Linux the effect feels exaggerated and there's no good way to stop it without reversing the animation. The fix also introduces a bug where the scroll stops working after returning to edit mode in some distributions. On Mac this implementation results in a very solid feeling and bug free behavior.

Restoring controls similar to how they used to be in 1.0 creates a different bug on Linux and Windows where the sloppy scroll still occurs when scrolling from certain areas outside of text bounds. Fully fixing this issue causes another issue where changes to the mouse cursor stop working. I'm inclined to leave the first workaround in favor over the second one because it doesn't bother most of the time and mouse cursors are crucial for newcomers to discover functionality from the UI that's not immediately evident. RC-2 shows this first workaround in action for Linux and Windows. Mac behavior on RC-2 is broken by the patch, but this has already been fixed for the final release.

Please let me know how Linux and Windows variants feel to you in RC-2. I'll try making an RC-3 for today if time allows.

[videosmith]

Mouse scrolling in edit mode responds like 1.0 again. Thank you. On Thursday, August 4, 2022 at 04:38:25 AM EDT, Javier O. Cordero Pérez ***@***.***> wrote: Not sure if its me/my gear, however the mouse wheel scrolling through text in edit mode appears to behave differently in the 1.1.0 beta vs. The1.0 release. This is difficult to describe, however when using the mouse wheel in 1.0 edit mode, the script appears to roll at the same velocity as the wheel input, as it behaves in word processors. In 1.1.0 it seems to act like a sloping velocity change dependent on the speed of the wheel input and rolls farther on a fast wheel scroll than a slow one, overshooting when I stop turning the mouse wheel. Am I making sense? You are making sense and this has nothing to do with your gear. Between v1.0 and the more recent betas, there have been changes done to the underlying libraries that add some kind of inertia to text scrolling. These changes were being masked by QPrompt because QPrompt used to take over the wheel event at all times. This caused a series of bugs in macOS that led to undesirable behavior, so now QPrompt toggles between its own wheel behavior and the underlying libraries as needed. QPrompt v1.1 RC-1 toggles between the native wheel and QPrompt's own implementation as you switch between edit mode and all other modes respectively. This reveals the flickable text's inert default behavior, which varies slightly between operating systems and is most sloppy on Windows and Linux. On Windows the effect of a single scroll tick varies drastically depending on how close or far apart in time was the delay between the last tick and second to last tick. On Linux the effect feels exaggerated and there's no good way to stop it without reversing the animation. The fix also introduces a bug where the scroll stops working after returning to edit mode in some distributions. On Mac this implementation results in a very solid feeling and bug free behavior. Restoring controls similar to how they used to be in 1.0 creates a different bug on Linux and Windows where the sloppy scroll still occurs when scrolling from certain areas outside of text bounds. Fully fixing this issue causes another issue where changes to the mouse cursor stop working. I'm inclined to leave the first workaround in favor over the second one because it doesn't bother most of the time and mouse cursors are crucial for newcomers to discover functionality from the UI that's not immediately evident. RC-2 shows this first workaround in action for Linux and Windows. Mac behavior on RC-2 is broken by the patch, but this has already been fixed for the final release. Please let me know how Linux and Windows variants feel to you in RC-2. I'll try making an RC-3 for today if time allows. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>