terminal.app window position
 

This might have been covered here before but I couldn't find it with a search.

Most of the time my terminal window comes up in the middle of my screen and I hate having to drag it out of my way and up to the upper left corner. Then I drag subsequent windows to the right of the first one and next to the lower of the first one...etc...etc...

Isn't there a way to edit the com.apple.terminal.plist file so that a terminal window position is in the upper left corner of your screen upon launch? I thought that changing some of the values around for WinLocULY, WinLocX and WinLocY would do the trick. But whatever I do to those doesn't seem to change anything.

My defult values are:

723, 31 and 0 respectively to those mentioned above.

:confused:

OK thatch, after all the flattery in the Davros thread, how could I resist!

One of the lesser known aspects of the terminal is that you can stash a whole heap of .plists in the directory

~/Library/Application Support/Terminal/

(which you might have to manufacture), and **after you relaunch the terminal.app** they'll be available for you from the terminal's menu:

File/Library/(....list of .plists available at above location)

So for example, if you have a need to ssh to a server quite often, just get a terminal window **in the preferred screen location**, with the opacity that you desire and so forth, and then save it using the terminal's save menu to the directory listed above. Now modify the file just created (using your favourite editor), in particular the "execution string".

Where you see:

<key>ExecutionString</key>
<string></string>

you should insert the command of your choice:

<key>ExecutionString</key>
<string>ssh myhost.com.au</string>

And the expected thing just happens when you invoke that window from the terminal's menu.

At this point you're probably saying: "yeah, this is all very nice, but what about my specific query". And the answer seems to be that the terminal ignores the location parameters in the com.apple.Terminal.plist at startup, and when opening new windows. That's to say that I couldn't do anything save muck up my existing preferences by changing the numbers in this file. (Ended up with a totally transparent terminal and all sorts of wackiness!)

So the way around this is as follows: open a window, set it up exactly as you like, in the place you want the thing to open when terminal.app is invoked. Save it as, say, start.term in ~/Library/Application Support/Terminal/ and then instruct terminal.app to open this .term file at startup. That is done via the preferences menu in terminal.app. (Terminal/Preferences... "Open a saved .term when terminal starts".) Doesn't help with new terminal windows, which still open in that purgatorial middle-left-of-screen. Maybe we could find a workaround for that as well, using the "Execute this command" terminal preference. But in the meantime this is at least a start.

In any case, I hope that the above is helpful for someone.

Paul

here, the default window size is a cascade factor of the original. and the position may be a factor of the size/dimensions with regards to the screen rez...

i want to see most apps display in near 8x11 proportion pages here. terminal being no exception, i set the shell window to 120x65 on my 1280x1024 rez display.

that takes up most of the vertical space. save that as default, then subsequent new windows cascade from that. like so...

http://home.mindspring.com/~bduart/cascade.jpg

Phat Cats
 

True indeed, and that works fine if the window that you want to see takes up almost the full height of your monitor. I think the problem that thatch is having is with (say) an 80x24 terminal window, the default version of which just perches in the middle-left of the monitor, regardless of the x,y locations set in the plist. New windows opened after this *do* cascade nicely, but always from that seemingly unalterable initial position. Quite a nice position for windows whose extent is akin to those in your lovely screenshot, but for us more petite/peasantly types it would nice to be able to juggle a little with the dictates of the starting window; hence my attempts above. Si?

Cheers,
Paul

si. unalterable initial position. i meant to say that.

i guess, in my years, i've given up fighting the merely pesky. condemn me :D

Thanks guys. I appreciate the response. I guess most people don't bother with this slight inconvenience kind of stuff. And I shoud probably heed mT's advice in this thread and not try to fight the merely pesky.

It never really bothered me before in 10.1.5. The window used to be reasonably near the upper left corner of my screen and subsequent windows cascaded appropriately. And if you dragged a subsequent window to another location, cascading from there worked fine. Terminal was smart enough to remember that.

But in Jag the cascade seems to have a different mind set of its own, always in the middle left of the screen regardless of where the previous window was positioned, which causes me to drag further and so it gets to be a litteral drag for me, out of sheer laziness of course.

