Moving Windows

Is there a general way to move a window of an application process via an AppleScript or is it always necessary to do so through the application process?

Hello Adam!

I don’t know what you mean by move, so I assume it is moving within a screen in general, and between spaces.

As you know; even System Events addresses the application process when you perform GUI Scripting.

And the SystemUIServer or any other windows server, aren’t available from AppleScript.

When you have stuff to move, this is doen by the window ID, which I think should reside in a list somewhere on the system, but then there is that, about identifying “your” window.

Maybe there is a solution in AsObjC, because there are at least undocumented cocoa calls you can use to at least move windows between spaces, but then, you will have to have the ID of the window in the first place.

I don’t know if this helps you or not.

It confirms what I thought.

Thanks

Hello! :slight_smile:

I have second thoughts as well.

The Mac OsX, has GuiScripting, and when you use UIElement Inspector, then I think you are going from the outside, that is from the Operating System and inwards, starting at some point with the Window Servers window that is in foreground. At least I guess you do, but I am not sure.

It is interesting to know.

I also wonder how VNC and stuff works, and Ard, I think that on the X11 platform, there is a co-ownership of the windows, between the applicatons and X11, giving you an easier access. To do pranks too. :smiley:

So maybe our windows model is more enclosed, but it is also safer!

By the way, here is a little nice bash function I have snagged an put in my profile, so now I can start up gimp from my regular terminal when I have X11 running.

[code]function get_xserver ()
{
case $TERM in
xterm )
XSERVER=$(who am i | awk ‘{print $NF}’ | tr -d ‘)’‘(’ )
# Ane-Pieter Wieringa suggests the following alternative:
# I_AM=$(who am i)
# SERVER=${I_AM#(}
# SERVER=${SERVER%
)}

		XSERVER=${XSERVER%%:*}
   ;;

aterm | rxvt)

find some code that works here…

   ;;
esac  

}

if [ -z ${DISPLAY:=“”} ]; then
get_xserver
if [[ -z ${XSERVER} || ${XSERVER} == $(hostname) || ${XSERVER} == “unix” ]]; then
DISPLAY=“:0.0” # Display on local host
else
DISPLAY=${XSERVER}:0.0 # Display on remote host
fi
fi[/code]

Hi MacUsr,

what does your bash script exacly ? launching Gimp, when X11 is already running ?
Is there a way to implement a continuous save-function for Gimp and X11 ? (i’m on Snow Leopard)
x11/Xquartz isn’t always so robust as it should be.

Hello!

It establishses contact between your regular terminal application, or shell within a terminal window to the XServer, so you can launch X11 applications from within Terminal.app, provided you have the rest of the setup right

It is quite stable, once you have gotten it configured right, but I think I worked too much to setup and configure X11 right. :frowning:

I don’t think there is possible to implement a continuous save function in Gimp, if it isn’t already there.

I don’t use Gimp really

No, you don’t have to go through the application process. System events can handle it. For example this will move the front Safari window to the left by 10 pixels.

tell application "System Events"
	tell process "Safari"
		set currentPosition to position of window 1
		set position of window 1 to {((item 1 of currentPosition) - 10), item 2 of currentPosition}
	end tell
end tell

Note: you will want to look at the System Events dictionary for the Window class to see everything you can do with a window. For example a window has a bounds property so you can change the size and reposition a window.

Hello!

I see using SystemEvents to tell the application something, to do it within the application.

Now, if you had gone to the window server and said: “Give me the coordinates for the window who has the z-index of 2” (behind the frontmost), then that is what I would have perceived as getting the window from “the outside”.

System Events are great to have though :slight_smile:

I can see your point because my script is telling the application process to do something, however “using the application process” to me would be using the application’s specific applescript commands… which this doesn’t do. This is one uniform way to work with the windows of any application, rather than having to issue application-specific commands. In the end I guess it’s up to the user’s interpretation.

You’re right. When using System Events you’re able to get the windows for processes that are connected to WindowServer and are drawn by it. Getting information drawn by other window servers isn’t possible with System Events. Applications that doesn’t respond to events will not give you the ability to manage windows as well, like preview, with System Events you can.

Hello! :slight_smile:

I see no problmes in different perceptions as to what is happning inside or outside and app.

But. There isn’t much uniformity left in reality is there, when you have to take Finders, extra 22 pixels, into account, and give Excel 33? … and so on. :slight_smile:

