How does one use xmonad with the physical screens in portrait orientation?
I have two physical displays and they are both rotated 90 degrees to the right (clockwise with original bottom edges on the left)
I'm on Fedora 21 (3.19.3-200.fc21.x86_64)
I don't know how to tell what window manager is running, but there's a gnome-shell process running...
When I sudo telinit 3 and then startx, xmonad comes up with everything in landscape orientation. I don't know how to change it at that point and I don't know how to make it start in portrait mode.
My .xinitrc file says this
#!/usr/bin/env bash
emacs &
gnome-terminal &
exec xmonad
Thanks in advance for any help!
Well, first of all, your window manager seems to be xmonad ;-).
Independent of that, xrandr does what you need.
Shamelessly taken from here (because SO doesn't accept duplicates from unix.stackexchange.com):
Find your output devices with xrandr (the first word before "connected", you should find two such lines), e.g. eDP1 if the output is
eDP1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
and then have fun with
xrandr --output eDP1 --rotate right
in your .xinitrc.
The original answer notices that by using a NVidia card you may have to add
Option "RandRRotation" "True"
to your xorg.conf (which i cannot verify with my setup).
Related
I'm setting up a terminal based programming environment, but I'm running into an issue with tmux. I need more horizontal scrolling space to view Pandas dataframes, but my horizontal screen buffer size is being restricted when I use tmux.
I've seen plenty of other answers that deal with vertical scroll-back limits, but I haven't been able to find SO answers or tmux documentation showing how to increase horizontal screen buffer size.
Below are the steps I found to increase vertical scroll distance:
1) open the tmux conf file
vim ~/.tmux.conf
2) add line to increase vertical scroll limit
set-option -g history-limit 9000
Is it possible to use a similar setting in .tmux.conf to increase horizontal scroll?
tmux adds resize-window in version 2.9, released March 26, 2019.
resize-window introduces the option to have a buffer size that is greater than the largest of the client window sizes, and takes parameters similar to the already existent resize-pane, i.e. you can either specify value for any (or both) of the height and width or you can more naturally opt to resize a window "from any of the sides".
After ensuring you are running tmux v2.9 or higher (tmux -V will tell you what version you have installed - if you need to upgrade, make sure you terminate any existing sessions to upgrade the running daemon):
To resize a window, enter tmux's command mode (default: ctrl-b followed by :) then type in resize-window followed by -x <NEW_WIDTH> or -y <NEW_HEIGHT> followed by Enter to set the width/height to an absolute value (in cells/characters).
To instead increase the existing width/height rather than specify it as an absolute value, use resize-window with one of -U, -D, -L, or -R followed by n to increase the size in the Up, Down, Left, or Right directions by n cells/characters.
e.g.
# set virtual terminal width to 2000 pixels
resize-window -x 2000
or
# increase width by 200 columns
resize-window -R 200
There is typically little benefit in increasing the height beyond the size of your actual client window as tmux already offers a huge scrollback and there's no such as vertical wraparound, but if a program requires some minimum space to e.g. layout a curses UI looks ugly at a constrained size, you can work around it with that.
If you build tmux from Git master or a 2.9-rc, you can use resize-window to set the width.
TL;DR: No.
Terminals do not normally have infinite width. Tmux specifically limits and wraps you to the horizontal and vertical size of your view. You can scroll backward through the view to see past data. You cannot scroll left and right because there is nothing to see left and right of your view; the output has been automatically adjusted to fit your view by continuing on the next line.
Based on the linked question above, screen has this capability. Tmux does not.
Edit: this answer was for tmux <2.8, which, as of this writing, was the most recent stable release. tmux 2.9 will have resize-window, see the tmux 2.9 changes file on the releases page when 2.9 is fully released
I'm trying to obtain the position of the mouse in pixels within an application running in a terminal.
The top answer to how to get MouseMove and MouseClick in bash? explains how to get the mouse position, counted in character cells, not in pixels.
I'm looking for a solution which also works if the app is running on a remote server and accessed via SSH (using xdotool will not work in this case, unless ssh -X was used).
I guess the solution will therefore involve escape sequences or an IOCTL.
It's okay if the escape sequences only work with one or few terminal emulators (I can use a detection mechanism to provide a fallback on the terminals which lack support for the escape sequence).
If the escape sequence only works on a few terminal emulators, I'm also curious to know the "group" of escape sequences that allow graphical output on these terminals (e.g. Sixel, Tektronix or ReGIS).
The goal is to embed small GUI elements in mostly text-based applications. It is currently possible on quite a few terminal emulators using Sixel, Tektronix or ReGIS do draw things, and \e[1000h or similar escape codes to get mouse events, unfortunately these mouse events are low-resolution (the coordinates in character cells, not in pixels).
xterm reports the mouse position with pixel resolution with the following escape sequences:
switch on pixel resolution: \e[2;1'z
report mouse position: \e['|
Details are described at http://invisible-island.net/xterm/ctlseqs/ctlseqs.html
Standard input and output are connected to a terminal that implements ANSI escape sequences, but is of unknown dimensions.
I need to know how big the terminal so to facilitate drawing a full-screen text UI on it. How can I get the size?
The correct size is not loaded into environment variables. I cannot use TIOCGETS; the the call would return success but the values are not correct -- the kernel doesn't know the size either.
There are lots and lots of answers searching stackoverflow, but they all depend on the OS providing the answer one way or anther; but this time that is not true.
The best clue I can find is the DSR command which returns the current cursor position; but there's no move to bottom/right command.
The resize program does this by moving the cursor to a very large column and row; the terminal moves as far as it can, e.g.,
CUP 999 999
Then resize asks where the cursor is:
DSR 6
The terminal replies with the actual cursor position (i.e., the cursor position report CPR), from which resize knows the terminal's size: the cursor is on the lower-right corner.
That's all done using standard (ECMA-48 / VT100) escape sequences. In XTerm Control Sequences (which should apply to your "ANSI" terminal)
CSI Ps n Device Status Report (DSR).
Ps = 6 -> Report Cursor Position (CPR) [row;column].
Result is CSI r ; c R
I'm using screen (I've seen it commonly referred to as GNU screen, though I'm not using GNU) in gnome-terminal in Ubuntu, and I love it. I like to use the vertical split so I can have a side-by-side view of two things.
Only problem is that if I use the mouse to select text on one side of the vertical split, it selects the text on both sides. This means I can't effectively copy and paste text from terminal while using a vertical split in screen.
Is there a way to overcome this problem? If there is a mouse-less solution, that would be even better.
Thanks! : D
I found the answer to my question in this Super User section:
Copy-paste with GNU Screen with vertically-split windows on OS X
Ctrl+Shift and the cursor can be used to select text in just one of the vertical splits.
Hope this helps someone!
I'm trying to print a postscript file to a Dymo LabelWriter (tried a LabelWriter 450 and LabelWriter 330-Turbo), i'm getting it trough ok, but the margin seems to be way to high, 1/3 of the label isn't printable (see pic, the black square is supposed to cover the entire label over the width).
The label is 89mm on 39mm (so 252pt x 123pt)
I'm using a boundig box of 8 8 252 123 and the page orientation is set to portrait.
I even tested it with an eps-file generated from Gimp, it leaves the same area blank.
anyone has an idea why it isn't printing correctly?
EDIT:
The file can be viewed here : http://pastebin.com/c7YC5ftb
The command I use to print it on a Dymo LabelWriter is:
C:\ps\gswin32c.exe -sDEVICE=mswinpr2 -dNoCancel -dNOPAUSE -dSAFER -sOutputFile="%%printer%%DYMO LabelWriter 450" -q "C:\ps\dymo.ps" -c quit
Not without seeing the PostScript file, no. I don't see from the Dymo web site that the printer accepts PostScript input, so how are you sending the PostScript file to it ?
Added in response to edits in the question.
Well its not absolutely clear to me what you expect this to look like.
Your original comment refers to a black square, but the PostScript doesn't contain a black square, it draws a rectangle with an aspect ratio of 20:1. You have set the media up to be wider than it is long (252,123) but you then use the Orientation to rotate the content by 270 degrees. Its true this is portrait, but upside down. If you want portrait why not just set the media to be portrait ?
Simply put the origin is the corner directly above your thumb in the photograph, and I think the long and short sides of the print are reversed with respect to the actual label.
Note that the BoundingBox comment is a comment and is ignored by the PostScript interpreter so changing it has no effect.
Perhaps if you could explain what you are trying to achieve ?
Problem is solved, the printer wasn't set to accept this type of labels
If you ever have this problem go the advanced settings of your printer driver and set the label.