I thought it should be easily remedied but found out that same thing Paul mentioned with the transparent windows and all. (About that, I use TinkerTool and thought that it may have been conflicting with the regular Terminal.app's window settings for transparency.) It was easy enough to change back from totally transparent to where I like it though. But the other 'wackiness' was also apparent in that window pane sizes had somehow increased beyond the default 80X24.

Another slightly off subject observation; when I tried using Property List Editor to change the .plist values, it would alter my values to different ones. And even after putting back the default values, it would change them to something else again. Weird. But straight editing without PLE worked just fine and the values would stick.

Anyway, someone on the hints site had responded to me about the .term file thing in the comments under 'Make option-click preferences stick in Terminal' and I had forgotten that one. So, I implemented that for the first window upon launch as was more elaborately put forth to here in Paul's posting. It's a good start for sure. But if I should close that window and open a new one, it doesn't remember that good position and opens back down in the middle hemisphere unless I choose from the File menu -> Library -> MyPreferredWindow.term.

Now I could go and make additional .term files for, say four windows worth, and then every time I want to have them I could pull them down from the file menu by their respective names, ie. MyPreferredWindow.term, MyPreferredWindow2.term, and 3 etc... and have their respective positions as well. But, geez, that's just about as much effort as dragging would have been.

I know I could have made a four window combination that launched with terminal.app from the same .term file but I won't necessarily need that many every time. So, next I began examining the differences between the OS versions of these .plist files and found some although I know next to nothing about what they might do based on their title alone. Since it was pointed out in the hint about the option-click being left out, I thought I might get lucky and discover another similarly left out string or value to return the smart cascade and/or window position.

One in particular interested me the most, <key>NSFontPanelLastUsedPane<key>, but I'm guessing that it probably is font related only. It's followed by: NSPreferencesContentSize and NSPreferencesSelectedIndex but I tried adding them and in various combinations with respect to their strings without any result what so ever.

And then there's the key 'NSWindow Frame NSColorPanel' which is common to both OS's but again doesn't sound related to what I am looking for exactly, although the string has some interesting number values which could be about window size and positioning. The string has eight numbers of which the last four are common to both OS's, 0 0 1280 1002, and has three of those in common with MyPreferredWindow.term file's WinLocULY, WinLocX and WinLocY, 0 0 1002. That's for the upper left corner of the screen, I think. Hmm.

I wish I had stumbled on a solution but I haven't and I know this has gotten terribly long winded. Maybe I'm close to finding one and then again, maybe not. Having spent an inordinate amount of time on this and coming up empty so far, I'm thinking of mT's favorite expression of late, 'Drive On'. Yes, it's true that I have missed some turn offs doing just that in life but it's my nature to be inquisitive and tinker under the hood.

I think you're right on the money, but I'd suggest you stop chasing for the hook that seems to have simply been left out of the build. That is, the terminal is just ignoring the relevant keys at startup. Bug, I'd say. (Time for the feedback page at apple. I'll do it if you do...)

In any case, I hope the earlier bit of my post above is useful for someone: having "preprepared" term windows available in the terminal's menu is pretty groovy. I wonder if there's a way to assign key equivalents to these...

On another (quick) tack, I was reading another forum in which someone asked how to make a command --top, say-- issued from the command line appear in a new terminal window, say in the top right hand corner. I guess everyone could answer that now: open a new terminal window, arrange as required, save the .term file as ~/terms/top.term for example. Edit the ExecutionString to read

<key>ExecutionString</key>
<string>top</string>

and then make a simple alias to it in your .cshrc file.

alias top 'open ~/terms/top.term'

If you don't want to open a new window all the time then \top is your friend.

