I used to disable gnome-shell's hot corner feature with the No Topleft Hot Corner extension. Upgrading to gnome-shell 40 has it deprecated. Gnome-tweaks claims it's able to disable it as well, but activating this "disable the hot-corner" option doesn't deactivate the hot corner at all. Finally, I found reading this Ask Ubuntu thread that I could
gsettings set org.gnome.desktop.interface enable-hot-corners false
but it doesn't work either, even though the command succeeds.So this little Apple©-like annoyance is back.
So indeed the question is : how do I get rid of it again ? ... Hell I love you Gnome, but you're really stepping on my nerves from time to time.
It appears I had to reboot for the gsettings command to take effect. And now that I did reboot, the command is taking effect immediately, meaning I can switch live the hotcorner feature with
gsettings set org.gnome.desktop.interface enable-hot-corners false
and
gsettings set org.gnome.desktop.interface enable-hot-corners true
I suppose that it did not work because the workstation was not rebooted since I had upgraded GNOME. Hope this documents this feature's behaviour as a whole.
Related
I have Lubuntu. But when i tried to use clean Awesome WM, i thought that can i use awesome WM with GTK themes. I this possible?
I tried to run awesome, but got:
E: awesome: main:463: another window manager is already running
Also, clean Awesome WM works fine without Lubuntu. How to use awesome WM as a Window Manager in Lubuntu?
In some case, you can add --replace to replace the current window manager. LXDE defaults to OpenBox.
Some desktop environment also have settings to replace the window manager (in this case, by AwesomeWM). A quick googling seems to indicate some distribution store this setting in /etc/xdg/lxsession/LXDE/default.
However this is a bit of going in circle around the real issue here. Why run AwesomeWM in LXDE? Their feature set overlap at a rate of almost 100%. If you use lxde only for lxappearance (gtk theme mananger) and PCManFM, note that those 2 applications run just fine from the normal Awesome session. AwesomeWM itself provide the panel, wallpaper and window manager features, which leaves nothing from the original LXDE.
I use Conemu and Cygwin at home and at work, and I was trying to get the keyboard and highlighting to behave the same way in both places, so I imported my home Conemu settings file into my work Conemu, and now I've lost my ability to use Apps+PgDn/PgUp to scroll the backbuffer. Instead, when I press the Apps key, the mintty menu pops up.
How do I get that back?
I finally figured out that the problem is mintty.exe. I think they changed it in Windows 10 so the Apps/Menu key makes the context menu pop up, and there doesn't seem to be any way to disable that. I'm using Windows 8 at work and Windows 10 at home, hence the disparity.
If you just set your task to run bash.exe, everything seem to work fine.
Now that I figured it out, I can see why running mintty.exe in ConEmu doesn't make much sense, since they're kind of competing products, both designed to be better alternatives to cmd.exe.
There are only a couple of differences:
bash.exe has no way to specify an icon, but that easily fixed by putting /icon "C:\cygwin\Cygwin-Terminal.ico" (or whatever your cygwin icon path is) in ConEmu's task parameters.
The color scheme is also different, but appending -new_console:P:"<Standard VGA>" to the task command makes it the same as mintty.exe's (I want ConEmu to run Far Manager with the <Solarized> color scheme).
I would like to share with you this post as I wasted a lot of time to understand why the WS_EX_LAYERED flag did not work on a fresh install of Windows (my test was on a Win7, I don't know if it can be reproduced on a Win8 o.s.).
This was my code:
...
hParentWindow=hWnd;
HWND myWnd=CreateWindowEx(WS_EX_LAYERED|WS_EX_PALETTEWINDOW,_T("STATIC"),_T(""), WS_POPUP|SS_BITMAP,position.left,position.top, position.right, position.bottom,hWnd,NULL,hInst,NULL);
Then I wanted to add a transparent layer:
CWnd::FromHandle(myWnd)->SetLayeredWindowAttributes(RGB(0,0,0), 255*0.6, LWA_ALPHA);
Running the code, the window never appeared! And this was not a child window (the WS_EX_LAYERED does not work for a child window), so the WS_EX_LAYERED flag should have worked.
Why?
After spending almost a day in searching for the solution, I found that the target PC (the one that hosts the executable) had the Aero Peek theme disabled because it had never run the "Performance Information and Tools"!
So, IMHO, a programmer that is going to use the WS_EX_LAYERED in his code, must determine if the Aero Peek is turned on or not (for example by looking into the \HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM key registry and check the EnableAreoPeek registry value), otherwise some windows could not be shown correctly in any PCs.
Hope this makes you to save your time!
I have been through the same issues today (Rosario I feel your pain of 2 years ago!).
I couldn't work out why windows were disappearing completely. I'm sure others may end up at this page for the same reason.
As such I wanted to pick up on one point.
The key factor to this seems to be that "Desktop Window Manager Session Manager" service must be running for transparent layers to function.
That EnableAeroPeek registry value, which relates to whether you see a full-screen preview of the windows as you look through them (eg. with alt-TAB or hovering over task manager mini-previews), can remain off and it not connected to the availability of transparency in tests I have carried out on multiple machines.
Similarly, if that registry setting is on but the DWMSM service being off, it will not give you transparency.
Rosario I'm sorry to contradict your own answer to your own question, but I think it's an important distinction!
So far the only way to test for the availability of transparency on Windows 7 & later before making a call which fails (or turns a window invisible) seems to be by checking for a running dwm.exe process.
Goal: To display an application in the middle of the screen on a solid colour background. This means nothing else showing no gnome-desktop nothing apart from the application and the solid colour background.
Currently I'm using X11 for the background xstart -solid Grey which is great however as a test application I'm running firefox which I see has no window decorations ie: max, min title or boarder neither for that matter does xterm. I was wondering if it is possible to show the decorations without installing gnome possibly by installing just the themes eg: gnome-themes which I have done but have been unable to make the connection, or weather just running X isn't going to work without more gnome modules. I'm new to delving into the inner workings of linux as I've never had to deal with it before. I did ask a question previously which led me to xstart and xsetroot and I've been playing around with them for a bit trying to familiarise myself.
I do recognise that it is possible that I have gone about this all wrong, but if we don't try we don't learn.
If anyone knows of any tutorials or documentation that could help or if anyone has any tips I'd be grateful for the pointers.
Cheers
Chris
SOLUTION
Just thought I'd mention that I solved my issue after installing an ubuntu server distro I added xinit via apt-get then added metacity Then I edited the gconf files using gconf-editor then removed the Gnome-panels from /usr/bin However as I may possibly require them in the future I have made a copy of them before I deleted them. Thanks again for the help it was much appreciated.
The window decorations are created/managed by the window manager. If you don't have one running, you won't get window decorations.
Ok... I think I understand what you are asking. Gnome is a "Desktop", and includes with it one of many "Window Managers" called Metacity if I remember correctly. That is the part that adds the title and borders etc. There are many pure window managers(not desktops). A common and popular "Window Manager" is fluxbox although there are many others. Fluxbox does allow you to "undecroate" a window when you launch it. I'm not sure if this is what you are asking. Hopefully it is of some help.
I've recently started using GNU Screen but have run into a very annoying problem.
In any screen window if I press the left arrow key or backspace when there is nothing typed at the prompt the screen seems to refresh, causing a slight flicker. After typing some text at the prompt using the backspace or left arrow won't cause the flicker (at least until the first character in the prompt is reached).
Anyone seen this before?
That's not a problem. It's a feature. It's supposed to behave like that when "visual bell" is enabled in your terminal. Which it is, by default I guess.
Take a look at this document. There are three properties in the file that relates to visual bell. You can change that in ~/.screenrc
vbell_msg "bell: window ~%" # Message for visual bell
vbellwait 2 # Seconds to pause the screen for visual bell
vbell off # Turns visual bell off
Try setting vbell property to off.
Also, I would recommend you ask the same question in ServerFault. I am sure you'll get way better answers over there. To access the site, since it's in private beta, check this blog entry.