Position & Size of 'Custom HTML Prompt' Windows Measure Differently Than Other Windows

Questions & Suggestions
1

When using Keyboard Maestro to set the position and size (using X0,Y0,Width,Height), I've noticed two inconsistencies with Custom HTML Prompt windows vs other windows. With the former:

  1. Y0 is from the top of the screen to the top of the window content area (i.e., the bottom of the title bar). With other windows, Y0 is from the top of the screen to the top perimeter of the window (i.e., the top of the title bar.)

  2. Height is from the top of window content area (i.e., the bottom of the title bar) to the bottom of the content area. With other windows, Height is from the top perimeter of the window (i.e., the top of the title bar) to the bottom perimeter of the window

Here's an example...

Using 0,60,1100,200, the below Custom HTML Prompt window is positioned as follows:

2024-03-26 21.20.00@2x
2024-03-26 21.20.00@2x2220×539 121 KB

Note that the screenshot includes measurements in nominal resolution pixels, i.e., points.

The Custom HTLM Prompt includes:

<head>
    <meta charset=utf-8/>
	<style>
		body {width: 1100px;}
	</style>
</head>
<body data-kmhandleschemes="http https"
      data-kmwindow="0,60,1100,200">

These inconsistencies make it challenging to accurately position and size Custom HTML Prompt windows.

  • When automating the placement of windows a special case would be needed for Custom HTML Prompt windows.

  • Unlike other window (and screen) dimensions, the height of the Custom HTML Prompt window title bar is not available via a Keyboard Maestro window/screen function or window/screen token.

@peternlewis, are these differences intentional?

1 Like
2

I believe so, but I can't fine the documentation or comments on it off hand.

Basically, from memory, it stems from a difference that was there originally and that needs to remain for compatibility.

3

@peternlewis, thank you very much for the reply.

That makes sense.

Would you consider one of the following enhancements?

  1. Adding an optional parameter to the HTML Body Attribute data-kmwindow that if set would position and size the Custom HTML Prompt window like other windows.

  2. Adding a window function (and token) that would return 0 unless a window is a Custom HTML Prompt and the Has Title option is checked. In these cases, return the height of the title bar.

Maybe there's a better way to address the issues I mentioned, but if either of the above were added, automated positioning and sizing of windows would be more straightforward.

Thanks in advance!

4

Possibly. I'll have to figure out the exact reasoning for it to know for sure.

I don't understand how this would work, it would have to be within the Custom HTML Prompt in order to know what the settings of the Custom HTML Prompt was, so how would a toke/function work?

5

@peternlewis, thanks again for the reply!

Excellent! From the users' standpoint, this would be easy to implement.

Chalk this one up as a dumb idea. When I wrote it I was thinking that I could use the new function/token in conjunction with the Manipulate a Window action; but since I've discovered that that action does not recognize Custom HTML Prompt windows.

1 Like
6

I've since noticed that, from a positioning standpoint, the inconsistency with other window types is not observed if...

<body data-kmhandleschemes="http https"
      data-kmwindow="0,60,1100,200">

is replaced with...

<body>

and Set Next Engine Window Position is used instead.

Keyboard Maestro Export

Unfortunately, however, there seems to be a downside with this approach: the Custom HTML Prompt does not seem to respond to the Next Engine width and height.

Keyboard Maestro Export

2 Likes
7

Hello Jim (@_jims):wave:

This is totally true - it’s because you will define the Window size and position like any other window …

If you go the route with using data-kmwindow you are going to define the position and size of the HTML content only from the upper left corner of your display. The Height of the window as well as the height of the Menubar are not ignored …

If you’d like to use data-kmwindow and position the window like any other window you will have to calculate with the height of the Window Titlebar when used as well as the height of your Menubar.

What I am thinking here is that this just because of WebKit’s integration and that maybe Peter has no more options for better integration based on how KM is developed than the options he is already using.

Maybe there could be another way of integration when using private API‘s… but that’s something that will never happen. We will have to wait until Apple gives Peter more flexibility with better public API’s I think … or just live with it like it is.

Greetings from Germany

Tobias

8

I've developed a method to address this inconsistency and shared it in the following tutorial:

Positioning & Resizing Windows, Dialogs, and Lists Using WindowArgs

2 Likes