Toggle between current font size slider position and a preset font size

[videosmith]

Describe the solution you'd prefer When prompting large font sizes and editing is desired, currently you need to slide the font size slider down to see more text on the screen, then slide back up after editing.

A radio button/toggle to quickly resize to a user inputted value, then toggle back to the previous size may speed up editing operations.

[Cuperino]

Wow... I had actually implemented this prior to v1.0 in the form of a "WYSIWYG" button that allows switching between two font sliders, one of which controlled the font size while exclusively while editing. The feature is still dormant in the code, I never fully removed it... The reason it was disabled is I found it was confusing to use for a couple of early testers.

I was thinking of giving users the option to separate the editor from the prompter for QPrompt v1.2. The dormant slider would then be used for the editor and a slider for the prompter's font size would be available both in the editor and prompter windows. What do you think of this idea?

Having the editor be the prompter would continue to be an option because it's the only way QPrompt can work on Android and iOS. The option to have a separate prompter would be disabled in those systems. Instead a solution like what you've proposed could be used for the mobile UI.

[videosmith]

I like having the editor and prompter integrated with one possible exception: If editing would real time update in the prompter as the operator scrolls. Two separate windows would bring up the issue of synchronization between the editor and prompter... should they auto update each other or not?

My suggestion is a (can a os macro recorder follow mouse/slider interactions?) or button that has a user-set size for a quick reduction of text, focused on the line where the cursor is positioned, so the talent can see more of the script while making changes, then restore the font size to the zoom slider's setting for scrolling, also focused on the line where the cursor is positioned.

[Cuperino]

Two separate windows would bring up the issue of synchronization between the editor and prompter... should they auto update each other or not?

I'm thinking of initially implementing a unidirectional "push to sync" button and soon after add the option for real time auto sync. In the push to sync, editing from the prompter instead of the editor would have to be disabled if there are changes in the editor that haven't been synced. With auto update enabled, editing from the prompter may need to be fully disabled for performance reasons.

(can a os macro recorder follow mouse/slider interactions?)

I doubt it. Modern operating systems restrict app's ability to read the inner state of another app without special hooks for security reasons. Some workarounds, such as the use of accessibility APIs, rely on user actions and are not considered reliable development practices in some cases.

My suggestion is a button that has a user-set size for a quick reduction of text, focused on the line where the cursor is positioned, so the talent can see more of the script while making changes, then restore the font size to the zoom slider's setting for scrolling, also focused on the line where the cursor is positioned.

What you're describing is, more or less, the WYSIWYG feature that was, until now, disabled in the program. The challenge here lies in keeping alignment with the correct line while switching between small and large font sizes, as the leftmost words in a line will probably have already been read, thus switching between modes would inherently set back the prompter by a few or several words on every switch.

I've just re-enabled the feature in the master branch for testing purposes, with improvements that prevent alignment resets in most circumstances. Expect a new build soon.

[Cuperino]

New beta build: https://github.com/Cuperino/QPrompt/releases/tag/v1.1.0-beta-7

[Cuperino]

When you have the time, please test beta-7 to see how the limitations of switching between a small and a large font-size influence your user experience. Please note that for this new Debian build of QPrompt to work, you'll need to install the libqhotkey package, which is provided among the downloads.

[videosmith]

I'm thinking of initially implementing a unidirectional "push to sync" button and soon after add the option for real time auto sync. In the push to sync, editing from the prompter instead of the editor would have to be disabled if there are changes in the editor that haven't been synced. With auto update enabled, editing from the prompter may need to be fully disabled for performance reasons.

In my workflow, clients normally direct me to make changes quickly while they are viewing the prompt output. I believe your current method of a single edit/prompt interface may work better for me than this approach.

[videosmith]

When you have the time, please test beta-7 to see how the limitations of switching between a small and a large font-size influence your user experience. Please note that for this new Debian build of QPrompt to work, you'll need to install the libqhotkey package, which is provided among the downloads.

