MACRO: Display Large Text Notification v1.2

Display Large Text Notification v1.2

REQUIRES KM Version 10 and above

This should work on most recent versions of macOS, down to at least Big Sur, and possibly Catalina.

image

PURPOSE:

Similar to the native Display Text action with the "Display text large" setting, but with many more options.

Based on based on the original work by @martin.

OPTIONS

This is a subset of the available options:

image

image

USAGE

Click to see all the options

image

Click to see the documentation, which is included in the macro itself.

VERSION HISTORY

1.2 "Timer Duration" now allows fractional values (i.e. 0.5)
1.1a Fixed a type in the HTML file.
1.1 Added the "Restore Window Focus" parameter.
1.0 Initial Release.

INSTALLATION

Upgrading an existing version:

If you are upgrading an existing version, delete the old macros before importing the new ones. There should be no breaking changes in the new version.

Downloading and Installing:

Download the macros, unzip them, and double-click the .kmmacros file. It will import 3 macros into the group "Display Large Text Notification":

  • Display Large Text Notification
    • This is the main macro. Call it as a subroutine.
  • Display Large Text Notification - Demo
    • See this macro for some brief examples.
  • Display Large Text Notification Cleanup
    • Used internally.
  • Display Large Text Notification - Reveal Macro Palettes
    • Hopefully you won't ever need this. Read the comments in this macro for an explanation.

Display Large Text Notification.v1.2.kmmacros.zip (20.8 KB)

12 Likes

May I ask a question before downloading it? In your example that says "Close and Copy buttons and Timer" did it insert the newline itself, or does the user have to insert the newlines manually? I need to ask because your subroutine includes only one visible line for "Text". Passing a multi line variable is possible in a single text box, but it's not obvious to some people.

Thank you for this macro. I love it!

1 Like

Sorry I didn't respond to this earlier - for some reason I didn't get an email notification.

If you specifically want newlines, then I would recommend using a "set variable to text" to set the multiline text, then use that as a parameter. Several of the demos do that.

If the text doesn't fit on the screen, it wraps automatically.

Hope that helps!

1 Like

HUGE thanks @DanThomas!

You've found an elegant solution to one of Keyboard Maestro's most frustrating features!

1 Like

Excellent, thank you @DanThomas

3 Likes

That reminds me to compliment you on the thorough documentation and guidance within your macro. :clap:

3 Likes

Thanks - I can't help myself. :slight_smile:

This is a very nice addition to Keyboard Maestro. Thank you!

Is there any way to create a setting that prevents the notification window from stealing the focus when it is displayed? I have a macro that runs continuously and it occasionally calls this macro. If I typing in another application this macro can steal the focus and my typing is blocked and I get error beeps until the Display Text window times out.

I tried to solve this when working with @martin's macro. I am not a html, CSS, javascript expert and could not find a solution.

Not that I can think of. A Custom HTML Prompt is always going to steal focus when it gets displayed.

You're the expert on that action, so I believe you.

However when I want a window to display text without grabbing the focus, I use Display Progress Bar which allows you to display a line of text on a window without grabbing focus. And it's easy to close programatically, as well.

@peternlewis - That's correct, right? A Custom HTML Prompt will always grab focus when it's launched, right?

Barring an "official" solution, I've had a quick play and immediately preceding your "Custom HTML Prompt" call with this async AS action may solve the problem:

Script:

tell application "Keyboard Maestro Engine"
	try
		set startWinID to id of window 1
	on error
		set startWinID to 0
	end try
	set winID to startWinID
	repeat until winID ≠ startWinID
		delay 0.1
		try
			set winID to id of window 1
		on error
			set winID to 0
		end try
	end repeat
	do script "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<array>
	<dict>
		<key>Action</key>
		<string>SelectWindow</string>
		<key>MacroActionType</key>
		<string>ManipulateWindow</string>
		<key>TargetApplication</key>
		<dict/>
		<key>Targeting</key>
		<string>FrontWindow</string>
		<key>TargetingType</key>
		<string>Front</string>
	</dict>
</array>
</plist>"
	
end tell

Demo -- change hot key to something unique, run with a window in another app active:

Re-activate Window.kmmacros (3.6 KB)

Image

Note that palettes are also engine windows, which is why this needs a unique trigger to avoid the Conflict Palette. There might be a way to work round that if it's an issue.

Um, what does it do? ;p

Logs the id of the frontmost Engine window (0 if none present), and when that changes (new HTML prompt [or, grrr, palette, etc]) sends the KM "activate front window of front application" action to bring your "working" window back into focus.

1 Like

I added this script call and it does help considerably. I reduced the delay to 0.02 seconds (not sure if this actually helps). I can now be typing in a separate application with multiple rapid asynchronous calls to "Display Large Text Notification" occurring. I still get occasional beeps when this occurs but focus always returns very quickly to the app where I am typing.

This is a major improvement.

Thank you!

The smaller the delay, the more frequent the check for the arrival of the HTML Prompt. The more frequent the check, the quicker focus will be returned to your active window. But the more frequent the check, the more OS resources devoted to doing the check.

So it's a balancing act -- make the delay as short as you can, but not to the point where it impacts the other things you are doing.

I've got an idea for how to build this into my Custom HTML Prompt. Let me experiment a little and see what I can come up with.

@Nige_S, @GordonZ, @Airy

I just uploaded version 1.1, which has a parameter to restore the focus to the main window.

The download file is in the first post. Let me know if this helps.

NOTE: This should respond pretty quickly to the application's window losing focus. No need for a timer.

Display Large Text Notification >> Write HTML to temp file >>

_restoreFrontWindowFocus = getKMVar_bool("Local__Restore Front Window Focus");

It needs to be modified to

_restoreFrontWindowFocus = getKMVar_bool("Local__Restore Window Focus");

2 Likes