You are not logged in.
@dsr - Thanks for the feedback. I've added a small fix to catch mouse move/resize with -prefix.
Offline
It works now. Thanks again!
Offline
With keyboard edge-snapping added, goomwwm is now feature complete based on my original vague ideas
So, shortly I will tag a version 1.0 and focus on bug-fixing and expanding the tutorial.
Offline
Can we have window hiding please? (Perhaps just select them in the window selector to map again.)
Last edited by chneukirchen (2012-07-13 16:03:45)
Offline
@chneukirchen - Ah yes, that request fell off my list at some stage, sorry.
I've just committed changes to allow window minimization. See Mod-/ and -minimize. Select from the window switcher to restore, as you suggested.
Offline
Hi aerosuidae, good to see you're active again!
You may (or may not) remember me from the #musca irc channel. Been a long time musca user - from early (February if my memory is correct) 2009 until March of this year! I'm now eagerly awaiting musca 2 and in the meantime am playing with goomwwm. I like it so far.
So, first I noticed a bug on my install (using what was in git yesterday - have not installed todays changes yet). Sometimes when I navigate using ijkl more than one window has the focus border. Not sure how to reproduce it yet, but I'll let you know if I notice any patterns.
Second, a feature request. Some way of saving and restoring the current layout (window sizes and positions) would be great. Perhaps some kind of mapping from screen size to layout, so that if the screen size changes to a size that has a layout stored, it uses that layout. My use case is that I use Arch on VirtualBox on windows on one of my machines and usually run VirtualBox in fullscreen, but when I need to access windows I unfullscreen VirtualBox - currently every time I do this, I lose my goomwwm layout. So, for me the ideal would be that if the screen size changes, it stores the layout for the old size before the layout adjusts to the new screen size. Then when the screen size changes back, it looks up the screen size, finds the old layout and reapplies it. Make sense?
Finally, is there an inverse of mod4+h and mod4+v? They seem to decrease the height and width by half, but what is the best way of increasing just the width or height (page up increases both and home/end set to the screen width/height and return fills available space, but what if I want more precise control over size without using the mouse?)
Anyway, keep up the good work!!
Last edited by dublindan (2012-07-14 13:58:48)
Offline
@dublindan - I remember the name
VirtualBox has a bug with refreshing window borders when using guest additions and vboxdriver: https://www.virtualbox.org/ticket/6479 . I encountered this myself while testing. Do you think this could account for what you saw?
Re: Screen layout saving. I'll give it some thought. Probably any solution would not be automatic on screen change; ie, I'd build it so that each layout change needed user input, even if it was only a popup menu of saved layouts and [enter] to trigger.
Another possibility is having a way to define a batch of window rules (which we already have with -rule) and apply them on the fly to all open windows. In this case a "saved layout" could become more flexible than a static snapshot. Eg, if a window has closed in the meantime, or more windows have opened, it wouldn't matter so long as rules existed.
Re: Mod-h/v. No exact inverse operations at present, although you could set Mod-Insert/Delete to lock the window horizontally or vertically, and then PageUp/Down or expand would only affect the unlocked plane.
The reason there is no explicit inverse for Mod-h/v is: a) because I havn't got around to it, and b) because they're really aimed at tiling stacked windows of the same size and position; the halving in size only comes as a side effect if no other windows are found
Edit: Ok, you tempted me! Mod-Shift-h and Mod-Shift-v now do the opposite of Mod-h and Mod-v. That is, they will un-tile (restack?) a group of previously tiled windows, or failing that, grow the current window by half.
Last edited by aerosuidae (2012-07-14 15:34:06)
Offline
Ah, yes, that bug is likely the cause of what I see. I suppose that means there's nothing you can do about it? No workarounds or anything like that?
Re: Mod-Shift-h/v - sounds perfect for my needs, thanks! Will give it a try shortly
Re: screen layout - manual would be fine. Perhaps some kind of rule/trigger could be added that can run on screen resize. Some way of automatically getting a snapshot of the layout prior to exiting fullscreen so I can't accidentally forget to store the layout would be nice. Restoring it manually isn't a problem as I can't accidentally mess up the layout.
One more bug - when I change the VirtualBox window size to be larger than it was when goomwwm was started, the 3x3 grid won't cover the entire screen space, but is fixed at the size the screen was when goomwwm started. Its not a big problem though, since running "goomwwm -cli -restart" fixes this and I imagine most non-VM users don't change the screen resolution terribly often.
Last edited by dublindan (2012-07-14 16:21:48)
Offline
@dublindan - I havn't found a workaround for the VirtualBox bug other than to skip the guest additions and use the vesa driver in Xorg, which really isn't that nice. Though honestly, I didn't play with it much...
The VirtualBox screen resize problem I can't diagnose immediately. Goomwwm does detect root window resizes done by Xrandr and reconfigure accordingly, but how the VM handles it... no idea.
Offline
Neither are show stoppers anyway, so there's really no rush. I'll use it as is for a few days and see how it goes.
I just tried the latest version - Mod-Shift-v/h is perfect, thanks very much!
Last edited by dublindan (2012-07-14 16:55:17)
Offline
@chneukirchen - Ah yes, that request fell off my list at some stage, sorry.
I've just committed changes to allow window minimization. See Mod-/ and -minimize. Select from the window switcher to restore, as you suggested.
You rock!
Offline
I just noticed that goomwwm was ignoring my .Xdefaults setting for psuedo transparency shading in urxvt. I've never used an .Xresources file in arch before but that seemed to fix the shading problem?
Last edited by bgc1954 (2012-07-15 02:12:44)
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
.Xdefaults is deprecated. So you should use .Xresources anyways.
Offline
@bgc1954 - .Xdefaults and .Xresources are not the responsibility of a Window Manager (a full desktop environment, maybe, but a WM just manages windows)
Last edited by aerosuidae (2012-07-15 06:50:31)
Offline
Mod-q kills conky if no other windows are open. Is there any way to prevent it? (Or is it a bug in goomwwm?) Conky is configured as a panel, as suggested in this topic.
Offline
@ma - That's a goomwwm bug. Thanks for reporting! Fix is committed.
Offline
Thanks. It works fine now. That was fast.
Offline
@dublindan - The new -ruleset stuff might help with your screen layouts. I know it isn't really what you suggested (ie, this is pre-defined layouts and no automatic saving) but I'm going to stick with this idea for a while and see how it goes...
Last edited by aerosuidae (2012-07-15 13:07:03)
Offline
@x33a: It may be deprecated but it's always worked until now with goomwwm. Thanks for pointing it out, though. Learn something new everyday.
@aerosuidae: I just mentioned it as I've never used a .Xresources file with any other window manager besides in Debian. It's just interesting that goomwwm would prefer one X file setting over another. But this only happens in my netbook as I'm still running an .Xdefaults on my desktop--although now I suppose I will change it to keep up with the times. That darned netbook is a pita sometimes.
Time is a great teacher, but unfortunately it kills all its pupils ... - Louis Hector Berlioz
Offline
So, after those few feature requests I'm back to thinking about tagging a v1.0 rc1 release shortly... unless someone shouts again and convinces me some missing feature is to die for
IMO the goomwwm code base now needs to let the dust settle and the remaining bugs (hopefully small) be squashed.
Last edited by aerosuidae (2012-07-16 03:20:17)
Offline
@aerosuidae: Do you plan to ever add support for hiding windows that do not belong to the tag selected by Mod-F[1-9]? Right now the screen becomes cluttered with windows very easily. Hiding them manually (one by one) is not really a solution.
As for squashing bugs: goomwwm does not seem to work nicely with keyboard layouts. For example, Mod-/ does not work on a Hungarian layout, where a slash is produced by pressing Shift-6. My uneducated guess is that when I press Mod-Shift-6 to hide a window, goomwwm receives Mod-Shift-/, which (due to the extra Shift) is not what it is looking for, of course… The same is true for Mod-` (Mod-grave), as grave is produced by AltGr-7.
Offline
Speaking of keys, I had to remap Mod-l as when running in VirtualBox, windows kept locking the screen when I pressed that but since I use colemak the normal ijkl isn't very convenient anyway, so I switched it to unei (which are the same physical keys as qwerty ijkl) and remapped Mod-u to Mod-q.
Not sure if this is a goomwwm issue or perhaps VirtualBox again, but Mod-Shift-Right does not work for me.
A feature I really miss from musca is being able to swap two window positions. Right now in goomwwm I have to manually move, eg, if I want two windows that are tiled above each other to trade places, I have to move one window down, cycle, then move the other up and perhaps resize both if they weren't the same size. It would be really cool if there were a way of swapping two windows. I'm thinking either limit it to two windows which are beside each other and then using musca-style "swap with window to the left/right/above/below" or popup the window switcher and choose which window to swap with that way. The windows then swap positions and sizes.
One other feature which I personally think would be useful is to have more than one grid that you can switch between, maybe you can set your own grid sizes in the rc file and then have a button for a popup grid size selection menu? Having more than one grid size would make tiling much simpler, imho (as I long time musca user I can't live without tiling!).
Last edited by dublindan (2012-07-16 09:03:38)
Offline
@ma
I don't plan to hide non-current tags, because tags are not meant to be desktops. The intended usage is simply to find groups of windows quickly, not to split up the workspace. The simplest way to hide other windows is to fill that valuable screen space with windows you do want to see
The Mod-/ problem: I don't think I could ever come up with default key bindings that works on all possible keyboard layouts? Have you tried using -minimize and -tswitch options to use alternate keys that do match your layout?
@dublindan
Thanks for the tip on Mod-Shift-Right. I'll do some digging.
The window swapping idea is certainly possible. Much of the required code is probably already done in the h/v tiling... yeah, let me think it over
A lot of grid and tiling functionality can be reproduced with rule sets. Have you had a look at -ruleset in this context, and the Mod-. rule set switcher? That code is fairly new, but potentially powerful I think, so any feedback on shortcomings would be appreciated.
Offline
@aerosuidae: Yes, I have tried -minimize and -tswitch. They work fine, of course, as long as the selected key does not require a modifier. This latter condition is a bit of an inconvenience, but it's okay for now. Regarding tags: Damn, I was almost sure you would say that.
Offline
Yes, I have tried -minimize and -tswitch. They work fine, of course, as long as the selected key does not require a modifier.
Hmm... that sounds like a bug, or I'm misunderstanding you. If you use (for example):
goomwwm -minimize v
This should result in mod-v triggering minimization. Do you get something different?
Edit: Just to clarify something: the above example would cause mod-shift-v to work for minimization also; ie, you can generally bind to any shifted keysym too because the shift mask (and caps lock, numlock, etc) is implicitly captured where necessary, without explicitly including shift on the command line.
Last edited by aerosuidae (2012-07-16 12:44:32)
Offline