You are not logged in.
First, I want to preface this by saying I know nothing about programming, and I was looking for a project this morning and decided to go back to the old posts I made about Diablo II when it worked in goomwwm. It was working before Aug 13 but I had to go fullscreen to get my keyboard to function in the game. You made some changes on Aug 13--added your hack back for sdl apps-- and then I didn't need to go fullscreen. A few days later Diablo didn't work anymore and fullscreen clipped the Diablo edges. Looking at your commits on github, I noticed a misc fixes, Aug 17, where you did something to the client.c file dealing with fullscreen _NET_WM_STATE_FULLSCREEN--have no idea what it means--and Aug 19, I was complaining something was wrong with diablo and fullscreen. Just wondering if Aug. 17 misc fixes are responsible?? Nothing on Aug 19 commits seems to deal with fullscreen. Hope I'm not being too Spockish about this and I'm sure it's not that simple.
Edit: Sorry about my multiple posts, but it would have made a terribly long single one.
Last edited by bgc1954 (2012-09-02 20:16:39)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@bgc1954, interesting.
When you mentioned the problem, I suspected the far larger title bar commits from Aug17 were the likely culprit. I can't immediately see how the misc fixes commit would be the problem, but let me think it over...
Offline
Thx for indulging my suspicions. I leave it to your greater wisdom.
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
I've only just now started using multiple monitors with goomwwm. It works nicely except that there doesn't seem to be a way of moving windows between monitors using only the keyboard (I can drag them with the mouse and then everything works as expected, but being a mousephobe I'd like to be able to do this with keyboard commands).
EDIT: It looks like I can move windows from my main monitor to the second one using the keyboard move commands, but not the other way around.
Am I missing something, or is there currently no way to do this with only the keyboard?
About the new window borders - they work great! Fixed the VirtualBox glitches I also like the title bars. While I'm used to not having them from using Musca for so long (and there's Mod-w for those rare times when you need to see it), it is actually really handy to have them. But, two feature requests:
1. I'd like a way of showing/hiding title bars on the fly (globally is fine, but per window would be even better!), either through a "goomwwm -cli -borders" command or something I can bind to a key or a rule (being available in a ruleset is a must if this were per window, rather than global, of course). Basically, I like having the option of a title bar, but I also like not having a title bar but don't want to have to decide before goomwwm starts.
2. If I set the title bar to be any less than about 14 pixels high, the bottom of the text gets cut off. Would it be possible to be able to also set the font size?
Other than that, everything's looking good! Happily using goomwwm on a daily basis with no immediate plans of switching to anything else. :-P The "-cli restart" issue still happens, however, but it doesn't bother me that much because I only really use it after updating to the latest goomwwm version, which is now much less frequent than it was a few weeks ago and my .goomwwm has stopped being in flux too.
Last edited by dublindan (2012-09-07 14:01:33)
Offline
@dublindan
Windows should move between monitors the same way as they move on the 3x3 grid, with the mod+<arrows>. Just move a window to an edge between monitors and keep going... If one edge doesn't work, try the opposite; you might have your monitors physically reversed compared to the xrandr/xinerama order.
See -titlebarfont to set font size as with any Xft named font, and -titlebar on (rather than a pixel value) should make the bar height auto-adjust to match font.
Feature request noted.
Edit: hmm, I missed your edit If the window won't move back, could be a bug. Do you have anything on that edge, like a panel or conky?
Last edited by aerosuidae (2012-09-08 03:27:11)
Offline
@aerosuidae : I experience some bugs with mplayer/mplayer2 fullscreen settings. I do not see black borders but see part of the other clients below it. Is there a special setting to make mplayer client fullscreen ?
Thanks !
Offline
@aerosuidae:
I experience the same problem as Sirsurthur with mplayer. If I hit modkey+f my window expands to the edges on the top and two sides but the bottom is clipped--sorta like diablo except mplayer isn't changing resolution and its only on the bottom. I thought maybe it had to do with my oneline conky on the bottom but it does the same thing with no conky. Also, running with or without a titlebar makes no difference. I don't know if this will help but here's the xwininfo for mplayer in fullscreen. My native resolution is 1280x1024:
xwininfo: Window id: 0x1400002 "MPlayer"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 1280
Height: 960
Depth: 24
Visual: 0x22
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x1400001 (not installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -0+0 -0-64 +0-64
-geometry 1280x960+0+0
I also tried an ignore rule which made no diff
rule "name: MPlayer ignore"
Edit: I really like the -titlebarfont option. Now I can use my favorite terminus font. Thx.
Last edited by bgc1954 (2012-09-08 18:44:48)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
Hello,
According to man page:
Mod-Home
Toggle _NET_WM_STATE_MAXIMIXED_HORZ for the active window. Cor-
ners will flash to acknowledge.
Mod-End
Toggle _NET_WM_STATE_MAXIMIXED_VERT for the active window. Cor-
ners will flash to acknowledge.
Is it correct? If I press Mod-Home current window maximized vertically.
Offline
@yellowrabbit, docs error. Thanks for pointing it out.
@sirsurthur, @bgc1954, what happens if you use mplayer's built-in fullscreen toggle? Is this mplayer with or without GUI?
Last edited by aerosuidae (2012-09-10 03:25:39)
Offline
@aerosuidae - The clipped off bottom behavior happens in mplayer with no gui. Using mplayers fullscreen toggle makes no difference. If I run gnome-mplayer goomwwm's fullscreen and mplayer toggle both behave properly, but there is an artifact left on screen as gnome-mplayer goes fullscreen and the video shifts position--like a window in behind the running video. I'll have to check this out in other wm's as I don't remember if this happens there also.
Edit: Apparently the artifact with gnome-mplayer is happening on other wm's too so that's not goomwwm's fault. Both openbox and i3 have no problem running mplayer with no gui fullscreen, using either the wm's fullscreen key combo or toggling fullscreen with mplayers f key.
Last edited by bgc1954 (2012-09-10 12:44:09)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
I'm also experiencing the issue with mplayer2. mod + f results in mplayer only occupying a portion of the screen, but from here mplayer's built-in toggle causes it to fill the rest of the screen. Using the built-in toggle by itself works as expected.
Also, the default window created by love doesn't allow itself to be resized (i.e. program specified minimum and maximum size are both 800 by 600). This causes goomwwm's horizontal and vertical maximizing functions to break movement of the window in the grid.
mod + Home causes the window to be restricted to horizontal movement, and any attempt to move said window will cause it to jump to one of the spaces in the top row of the 3x3 grid.
mod + End acts similarly. It causes movement to be restricted to the vertical, and any attempt to move the window will cause it to move to one of the spaces in the leftmost column.
Pressing both mod + Home and mod + End will cause the next attempt to move the window using mod + any arrow key to move the window to the top left space in the grid, from where it cannot be moved.
Last edited by Supplantr (2012-09-10 22:17:58)
I use linux and I dont understand nothing in this post.
Offline
I've committed changes to partly fix the mplayer full screen problem. For the moment you may still need to use both goomwwm's mod-f to set mplayer full screen and then mplayer's own f toggle to get the video aspect right. There may be a smarter way for goomwwm to handle this so the second keystroke is not needed, but I'll have to do more research.
@Supplantr, The EWMH standard doesn't seem to specify now maximize horz/vert should be handled with windows that specify a maximum size. Are you thinking goomwwm should just ignore maxmize horz/vert for such windows?
Offline
Mplayer is behaving now with either the built-in toggle or mod+f in goomwwm. Gnome-mplayer is actually improved as there are no artifacts or background windows when using built in toggle. The artifact is still there with mod+f but as I said, the same happens in openbox and i3, so you actually improved it in goomwwm. Thx again.
Last edited by bgc1954 (2012-09-11 14:36:11)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@aerosuidae, that seems like a simple solution. I can also confirm that mplayer and fullscreen are now working appropriately. Thanks!
I use linux and I dont understand nothing in this post.
Offline
@aerosuidae : Indeed, issue with mplayer is gone ! Thanks a lot for that and for this very intersting wm ! I am looking forward to see the further development you will do on goomwwm !
Offline
Excellent, glad it works once more. I was trying to be too smart and broke mplayer
I'm working through some code clean-up atm. Current goomwwm-git will probably become v1.1, as is.
Offline
Just noticed some other games I have running in wine and they all display similair behavior--or worse--to Diablo 2. I know you hate wine but in order to not use windows I occasionally use wine for games and no other wm exhibits these behaviors so it is some kind of bug--although not likely one you care to spend time on. These other games play fine in goomwwm but if I hit mod+f the games disappear and an enlarged background appears.
Starcraft, for example, plays fullscreen already but if I hit mod+f the game disappears and any window that may have been behind it displays in a larger resolution or just the background, enlarged, if I have no other windows open. Hitting mod+f again returns the game but the screen can be shifted by moving the mouse to the edge of the screen--it's not locked in position. Another oldie but goodie, Star Castle, has this same behavior.
A simple poker game I play on occasion displays as a small window inside a full blue screen. It completely dies if I hit mod+f and you can't get it back.. All that you see is a little blue square in the upper left hand corner. You can see it as still running in htop but you have to kill it to get rid of the little square.
Just thought I'd mention it if you ever fall into like with wine.
Last edited by bgc1954 (2012-09-24 21:01:59)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@bgc1954, do all these games change the screen resolution on the fly when switching to full screen?
Offline
@aeroduidae:
As far as I can tell, it looks like they do change the resolution--just guessing, it looks like they go to 800x600 to run--since the background when I hit mod+f looks like diablo's resolution of 800x600. I can't telll since there is no window to click on for xwininfo as the game just disappears when going fullscreen and I get the enlarged background. But with the poker game I clicked on the little blue box in the upper left corner and it said:
xwininfo: Window id: 0x1c00004 "poker.exe - Wine desktop"
Absolute upper-left X: 0
Absolute upper-left Y: 0
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 16
Height: 16
Depth: 24
Visual: 0x21
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x1c00003 (not installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners: +0+0 -1264+0 -1264-1008 +0-1008
-geometry 16x16+0+0
which makes no sense to me but perhaps makes sense to you.
Thx for your attention to this as it is important to me only, AFAIK, but I really, reallly like goomwwm and this is the only small annoyance for only using it alone without having to revert to the other many, many other wm's that I have installed in Arch.
Edit: Just digging around some more and if I place a rule in .goomwwmrc
rule "name:poker.exe - Wine desktop ignore"
I can get the poker game back when going from mod+f and back with mod+f. I'm totally confused and too much wine--as in red--so hoping this sheds a tiny bit of light on this.
Last edited by bgc1954 (2012-09-25 03:46:38)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
More experimenting this AM brings more info--like you really want that.
I don't really need a rule for that poker game. I tried it again this AM without one and it still becomes a little blue square when using mod+f but comes back again with mod+f.
The Starcraft screen can be shifted by moving the mouse to the far right and bottom of the screen and there are blue squares in the top right, bottom right and bottom left of the enlarged screen. The screen locks into place once you click on it. The game plays natively fullscreen but if you hit mod+f the game disappears until you hit mod+f again.
Star Castle is an old style vector graphics game that is keyboard controlled. The screen will shift regardless of whether you click on it or not and there are no blue corner boxes, but once you click on it, the keyboard doesn't respond so you can't play and you have to kill it. Killing it with mod+esc kicks you out of X and back to my xdm login screen with enlarged resolution. The fact you can kill it with the goomwwm key combo shows that the game loses keyboard focus, I guess, once the mouse is clicked on the screen.
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
Eureka, I think I found it!
I've been playing around with some of your commits and rebuilding goomwwm over and over for the last week or so. It turns out that my wine problems disappear if I reverse your handle.c commit from Aug. 13 (hack still necessary) and rebuild after doing:
// special hack for fullscreen override_redirect windows (like SDL apps) that are stupid.
// ensure they get raised above the focused window once. after that they're on their own.
/*if (c && c->xattr.override_redirect && !c->cache->is_ours)
{
client_extended_data(c);
XRaiseWindow(display, c->window);
}*/
}
Now of course blockattack and flobopuyo don't play in fullscreen--they're not too bad in a windowed mode though--but all my wine apps behave themselves. It's a trade-off I can probably live with, if necessary. But the best part is I've learned a tiny bit about C. Takes me back to the old days when I goofed around with basic. I'm showing my age with that statement.
Note: Starcraft and star Castle still disappear if you hit mod+f and Diablo still gets clipped side and bottom, but they're already fullscreen when they start so I don't need to use mod+f anyway. And now I don't have any problem with keyboard or mouse stealing focus from one another in Diablo.
Last edited by bgc1954 (2012-09-25 18:49:38)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@bgc1954, interesting; so it's an either-or situation between wine and SDL, in full screen.
That hack for SDL has always bothered me. It suggests there is something I'm missing about working around override_redirect windows. It's apparently not enough to just leave them alone if a WM does anything unusual with stacking and tiling.
Thank you for pursuing this bug. It may not affect many people, but it's still worth squashing if we can...
Offline
Thank you for pursuing this bug. It may not affect many people, but it's still worth squashing if we can...
I don't know about the we part--I think it's more you. As far as coding goes, I'm a basic copy, paste and imitate kind of guy but I'm always willing to help troubleshoot.
Another tidbit of info, FWIW, I noticed while playing around with different wine games, they still can shift around on the screen until you click with the mouse. But before you click and focus on it the little blue squares in the far corners--off screen--are there, in Diablo's case the squares are red. I think goomwwm gets very confused when multiple windows are raised in different resolutions--as in Diablo--and I don't have a clue what or if anything can be done. Other wm's must ignore this behavior as their resizing doesn't go offscreen like in goomwwm. Your hack for SDL apps seems to work since sdl apps just seem to have either a fullscreen or windowed state, not multiple windows and intoductory screens. I feel like I'm just blathering now so I'll stop. Maybe goomwwm is still just trying to be too smart.
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@aerosuidae I am also not able to move windows across my multimonitor setup using just the keyboard.
I have three monitors running on two video cards, all configered in my xorg.conf like below.
"ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
Screen 2 "Screen2" RightOf "Screen1"
Screen 0 "Screen1" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "1"
EndSection
Screen 0 is 24 inch in landscape mode;
Screen 1 is 24 inch portrait mode;
Screen 2 is an 19 inch in landscape mode.
I cannot move windows from Screen 1 to Screen 2, but I can move across other screen jumps (even Screen 2 to 1).
BTW, I really like your window managers, musca was the first tiling WM I used a lot. I still use subtle on my laptop, but for my workstation goomwwm is it.
Productivity ++
P.S. Another feature request would be to be able to jump from window to window on a multihead setup across screens with the Mod + hjkl keys. Right now I think it only works on one monitor.
Offline
@ksira, would you mind sending xrandr output? Assuming you have the extension running. I know xinerama/xrandr are supposed to be mutually exclusive, but for example some drivers (like nvidia) seem to provide both protocols...
Are screen 1 and 2 on different video cards?
Moving the focus between monitors uses the same general logic as moving windows. Could be the same bug.
edit: clarification
Last edited by aerosuidae (2012-09-27 05:02:13)
Offline