You are not logged in.
@dublindan - I've committed changes to allow window swapping by direction. Using mod-shift-i/j/k/l by default. These currently rebind to match whatever four keys are used for focus switching.
Edit: Actually, this was a great idea Thanks for pushing for it. A slight extension to allow windows of different sizes to be swapped allows almost classic Musca swap behavior, all without a framset, and even makes it trivial to simulate a master/stack type tiling setup.
Last edited by aerosuidae (2012-07-16 14:39:04)
Offline
@aerosuidae: Sorry for the confusion. Indeed, -minimize v works just as you wrote; I can even do -minimize comma, and it works for both Mod-, and Mod-? (“?” is Shift+comma). So, it works for shifted key symbols – except if they involve the 0-9 keys (because they are bound already???). However, I cannot bind keysyms that are produced by pressing the AltGr modifier. For example, -minimize at (Mod-@ → Win+AltGr+V) does not work.
Offline
Well, I leave my netbook for awhile and now my urxvt terminal has no shading at all, even with .Xresources instead of .Xdefaults. I thought using the .Xresources fixed my shading but it turned out I hadn't deleted the .Xdefaults file and as soon as I did my urxvt had no settings for font, shading, tranparency, nada. I just did a new git build while crossing my fingers but doesn't seem to make any difference.
Also I just found out through a process of elimination that I can't use trayer if I want to play flobopuyo. If I have trayer running so I can use volwheel to adjust my volume setting, flobopuyo comes up as a black screen with a blue outlined box in it. Suggestions?
My .xinitrc file:
eval `cat ~/.fehbg`
setxkbmap -option terminate:ctrl_alt_bksp
#exec openbox-session
#exec i3
dzconky &
trayer --align right --transparent true --alpha 255 --widthtype request &
volwheel &
exec goomwwm
Edit: Any further thoughts on a mod+key combo for exiting goomwwm?
It seems I can use aterm and my shading settings are respected. I don't get it. When I first started using goomwwm, urxvt behaved normally but something has changed recently?
Last edited by bgc1954 (2012-07-16 19:53:08)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
Very cool, thanks! Works exactly how I hoped.
Besides the VirtualBox screen resize issue where the layout is lost (which, when I'm at home, I get around by maximizing the VirtualBox window on a second monitor and then never resizing it), goomwwm is really starting to shine as I can now use it almost like I used musca, only that the floating aspects actually make it more flexible.
I haven't looked into the new ruleset stuff yet. It'll probably take me a few days to really dig into it, but I'll give you feedback on it when I do. I didn't see a rule for minimizing a window - if this were added, I imagine rulesets could be used to simulate workspaces.
I also ran into the fact that you currently cannot map AltGr keys (personally, I had hoped to remap the cursor keys to Mod-AltGr-u/n/e/i (on qwerty that would be Mod-AltGr-i/j/k/l) which correspond to the following characters: úñéí. I tried mapping ntilde and uacute as well as ugrave, but none of these worked.
One more question - is it possible to bind keys to run external scripts like you could with musca? If you could bind a key to exec commands, for example.
Anyway, goomwwm has really taken shape and I now see it as a viable contender as my main WM. Keep up the amazing work!
Last edited by dublindan (2012-07-16 21:21:46)
Offline
@ma, @dublindan - I don't have an AltGr keyboard to debug with, so I may be of limited help here. Perhaps I can find an on-screen version somewhere... But, if AltGr is mapped to one of the five X11 built-in modifier masks (eg, Mod1Mask = Alt, Mod4Mask = Win/Meta) then we could add in a little hook to catch it for shifted keys. Try using xev to see which code and sym AltGr is sending?
@bgc1954 - Could well be a goomwwm change affecting your terminal shading via some side-effect, somewhere, but I can't suggest much on how to track it down. Technically, the window manager doesn't have anything to do with .Xdefaults/.Xresources. That is the job of xrdb; maybe it is not operating the way you think, on your netbook?
A guess: If you run trayer without transparency, does flobopuyo then work?
How about with a panel other than trayer, like lxpanel. Any change?
The quit key was added a while back, but I see that only -quit made it onto the man page. I'll fix that. Anyway, mod-pause pressed twice should now quit goomwwm. Alternatively:
goomwwm -cli -quit
@dublindan again: At present goomwwm doesn't have a mechanism to bind keys to external scripts, although you could get away with a lot using the -1 through -9 options. Otherwise, use xbindkeys
Offline
@aerosuidae: In my case ("hu" layout, 105-key Hungarian keyboard), AltGr has keycode 108, keysym 0xfe03 (ISO_Level3_Shift), and it is mapped to Mod5. AltGr is usually the group modifier, or whatever it is called in X11 jargon.
Last edited by ma (2012-07-17 08:05:33)
Offline
My AltGr is the same: state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift). My layout is gb variant of colemak.
If I press AltGr-u, I get ú: state 0x80, keycode 31 (keysym 0xfa, uacute), which is the same keycode as 'u' but different state and keysym. Seems that left control has state of 0x04 and mod4 has state of 0x40 - can the key state be used to detect AltGr?
Offline
Hello, I'm trying to use this nice clock with goomwwm:
https://jcs.org/notaweblog/2005/06/28/pixelclock/
https://github.com/jcs/pixelclock/blob/ … xelclock.c
Trouble is, I need to toogle _NET_WM_STATE_BELOW for a terminal or any window obscuring it in order to show. Is there any way to patch the program for some EWMH hints or something? Or maybe implement configurable corner padding in goomwwm, e.g. leave 3 pixels right?
Offline
@ma, @dublindan - I've committed some changes to make key binding more flexible. I would appreciate if you could test with your AltGr layouts. Each key binding can now take custom modifiers to override the default -modkey, eg minimize on alt-m:
goomwwm -minimize mod1-m
If your AltGr is mapped to mod5, then theoretically you should now be able to bind stuff to mod5 providing you know the correct X11 key name of the final shifted character... Good luck!
@sime - I'm not sure _NET_WM_STATE_BELOW is the best idea... that would force such windows to be below their peers as well as the pixelclock. But, you can set this on windows with mod-b.
IMHO that pixelclock software should be changed to act like a panel. Eg:
Stop being override-redirect and instead set _NET_WM_WINDOW_TYPE_DOCK.
Set _NET_WM_STRUT or _NET_WM_STRUT_PARTIAL to reserve screen-edge space.
Someone else asked for padding before. I'll dig around and see how many headaches it would cause.
Edit: Nope, I'm not going to do screen padding, sorry. It gets complex with multi-head support, and this sort of thing is the whole reason why EWMH hints exist On another note: It seems like that pixelclock should be able to be replicated using conky...
Last edited by aerosuidae (2012-07-17 12:55:37)
Offline
@sime - Here is a fork of pixelclock as an EWMH panel with struts: https://github.com/seanpringle/pixelclock
I like this general idea. I'll trial the clock myself
Offline
@aerosudiae: It took all morning but I think I've got everything sorted out on my netbook. My .Xdefaults/.Xresources problem with urxvt ended up being a video driver. There was some discussion here on the forums about whether to use xf86-video-intel-uxa or -sna with plain intel going by the wayside. Alot of opinions thought the -sna intel option was better unless you had problems as the -uxa was like the old driver so I was using the -sna. As soon as I switched over my urxvt shading problems disappeared. I kind of figured it had to be a video issue as my desktop, running nvidia, had none of these problems.
There is still a problem running flobopuyo with a system tray or panel but only if you set flobopuyo to run fullscreeen. It runs fine in a window on goomwwm. Funny that i3 had no problem with the intel-sna driver or fullscreen flobopuyo. Who knows why? Probably still a video driver issue as flobopuyo runs fine on my desktop fullscreen with a tray, etc.
Edit: While doing all my fiddling, I found out I don't really need a system tray after all. I'm using the netbook volume keys with xbindkeys which I prefer now so something good came out of this after all. Still enjoying goomwwm.
Last edited by bgc1954 (2012-07-17 18:40:48)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
@sime - Here is a fork of pixelclock as an EWMH panel with struts: https://github.com/seanpringle/pixelclock
Wow, thanks so much!
Offline
I started to use goomwwm, THANKS! This is an amazing concept, so far I shied away from tiling wm's, but this made me like the idea.
One problem: starting d1x-rebirth, d2x-rebirth or World of Padman in full screen freezes everything (black screen), I have to pkill the process in a console to gain back control. Supertuxkart works well.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
@SanskritFritz
Thanks for the bug report. I installed World of Padman and then learned more about SDL apps than I was ever planning too
Turns out SDL uses override_redirect, a brute force approach, for running full screen games on X11, then just assumes things will always turn out peachy. Not quite sure what those guys were thinking. AFAIK setting _NET_WM_STATE_FULLSCREEN would work just fine...
Anyway, mini rants aside, I've committed a small hack in goomwwm which allows WoP to run for me. Would appreciate if you could test this with the other games which I can't be bothered to install today
Last edited by aerosuidae (2012-07-18 05:39:27)
Offline
If your AltGr is mapped to mod5, then theoretically you should now be able to bind stuff to mod5 providing you know the correct X11 key name of the final shifted character... Good luck!
Thanks a lot, it works! But it looks like you have to bind to the unshifted symbol. So if I want to bind an action to Win+@ (Win+AltGr+V), then instead of
goomwwm -minimize mod4-mod5-at
I have to use
goomwwm -minimize mod4-mod5-v
Which I do not mind at all. I can even bind to Win+/ now:
goomwwm -minimize mod4-shift-6
By the way, it looks like there can only be one whitespace character between an option and its argument in ~/.goomwwmrc. It took me a while to figure out why some of my bindings were not working…
Last edited by ma (2012-07-18 08:05:00)
Offline
By the way, it looks like there can only be one whitespace character between an option and its argument in ~/.goomwwmrc. It took me a while to figure out why some of my bindings were not working…
Bug! Thanks. Fix committed.
Offline
Hi! I'm currently an xmonad user, but I'm really excited about possibly switching to goomwwm.
I've been running goomwwm in a separate X server for the past few days (and updating the package each morning), but I'm having some issues that are keeping me from taking the plunge. Apologies if I'm misunderstanding something or if I've missed the solution in this thread or the docs. I'm running an nvidia laptop with an external display, and the problems seem the same with or without the external display enabled.
Here is an example scenario that I've tried with urxvt, xterm, and gnome-terminal:
When I launch any of the three terminals on a blank screen, the foreground of the terminal does not display until I resize.
If I then press mod-enter, with xterm or urxvt the terminal fills the screen as it should, but only the top and left borders seem to align correctly. The right and bottom edges of the window seem to align to the edges of the screen so that the borders are off the screen. With gnome-terminal the terminal enlarges to fill most of the screen, but it leaves a little bit of space around the bottom and right edges. All the terminals seem to update their contents once at this point, in that I can see any keys I pressed before maximizing, but subsequent interactions do not refresh the display.
Pressing mod-enter again brings xterm and urxvt more or less back to their original size, again refreshing the contents only once. Both terminals lose their borders, and xterm displays a black artifact on the right and bottom edges that seems to be twice the width of the border.
With gnome-terminal, subsequent presses of mod-enter toggle it between various states that fill most or all of the screen. (It never returns to its original size).
Offline
@mikezackles
Wow, that sounds impressively broken somewhere Questions follow. Sorry if I've misunderstood your post anywhere...
When the borders are off the screen, how far do you think it is? Just the width of the border itself, or a long way? I ask because borders are intended to disappear when a window is full screen. Note also that gnome-terminal resizes itself to a multiple of its font size (fixed cols/rows) and will often have small gaps on its right and bottom edges.
Just to confirm: by separate X server you mean on another tty and different DISPLAY? Does the same thing occur with just one X instance and goomwwm running on the box? What about when running something like dwm in the second X instance; is that similarly broken or seems ok? What about running goomwwm in Xephyr instead; any difference then?
Windows not refreshing is definitely sounding bug-like. Are non-terminals similarly affected, eg Firefox? Are you running the nvidia proprietary drivers, or plain old nv?
Also, can you please collect the following diagnostic info from the second X instance, while the terminal(s) are open and the problems are occurring:
xrandr
wmctrl -d
wmctrl -lG
Edit: You mentioned mod-enter, which always tries to expand (it's not really a toggle, even though it often works that way). Try mod-pageup and mod-pagedown too, to see how they behave.
Last edited by aerosuidae (2012-07-18 14:18:56)
Offline
@aerosuidae - What ever you did for SanskritFritz fixed it so I can now play flobopuyo in fullscreen on my netbook with goomwwm. Thanks aerosuidae.
Last edited by bgc1954 (2012-07-18 15:24:17)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
Here's some of the requested info. I'll get back to you with the rest. Sorry if there's any X stuff I'm misunderstanding.
Are you running the nvidia proprietary drivers, or plain old nv?
I'm running the proprietary nvidia drivers.
xrandr
Screen 0: minimum 8 x 8, current 3200 x 1200, maximum 8192 x 8192
LVDS-0 connected 1280x800+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
1280x800 60.2*+
DP-0 connected 1920x1200+1280+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
1600x1200 60.0
1280x1024 75.0 60.0
1280x960 60.0
1152x864 75.0
1024x768 75.0 70.1 60.0
800x600 75.0 72.2 60.3 56.2
640x480 75.0 72.8 59.9
DP-1 disconnected (normal left inverted right x axis y axis)
wmctrl -d
0 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
1 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
2 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
3 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
4 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
5 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
6 * DG: 3200x1200 VP: 0,0 WA: 0,0 3200x1200 N/A
7 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
8 - DG: 3200x1200 VP: N/A WA: 0,0 3200x1200 N/A
wmctrl -lG
0x00c00007 0 3994 834 672 385 booky Urxvt
Just to confirm: by separate X server you mean on another tty and different DISPLAY?
Unless I'm mixed up I think that's correct. My .xinitrc is set up to take the wm as a command line parameter, so with xmonad running on display :0 on tty7 I'm running
xinit goomwwm -- :1
on tty2 which launches the X server on tty8.
Does the same thing occur with just one X instance and goomwwm running on the box? What about when running something like dwm in the second X instance; is that similarly broken or seems ok? What about running goomwwm in Xephyr instead; any difference then?
If I launch xmonad as above using xinit xmonad -- :1 it works normally. I'll get back to you about Xephyr and running goomwwm by default. I'll try dwm too for good measure.
When the borders are off the screen, how far do you think it is? Just the width of the border itself, or a long way?
Unfortunately it is difficult for me to tell how far offscreen the borders are since I can't see the result of interactions with the terminal. That does remind me that before several days ago hitting mod-enter would actually resize to the entire 3200x1200 virtual screen size (not sure if that's the correct term in X parlance). So maybe it's trying to use the entire virtual screen size instead of just that monitor?
Note also that gnome-terminal resizes itself to a multiple of its font size (fixed cols/rows) and will often have small gaps on its right and bottom edges.
With gnome-terminal I can sometimes see grey in the extra space as though it's trying to pad itself, and sometimes I just see through to the background.
Try mod-pageup and mod-pagedown too, to see how they behave.
These work (I assume) normally until it gets to full size, but at full size I get the same behavior as though I hit mod-enter.
Are non-terminals similarly affected, eg Firefox?
Yes. Firefox draws its scrollbars and content at the same size it was before expanding in the upper left corner, and the rest of the screen is grey.
edit:
Duh, here's the wmctrl -lG output with a fullscreen urxvt that's exhibiting the problems we've been talking about:
0x00c00007 0 2560 0 1920 1200 booky Urxvt
So I guess it's not using the entire virtual screen size.
edit2:
Should that 2560 be a 1280?
Last edited by mikezackles (2012-07-18 16:32:53)
Offline
Here's a fullscreen urxvt on the other monitor (same issues on both monitors, by the way):
wmctrl -lG
0x00c00007 0 0 0 1280 800 booky Urxvt
Offline
dwm seems to work fine on display :1. I can spawn terminals and switch between them with no refresh issues. There are some gaps at the bottom of the screen beneath the terminals, but I'm guessing it's just the resizehints setting. I haven't been able to get Xephyr to work yet.
Offline
Just fyi, I did a little fiddling with the source, and this
diff --git a/handle.c b/handle.c
index 4249ca1..732b673 100644
--- a/handle.c
+++ b/handle.c
@@ -694,8 +694,8 @@ void handle_mapnotify(XEvent *ev)
ewmh_client_list();
// some gtk windows see to need an extra kick to make them respect expose events...
// something to do with the configurerequest step? this little nudge makes it all work :-|
- XSetWindowBorderWidth(display, c->window, 0);
- XSetWindowBorderWidth(display, c->window, config_border_width);
+ //XSetWindowBorderWidth(display, c->window, 0);
+ //XSetWindowBorderWidth(display, c->window, config_border_width);
winlist_forget(windows_minimized, c->window);
c->cache->has_mapped = 1;
}
makes the initial window contents visible.
Setting the border width to zero seems to make everything work as expected so far, with or without the above patch.
Let me know if I'm spamming this thread
Offline
@SanskritFritz
Thanks for the bug report. I installed World of Padman and then learned more about SDL apps than I was ever planning too
Turns out SDL uses override_redirect, a brute force approach, for running full screen games on X11, then just assumes things will always turn out peachy. Not quite sure what those guys were thinking. AFAIK setting _NET_WM_STATE_FULLSCREEN would work just fine...
Anyway, mini rants aside, I've committed a small hack in goomwwm which allows WoP to run for me. Would appreciate if you could test this with the other games which I can't be bothered to install today
Works well now, thank you aerosuidae.
zʇıɹɟʇıɹʞsuɐs AUR || Cycling in Budapest with a helmet camera || Revised log levels proposal: "FYI" "WTF" and "OMG" (John Barnette)
Offline
So it's seeming to me like my issue happens every time XSetWindowBorderWidth is called with a width of 0. Swapping out for XConfigureWindow doesn't seem to help.
Offline