Given this sample myManageHook. How can I call UpdatePointer after doIgnore? All my tries resulted in type incompatibilities.
myManageHook = composeAll . concat $
[
-- IntelliJ idea Tweaks
-- Manage idea completion window
, [ appName =? "sun-awt-X11-XWindowPeer" <&&> className =? "jetbrains-idea" --> doIgnore ]
, [ (className ~=? "jetbrains-") <&&> (title ~=? "Changes in") --> unfloat ]
]
where
unfloat = ask >>= doF . W.sink
My problem is that IntelliJ Idea popup window loses focus during typing if my mouse pointer is located over suggestions dropbox. That's why I'm trying to move the mouse to an upper part of the screen when this window appears.
UPD Found related thread with workarounds for Idea https://youtrack.jetbrains.com/issue/IDEA-112015#comment=27-2362253
You can use liftX to turn an X action into a Query action. You probably want to use XMonad.Actions.Warp instead of X.A.UpdatePointer instead, though; the latter looks like it might do a bit too much magic to sensibly fire during a manage hook. Anyway you should be able to try that out yourself once you see how to lift X actions.
So, for banish, you could use liftX like this:
... --> (liftX (banish UpperLeft) >> doIgnore)
Other X actions can be lifted and sequenced with doIgnore similarly.
Related
I am hoping that you folks can help me as I am new to Haskell and Haskell-fu is rather weak.
I am trying to create a quake-like terminal that drops down when called upon. For the most part I figured that storing a named urxvt terminal in layout managed by a simpleDrawer (XMonad.Layout.Drawer) works well for this. What I am having a problem with is binding a key to it so that it will pop up on whatever workspace I happen to be in.
The bringSelected option doesn't work for me as I do not want to have to deal with the grid menu. What I have tried that has gotten me the closest is:
raiseMaybe (spawnHere "urxvt -name drawer") (resource =? "drawer")
And:
ifWindows (resource =? "drawer") (mapM_ focus) (spawn "urxvt -name drawer")
The problem is that both essentially do the same thing in that instead of bringing said window (with resource =? "drawer") to my current workspace, it shifts me away from my current workspace to wherever it was last invoked.
Ideally I am looking for something along the lines of:
ifWindows (resource =? "drawer") ({- bring window to current workspace -})
(spawnHere "urxvt -name drawer")
Going over the contrib docs it seems that I am trying to reinvent the wheel as I can just easily use scratchpad. That should do the trick.
But...if anyone has any ideas regarding the question above, i.e. using ifWindows to pull another window from one workspace to another I would love to know how you went about it.
Added the following myKeys:
, ("M-`", scratchpadSpawnActionTerminal myScratchTerm)
Defined the ManageHook:
myScratchPadHook :: ManageHook
myScratchPadHook =
scratchpadManageHook (W.RationalRect fLeft fTop tRight fBottom)
where
fLeft = 0.0
fTop = 0.75
tRight = 1.0
fBottom = 0.25
and added
<+> myScratchPadHook
UPDATE
I have simplified the demonstration of this with an actual project created from the scaffold - you can check it out here: https://github.com/tetigi/yesod-bug-test
Follow the README to set up the repo and replicate the issue! Thanks :)
ORIGINAL POST
I've recently been trying to create a simple website using yesod - in one particular handler, it makes a couple of runDB calls (selecting and inserting some values into a ~200 item DB). However, on medium load, such as reloading the page rapidly in a browser, the page starts to hang.
Doing some debugging, I found that it seems the yesod app is not releasing the connections to the DB pool in a timely fashion and ends up waiting for them to release. To correborate this, I found the other following things:
Reducing the DB pool to 2 gave me a freeze after only a couple of clicks
The default (10) froze after about 5 seconds of clicking
Increasing the DB pool to 100 gave me a much longer click period, up to about 10-15 seconds of rapid clicking
The issue is the same whether I'm using postgres or sqlite
In postgres, it was possible to see the 'COMMIT' transactions stacking up over time
These transactions would eventually dissappear over time and the website would be responsive again
Is there something I'm missing here? The webpage does not do anything complicated, as the snippet below will show. Any ideas? As it stands, the website will be unuseable for multiple users until I find a way to fix this!
I'm using the standard scaffolded yesod application via stack as is recommended in the documentation.
Cheers!
Luke
Example handler code (abridged)
getCompareR :: Handler Html
getCompareR = do
-- Get all entities from the db. Throws error if < 2 elems in the DB.
entities <- fmap (\xs -> assert (length xs >= 2) xs) $ runDB $ selectList [] []
-- Pick an entity at random
Entity _ thisThingEntity <- liftIO $ runRVar (choice entities) DevRandom
-- Pull out everything NOT the thing we just picked
otherEntities <- runDB $ selectList [ComparisonHash !=. (comparisonHash thisThingEntity)] []
-- Pick one at random
Entity _ thatThingEntity <- liftIO $ runRVar (choice otherEntities) DevRandom
-- Some stuff including some inserts
-- ...
-- ...
runDB $ sequence [update thisId [ComparisonElo =. thisElo], update thatId [ComparisonElo =. thatElo]]
-- Start laying out the webpage
defaultLayout $ do
-- Fill in the rest with compare.hamlet
$(widgetFile "compare")
The issue lies within Data.Random - replacing the choice call with something like:
import System.Random (randomRIO)
...
-- Pick an entity at random
randomInt1 <- liftIO $ randomRIO (0, length entities -1)
let Entity _ thisThingEntity = entities !! randomInt1
Fixed everything and we no longer get slow down. Not really sure why Data.Random is doing this, but at least it works now!
Another interesting thing to note - the issue is NOT present on Mac OS X, only on Linux flavours (CentOS, Arch, Ubuntu being the ones we tried)
my question should be a piece of cake for anyone a bit learned in Haskell:
I would like to use the dwm-like multihead-setup: each physical screen gets it's own set of workspaces. No automatic swapping of windows or focus or whatsoever.
This is provided by the extension XMonad.Layout.IndependentScreens (http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IndependentScreens.html) which works fine.
But I would equally like to use the cycling function provided by XMonad.Actions.CycleWS (http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-CycleWS.html) which works equally fine (by itself).
As it is, when I cycle through the workspaces, it goes: Screen1 WS1 <--> Screen2 WS1 <--> Screen1 WS2 <--> Screen2 WS2 etc.
The cycling function would have to be wrapped in a independent-layout-function i guess. As I said, this is probably extremely simple, but I know little of Haskell and couldn't figure it out.
Both of the extensions are well documented, so this should be a simple one for some of you guys.
Thanks for helping!
I guess the main trick is to build a WSType which informs CycleWS that you're only interested in physical workspaces that appear on the same screen as the current physical workspace. Here's how you would do that.
isOnScreen :: ScreenId -> WindowSpace -> Bool
isOnScreen s ws = s == unmarshallS (tag ws)
currentScreen :: X ScreenId
currentScreen = gets (screen . current . windowset)
spacesOnCurrentScreen :: WSType
spacesOnCurrentScreen = WSIs (isOnScreen <$> currentScreen)
Then you can use spacesOnCurrentScreen in keybindings something like this:
, ((modM, xK_whatever ), moveTo Next spacesOnCurrentScreen)
, ((modM, xK_whatever2), shiftTo Next spacesOnCurrentScreen)
I haven't tested it, but it typechecks at least. ;-)
I want to write small script with simple GUI using Rscript or littler.
In the example I use gWidget2RGtk2.
For example, helloworld.R
#!/usr/bin/r
library(gWidgets2RGtk2)
W <- gwindow("Window", visible=FALSE)
L <- glabel("Hello World!", container=W)
visible(W) <- TRUE
This works well if it run in a R session, but get an error when it run from shell:
Error in UseMethod(".gwindow") :
no applicable method for '.gwindow' applied to an object of class "NULL"
In the case of graphics, I know that is required X11() before use plot().
Is possible fix this script to allow render widgets from shell?
(I only need run the script on linux machine)
EDIT: This is an example that works well on Linux. (includes suggestions received in the answer and comment.)
#!/usr/bin/r
require(RGtk2) # required for gtkMain()
require(gWidgets2)
options(guiToolkit="RGtk2")
W <- gwindow("Window", visible=FALSE,
handler = function(h, ...) {
gtkMainQuit() # stop main loop when windows is closed.
}
)
L <- glabel("Hello Word!", container=W)
visible(W) <- TRUE
gtkMain() # start main loop to keep the script alive.
Yes, I have done that in the past. You have to make sure you have a GUI event loop running to keep the app alive by waiting.
Using GHC, on Ubuntu 13.10, iNotify works-
import Control.Concurrent
import System.INotify
main = do
n <- initINotify
addWatch n [Modify] "/home/fred/" $ \event -> do
putStrLn $ "file changed: " ++ show event
threadDelay 10000000
and GTK2HS works-
import Graphics.UI.Gtk
main = do
initGUI
{-Add your widgets here.... or don't, the bug appears either way.-}
mainGUI
But if I put the two together, inotify never triggers. (it compiles and runs though....)
main = do
n <- initINotify
addWatch n [Modify] "/home/fred/" $ \event -> do
putStrLn $ "file changed: " ++ show event
initGUI
mainGUI
I've tried putting the inotify and GTK stuff in separate threads, it made no difference. I suspect something like a signal collision between the libs....
Oh, and in case it matters, I am trying to build a small tool that runs in the background, watches for file changes, and displays some info in the application indicator when this happens.
Note-
To trigger iNotify, just create or modify a file in the directory given in addWatch....
echo "abcd" > /home/fred/aFile
touch doesn't seem to work.
Compile (actually, technically, link) with -threaded. This way the inotify thread will be evacuated from the main execution context before the mainGUI loop goes into C-land and stops cooperatively switching to the GHC runtime. More details on multi-threading and gtk are available at this post I wrote a while ago.