Is it possible to change window title of an arbitrary window that does not belong to my application (identified by application PID or window descriptor) in KDE? If so, how can it be done?
For anyone also searching for this, the above has helped me find the way to do this from the command line...
You will need to have wmctrl installed....
From the command line this can be achieved like this:
First (optionally) list all windows:
wmctrl -l
Then, assuming you have a window called "foo this is a window bar", issuing
wmctrl -r "this is a window" -N "Full new title"
will set the title of this window to Full new title
Yes, it can be done.
Iterate over the X11 Windows and check for one with the _NET_WM_PID property set to PID, yielding the XID of the window;
then change the WM_NAME property of that window.
But note that if this _NET_WM_PID property is not set by the program on its windows, you will not be able to find the window by the PID. And note that a program may set _NET_WM_PID on all of its windows, so the result of the first step may not be a single window.
Related
In tmux, how can I move a window from a session to another session?
ex. move window:4 in session [0] to session [4] .
From my testing on tmux 2.6, you'll need two things for the command to move an entire window over:
The name of the session you want to move the window from (for future reference, $session_name)
The index of the window you want to move (in the session it's currently in, of course -- we'll call this $window_index). This is actually optional -- if you omit this, then it defaults to the window in focus in the session you're pulling the window from.
From this point, you can just change to the session you want to move the window into, <tmux-escape>: into a command prompt, and type a command of this form:
move-window -s $session_name[:$window_index]
...where, as noted before, the $window_index is optional (as indicated by the square brackets, which aren't actually part of the syntax
). To use some concrete examples:
# Moves from currently-focused window from session named `$session_name`
move-window -s $session_name
# Moves from window with index `$window_index` from
# session named `$session_name` into the current session
move-window -s $session_name:$window_index
Et voilĂ ! Your window got moved. :)
EDIT: Added some more info on an alternative that omits $window-index.
There's now a built-in shortcut <tmux-escape>. to bring up the move-window command, so it's as easy as <tmux-escape>. <session_name>:<window_index> or to move a window within the same session, omit the session name: <tmux-escape>. <window_index>
I have a network simulator (mininet) which simulates switches and hosts for me. I can xterm switches in order to send packets.
I want to print the the "xterm title" in the terminal. For example the xterm title is "Node:s1"(root), I am searching for a command that print "Node:s1(root)" in the xterm named "Node:s1"(root). Do you know any command that can print the xterm title?
If that's xterm, you can do this. Other terminals may have the relevant code disabled (permanently), but with xterm, you can configure it and get the title string. In the manual page, that is the allowWindowOps resource.
xterm (and similar programs) let an application set the title by sending an escape sequence to it. There is another escape sequence which asks the terminal to send the title string back to the host. If the host is not expecting that, and if the string contains commands, your shell will execute those commands.
The place to start reading is the xterm title HOWTO.
Newer versions of xterm have a different feature for applications that merely want to set the title and restore it. That accounts for most applications that set the title, such as GNU screen. It happens that GNU screen can use this newer xterm feature. It's only been around 6 years (November 2009), so other programs have not caught up.
Further reading:
6.3. Xterm Title Bar Manipulations (Bash Prompt HOWTO)
xtermcontrol (a well-known program for titles, colors, etc)
Is it possible to obtain the current name of the xterm window? (mentions the stack, but does not point out that one cannot get the title this way)
I wrote the following command to search Vim's help files:
command! -n=1 -complete=help SearchHelp \
help | execute "grep! -i <args> $VIMRUNTIME/doc/ -r" | botright copen
Now, for example, when I have forgotten the key to increment the number under the cursor, I can do:
:SearchHelp increment
to search through the help files. (The answer turned out to be <Ctrl-A>.)
The problem is ... I have a few windows open, and I want quickfix to leave them alone. When I hit <Enter> in the quickfix list, I want it to open the result in that help window which I split open at the beginning of the command.
But it doesn't do this. It seems to prefer to always open the result in the bottom-most of all my editing windows, regardless of which window I was focused on, and with complete disinterest for the help window I opened. Obviously this moves away from whatever file I happened to be editing in that window (yes I have :set hidden), requiring an arbitrary number of <Ctrl-O> keys to get back to the file when I have finished browsing the help files.
So how can I get quickfix to open in the previously focused window (ideally that help window that was split open)?
(Incidentally, I sometimes use a patched version of Yegappan Lakshmanan's old grep.vim plugin, and somehow this does open :cope results in the window that had focus before I ran :Grep. I am not sure what's different in the two situations.)
The behavior (among others like :sbuffer) is controlled by the 'switchbuf' option. With a value of useopen, you can make it re-use a window if it already displays that help page. If you need more control than what is offered by that option, you do need to use a custom command / mapping.
So far what I have come up with is to replace that help command with:
99wincmd j | wincmd s
This splits whatever window happens to be at the bottom of the screen, so that when the quickfix clobbers the bottom one, I still have a window that keeps the file visible.
This solution is workable, but not quite as neat as my preferred result, which is to open results in the help window which was split just above the window I was focused on when I ran the command.
If an Emacs frame is split in several windows and a new buffer is opened, is there a possibility to tell Emacs in which window to open the buffer.
Especially, if one window contains a dired buffer and I want to tell Emacs in which of the other opened windows a new file shall be displayed.
If the Emacs frame is for example split like this:
____________________
| | |
| | |
| A | B |
| | |
| | |
--------------------
| | |
| C | D |
| | |
--------------------
Where A,B,C and D are the windows. If A contains a dired buffer, can I tell Emacs to open a new file in a new buffer in window D?
Here's another answer --
You can do what you want using Icicles. In Icicle mode, C-x o, which is normally other-window, is icicle-other-window-or-frame. A prefix arg gives it several alternative behaviors, one of which (for Emacs 24 and later) is to choose a window that will be used by the next buffer-displaying operation (e.g., C-x C-f, C-x b).
That's what happens if you use a double plain prefix arg: C-u C-u C-x o. That invokes command icicle-choose-window-for-buffer-display, which you could of course also bind to any other key.
You choose the target window by name (using completion or cycling etc.).
All that command does is set variable icicle-next-window-for-display-buffer to the window that you choose. Icicles advises commands display-buffer, switch-to-buffer, and switch-to-buffer-other-window so that the next time they are called they use the window that is the value of icicle-next-window-for-display-buffer. (After that invocation they return to their normal behavior.)
This means too that if you have another method of choosing a window, which you prefer (e.g. cycling using one of the other methods mentioned here), then you could modify that method to set icicle-next-window-for-display-buffer to the chosen window, to get the same effect (in Icicle mode). IOW, it does matter how you choose the window; just set the variable value to it and the next buffer-displaying action will use it.
Others will probably give you answers that more directly respond to your question. My answer is to just move the focus to the window you want and then use C-x C-f or whatever to open the file or display the buffer you want in that selected window.
In order to do what you requested directly, you need anyway to use a key sequence that invokes the command you want. And if you want something general that works with different commands (e.g. find-file and switch-to-buffer) then you need to use a prefix key or repurpose the prefix arg. That is typically just as many key strokes as it is to switch to the window and then use the usual command.
Of course, with my suggestion you need a command to quickly switch to the window you want. There are various commands out there that let you cycle among windows or use completion to quickly pick a window by name or number.
So that's what I would suggest: switch to the window and then display whatever you want there, instead of trying to combine (a) designating the target window with (b) invoking the command that displays the buffer. IOW, just do it the old-school way: go to the window and then display there.
Of course, if you don't really want to end up in that newly displayed buffer, and you just want to keep the focus where you started, then with my suggestion you would need to cycle (e.g.) back to your starting window. It's not clear from your description whether this is your use case. If it is, then my solution is probably not that helpful.
But even in that case, it might still be useful to split things up: (a) a command to (only) designate the window to use for the following display-buffer command and (b) the display-buffer command. IOW, do essentially the same thing I suggested, but the first step would only designate the target window instead of switching to it, and the second step would use that designated window. (You would need to define (a) and (b), as a general mechanism.)
In this case too my suggestion differs probably from what others might suggest, in that it does not try to combine window choice with display command. They are coupled sequentially, but not combined in one command.
make the window that you would like to load the buffer in, activated and press:
C-x b
and you will be prompted by:
Switch to buffer (default *Buffer List*):
press enter(ret) without writing anything to choose the default. and then you will find buffer list loaded in that window. then choose the one you like to load and you will find it loaded in the same window.
Apologies in advance if this has already been asked - it's really hard to search for this as bash and terminal show up together in so many places.
Basically what I'd like to be able to do is have a bash script be aware of whether or not the terminal it's running in is currently active (selected) so that I could use notify-send to inform the user something has completed only if it's not currently the active window. I'm guessing it would be possible to do something that can at least detect whether the active window is a terminal window by accessing gnome somehow, but I have no idea how and I imagine it would likely be a hack, but any help would be appreciated.
Well this question is rather about xserver and window management then bash itself. You need 2 things for this:
package with xprop, this is xutils if I remember correctly.
you need to set unique terminal window name, so you could later find it on window stack, here is working example: http://www.linuxquestions.org/questions/linux-server-73/set-terminal-title-dynamically-803469/
a) to find your window:
$> xprop -root _NET_CLIENT_LIST_STACKING
It gives an output like:
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0xe0001e, 0x3a0006d, 0x1a00004
This is window stack so the last window is on top. You need to extract list of window ids (0xe0001e 0x3a0006d 0x1a00004).
Next you have to iterate over that list of ids. You will find your window by examining this property:
xprop -id <win id> WM_NAME
b) Example how to raise your window is here:
X11: raise an existing window via command line?
After some more digging I've found a workable solution so I'm going to post it as an answer, but it's not very portable so I'd still appreciate any better solutions.
What I've found is that when using Gnome you have access to a $WINDOWID variable from the gnome-terminal (this doesn't work if you've ssh'ed to another box unfortunately and so isn't ideal). This can be combined with xprop like this:
activeWindow=$(xprop -root | awk '/_NET_ACTIVE_WINDOW\(WINDOW\)/{print $NF}')
thisWindow=$(printf '0x%x\n' $WINDOWID)
Which can then be compared for equality. A more suitable way of getting the current window id would be good however.
Edit: Having seen Zaytzev's answer I guess this could be combined so instead of using $WINDOWID I could set the terminal title and check whether xprop -id $activeWindow WM_NAME is equal to my window title.