Display Large Text action; Set Display for Its Appearance?

[Frederico]

At the risk of duplicating other threads on the Display Large text action's somewhat limited capabilities and parameters, I'm wondering if, like Display HTML, I can set the target display for the text float-over window.

It seems to be bound to the Main Screen (Display containing the Menubar), rather than the screen with the frontmost window. I haven't tested, but I'm guessing that KM will target whichever screen has a Menubar in focus, such that if I used Spaces/Mission Control with a Menubar on all screens, the float would appear on the display with the in-focus Menubar. At least that would make sense to me, anyway, and is certainly a desirable behavior.

Problem is I don't use Menubar on all Displays (total of six); and I'm recently completely focussed on a screen that doesn't show the Display Text Large, and I'm missing important informational notices.

I only have two-three solutions, none of which act in a preferable or acceptable manner, or are EOL. The Display HTML Action indeed can target the desired Screen, but gets in the way, and isn't easily created for every desired instance; though it can be dismissed without user interaction.

Display Text in a Window works, is formattable, but is still ugly/inelegant and requires I dismiss it.

Changing Duration of Display Text Large could work in some instances, but it would get stepped on by any subsequent messages.

My current method has been to pass the text to Growl, and use it to target the correct/desired screen in focus, along with desired formatting and duration; but as I, like most everyone else, is on a quest to eliminate 32 bit and EOL software and utilities per Catalina/Big Sur requirements, my beloved Growl is going away one day.