Thank you. I downloaded 'qprompt-main-2eabca7-main-linux-64-gcc.AppImage' (I assume libqhotkey is already included).

I think this is a great option!! Really helps with situations where I am in 480p resolution to accommodate smooth animation on RPi 400 computers and the text area is reduced by the bottom menus.

The only comment so far is that the switching appears to 'sync' be on whatever text is somewhat centered in either window at that time vs. cursor position... is this correct?

[Cuperino]

In my workflow, clients normally direct me to make changes quickly while they are viewing the prompt output. I believe your current method of a single edit/prompt interface may work better for me than this approach.

It's clear to me now that the best approach varies according to the operator's context. I'll leave this feature in and also work on something for the other group of users for a future update.

I assume libqhotkey is already included (with the AppImage)

Yes it is.

I think this is a great option!! Really helps with situations where I am in 480p resolution to accommodate smooth animation on RPi 400 computers and the text area is reduced by the bottom menus.

Happy to hear. I'll keep looking for ways to optimize for space on small screens.

The only comment so far is that the switching appears to 'sync' be on whatever text is somewhat centered in either window at that time vs. cursor position... is this correct?

It centers to the vertical middle of the reading region. If the cursor is placed within that line, then it centers to the line that matches the cursor's placement.

Following the cursor at all times is a bad idea because if the cursor is at start or at end, the user starts prompting and then switches to the small font size, their position could be reset, which would result in frustration. Always matching the reading region would frustrate readers the least.

The cursor could be followed, but the condition in which it is followed should be carefully defined. I'm going to try have QPrompt follow the cursor only if it is within the bounds of the viewport, and use the reading region for cursor placement if the cursor is off screen.

[Cuperino]

I've updated the code to: When switching to the large font, follow the cursor only when the cursor is within the visible bounds of the viewport. The behavior remains intentionally unchanged when switching to the small font, in other words, there the read region's placement continues to be used.

New beta soon. Likely tomorrow.

[Cuperino]

I've moved the WYSIWYG button's action to the left of the Font size slider to reduce UI clutter.

[videosmith]

Sounds good. Is this still beta, or a final release? On Wednesday, July 13, 2022 at 12:40:52 PM EDT, Javier O. Cordero Pérez @.***> wrote:

I've moved the WYSIWYG button's action to the left of the Font size slider to reduce UI clutter.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[Cuperino]

This will be a beta. Today I marked all the issues that need to be addressed prior to the final v1.1 release with needs attention prior to release. Most of which are almost done by now!

I will also attempt to fix issues #78 and #81 prior to release, but I can't promise anything about those because the development pipeline for testing the Android version is very poor and needs to be improved. These could take a few more days.

Also, a user in our Telegram chat reported experiencing crashes on Windows 10. Unfortunately they left without providing enough detail. I'll do my best to recreate their setup with educated guesses based on what used to crash previously, and if I'm able to replicate the crashes I'll work on a fix, but I can't consciously fix what I can't see as broken.

Then I need to ensure all the changes I've done lately from macOS don't break anything on Linux and Windows. Normally I develop QPrompt on Linux but the Mac version had glaring issues that needed to be addressed, so development had to be done on the Mac; and my backup PC is starting to break apart ("failing to post" and showing graphical glitches), probably from overheating, while the laptop I ordered to replace my broken laptop (which sadly I couldn't repair) just began manufacturing.

Last but not least, there are various issues with Craft, the tool used for our build pipelines, that are affecting our ability to create packages for distribution. I've added links to my bug reports over at https://github.com/Cuperino/QPrompt/issues/8#issuecomment-1184034498. Nevertheless, I may end up releasing a Deb package for x86_64 if I'm unable to build QPrompt's AppImage correctly. Fortunately Snap and Flatpak won't suffer from that problem.

The Snap and Flatpak releases will be delayed about a week, as those need to accommodate the inclusion of the QHotkey library. Having said that, I expect QPrompt v1.1 to be out this month.