gtk2hs: Request recalculation of windows size after removing a widget - haskell

I have a Window with three Entry widgets and one Button. I use the button to remove one of the widgets programmatically. The problem is that the main window doesn't change it's size to fit the new layout after it's been removed.
I can imagine that I need to send some Signal or Event to the main loop which would cause the recalculation but I've been unable to find such functionality.
Here is some example code:
import Graphics.UI.Gtk
import Data.IORef
import qualified Graphics.UI.Gtk as G hiding (Point)
import qualified Graphics.UI.Gtk.Gdk.EventM as E
import qualified Graphics.UI.Gtk.Abstract.Widget as W
import qualified Graphics.Rendering.Cairo as C
makeEntry :: String -> IO Entry
makeEntry str = do e <- entryNew
entrySetText e str
return e
main :: IO ()
main = do
initGUI
window <- windowNew
box <- vBoxNew False 0
G.on window G.keyPressEvent $ E.tryEvent $ do
"Escape" <- E.eventKeyName
C.liftIO $ G.widgetDestroy window
set window [ containerChild := box ]
e1 <- makeEntry "e1"
boxPackStart box e1 PackNatural 0
e2 <- makeEntry "e2"
boxPackStart box e2 PackNatural 0
e3 <- makeEntry "e3"
boxPackStart box e3 PackNatural 0
button <- buttonNew
set button [ buttonLabel := "Remove" ]
boxPackStart box button PackNatural 0
onClicked button (containerRemove box e2)
onDestroy window mainQuit
widgetShowAll window
mainGUI

You can ask your top-level window how big it wants to be, and make it be that big:
refresh window = do
Requisition w h <- widgetSizeRequest window
windowResize window w h
To use this, stick it in the button's click-handler:
onClicked button (containerRemove box e2 >> refresh window)

Related

Execute code beyond original screen view with Vim to R using GNU Screen

I'm using GNU Screen to send code from Vim to R with the following .vimrc configuration:
map <C-L> "kyy:echo system("screen -S $STY -p R -X stuff ".shellescape(#k))<CR>j
vmap <C-L> "xy:echo system("screen -S $STY -p R -X stuff ".shellescape(#x."\n"))<CR>j
(I use cntr-L to send code from Vim to my R window titled "R".)
I can run functions within the current screen,
exp_val <- function(roll){
vals <- numeric(length(roll))
vals[roll == "G"] <- 1/6
vals[roll == "Y"] <- 1/3
vals[roll == "R"] <- 1/2
sum(vals)
}
prob_choice <- function(roll, ng = 6, ny = 4, nr = 3){
tot <- ng + ny + nr
i <- c(ng,ny,nr)
col <- c("G","Y","R")
p1 <- i[col==roll[1]]/tot
i[col==roll[1]] <- i[col==roll[1]] - 1
p2 <- i[col==roll[2]]/(tot-1)
i[col==roll[2]] <- i[col==roll[2]] - 1
p3 <- i[col==roll[3]]/(tot-2)
p1*p2*p3
}
but when I try to scroll down and highlight another function that extends below the original screen view
single_round <- function(sampsp,probs=rep(1/nrow(sampsp),nrow(sampsp))){
r <- sample(1:nrow(sampsp),1,prob = probs)
dice <- sampsp[r,]
roll <- numeric(3)
i <- which(dice=="G"); roll[i] <- sample(c("B","S","F"),1,prob = c(1/2,1/6,1/3))
j <- which(dice=="Y"); roll[j] <- sample(c("B","S","F"),1,prob = c(1/3,1/3,1/3))
k <- which(dice=="R"); roll[k] <- sample(c("B","S","F"),1,prob = c(1/6,1/2,1/3))
num_dice <- c(length(i),length(j),length(k))
outcome <- c(sum(roll=="B"),sum(roll=="S"),sum(roll=="F"))
if (is.null(roll[i])){roll[i] <- 0}
if (is.null(roll[j])){roll[j] <- 0}
if (is.null(roll[k])){roll[k] <- 0}
feet <- c(sum(roll[i]=="F"),sum(roll[j]=="F"),sum(roll[k]=="F")) # to keep track of color of footprints
list(num_dice,outcome,feet)
}
I get the following error
X: stuff: one or two arguments required
Is there anything I can change in my .vimrc so I can highlight and execute a large part of the script that extends beyond the original screen view?

Haskell Gloss - Do something every frame key is pressed