[quote= DJ Bazzie Wazzie
]You’re right. When using System Events you’re able to get the windows for processes that are connected to WindowServer and are drawn by it. Getting information drawn by other window servers isn’t possible with System Events. Applications that doesn’t respond to events will not give you the ability to manage windows as well, like preview, with System Events you can.
[/quote]

System Events is a rather dedicated app! The other point here, is that there is possible to evade System Events, but then you need the Id of the window, which I think to be hard to find, without addressing the application first.
So you are in reality coerced to address the application in the first place!

:D… I think the whole point is that what you want can’t be done. The desktop you’re looking at can be drawn by multiple processes. So getting top level from WindowServer doesn’t mean it is the window on top you actually see. That’s why I mentioned system events is only connected to the WindowServer. The pro is that it can get properties of all windows in the WindowServer (even from non-scriptable applications) the drawback is that Mac OS X still allows to have multiple window servers up that draws windows on your screen and they are out of reach from system events.

As far for addressing: It is pointless to get the highest level window from WindowServer because it doesn’t need to be top level of all windows on your screen. So requiring a process’s name as an identifier is rather better than worse because now you know the returned data is always correct.

Hello!

I think you can get the frontmost window, if you go down to QuartzWM, and knows how to either look, or builds your own, if that is possible. But the practicality in this, now that is a whole other story.

We were discussing what was possible or not, not necessessarily through System Events, as I think it started out, but System Events, is of course the way to go from an AppleScripter’s perspective!

This was interesting! :slight_smile:

QuartzWM is only for X11 which means that you will only get window information for X11 windows, not for windows managed by WindowServer.

Hello!

I was actually totally sure of that QuartzWM was the “Core Graphichs Server” on Mac OsX

But if that isn’t so, then there has to be something common under there, in order for several window servers to cooperate?

They have to know what the others are doing, in order to know what to redraw, and what not.
I run X11 seamlessly with MacOsx, that is I use the Mac Osx Desktop, and has X11 windows and Mac OsX windows intermingled, and it works perfect…

I’ll certainly read up on the architecture! Is there any AppleDoc’s you recommend?

Edit

Never mind! :slight_smile: I’ll read the Architecture Overview.

I think you’re talking about Quartz 2D. Windows and rendered objects on your screen are two different things. If we’re talking about rendered objects there is of course one central point as you mentioned. Eventually everything goes through WindowServer, but a window from another window manager (QuartzWM for example) is rendered before send to the WindowServer. At this stage the object is nothing more than an graphical object that will be passed to Quartz 2D and has lost it’s role as a window completely. The leveling is done at this stage as well for masking (to only render what you see).

Hello!

I thought it just worth mentioning, before I read the Architecture Overview, that the x-windows I get by firing up XQuartz are having the usual Mac-style windows controls, But thinking a l ittle, and playing with the Regular Expression Editor, I realize that it is the XQuartz that wraps the windows from X11into the Mac style window, and passes the window information over to the OsX WindowServer

I think you are absolutely right! :slight_smile:

Hello!

I quote page 41 from OSX Technology Overview:

This quote, is not adding anything to the subject, but giving factual information! :slight_smile:

This is where Quartz are coming from after all! The X11 windows, that you can do all kinds of fun stuff with, from the X11 side, are indeed rendered as OSX windows after all, using the same window server for the rendering, but managing window information and giving the X11 perception of things through X11, but the windows, that Quartz Compositor do deal with, is real windows, not just rendered graphichs!

So, to my understanding, we are dealing with just one real window server here. Real, in the sense, that it is responisble to for the rendering and identification of windows. Not that this matter much, but for me, it is interesting to know! :slight_smile:

Exactly! That was what I was trying to say. Window rendering and window management are two different things, Quartz 2D renders windows (but also objects, images, postscript/pdf, text, etc) and WindowServer (Quartz Compositor) manages the windows. In your quote the WindowServer and Quartz should be considered as the same but in most of Apple’s documentation it isn’t so I prefer to see Quartz and WindowServer still as two different things. Also because WindowServer is responsible for more than window management alone.

Yes!

I did not say that you were wrong, and just for the record, it it is nothing wrong in being wrong, as long as it leads to clarity. The important thing to me, is to be able to discuss things, be humble and open, and reach some kind of conclusion in the other end.

We kind of talked passed each other. I actually guessed how it was with you and the window server, after reading up in the Mac OsX Technology Overview Which is a good read!

What stumbles me in this, is actually how much extra services you get in X11 windows, than in OsX, that in X11 you can actually move a process from a window on one computer to a window on another computer. But there are ways in pure OsX as well with remote procedure calls.