Cheers,
Paul (permanently prodding the merely pesky, and incessantly inculcating the truly inconsequential. It's all two-tenths of three-tenths of damn-near nothing herein: this OS must be maturing!)

hmm, well, gentlemen, i never experienced any of this wonkiness with terminal window settings.

i suppose it might be because the first thing i did with first 80x24 window was groan, and make it 120x65 and put it in position and save as default and close/quit/start terminal and it's opened in the relatively decent position (cascade.jpg, above) every time.

satisifed with that, as that is how i want it (large shell window) i dint need to tinker.

thatch, if you're still game to experiment, quit terminal and

delete ~/Library/Preferences/com.apple.Terminal.plist

launch terminal

get that first window positioned and using a suitably large vertical portion of the screen.

you can open the Show Info window, scroll to ( Window ), and directly enter numbers in x and y to tune this. save as defaults. close. quit. launch terminal. hit command-N and see what happens.

anyhow, that's how i did it first time, and then i "drove on"

http://home.mindspring.com/~bduart/shelly.jpg

paul, isn't it rather bad form to name an alias the same as a real command? i know this has bit others since the dawn of time.

Paul, thanks. You are probably right in encouraging the bug report and so I will.

And your post is very useful. A quick search here and I didn't find anything on term or .term files directly other than your posts on this thread. So, it should be of benefit to all who may be interested. I remember an O'Reilly tutorial on term files that I did with streamripper a while back but I had forgotten how useful term files are until all this recently came up again.

The example of top is well taken even if there is a conflict with the command top as mT pointed out. But that is easy to fix by just making the alias a bit different, like 'mytop'. I noticed I already have an alias, 'topcpu', which relates to:

top -u -s 10

mT, I can see why you might like the larger termial window. It makes sense to have more room. But to try your experiment, I used the lower right corner of the freshly opened window to drag it down to full screen vertically, (80X69), then adjusted the info window setting back to the default 80X24, clicked use as default, closed, quit and relaunced. But the result was the large window, 80X69, on my 17" flat panel display. Did I miss something or are we looking at another potential bug?

Well, yeah, maybe: depends on what the real command is, and whether the alias is likely to cause any grief if inadvertantly called. (So, unless you know your way around the system, probably "yes", but in this case "no". That'd be a general "yes" then?). Of course if any script is going to be invoking one of my aliases (or, indeed, is going to be invoking "top") then it's a script that needs some pretty serious reconsideration.

In general I think I'm simply getting slacker; all these stories about old war wounds just don't cut to the quick like they used to. Maybe I'm just laying down some land mines in my machine's unconscious in order to generate some problems down the track? What's a day at the machine without the odd noggin-scratch? (Productive?)

In any case, I won't put up any phoney defence. This is the newcomers section, and newcomers shouldn't follow my slovenly habits. Develop your own!

As penance I can but offer a nice little script from a companion thread to this one, hosted far, far away. Here goes:

---------------------------------------------
osascript<<END
set init to {40, 40} --top left corner of window relative to top left of screen
set dx to 20 --amount to shift each new window right
set dy to 30 --amount to shift each new window down
tell application "Terminal"
set thewindows to (every window)
set num to the length of thewindows
do script "$1"
set tl to {(item 1 of init)+dx*num,(item 2 of init)+dy*num}
set position of window 1 to tl
activate
end tell
END
---------------------------------------------

If you save the stuff between the dotted lines as, say, "nt" in your ~/bin directory, make it executable (chmod u+x ~/bin/nt) and then type "rehash" you'll be able to enter, for example, "nt emacs" to open a new window cascading from wherever initial position you'd like (by whatever delta you'd like) and running emacs, for example. Try it a few times with different commands to get the idea. Probably not all that useful, but that seems to be the nature of this particular thread, just like its companion!! More fun than functional.

You might object that you already need a terminal window open to invoke "nt", and that this window will be at the ugly default location, but we've already seem that there are ways around that! For example, use terminal.app's ability to execute one of your .term files on startup, and make that .term file sit at the init location you specify in the script above. As above, this ability is invoked via Terminal/Preferences...

Once again, handy/fun/interesting if not exactly earth-shattering.

Don't worry, I have several more variants along these lines in reserve! More threat than promise, I know...

Cheers,
Paul

Hi Paul,

I tried the script you've included and it works but gives this:

## Component Manager: attempting to find symbols in a component alias of type (regR/carP/x!bt)
execution error: Can't get end. (-1728)


I tested it as you directed with 'nt emacs'. The window was in a reasonably nice enough position though. I also tested it with a few aliases and it worked fine but still gave the same error for each although the cascade was good.

No biggy. Hope you're having a great night, mate.

I think "heredocs" are destined to be the bane of my online life. Such lovely constructs (osascript commands are incredibly ugly otherwise), but so finicky about the delimiter. I'm guessing that you've inadvertantly added an extra space after the final "END" line. It has to be the three letters END and then nothing else. As you noted, things probably still work OK, but getting an error message every time is not much chop.

So just chop out that space (he says, hoping that's the root of the particular evil) and all should be well. The reason I'm a bit wary is that I definitely haven't seen the "Component Manager" bit before. Very scary looking. Is anyone else prepared to twitch their whiskers and squeal like a guinea pig? [[Or even just try the script?]]

Cheers,
Paul

getting a lot of those component manager errors. they seem innocuous...

$ grep -ic "## component" /var/tmp/console.log
105
i think that was what i should have said above. 'tis easier for neophytes to get tripped up by this and without the chops to grok.

choppin' broccoli...

Hi mT,

thanks for allowing me to shirk responsibility for that particular error. (Assuming that you haven't run my script 100+ times to generate those lines in your log!) Oh yeah: for what it's worth, my grep on the logfile revealed zero such beasties.

Oh yeah, further thanks for dragging me out of the eighties and into the LAND OF THE GIANTS. Don't know why I've been propping up the 80x24 standard for so long, but it must have had something to do with some dirty old full-screen curses based applications at work, which would rapidly become somewhat "abstract" in non-standard windows. No such nonsense required at home (or for most work screens), so I'll be upping the ante herein. What cheer, eh?

Paul

i have run your script exactly zero times, since i have no issues with my shell windows. that in no way reflects what i think about your efforts :D

i have these component mgr messages since 10.2.1, and i can't seem to identify what generates them, but since you no got them, i am pressed to assume they are the result of some 3rd party install.

babbling as usual
 

'tis cool, 'tis cool...

Maybe I should just add another "eff it" and be done with this line of thinking? Of course all the above is naught but a proof of concept. The only real value in my bits and pieces above will come from inserting these hooks into your scripting arsenal. (I feel your pun.)

Content? What's that? Here's a small attempt: fun time for anyone looking to automate processes: the free "Youpi Key", which is rather nifty. versiontracker as usual.

Finally, in a weird case of synchronicity, the new "Mac OS X for Unix Geeks" from O'Reilly has a section giving the "osascript via heredocs" that I mentioned above. Bloody plagiarists! I only worked that out last night!! Ironical smirk when I noted that they still haven't grokked the "open -a" cuteness in OS X. As per the man page, they insist on using absolute paths to applications, when in fact... (STFU about open -a already Paul...)

Ramble, ram bull,
Paul

Hey guys, I took a look for spaces at the ends of all lines since I hadn't done that before you mentioned it. I don't usually do that but for this one I was in a hurry and just used BBEdit Lite with the save unix line breaks preference and a copy and paste to create it. Anyway, each line had an extra space at the end so I removed them via a command line text editor. Now the script gives a little less of an error, perhaps what you might have expected.

## Component Manager: attempting to find symbols in a component alias of type (regR/carP/x!bt)

Well, it's a little shorter anyway. And I grep'd to find I only show 12 of those errors on my rig and I figure they have all come from this test earlier today. So, I don't imagine a third party app causing it.

I do appreciate your bantering back and forth with me a while on all this. It started out as what I thought was possibly an oversight I was making when editing the .plist files for Terminal's window position and turned into... yikes!... all this.

You don't neccessarily have to be chopped broccoli to post in this forum, just have something you think might be an easy or maybe even dumb question, or was it? Having the chops to grok is the ultimate goal and I guess there's glory in that somehow, someday. I wish I had more time for learning. I am enjoying the ride though.

:cool:

Error messages
 

Hi again,

there are a few references to that error message floating around the web: someone suggested that it might be related to Toast Titanium. Either of you have that thing? Here's the message of possible interest:

-----------
Let's guess: you have updated your Toast Titanium to 5.2?

Go into /Library/QuickTime and move 'Toast Video CD Support.qtx' aside (into /Library/Quicktime.disabled e.g.?).

You may not be able to look Video CDs then, of course.
------------

Cheers,
Paul (more in hope than expectation)

that dood it...
thanks, paul.

anyone who still thinks there is no "extension management" in OSX, or any OS for that matter, philosophically needs a depantsing.

Paul,

You nailed it all right. I do have Toast Ti 5.2. I moved that file out of /Library/QuickTime and all was well with the script, no more errors. I suppose I ought to submit a bug report to Roxio for that one, eh?

Thanks again!

;)

Yowser! Two from two.

What cheer, eh?

Cee veb ees un amaising plaice. (Swimming on the back of a giant turtle?)

Best wishes,
Paul