I want to move an object in Haskell Gloss every frame a key is pressed, not just the one frame that the key is started being pressed. (Example: While 'w' key is pressed, accelerate object every frame)
Edit: I tried using the second parameter of EventKey but to no avail.
My code:
--TODO - Holding keys doesn't work yet
handleKeys :: Event -> AsteroidsGame -> AsteroidsGame
handleKeys (EventKey (Char char) _ _ _) game
| char == 'w' = move 0 1
| char == 'a' = move (-1) 0
| char == 's' = move 0 (-1)
| char == 'd' = move 1 0
where move x y = game {player = accelerateObject (player game) x y}
handleKeys _ game = game
accelerateObject :: Object -> Float -> Float -> Object
accelerateObject obj hor ver = obj {vel = (vx + hor, vy + ver)}
where (vx, vy) = vel obj
As OP correctly deduced, gloss gives you input events ("key was just pressed", "mouse was just moved"), rather than input state ("key is currently pressed", "mouse is at x,y"). There doesn't seem to be a built-in way to see input state on each frame, so we'll have to make our own workaround. Thankfully, this isn't too difficult!
For a simple working example, we'll make an incredibly fun "game" where you can watch a counter count upwards while the space bar is pressed. Riveting. This approach generalises to handling any key presses, so it'll be easy to extend to your case.
The first thing we need is our game state:
import qualified Data.Set as S
data World = World
{ keys :: S.Set Key
, counter :: Int }
We keep track of our specific game state (in this case just a counter), as well as state for our workaround (a set of pressed keys).
Handling input events just involves either adding a key to our set of currently pressed keys or removing it:
handleInput :: Event -> World -> World
handleInput (EventKey k Down _ _) world = world { keys = S.insert k (keys world)}
handleInput (EventKey k Up _ _) world = world { keys = S.delete k (keys world)}
handleInput _ world = world -- Ignore non-keypresses for simplicity
This can easily be extended to handle eg. mouse movement, by changing our World type to keep track of the last known coordinates of the cursor, and setting it in this function whenever we see an EventMotion event.
Our frame-to-frame world update function then uses the input state to update the specific game state:
update :: Float -> World -> World
update _ world
| S.member (SpecialKey KeySpace) (keys world) = world { counter = 1 + counter world }
| otherwise = world { counter = 0 }
If the spacebar is currently pressed (S.member (SpecialKey KeySpace) (keys world)), increment the counter - otherwise, reset it to 0. We don't care about how much time as elapsed between frames so we ignore the float argument.
Finally we can render our game and play it:
render :: World -> Picture
render = color white . text . show . counter
main :: IO ()
main = play display black 30 initWorld render handleInput update
where
display = InWindow "test" (800, 600) (0, 0)
initWorld = World S.empty 0

