When I call this script on a Linux OS Term::Size::Any (chars) and Term::ReadKey (GetTerminalSize) return always the same number of columns.
When I call the script on a Windows machine the returned number of columns differ as soon as I resize the terminal with the mouse to a smaller size. chars returns the new width while GetTerminalSize returns the initial terminal width.
Is there a trick to get from GetTerminalSize the new resized terminal width?
use strict;
use warnings;
use 5.10.0;
use Term::Size::Any qw(chars);
use Term::ReadKey qw(GetTerminalSize);
say( ( chars( \*STDOUT ) )[0] );
say( ( GetTerminalSize( \*STDOUT ) )[0] );
What you are currently doing is not called "resizing", the terminal screen size is still the same, you are just diminishing the terminal visible size.
To change the Window Terminal "size", click on the top left corner, go to Properties change the "Screen Buffer Size", at the moment you are just changing the "Window Size"
Related
I have an extended display set up like this:
In the extended display, I have a Finder window positioned on the left half of the extended screen:
When I call this AppleScript:
tell application "System Events"
tell process "Finder"
{position of window 1, size of window 1}
end tell
end tell
I can get the position of the Finder window:
224, 1331, 881, 1075
However, if I move the bottom screen to the left:
The same AppleScript call now provides a different window position:
10, 1331, 881, 1075
How can I get the "position" of the extended screen?
I know I can get the bounds of the desktop using:
tell application "Finder" to get bounds of window of desktop
But that returns the exact same result for both extended display positions:
0, 0, 2304, 2416
I also know I can get the display resolution using
system_profiler SPDisplaysDataType
But that doesn't seem to tell me anything about the extended display's "position", just its resolution.
That same link suggests the command
defaults read /Library/Preferences/com.apple.windowserver.plist
Which looks promising because it has UnmirroredOriginX and UnmirroredOriginY listed for displays. The problem with that file is that I don't see a way to figure out which one of the 17 (in my case) settings is currently active.
For background, my motivation for this question is to derive window positions like left, right, and center 1/3rds and comparable 1/4ths and half positions for windows in an extended display no matter where the extended display is "positioned" relative to the main display. I am trying to replicate the behavior of a program like Rectangle except programmatically. That way windows can automatically be opened and sent to certain positions when certain scripts are run.
I would just send keystrokes to Rectangle itself but it has no way of specifying main or extended display (only "Next" and "Previous" display), so there is no deterministic way to guarantee which display the window will go to as far as I know.
I would also be happy to hear about any other CLI accessible program that can position any window to any 1/2, 1/3, or 1/4 positions in a specific (main or extended) display.
The solution I came up with was to get the resolution using a regex on the output of
system_profiler SPDisplaysDataType
for lines matching
Resolution: (\d+) x (\d+)
I divide both of those numbers by 2 because I always use retina / 4K monitors. This calculation seems to exactly match the AppleScript position values for the 4K displays but not retina. Luckily for me, the 4K display is the only one I need to be completely accurate.
Because I always scale my main monitor to higher resolution than my laptop screen, I can infer that the larger number is the monitor and thus the main display and the smaller is the extended display.
I then call
tell application "System Events"
tell process "%s"
{position of window 1, size of window 1}
end tell
end tell
On whatever target application's window needs to be positioned, which for me is always the frontmost (usually newly opened) window.
Because I always have the main monitor positioned on top of the extended display (laptop), if the returned Y position for the window is higher than the resolution height (divided by 2) of the main monitor, I assume it is in the extended display.
From there, I can keystroke the "Next Display" hotkey in Rectangle if it is in the wrong display. Then I can keystroke the appropriate 1/2, 1/3, 1/4 hotkey in Rectangle.
I have a multi-monitor Mac desktop (4 displays each of 1920x1080 arranged in a 4x4 rectangle) and can use a mouse to open a window across all monitors, filling the whole four screen desktop.
(am running Mavericks and have disabled the "Displays have separate Spaces" checkbox)
I want to be able to so this automatically, so used AppleScript. However, the window will not open to a height greater than one of the displays (1080 pixels), even though the displays are arranged in a 4x4 matrix so that the total height of the desktop is reported as 2160 pixels. Window width is no problem and the script opens nicely across displays horizontally.
Here is the key part of the AppleScript:
tell application "Finder"
set bounds of first window to {0, 0, 3840, 1800}
end tell
There seems to be some kind of limit on the vertical size of the window. Any ideas how I can achieve automation?
Googling has pulled endless gripes about multi-monitor support on Mavericks but I can't find anything related to this particular issue.
Thanks in advance
BACKGROUND
I've tried this on two multi-monitor display configurations:
Early 2014 Mac Pro.
Four external 1920x1080 monitors arranged landscape in a 2x2 rectangle.
Reported desktop size is {0, 0, 3840, 2160}
MacBook Pro Retina Late 2013:
Two external 1920x1200 monitors arranged one above the other
(and the laptop's own 2880x1800 internal display of course)
Reported desktop size is {0, 0, 3360, 2400}
I don't have multiple monitors to test this, but on my one monitor the (0, 0) point is the upper left corner of my screen. Maybe you need to adjust the second number of your bounds. My suggestion would be to open a window manually by hand. Then run this code to get the bounds. Then try to set the bounds with the returned values. Of course I still don't know if this will work but at least you'll know you're working with the proper bounds. Good luck.
tell application "Finder"
return bounds of window 1
end tell
EDIT: once you know the proper bounds, you might try using System Events to resize the window. System Events doesn't know "bounds", but it does know "position" (the first 2 numbers in your bounds) and "size" (the second 2 numbers in your bounds). Try this with your numbers.
tell application "System Events"
tell process "Finder"
set position of window 1 to {0, 400}
set size of window 1 to {800, 500}
end tell
end tell
Not to revive a dead subject, but with some external dependencies it is possible to resize larger than the monitor resolution. You need a program called MegaZoomer [https://github.com/ianh/megazoomer] ... and you need EasySIMBL [https://github.com/norio-nomura/EasySIMBL].
Install EasySIMBL first, (can be downloaded from http://www.macupdate.com/app/mac/44354/easysimbl ). Then pull down MegaZoomer from (http://www.macupdate.com/app/mac/21275/megazoomer) ... copy the megazoomer package into the EasySIMBL packages dir. You will need to enable the package in SIMBL. You may have to reboot. Then run your applescript and it should work.
How can TinyTERM's MainWindow be programmically moved using TinyTERM's CScript and/or TinyTERM's TE Object?
I see the CScript language has a MoveWindow function
Void MoveWindow( hWnd, iX, iY, iW, iH bRepaint )
Calls Win32 MoveWindow function.
MoveWindow( hFrame, x, y, w, h, 1 );
Does anyone know how to get the MainWindow's hWnd?
I am using Version 4.42.
TinyTERM Plus Programmers Reference Manual
http://www.centurysoftware.com/docs/TinyTERM_Plus_PRM.pdf
Support Page
http://www.centurysoftware.com/support/index.php
I want to Move the MainWindow because I using another program to launch TinyTERM Plus. Currently TinyTERM starts up in the middle of the screen. I would like to move it on top of the application that launched it. Since I am going to have 4 (or more) applications launching a session of TinyTERM it is going to be confusing to have all the TinyTERM session on top of each other. The user will have to manually move them around.
In TinyTerm .TPX file the following two settings can be used:
xwindow= (Sets the LEFT position of the window)
ywindow= (Sets the TOP position of the window)
This .TPX file is set up in the same format as a .INI file.
This needs to be changed before starting up TinyTerm.
Another setting I used was to change the Window Size:
wwindows= (Change the WIDTH of the window)
hwindows= (Change the HEIGTH of the window)
When this was resized the font also got resized.
This came in handy because the User could define the sized of
the window that started up TinyTerm. Knowing that size allowed
me to set TinyTerm window to the same size.
I have creating one window using CreateWindow. But is there any api which can give system screen height and width of the system. So that it will very helpful to locate windows according to the system screen.
The GetDesktopWindow() function will give you a handle to the desktop window.
You can then query this for it's size using GetWindowRect()
Edit: Note that this will give you the size of the primary display. To handle multiple monitors you will need to use GetMonitorInfo()
To get the size of the workarea on the primary monitor, the call to make is SystemParametersInfo with SPI_GETWORKAREA.
Alternativly you can pass CW_USEDEFAULT (-1) as the x-co-ordinate and windows will pick a position for the window for you.
I've determined that I can use GetSystemMetrics(SM_CMONITORS) to query the number of attached monitors, but is there any way to control what monitor CreateWindowEx() uses for the window?
Yes, by the "x" and "y" arguments. Use EnumDisplayMonitors (pass two nulls) to enumerate the monitors. Your MonitorEnumProc callback gets a RECT* to the monitor's display rectangle. You'd get a negative RECT.right if a monitor is located at the left of your main one.
Each monitor simply displays some part of the desktop, so showing the window on a particular monitor is a matter of moving the window to the part of the desktop displayed by that monitor. When you call CreateWindowEx (or CreateWindow) you can specify x and y coordinates for the window, so displaying it on a particular monitor simply means specifying coordinates that fall within the area displayed by that monitor.
You can find the work areas for the monitors on a system with GetMonitorInfo.
The x and y parameters specify the location of the new window. This point can be anywhere on the virtual screen (all the monitor rectangles combined).
If you want to create the window on the same monitor as another window you can call MonitorFromWindow. Otherwise can enumerate all the monitors with EnumDisplayMonitors.
Either way, once you have a HMONITOR handle you must then call GetMonitorInfo. Your x and y parameters should be a value inside the bounds of the rcWork member in the monitor info struct. You would normally choose values that puts your window in the center of this rectangle.
It is important to use the workarea rectangle and not the full monitor rectangle because you don't want your window to appear underneath the Taskbar and other always-on-top appbars.