Since the last big update including Xfce 4.16 (I'm running Arch Linux), the action buttons like Ok or Cancel are wrongly placed at the top of the window in most application's dialog boxes.
Here's an example with the Open File window in LibreOffice, I see the same behavior in other application like Firefox or Mousepad :
(source: lps-it.fr)
This is very annoying as it breaks the ergonomic of the dialog box and make the user experience painful.
I believe this is coming from GTK3 but I'm not sure.
Do you know which component is to blame for this, and how to fix it ?
xfconf-query -c xsettings -p /Gtk/DialogsUseHeader -s false
Will move them back to the bottom. See: Arch Wiki Xfce Page
Related
When you open the file menu (or any other menu in the menu bar), it looks something like the attached image.
MacOS file menu
In Windows, when you select the command you want, the menu instantly disappears and the action is instantly performed. In MacOS, however, the command you chose blinks, the window fades out, and then the action is performed.
I know there are commands and settings to disable certain animations in MacOS, but I can't seem to find one relating to this yet.
This is one of my major pet peeves with MacOS and I'd appreciate any help. It might be the case that I'm making a huge deal out of this when it's not as such, but it does get annoying sometimes and slows down my workflow.
Thanks!
I want to change some tmux styling when the terminal loses focus/becomes inactive (i.e. when I've clicked on an open Google Chrome window). I know I could check with the window manager to see which application window is focused, but this doesn't work across window managers.
Do terminal emulators themselves expose this information at all?
I tried running showkey -a to see if any escape sequence was sent when focus was lost, and it doesn't look like it.
I think some terminals implement this, but not all, based on this comment on the issue tracker for the vim-tmux-focus-events plugin:
About the question "I was expecting the event to fire when changing focus between different windows in my window manager": yea, I see how that would be very useful. I think this might be dependent on the terminal application you're using. I just tested this on OSX and here's some quick results:
it's working for iTerm when tmux is running inside the window
not working for iTerm running plain bash + vim inside (no tmux)
not working for Terminal.app (with or without tmux)
[...]
So, if I'm not wrong, it's up to terminal applications to implement "focus gained", "focus lost" functionality.
I have a vague memory (though I don't remember for sure) that focus gain/loss might have worked for me when using that plugin and gnome-terminal, so it might be worth a try.
I posted this on the yad list, apparently with invisibility enabled (nobody's even viewed it! - usually, the list is very responsive.), so I thought I'd see if any of you have some ideas. It probably applies to any bash script using any gui pop-up utility such as dialog, xdialog, or zenity with the KDE desktop.
In general, I love yad. It blows away zenity and the developer is usually right there to answer questions and fix/enhance things.
Essentially, I have a set of scripts that use pop-up gui dialogs for interaction with the user.
It works great until you click the mouse anywhere else on the KDE desktop while one of the pop-ups is displayed.
Once you do that, all subsequent dialogs "appear" behind everything else and are usually invisible except for in the taskbar and have to be manually selected from there to become visible/active/focused again.
Is there a way to fix this? I assume it's a desktop and not a yad problem.
Thanks,
Joe
kubuntu precise 64-bit (KDE 4.8.5)
My duplex printing system, written in bash, makes multiple calls to yad from within one (possibly nested) script. It works great, but has one major problem.
If the user clicks the mouse anywhere outside a yad dialog while the script is running and displaying something with yad, all subsequent yad dialogs appear behind everything else and are essentially invisible.
The script still shows up in the task manager, so these dialogs can be brought back to the foreground one by one, but it's really counter-intuitive and annoying.
I assume this is a "feature" of KDE and not a bug in yad.
Is there any way to fix/prevent this? I tried adding --on-top to the dialogs, but it didn't help.
When I'm running the script (which may take awhile, or I may want to do something else while a dialog is waiting for input), I can't do anything else for fear of having this problem occur. I can switch to another desktop, but that's dodgy because the next dialog (but only that one) may pop up there and throw the whole thing off.
I'm using the latest yad from the ppa on kubuntu precise.
The stacking order of windows is controlled by the KDE window manager. When a UI application, like yad, creates a window, it may communicate preferred attributes, like "always on top", to the WM. When this does not work for some reason, you may try to call command line utility, for example wmctrl that instructs the WM to raise an existing window:
wmctrl -a "Yad"
Thanks! I had the same issue with a zenity dialog poped up from a gedit custom External tool (sh script). Adding the wmctrl -a "CVS commit" cmd fixed it.
I just switched from OSX Terminal to iTerm2, and I seem to have lost one piece of functionality.
In Terminal, I could scroll through output of the less command with my mouse, because I had installed MouseTerm.
However, when I try scrolling less output in iTerm2, the window's scrollbar moves instead.
Strangely, scrolling works as expected with vim.
How can I scroll less output with my mouse in iTerm2?
Now it is implemented in iTerm2 and can be activated by
Settings -> Advanced -> Scroll wheel sends arrow keys when in alternate screen mode and change it to Yes
(defaults write com.googlecode.iterm2 AlternateMouseScroll -bool true still works but it just changes the same setting)
The iTerm2 issue is now marked as "fixed" -
but the fix is to add a hidden option, so it is not immediately obvious
how to enable the new AlternateMouseScroll option.
As Filippo Valsorda (author of the patch) writes,
once you install a nightly build (still not present in 1.0.0.20140629) of iTerm2,
just run this command:
$ defaults write com.googlecode.iterm2 AlternateMouseScroll -bool true
restart iTerm2, and all your windows will report scroll events as up/down arrow-key escapes
when the terminal is in the "alternate screen" (direct addressing) mode
used by programs like less, vim, emacs, etcetera.
For applications like vim and emacs that provide additional mouse support,
you will still want to enable mouse reporting mode,
as this automatic mode switch only enables scrolling.
Finally did it, I've been spending a lot of time on this looking here and there with no luck, the simplest steps are:
Install the 2.9 beta version
Done
Not the OP's question, but for anyone here trying to get this to work in tmux, with credit to choco via this github comment here's a snippet to add to your tmux.conf to get it to handle alternate screens (e.g. less, vim) correctly:
# Check if copy-mode or any mouse flags, then send mouse events
# or check if we're in alternate screen end send navigation keys (up, down)
bind -n WheelUpPane if-shell -Ft='#{?pane_in_mode,1,#{mouse_any_flag}}' \
'send -Mt=' 'if-shell -Ft= "#{alternate_on}" \
"send -t= Up" "copy-mode -et= ; send -Mt="'
bind -n WheelDownPane if-shell -Ft= '#{?pane_in_mode,1,#{mouse_any_flag}}' \
'send -Mt=' 'if-shell -Ft= "#{alternate_on}" \
"send -t= Down" "send -Mt="'
Note, this doesn't require the Iterm preference change mentioned in other answers, but it also isn't hurt by it.
This isn't implemented as of now.
There is an open issue in the iTerm 2 issue tracker about implementing it.
The latest version of less supports the --mouse and related flags so there's no need send arrow keys to alternate screens.
I've been googling around trying to figure out if it's possible to use my mouse wheel to scroll while inside Vim in Mac's Terminal, with no luck. It seems as if only X11 or iTerm support this.
Before I give up, I thought I'd try the geniuses here to see if anyone knows a way to do this. So, does anyone know if I can set that up?
Or should I seriously consider using a different terminal application?
And if you're using iTerm, add this to your vimrc
:set mouse=a
http://bitheap.org/mouseterm/
Use MouseTerm (and do make sure to install SIMBL first!) and scrolling will work like a charm, even remote, using Mac Terminal.
You need to fully quit the Terminal application (Command+Q) and then launch it again after installing MouseTerm.
This is an old question, but a top hit on google, so I feel compelled to provide an updated answer.
Running OSX El Capitan 10.11, vim mouse and trackpad scrolling just worked(TM) for me in Terminal.app by default. However occasionally the mouse/trackpad input stopped manipulating the vim buffer, and started scrolling the terminal buffer. The answer was Command+R or Menu View --> Allow Mouse Reporting. Turning that on allowed the mouse/trackpad scroll operations to move the cursor in vim.
Termanal Menu > View > Allow Mouse Reporting
Terminal Menu > Preferences >
Keyboard > Scroll alternate screen
If the mouse functionalities still do not work properly take a look at my answer in this post How to let vim behave on Mac OS X as on Ubuntu?, just add to your .vimrc
set ttymouse=xterm2
You can read this article, but I'm pretty sure since the default terminal in Mac OS X has a built-in scrollbar, the mousewheel commands automatically go to it. You could definitely use gVim as suggested in the previous answer. I find that I don't generally want to use the mouse in Vim though as it takes my hands off the keyboard.
I just use 50j to go down and 50k to go up. Not exactly scrolling, but it works pretty well.
Make sure the terminal is xterm & not ansi in Terminal Menu > Preferences > Profiles > Advanced. I accidentally broke scrolling by changing the term type in a naive effort to get coloring to work over ssh.
Use gVim, which gives you a text editing environment in a window you can scroll. Terminal is not involved when using gVim.
I'm using xterm in X11 (XQuartz 2.3.4) and vim works very fine with mouse and also suport 256 colors.
Here is the ~/.Xresources I use to make my xterm nicer in X11:
XTerm*faceName: Lucida Sans Typewriter Regular
XTerm*faceSize: 9
XTerm*utf8: 1
xterm*saveLines: 1000
xterm*jumpScroll: true
!xterm*awaitInput: true
!xterm*multiScroll: true
XTerm*scrollBar: false
xterm*scrollbar*thickness: 16
xterm*rightScrollBar: true
XTerm*foreground: white
XTerm*background: grey10
!XTerm*background: black
XTerm*cursorColor: yellow
xterm*visualBell: false
xterm*loginShell: true
Little tips, to remove the bell sound in X11's xterm type this command:
xset b 0
I would recommend using iTerm - it has so many advantages over Terminal eg Mouse support, 256 colors, sensible copy and paste (auto-copy, word/url selection with double click, middle click paste)...
When using iTerm create a .vimrc file (if not already there) in your home folder and add the line:
:set mouse=a
Scrolling down in vim to view a file works after this.