What would be a typical game skeleton in Haskell [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
What would be the typical game skeleton for a Haskell game, let's say a simple shoot them up for instance?
I am particularly interested on the data structure, and how to manage the update of all the elements in the world, in regards of immutability issue.
Just saying that
new_world=update_world(world)
is a little bit simplistic. For instance, how to deal with multiple interaction that can occurs between element of the world (collisions, reaction to player, etc....) especially when you have a lot of 'independent' elements impacted.
The main concern is about immutability of the world, which makes very difficult to update a "small" part of the world based on another subset of the world.
I love gloss (gloss 2D library. it's very closed to your needs (I think)
A very simple example
import Graphics.Gloss
import Graphics.Gloss.Interface.Pure.Game
-- Your app data
data App = App { mouseX :: Float
, mouseY :: Float
}
-- Draw world using your app data
-- Here thing about *draw* your world (e.g. if radius > MAX then red else blue)
drawWorld (App mousex mousey) = color white $ circle mousex
-- Handle input events and update your app data
-- Here thing about user interaction (e.g. when press button start jump!)
handleEvent
(EventMotion (x, y)) -- current viewport mouse coordinates
(App _ _) = App x y
handleEvent e w = w
-- Without input events you can update your world by time
-- Here thing about time (e.g. if jumping use `t` to compute new position)
handleTime t w = w
runApp =
play
( InWindow "Test" (300, 300) (0, 0) ) -- full screen or in window
black -- background color
20 -- frames per second
( App 0 0 ) -- your initial world
drawWorld -- how to draw the world?
handleEvent -- how app data is updated when IO events?
handleTime -- how app data is updated along the time?
-- enjoy!
main = runApp
One simple example modifying some data structure (a list of circle radius) along the three event handlers (draw, input and time)
import Graphics.Gloss
import Graphics.Gloss.Interface.Pure.Game
import System.IO.Unsafe
data App = App { mouseX :: Float
, mouseY :: Float
, circleList :: [Float]
, lastTime :: Float
, currTime :: Float
}
drawWorld app =
color white $ pictures $ map circle $ circleList app
handleEvent
(EventMotion (x, y)) -- current viewport mouse coordinates
app = app { mouseX = x, mouseY = y,
-- drop circles with radius > mouse **MOVED** position
circleList = filter (<(abs x)) $ circleList app }
handleEvent e app = app
handleTime t app =
app { currTime = currTime', lastTime = lastTime', circleList = circleList' }
where currTime' = currTime app + t
-- create new circle each 1 second
createNew = currTime' - lastTime app > 1
lastTime' = if createNew then currTime' else lastTime app
-- each step, increase all circle radius
circleList' = (if createNew then [0] else []) ++ map (+0.5) (circleList app)
runApp =
play
( InWindow "Test" (300, 300) (0, 0) )
black
20
( App 0 0 [] 0 0 )
drawWorld
handleEvent
handleTime
main = runApp
with result

Why is X library reporting wrong string length values?

I was trying to get the width of the string, using XTextWidth() function, but for some reason the returned value is always bigger than the actual displayed length of string. In the following example, the value printed out is 196, while if I measure the width on-screen, it's somewhere around 168 pixels (the following is compilable and runnable example):
import Control.Concurrent
import qualified Graphics.X11.Xlib as X
import qualified Graphics.X11.Xlib.Types as Xt
import qualified Graphics.X11.Types as Xt
main = do
display <- X.openDisplay ""
let dflt = X.defaultScreen display
border = X.blackPixel display dflt
background = X.whitePixel display dflt
rootw <- X.rootWindow display dflt
win <- X.createSimpleWindow display rootw 0 0 500 300 1 border background
X.mapWindow display win
X.moveWindow display win 0 0
updateScreen display win
updateScreen display win = do
gc <- X.createGC display win
bgcolor <- initColor display "white"
fgcolor <- initColor display "black"
X.setBackground display gc bgcolor
X.setForeground display gc fgcolor
font <- X.loadQueryFont display "-misc-fixed-*-*-*-*-14-*-*-*-*-*-*"
let str = "Some reasonably long string."
len = X.textWidth font str
putStrLn $ show len
X.drawImageString display win gc 0 50 str
X.freeFont display font
X.freeGC display gc
threadDelay 100000
updateScreen display win
initColor :: X.Display -> String -> IO X.Pixel
initColor dpy color = do
let colormap = X.defaultColormap dpy (X.defaultScreen dpy)
(apros,_) <- X.allocNamedColor dpy colormap color
return $ X.color_pixel apros
How can I fix it?
You are not displaying with the selected font. Try this:
X.setFont display gc $ X.fontFromFontStruct font

Haskell, Change drawing color on mouse click

I want to make a haskell program where some shape is drawn in a window. When I click inside the window the color of the shape should change.
I have come up with this:
testDemo points =
runGraphics $
do
w <- openWindow "Test" (480, 550)
colorRef <- newIORef Green
let
loop0 = do
color <- readIORef colorRef
e <- getWindowEvent w
case e of
Button {pt=pt, isDown=isDown}
| isDown && color == Green -> writeIORef colorRef Red
| isDown && color == Red -> writeIORef colorRef Green
_ -> return ()
color <- readIORef colorRef
drawInWindow w (withColor color (polyline points))
loop0
color <- readIORef colorRef
drawInWindow w (withColor color (polyline points))
loop0
It kinda works.
The problem is, that I think that a window event is triggered almost all the time, so everything is drawn all the time which makes it slow.
How could I make it so, that I only change the drawing when a click is registered?
First of all, getWindowEvent will block until the next event occurs, so everything is drawn only on event. If you think that a window event is triggered too often, then you can print events to the stdout to figure out what event is triggered and just ignore it (e.g. skip drawing on all the events except Button event).
BTW: you don't IORef, you can just pass the current color through the loop.
testDemo points =
runGraphics $
do
w <- openWindow "Test" (480, 550)
let
loop0 color = do
e <- getWindowEvent w
let newColor = case e of
Button {pt=pt, isDown=isDown}
| isDown && color == Green -> Red
| isDown && color == Red -> Green
_ -> color
when (newColor != color) (drawInWindow w (withColor color (polyline points)))
loop0 color
let color = Red
drawInWindow w (withColor color (polyline points))
loop0 color
(The code is not tested with the compiler, so...)
Thanks for the answer.
I modified the code slightly according to my understanding of what it should do.
testDemo points =
runGraphics $
do
w <- openWindow "Test" (480, 550)
let
loop0 color = do
e <- getWindowEvent w
let newColor = case e of
Button {pt=pt, isDown=isDown}
| isDown && color == Green -> Red
| isDown && color == Red -> Green
_ -> color
when (newColor /= color) (drawInWindow w (withColor newColor (polyline points)))
loop0 newColor
let color = Green
drawInWindow w (withColor color (polyline points))
loop0 color
The results are a bit sketchy though. Sometimes the color changes immediately and sometimes it takes a very long time. I believe it could be some update issue, because when I close a window I see an issued color-change happen just before the window is gone.
Any ideas?
It helps if I call clearWindow before I draw the new stuff. I don't really understand why. Does it schedule a redraw of the window maybe?
Would be nice to know, but in general the problem is solved for now.

Resources