[as an aside, if anyone knows of, or knows how to code custom floating notifications with fine controls, a la Growl, I'd LOVE to hear of it.]

System Notifications are too unreliable, too limited, too small, and too annoying. They also disrupt macros using mouse-clicks and GUI interface, such as typing text; as does Display HTML.

So, if there are some hidden prefs for DisplayTextLarge -[target window] I'm not seeing, I'd appreciate a hint; or kindly consider this a feature request, @peternlewis, along with other requests for more accessible, on the fly display options and control for this invaluable action.

Kind Regards to All and Happy Thursday

F

[peternlewis]

@Frederico

It seems to be bound to the Main Screen (Display containing the Menubar), rather than the screen with the frontmost window.

Keyboard Maestro simply displays the window and asks the system to center it, so the system is picking the screen. In my tests, it picks the screen with the front window on it.

@Frederico

Problem is I don't use Menubar on all Displays (total of six);

How do you do that? I don't see any Display arrangement preference to avoid a menu bar on all windows.

[Frederico]

@peternlewis

Keyboard Maestro simply displays the window and asks the system to center it, so the system is picking the screen. In my tests, it picks the screen with the front window on it.

For me, the Main Display (with Menubar) happens to be the center of three 4K displays. I freely admit I should've tested before posting; I was bored in a waiting room. (;

@peternlewis

How do you do that? I don't see any Display arrangement preference to avoid a menu bar on all windows.

System Preferences –> Mission Control –> Displays have separate Spaces (High Sierra(?) and later; else Spaces prefs)

HTH

Any comments on adding a method of targeting the display? Or is there a new window-type that could be added to KM.future that could replicate, except with easily-accessed fine controls?

[peternlewis]

@Frederico

System Preferences –> Mission Control –> Displays have separate Spaces (High Sierra(?) and later; else Spaces prefs)

So you have that turned off? Mine is turned on, which I assume is the modern default (as opposed to the old style entire desktop is one big space across multiple monitors).

@Frederico

Any comments on adding a method of targeting the display? Or is there a new window-type that could be added to KM.future that could replicate, except with easily-accessed fine controls?

There is currently no way to target a specific screen. I doubt I would add such functionality, though I would have thought it was targeting the screen with the front window, but if you have the preference turned off then the entire display might b e being treated as one big screen and centering it may act differently.

[Frederico]

@peternlewis

So you have that turned off? Mine is turned on, which I assume is the modern default (as opposed to the old style entire desktop is one big space across multiple monitors).

You are correct; it is the modern default since Spaces was created (or at least since it got wrapped into Mission Control). I dislike Spaces to begin with, let alone treating each display as a Space. Unfortunately it requires Logout to test, and I'm not in a position to do that just now (running an exceptionally long render that will bork if I Logout or switch users).

@peternlewis

I would have thought it was targeting the screen with the front window, but if you have the preference turned off then the entire display might be being treated as one big screen and centering it may act differently.

Indeed; it is definitely centering on my Main Display (lower center), but it's ignoring the set of three upper displays, so it's obviously smart enough to not center on the entire display area.

It definitely doesn't respect or consider frontmost window in my case.

I get that you're not motivated to change/improve the behavior for an edge case like mine, but I have to believe there are legions of MacBook users with a second display, who choose where to display the Menubar, rather than in Spaces. I know I am/was responsible for a couple dozen who have Spaces disabled.

Do you at least get the why of my request? Sometimes misery only needs acknowledgment. (;

[Frederico]

For anyone following along, I did think just now to test where it appears by moving the Menubar to different displays (doesn't require Logout); and it definitely focuses and centers on whichever display is declared to be Main display (includes Menubar). So that neatly explains why it behaves as you Spaces users expect, and you get the behavior I desire; i.e., whatever window is in focus will by default have its parent display's Menubar also in focus; and KM's request for the System to Display Large Text Window is correctly interpreted to mean where the user is likely focussed.

The thing is, while the System, correctly interprets this same idea in many/most other apps (e.g., an AppleScript 'tell current app' [default] dialog will always appear in the screen whose window is frontmost; most app's Preferences and About and New Window will appear on whatever screen is currently in focus, unless it stores prefs for that window separately, and it can remember it through relaunch; a sloppy app will display said window offscreen entirely if that screen goes missing) whether or not you're using Spaces; so I humbly suggest, @peternlewis, that there's a parameter that could be specified at a code level that is missing.

So, though I get you're unwilling to allow for targeted display, I don't think it unreasonable to adopt whatever System API parameter that tells an app to respect the user's frontmost window focus on a system not using Spaces, n'est-ce pas?

[peternlewis]

@Frederico

I dislike Spaces to begin with, let alone treating each display as a Space.

I agree, I basically never use Spaces. But menu on each display and seperate spaces for each monitor works reasonably well in my experience, even as a traditionalist. About the only downside is not being able to have windows across monitors, but that has benefits too, you can move a window near the edge of one monitor without obscuring the other.

@Frederico

So that neatly explains why it behaves as you Spaces users expect, and you get the behavior I desire; i.e., whatever window is in focus will by default have its parent display's Menubar also in focus; and KM's request for the System to Display Large Text Window is correctly interpreted to mean where the user is likely focussed.

Right, it is focussed on the center of the currently selected screen, which is where the menu bar is.

So what happens in a typical app if you open up a new window for the first time. I presume it usually goes on the main (menu bar) screen?

In this case, I simply open the window and the system chooses where to go. It's centered, but presumably centered on whichever is the screen it is already on.

I'm afraid I don't know how I would change it in this case to choose a different screen.

I'll take a look, but basically this is just doing what the system does, and I'm not sure I want to go against that.

[Frederico]

@peternlewis

So what happens in a typical app if you open up a new window for the first time. I presume it usually goes on the main (menu bar) screen?

As I said, it greatly depends on the app. There are apps that refuse to respect either Main Display or 'last used' coordinates; TeamViewer is an example of this; whichever screen is hosting the main TeamViewer window (the list of computers, actions, etc.), is the screen on which it will open a new connection window; and connection windows (nor the main window, annoyingly) will not remember their screen coordinates between sessions /app launches; whereas an app like Screens also opens the first session of a given device on whichever screen is hosting its main window, but, after closing and reopening a saved connection or previous device, it will record and recall the last window position.

An app like BusyCal or BusyContacts will (mostly) remember where your windows should reopen; but certain windows, like 'About' and 'Check for Updates...' will only appear in the dead center of the screen whose window is frontmost, regardless of Menubar or not.

There are many other examples, good, bad, and worse; but the point I'm making is it's clearly possible to dictate (or not) on which screen the windows appear, regardless of Spaces or no Spaces (single Menubar).

I'd really appreciate any effort you can put towards this; perhaps a well-worded query to the Developer's list and/or Twitter might yield clues, if not an answer?

Thanks!

[Frederico]

So, today is a riddle; for no reason I can suss out, the Display Large Text window is now appearing on my upper display, above the Menubar on the main display (of six displays). It has even persisted through a Logout/Login. I have not tried a Restart, as, quite frankly, I like it up there, and it wouldn't bother me if it stuck -- though I still wish I could target a given display, or at least the display in focus.