I just wanted to mention that Adobe has released a native 64-bit version of their Flash plugin for web browsers today. I installed it for Firefox by going to this page, and clicking the “Download 64-bit Plugin for Linux” link. Before doing anything uninstall all flash plugins that you have on your system! For me, this was achieved by removing the nspluginwrapper and flashplugin-nonfree packages. Just extract the file you downloaded from the Adobe page; you will get a file called libflashplayer.so. Create a new directory called “plugins” in ~/.mozilla. Then, copy the libflashplayer.so file into ~/.mozilla/plugins, and restart Firefox. Done!
Even though it’s an alpha release, it seems to be working fine for sites like Youtube and CNN video, on my Xubuntu 64-bit system.
I have discovered a one-liner fix to the Aurora GTK Engine, for the bug where the menu opens and then immediately disappears when right-clicking on a file in Thunar (Xubuntu).
Open up ~/.themes/Aurora/gtk-2.0/gtkrc, and change the GtkMenu::vertical-padding = 0 to GtkMenu::vertical-padding = 1. Now if you right-click on a file or folder in Thunar, the pop-up menu works properly.
UPDATE November 11, 2008: Thanks to this guy, I can now happily use Aurora-midnight with Firefox — and input text box areas for sites like Google and the new Hotmail work much, much better (especially Hotmail, where I had black text on black backgrounds for new emails!). Here is my userContent.css file located in ~/.mozilla/firefox/…default/chrome:
I’ll try to keep this short. I’m using Xubuntu 8.04.1 + vim 7.1.138. (Xfce4-terminal is version 0.2.8).
The problem: If you have the lines and columns options set in your .vimrc file for gvim‘s default window size upon startup, you run into a strange graphics glitch if you attempt to run simple console vim inside xfce4-terminal. What you type does not get displayed, and a new line appears after every keystroke, deleting the previous line — although the data of what you typed in is still there. It is the same problem discussed here. I encountered this problem while executing the git commit -an command from xfce4-terminal, when git resorted to vim as the default text editor. (NOTE: You might need to edit xfce4-terminal’s default window size in ~/.config/Terminal/termnalrc (the MiscDefaultGeometry option) to reproduce the glitch — I had mine set to 80×19).
The solution: Make the lines and columns options in .vimrc dependent on the “gui_running” variable, like so (copied from here):
"GUI is running or is about to start.
"Maximize gvim window.
set lines=69 columns=100
" if we're in console Vim, then we just want to leave the window size alone --
" let it simply be whatever the window size of the terminal is before vim is
" "This is console Vim.
" if exists("+lines")
" set lines=69
" if exists("+columns")
" set columns=100
This works. You do not get the strange graphical glitch behavior described above, by making vim only resize the window if it is gvim, and not console vim. I have commented out the console vim settings because, as stated above, I already have a default window size of 80×19 for xfce4-terminal.
Note: If you use xterm, it doesn’t matter — even if you don’t have the special “gui_running” option in your .vimrc, console vim will work properly. So run git commands in xterm if you don’t like xfce4-terminal.