System font formatting properties affect the document inside the editor #104
Comments
|
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 |
Cuperino
changed the title
|
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: ***@***.***>
|
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.
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.
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
changed the title
|
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. |
|
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?
|
|
Had to send the previous message through email because could not save on GitHub from my phone for some reason.
|
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. |
|
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: ***@***.***>
|
|
Fyi: Also noticed that after changing a script to normal weight, then copy/paste part of it, the paste appears in Bold again. |
In my Debian 11 KDE Plasma system where I was able to replicate this issue, QPrompt always applies the system's bold, regardless of the prompter's contents. Copying the contents from QPrompt to LibreOffice reveals QPrompt's contents themselves are not in bold despite being displayed in bold. Manipulating the font's weight in LibreOffice and then pasting it to QPrompt has no effect because QPrompt is applying the system's bold regardless. |
|
Whats unusual is that it only affects that attribute, italic, underscore, color and strike through don't seem to be affected... just an observation... not a deal breaker.
On Thursday, August 25, 2022, 04:30:37 PM EDT, Javier O. Cordero Pérez ***@***.***> wrote:
Fyi: Also noticed that after changing a script to normal weight, then copy/paste part of it, the paste appears in Bold again.
In my Debian 11 KDE Plasma system where I was able to replicate this issue, QPrompt always applies the system's bold, regardless of the prompter's contents. Copying the contents from QPrompt to LibreOffice reveals QPrompt's contents themselves are not in bold despite being displayed in bold. Manipulating the font's weight in LibreOffice and then pasting it to QPrompt has no effect because QPrompt is applying the system's bold regardless.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
It's probably because bold in CSS is dealt with differently from other font properties. Instead of bold being a simple boolean type value (true or false), regular text means having a "font weight" of 400, and bold means having a font weight greater than 400; it being set to 700 by the standard. Here's Qt's table of weights for reference, which apparently borrows this from OpenType: |
|
Just wondering if there's been any progress on this issue? Still unable to bold text on macOS using the default font, which also means that Markdown import doesn't really work either... |
|
Hi @Douglas-Cox, No progress on this one; but are you confident you're having this issue (#104) and not a different one? (Here's a list of all past and present issues that mention bold: https://github.com/Cuperino/QPrompt/issues?q=bold) I personally doubt this issue could affect Mac users. What version of macOS are you running, and is it on an Apple Silicon or Intel CPU? |
|
Hi @Cuperino - thanks for the quick reply! Possible that this isn't the same issue, but in searching open issues it seemed like it could be the problem. Running QPrompt 1.1.2 on macOS 12.6.2 Intel. Happy to raise this on a new issue if it needs further investigation; or let me know if there's something obvious that I'm missing.
|
|
@Douglas-Cox I've replicated your issue. It is a different issue. For the sake of keeping things organized, let's continue the conversation at: #2 |
|
@Douglas-Cox This won't help with Bold, but I forgot to tell you that you're running a slightly outdated version of QPrompt. Updating to v1.1.3 will give you a nice performance boost. |
|
I've given this issue another go today, but am still unable to find a solution. |
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
Expected behavior
Should be identical on both platforms
Screenshots (optional)
Device information
The text was updated successfully, but these errors were encountered: