I'm playing about with the most recent NSDocument in a Swift document-based-app. One thing that's a bit odd is that the starting location for a new window is near the bottom of the screen.
Playing with the Storyboard a bit, its not clear how to use the built-in settings to come up with a reasonable "near the top" selection - the setting moves up from the bottom, not down from the top, so the position would change depending on the screen size?
I assume there's a position mechanism I can hook, but it's not obvious in the shell code that's supplied. Any hints?
OS X coordinate system is flipped in contrast to iOS. So the 0,0 is the bottom left corner.
You can calculate the position of your window in similar manner (any screen size)
CGFloat width = NSWidth([self.window screen].frame);
CGFloat height = NSHeight([self.window screen].frame);
[self.window setFrame:NSMakeRect(100, height - 100, width, height) display:YES];
Most easiest is to set initial height to 900 and forget about it and enable window restoration -> this will cause to open the window where it previously was and this is where it user wants.
Select your window in Storyboard. And fill initial position coordinates
Related
There is a CTreeCtrl in an arbitrary position on a fixed size CDialog.
Could you please advice how to position this CTreeCtrl in OnInitDialog so that its left, right and bottom sides were touched to the dialog sides, and there was an indent N on top?
I've been experimenting for several hours now, but it doesn't stick correctly to right and bottom:
CRect rect;
GetWindowRect(&rect);
rect.top = N;
m_Tree.MoveWindow(&rect);
I also tried GetClientRect.
I need to get the following:
By far the easiest solution in this case it to just use the inbuilt Dynamic Layout functionality:
Select the control in the IDE.
Set the Sizing Type property to Both.
Set Sizing X and Sizing Y to 100.
Then, as long as your dialog Border property is set to Resizing the tree control will stretch as you wanted:
No coding required as you can see:
Much easier!
Manual Method
But, if you do things manually you need to be sure that you understand what type of coordinates the API calls provide you. Coordinates can be relative:
Screen Coordinates
Client Coordinates
For example:
CWnd::GetWindowRect:
The dimensions are given in screen coordinates relative to the upper-left corner of the display screen. The dimensions of the caption, border, and scroll bars, if present, are included.
CWnd::GetClientRect:
The client coordinates specify the upper-left and lower-right corners of the client area. Since client coordinates are relative to the upper-left corners of the CWnd client area, the coordinates of the upper-left corner are (0,0).
CWnd::MoveWindow:
For a top-level CWnd object, the x and y parameters are relative to the upper-left corner of the screen. For a child CWnd object, they are relative to the upper-left corner of the parent window's client area.
Your tree control is a child so when you move it, the coordinates need to be relative to the upper-left corner of the parent window's client area.
Note, there is a handy CWnd::ScreenToClient API to translate from one system to the other. But this is not required in this instance.
Manual Method — Example
Putting it all together:
CRect rct;
GetClientRect(&rct); // The client area of your window (in client coordinates)
rct.top += N; // Adjust the top margin as required
myTree.MoveWindow(&rct); // Now move the child control
Please note that I have not debugged this to verify the code but it conveys the ideas.
Where possible I use the built in dynamic resizing, althought it can be very tricky to work out the sizing values. But in your case it is simple - 100.
I should point out that the above code will manually get it to the right place. But then you have to resize it as the window resizes. Try the Dynamic Layout approach instead.
I'm making an emacs-esque toy text editor. At startup, there's one large window (a QTextEdit derivative) in the top center of the screen, with a minibuffer (QLineEdit derivative) underneath. Both of the actual editing widgets are contained in the grids of parent classes called Window and MiniWindow (Window also keeps track of a QLabel that appears directly beneath the QTextEdit).
My Window object is at location 1, 1 in the grid, and my MiniWindow object is at 2, 1. I've set content margins to 0 and spacing to 0, which looks great at first, but when I try to grow the window by dragging on the corner, this starts to happen:
As you can see, the screen is divided into two rows (as it should be), but half of the vertical length of the screen is dedicated to each row. What I need is for the top Window to stretch its length during resizing so that it is always adjacent to the MiniWindow underneath. Is there some other option I need to be setting?
Nevermind, got it.
I was having this problem because the QLineEdit object was in the grid of my container class, MiniWindow. The height of a MiniWindow object is free to vary with the window resizing in a way that a QLineEdit alone would not be. The fix was set to the maximumHeight of MiniWindow to approximately the height of a QLineEdit, which is around 16.
Works great now.
I am trying to display mouse position on timer. I use winfo_pointerxy(), here is part of the code from my_func():
curr_x, curr_y = mouseFrame.winfo_pointerxy()
curr_x = mouseFrame.canvasx(curr_x)
curr_y = mouseFrame.canvasy(curr_y)
mouseFrame.create_oval(curr_x, curr_y, curr_x + 5, curr_y + 5, fill='green')
start_btn.after(time_interval, my_func)
It seems like I use canvasx() wrong cause it still returns position counted from the left-up corner of the screen.
According to this tkinter reference (which I use constantly)
Because the canvas may be larger than the window, and equipped with
scrollbars to move the overall canvas around in the window, there are
two coordinate systems for each canvas:
The window coordinates of a point are relative to the top left
corner of the area on the display where the canvas appears.
The canvas coordinates of a point are relative to the top left
corner of the total canvas.
If your canvas is against the upper left corner of the window (display) and you have not scrolled the canvas, the two sets of coordinates should be the same.
I'm actually developing a game in Swift SpriteKit.
I set the position of a SKSpriteNode:
skPart1.position = CGPointMake(0, 100)
So the node should start at the very left window-edge.
|-------------------------|
|-------------------------|
|-------------------------|
|-------------------------|
|==========|--------------|
|==========|--------------|
|==========|--------------|
But in reality half of my SKSpriteNode is outside of the screen:
|-------------------------|
|-------------------------|
|-------------------------|
|-------------------------|
==========|--------------------|
==========|--------------------|
==========|--------------------|
I've read the same problem on stackoverflow, but the only solution provided there was, to set the scaleMode to AspectFit.
I've figured out, that it works with SKShapeNode. But why not in SKSpriteNode?
And I've alreay tried that.
How can I fix that?
SKSpriteNode has an anchorPoint property that defaults to the center of the image, which is why half of the sprite is off the left side of the screen.
You can adjust the anchorPoint so that it behaves like your SKShapeNode with the anchor in the bottom left. Try this :
skPart1.anchorPoint = CGPointMake(0,0);
I know you have accepted an answer, however this is the ideal way to handle the situation and it's why the property exists.
I think this actually depends on what you're using as your SKShapeNode. If you're using a rectangle, then the point you give it will be the lower left corner of the rectangle. But if you use a SKShapeNode circle, it'll drop the circle centered on that point you give it, and you'll see very similar behavior to the SKSpriteNode.
The SKSpriteNode is using the center of the image as the point it places your sprite at, and so when you're placing your node at (0, 100), exactly half of it is being draw to the left of the screen.
If you want your sprite to be drawn as far left as possible, but completely on the screen, you should be able to accomplish this by offsetting for one half of the sprite's width.
skPart1.position = CGPoint(x: skPart1.size.width / 2, y: 100)
I am trying to write a script to let me start a set of terminals of specific size at a specific position on screen (for instance, four terminals spread across my screen in a grid model each active). If there is already a tool that can do this, that would be great too... Any suggestions?
I'm sure there will be better answers but one thing I did find useful was this:
gnome-terminal --geometry=130x25+20+525
So on my large monitor, the following is giving me two nice terminals:
#!/bin/sh
gnome-terminal --geometry=150x125+20+25
gnome-terminal --geometry=150x125+1020+25
And the following is the explanation from the man page for quick reference:
-geometry WIDTHxHEIGHT+XOFF+YOFF
(where WIDTH, HEIGHT, XOFF,
and YOFF are numbers) for specifying a preferred size and location for
this application's main window.
The WIDTH and HEIGHT parts of the geometry specification are usually
measured in either pixels or characters, depending on the application.
The XOFF and YOFF parts are measured in pixels and are used to specify
the distance of the window from the left or right and top and bottom
edges of the screen, respectively. Both types of offsets are measured
from the indicated edge of the screen to the corresponding edge of the
window. The X offset may be specified in the following ways:
+XOFF The left edge of the window is to be placed XOFF pixels in from
the left edge of the screen (i.e., the X coordinate of the win-
dow's origin will be XOFF). XOFF may be negative, in which
case the window's left edge will be off the screen.
-XOFF The right edge of the window is to be placed XOFF pixels in
from the right edge of the screen. XOFF may be negative, in
which case the window's right edge will be off the screen.
The Y offset has similar meanings:
+YOFF The top edge of the window is to be YOFF pixels below the top
edge of the screen (i.e., the Y coordinate of the window's ori-
gin will be YOFF). YOFF may be negative, in which case the
window's top edge will be off the screen.
-YOFF The bottom edge of the window is to be YOFF pixels above the
bottom edge of the screen. YOFF may be negative, in which case
the window's bottom edge will be off the screen.
This approach is very simple and using a command like this:
gnome-terminal -x sh -c "ls|less"
In addition to the above commands, one can do even more fancy things :) For instance, you can make it launch itself into a specific directory (very useful if you're editing source code in one window and debugging using the other like I am).
Terminitor is a project that addresses this: https://github.com/achiu/terminitor
Unfortunately, it doesn't have gnome-terminal support yet (just OS X and Konsole).
Terminator has such a feature.