I've been trying the Center Window action and I noticed that it "centers" the window differently than the same action in BetterTouchTool (a "little bit above what BTT considers center")
Could you shed some light into what is going on? Why the difference? Are both apps considering different total dimensions to calculate the center (e.g. one considers the menu bar, etc.). Which of the apps "is right"?
The closest I could find here was this post, but I really don't want to be messing with percentages and calculations when there is an action that should achieve this and, I was hoping, would have total parity with BTT action.
Thanks.
EDIT: Just tested it, and that is exactly what seems to be happening. Keyboard Maestro centers on the whole screen, without excluding the Menu Bar. Better Touch Tool centers on the screen excluding the Menu Bar
Wouldn't it make more sense to have the center action working as BetterTouchTool does? Considering you are not able to overlap (or underlap) the Menu Bar if you try to drag a window over it, my opinion is that those 24 pts shouldn't be considered for the centering calculation and it should happen just below it (from the bottom of the Menu Bar to the bottom of the screen). Also looks nicer and truly "centered" with the BTT action, vs. Keyboard Maestro that visually looks like the app window is not in the "proper center".
Looking forward to hear more on this and the reasoning for considering it for the Center Action. Thanks again!
I imagine this comes down to user preference: To me, the first window (KM) is centered, and the second one (BTT) is not. Why? Because the KM window is the same number of pixels away from both the top and the bottom of the screen.
To me, it doesn't matter that you can't put anything in the menu bar area: The menu bar is still part of the screen, and I see it as pixels, just like anything else on the screen. A centered window—again, to me—is one that's the same distance from all the screen boundaries, regardless of what's being shown on the pixels.
The SCREENVISIBLE() function returns the dimensions of the screen excluding the menubar.
The MENUBARHEIGHT function returns the height of the menu bar in pixels.
The height position could also be expressed as (SCREEN(Main,Height) + MENUBARHEIGHT) / 2, but the use of SCREENVISIBLE makes it a little more intuitive
I've seen this solution in the linked thread, but I really don't want to be customizing a default action with extra calculations. Imagine I would have to be replicating this one in every Macro where I need to center a screen (vs. just using the default Center Action), or create a custom Subroutine (e.g. "My Center Window") and use that instead, but it all seems messy to me when there is a declarative built-in action that should be used.
Well, BTT's definition of "Screen" (and yours) appears to be the "work area" under the menu, not the "screen".
One possible solution (that won't break existing macros) is for KM to introduce a new action called "Work Area" instead of "Screen" and that would centre in the work area rather than the screen. In fact, I think KM allows users to create new actions (I haven't used that feature yet.) This would be a perfect situation to use that feature. I highly recommend looking into that.
Thanks Airy; you are totally right. Probably the proper "true" screen centering is the one in Keyboard Maestro; although if it aesthetically doesn't look right to me.
Ideally, would be great to have a checkbox, context menu setting, or something within the action to "Ignore Menu Bar" (better wording), which would be how it works right now. It one deselects that option, the Menu Bar should be taking into consideration and the window centered only within that "workspace".
Instead of a subroutine I'd propose setting the action up once, exactly how you want it, and then adding the action to your favourites with a recognisable name:
Once added as a favourite action you'll have immediate access to it both via the "New Action" menu, and the "Insert Action by Name" menu (the one opened with ⌃+⌘+A). Your favourite action will also be listed under Edit > Insert Action > Favourites, even making it possible inserting it with a hot key, for instance using a Select or Show a Menu Item action set up in a hot key triggered macro:
I'm never one to care much what other (non-Apple anyway) applications do.
If you want to center in a different way, there are many ways to do it, the most obvious being to use the Center At variant.
An argument could be made for any number of different definitions for what you want when centering a window on a screen. Personally, I use this one:
which actively biases it towards the top of the screen.
It is highly unlikely that I'd change the current behaviour intentionally, though it's definitely possible it might change in the future in any number of ways given centering is not a well specified concept.
@Alexander setting it as a Favourite wouldn't be duplicating the Action in every Macro where I pasted it, instead of reusing a Macro or Subroutine? If in the future I needed to make some adjustments, I'd have to modify it everywhere... is that correct?
Agree Peter; every user could define "centering" differently, so would be very difficult to cater to all
@Airy thanks for the Plug-In actions heads up. I've looked at them in the past but they were too convoluted and complex to create a mantain; specially for a simple action like this one
My final solution to have a normalized Centering Action between KM and BTT will probably be invocating one from the other. I still have to think which way of centering I prefer to have moving forward
For future adjustments creating a subroutine can definitely make sense. Another way to go about this is by having your center of choice defined in a global variable. This way you can adjust the one variable to adjust the center of all windows defined by the Manipulate a Window actions set up to read this variable for center position. By using variable .x and .yDot Notation you could for instance have it set up quite neatly as propose below:
