I generally use tmux with 3-4 panes open. One of these panes is rarely used, so I'd be happy to hide it away somewhere. I suppose I could do this in a new window, but I'd rather hide it "behind" an existing pane.
For example, I'd like to keep rails server running in the background because I rarely need to refer to it, so guard occupies that pane instead. When I need to look at the rails server output, I'll switch to the guard pane and then "tab" over to the rails server.
At least, that's the ideal situation, but I can't figure out how to achieve it.
Tmux currently does not provide the functionality of 'hiding' panes.
For now, the closest tmux comes to hiding panes is the 'pane zoom' functionality. It is toggled with prefix + z. When 'on', the pane is resized to 100% of the window and all the other panes are hidden. Setting the pane zoom to 'off' unhides the hidden panes.
That said, I think the 'zoom' functionality is not ideal for your use case. Other have pointed it out: just using a new window that doesn't get in your way might do the trick and is a simple solution.
You should be able to do this using break-pane and join-pane - see this question on Unix&Linux.
i am not sure what is in your mind of the concept "tab"; however, from what you want, a window is more than enough.
Imagine you have a "tab" in tmux, then, you more or less have to switch to that tab in order to see the output, so, the operation is exactly the same with window of tmux.
Normally, I type <c-x> c to have a new window, and then go back to the main workspace (the previous window) with <c-x> p and open my vim there to work. I might have multiple panes on my main workspace with tmux pane (not with vim pane, cos i need to have the terminal always to navigate). Then after I change things, save, just type another <c-x> p to go to the server and see what happen there
(note that I bind <c-b> to <c-x>)
Related
In new versions of tmux, I know that I can use set -g mouse on to enable mouse support in order to be able to resize panes with the mouse.
But it also enable a feature that I do not want which is using copy mode when I select text in the terminal. In that way I am no more able to copy text in the system clipboard in order to paste it outside of tmux.
My question is: is there a way to enable resizing panes with the mouse, which very handy, without having to enable mouse support for other things?
Because there in no answer, I will try to answer myself:
Apparently there is no way to do this, since when a mouse event is intercepted by tmux, it cannot be forwarded to the system. I say this but it is pure deduction, I have no knowledge about that.
As an alternative, there is a way to prevent tmux to intercept the mouse, by holding a key like "fn" on Mac OS.
I'm using tmux for the first time as a replacement for iterm (mostly because of the split panels function) and it works great. Now, i have a question about the copy-text behaviour.
It's possible to configure tmux, so i can select text with the left button (in copy mode) and it's automatically copied (to the clipboard) when i release the left button? (same as in irc clients)
Tmux’s select behavior will depend on your mouse settings. If mode-mouse is off, Tmux should stay out of the way. But, by default, it may be set to “on”. Then it will use its own “paste buffer”. To bypass that, you can hold down shift while selecting and pasting. (This works on Linuxes, but probably on Mac, too; not sure what OS you’re on.)
I'm trying to create a visual indicator of which pane is currently focused in tmux when my terminal (iterm2, OSX) window gains focus. I have found that iterm2 sends a focus gained escape sequence (^[[I) so now I am trying to find how I can capture that and fire the prefix q command which shows pane numbers with the active pane in red.
Any ideas on how to capture the escape sequence in tmux OR in iterm2?
I have a partial solution to my issue which takes a different approach. Since I usually have vim and one terminal pane open, dimming vim when it is not focussed is a good indicator which pane is active. In order to achieve this I have modified the vim-diminactive plugin to react to focus events (https://github.com/blueyed/vim-diminactive/pull/8), this requires the Vitality.vim plugin as well as enabling (focus-events) in tmux options.
In order to completely solve my issue I am working on changing the background colour of terminal panes when they lose focus. I use zsh so I can capture the focus event with bindkey (I have verified this works) to issue a background colour change escape code to iterm2, however this seems to have no effect in tmux.
I have a main window (on MS Windows) and I want to have sub windows or subpanels with free screen movement. I can use dialog and Qt::splashscreen flag, but when I am on these subwindows I lose the focus caption for the main window. Is there any trick to do what I want? (Something like a multi-focus...)
Maybe it is impossible?
I'm not sure what you mean by losing the focus.
When I create an application with multiple windows, this is what I do: in the sub-window widget, I set the parent to the main window, and set the Qt::Tool flag. It has multiple effects: the window manager sees it as one window, and when you focus any window, all the windows raise.
Do you want QMdiArea? Or a focus proxy?
In Qt, all top-level windows are independent, none is the "main". If you want to nominate one as a main window and have it steal focus from the others, then you will have to implement that manually.
Sounds like you just want to have widgets that you can move around freely on a parent widget/window, without invoking the "window focus changed" event between native Windows windows (...).
I'm not sure if there is a ready-made solution for that, but adding some grab/move/resize events to a widget's edges shouldn't be that hard, or?
I'd simply catch mousedown/up events on certain areas (these should probably be widgets of their own with a link to the parent movable widget), and have them resize/move the window when the mouse moves.
I need to keep a NativeWindow I am creating on top of the main window of the application.
Currently I am using alwaysInFront = true, which is not limited to the windows in the application. I can successfully synchronize the minimize/restore/move/resize actions, so the top window behaves appropriately in those cases. Even though using this option has the drawback that if I alt-tab to other application the window goes on top of the other application.
Because of the above I am trying to get it to work without using the alwaysInFront. I have tried using orderInFrontOf and orderToFront, which gets it in place but when I click an area in the main window the top one becomes hidden i.e. air makes it the top one.
I have tried capturing activate/deactivate events but it only happens on the first click, so on the second click the top window becomes hidden again. I also tried making the top window active when the main one becomes active, but that causes the main one to loose focus and I can't click on anything.
Ps. I am doing this to improve the behavior of a HTMLOverlay I am using - see Flex Air HTMLLoader blank pop up window when flash content is loaded
Listening for Event.DEACTIVATE and calling event.preventDefault() should work. Not sure if that is what you have tried, but I have an app where that does the trick.
I ended up turning on/off the alwaysInFront option based on whether the main window or the top window were active i.e. if none where active I turned it off. This was additionally to what I mentioned in the question.
That way when the user switches to another application, the window doesn't go on top of the other apps. I still would prefer a solution where I don't have to use the alwaysInFront option, or even better an alternate solution to the flex loading flash in external sites issue I linked to above.
Ps. I will try to check with the owner of the HTMLOverlay to submit a patch (its an improvement, although its tied to an app that doesn't open extra windows when opening the overlay).
Update: I have committed the changes to the HTMLOverlay.
I'm trying to do something very similar. In an AIR application, I have one large full screen window which is essentially the "desktop". I always want this window to stay behind all other windows in my app. There are, however, some items on the "desktop" window that need to be clickable.
There appears to be no clean way to force a window to maintain its position in the window ordering.
What I've settled on so far, which isn't perfect, is to make all other windows in my app use the alwaysOnTop property but bind this to a global var (ugh) that I maintain to track the overall application level active/inactive state. This way, when I switch to another app, my windows don't float above the all other app windows - they correctly move behind as expected.
Then, I have a regular (alwaysOnTop=false) window that is fully transparent as an "overlay" to the desktop window on which I can place various interactive controls. This window is OK to come forward since it's transparent and my other windows are alwaysOnTop.
Finally, and crucially, I install three event listeners on the "desktop" window as follows:
protected function onApplicationComplete(event:Event):void
{
this.addEventListener(MouseEvent.MOUSE_DOWN, onClickHandler, true,1000,true);
this.addEventListener(MouseEvent.CLICK, onClickHandler, true,1000,true);
this.nativeWindow.addEventListener(Event.ACTIVATE, onActivateWindow,false,-1);
}
protected function onActivateWindow(event:Event):void
{
trace("sent via activate to back");
orderInBackOf(bigTransparentWindow);
}
protected function onClickHandler(event:MouseEvent):void
{
trace("sent via click to back");
orderInBackOf(bigTransparentWindow);
}
I'm not entirely happy with all this since there is still some occasionally noticeable flicker of objects in the overlay window - it appears that the "Desktop" window gets ordered in front of it, an update of some sort happens, and then it gets forced behind again.
Any better solutions welcome!