I decided to try Xmonad today and installed it on VM with Arch linux. Without spacing it works perfectly, but when I am adding it, Xmonad only show one newest window on screen (if I open new window, old one just disappear).
There is my simple configuration I made using information from there:
import XMonad
import Xmonad.Layout.Spacing
main :: IO ()
main = xmonad $ def
{ layoutHook = spacingWithEdge 10 $ Full
}
Sorry if I am being dumb. This is my first time using Xmonad and Haskell.
Your configuration replaces the default layoutHook with one that only makes the Full layout available. Changing the relevant line to...
{ layoutHook = spacingWithEdge 10 $ layoutHook def
... should add the spacing while keeping all the default layouts available. Note that:
You can switch between the available layouts, with the default key binding being Alt + Space; and
You can switch the focused window, even while using the Full layout, with the default key binding being Alt + Tab.
Related
I use a layout with avoidStruts so that I can bind key
((myModMask, xK_b), sendMessage ToggleStruts)
to hide the xmobar toolbar.
Now I have a strange behaviour:
When restarting XMonad with "mod-q", XMobar in a GNOME
session gets hidden behind the background window
and doesnt come up again. ToggleStruts still seems to
works though, only that only the background is visible where
the XMobar should be.
Here are my config files:
https://github.com/eiselekd/dotfiles/blob/master/.xmonad/xmonad.hs
Is there any easy workaround? Maybe send the background window behind the XMobar again...
I know that there are the XMobar options
overrideRedirect = False
lowerOnStart = False
however whilst XMobar is visible on startup when these
options are added, the XMobar window is suddenly not hidden by ToggleStruts
any more. So I dont want to use these.
Another possibility that I tried and that is working is to spawn in the StartupHook
xdotool windowraise `xdotool search --all --name xmobar`
to raise XMobar via xdotool, however I would like to know a
XMonad/Haskell command instead.
I've just converted my application from Qt to Gtk. It all works except that although it opens the initial window fullscreen with all three buttons (- [ ] X) on my desktop (1280/1024), when I check it on my laptop (1280/800), the window's too tall, and worse, the header bar is missing the [ ] button. I've tried various things in Glade, and self.window.maximize/fullscreen without effect.
I need to ensure that the window doesn't open larger than the screen and doesn't lose any decorations.
Ubuntu 15.10 MATE/Glade 3.18.3/GTK3+/Python3.4.
I'm trying to make a simple app in Haskell using GTK3 and WebKit. This code creates and shows a window containing a WebView inside, which displays a random number each time a key gets pressed.
import Control.Monad.Trans (lift)
import Control.Concurrent (forkOS)
import System.Random (randomIO)
import Graphics.UI.Gtk -- gtk3
import Graphics.UI.Gtk.WebKit.WebView -- webkitgtk3
main = forkOS $ do
-- Init GTK.
initGUI
-- Create a window which would finish the GTK loop
-- after being closed.
window <- windowNew
window `after` objectDestroy $
mainQuit
-- Create a WebView inside.
webView <- webViewNew
set window [containerChild := webView]
-- Make the WebView display a random number on key press.
webView `on` keyReleaseEvent $ lift $ do
x <- randomIO :: IO Int
webViewLoadString webView (show x) Nothing Nothing ""
return True
-- Run GTK.
widgetShowAll window
mainGUI
When I run it in GHCi (7.8.3), it works fine. However, when I run it again without quitting GHCi, the WebView never shows anything – just plain white area. This is upsetting, as I like to tinker with code in GHCi.
Of course, everything works just fine if I don't use forkOS and run the whole thing in the main thread. What's the reason for this limitation (I thought all GTK functions considered the “main” thread to be the one in which initGUI was called), and can it be overcome somehow?
If it works like python(I don't know haskell) you should keep the gtk main loop in the main thread.
In your second thread call g_idle_add with a callback to make changes with gtk, and transport data between your second thread, and gtk. You should start your non-main thread before gtk main so it's not blocked.
I'm sure there is a binding of g_idle_add in haskell. There is also g_timeout_add which works for this too.
This all has something to do with gtk not being thread safe.
I have a full screen application based on Qt. Full screen applications should always be on top because otherwise part of the window will be obstructed. I want the frameless full screen window to have child windows (special dialogs, ..). These child windows should be shown on top of the full screen window. Not much sense in showing them below.
A short, self contained example is:
from PySide import QtGui, QtCore
app = QtGui.QApplication([])
window = QtGui.QWidget(f=QtCore.Qt.WindowStaysOnTopHint)
child_window = QtGui.QWidget(window, f=QtCore.Qt.Window)
child_window.resize(400, 300)
layout = QtGui.QVBoxLayout(window)
exit = QtGui.QPushButton('Exit')
exit.clicked.connect(app.exit)
layout.addWidget(exit)
create = QtGui.QPushButton('Create child window')
create.clicked.connect(child_window.show)
layout.addWidget(create)
layout.addStretch()
window.showFullScreen()
app.exec_()
It's written in Python and tested on Python 3.X + PySide 1.2.2 (Qt 4.8) + Ubuntu 14.04 (Unity desktop) or Windows 7. However transformation to C++ Qt (or PyQt) should be straightforward.
The observation is that on Windows everything is as described at the beginning. The Qt.WindowsStaysOnTopHint is not necessary, while on Ubuntu it is.
On Ubuntu I see that initially the full screen main window is on top of everything but as soon as a child dialog window is created the usual desktop decorations (top and left bars) are shown above the full screen main window obstructing part of the view! As soon as the child window is closed the full screen window is on top again.
Question is now if there is anything that can be done to have a full screen window which is on top plus child windows on Ubuntu and with Qt?
The different behavior between Windows and Linux is also not satisfying because OS specific code should be avoided if possible.
Later:
Using the overview of available desktop environment on Ubuntu I installed several environments and tested them.
KDE, Lubuntu (Lxde?) and Openbox work as expected (and equally to Windows). The main window stays on top when shown full screen and child windows are displayed above.
However for Gnome-Shell (Gnome 3), Xfce, Unity and Awesome the desktop decoration stays on top of full screen mode windows of children windows are displayed also. Xfce and Unity behave exactly equal, Gnome and Awesome have even some small additional problems.
Did you tried thing which documentation suggests?
Qt::WindowStaysOnTopHint 0x00040000 Informs the window system that the window should stay on top of all other windows. Note that on
some window managers on X11 you also have to pass
Qt::X11BypassWindowManagerHint for this flag to work correctly.
Another thing why you want other window to be a child if it you what to be under a parent?
I am using xmonad (with minimal configuration, main = xmonad gnomeConfig{ modMask = mod4Mask, terminal = "gnome-terminal" }) and my computer has two monitors and I am using xinerama.
This works, but way too often I am surprised by the mapping of xmonad screens to monitors,
when pushing a window to a screen (shift-mod-N) or moving focus to a screen (mod-N).
Also, mate-panel shows window symbols on virtual screens symbols - but something is not right there (these virtual screen seem to have double width, I guess because it's one X screen)
What is the right mental model for this?
(Is there a magic key that shows the screen number of the current (focused) window?)
NOTE (suggested by answers below): in xmonad lingo, a window is on a workspace, and a workspace is mapped to a (physical) screen.
The XMonad.Actions.PhysicalScreens documentation says the following:
This module allows you name Xinerama screens from XMonad using their
physical location relative to each other (as reported by Xinerama),
rather than their ScreenID s, which are arbitrarily determined by your
X server and graphics hardware.
Screens are ordered by the upper-left-most corner, from top-to-bottom
and then left-to-right.
I believe that "physical location relative to each other" refers to the layout specified by the ServerLayout section of Xinerama's configuration file. I am doing a bit of guesswork here, as I am not very familiar with Xinerama, but it seems that module can help with the issue of unpredictable screen numbers.
Here is a copy of my answer from here. I will preface it by giving a terminology clarification: what you call "screen" is called a "workspace" in xmonad parlance, and what you call "monitor" is called a "screen".
By default, this is what happens:
There are 10 distinct workspaces, numbered 1-10.
Each screen is assigned one of the ten workspaces.
There are two ways to navigate: you can choose to focus a particular screen (via mod+w,e,r) or to focus a particular workspace (mod+1,2,...,0).
If you focus a particular screen, the assignment of screens to workspaces does not change, but the selected screen gets input focus.
If you focus a particular workspace, and that workspace is not currently visible on one of the screens, then the currently focused screen has its mapping changed to that workspace.
If you focus a particular workspace, and that workspace is currently visible on one of the screens, then the currently focused screen and the screen showing that workspace have their mappings swapped.
There's two common ways of tweaking this behavior. One way is to change case (6) to keep the mapping as is, but change input focus to the screen that is showing the workspace you selected. See view. The other way is to change (1) and (3) in tandem: create (10 * number of screens) workspaces, and arrange for the mod+1,2,...,0 keybindings to choose which workspace to jump to based on both which key you pressed and which screen is currently focused. The result of this modification is to create the illusion that each screen has an independent set of workspaces that never interfere with each other -- rendering case (6), the confusing case, impossible. See IndependentScreens.