You are not logged in.
Feature request:
In rotate_desktop, only go to desktops which contain at least one client. If you want to go to a specific desktop, it makes more sense to go there directly with MOD?+$number. I think it's useless to rotate to empty desktops.Opinions?
Yeah, this makes sense. Go for it c00kie
Last edited by Cloudef (2012-02-05 11:02:54)
Offline
Here's a patch!
But please dont make this the default behaviour, i like staring at my wallpaper sometimes.
Agreed
Offline
Here's a patch!
But please dont make this the default behaviour, i like staring at my wallpaper sometimes.
Thank you for your patch, i will try it latter today.
Btw, this could be added in master branch and just provide option in config to enable/disable it. It is is 3 lines patch, so it would only add 3 lines to sloc. I believe it is a good compromise
Offline
Cool!
I tried TheLemonMan's patch, it works, but not perfect. Rotating backwards doesn't work if the "jump" is more than one desktop, e.g. from desktop 3 to 1, in case there's nothing on desktop 2, but on 1 and 3.
Last edited by Army (2012-02-05 16:38:31)
Offline
Pushed!
@whooper
the st bug should be fixed
applied the patch by TheLemonMan, should be working good.
I also renamed "rotate_desktop" to "rotate" and the new function is called "rotate_filled" as in filled with windows/clients. Also -1 and +1 are now PREV and NEXT, as seen the config.def.h , and the default keys changed from the arrow keys (XK_left, XK_right) to vim-like keys (XK_h, XK_l).
I also created a new branch - core that has only the most basic functionality of monsterwm. master has basic features like resize master area, toggling of panel, toggling between the last focused desktop etc.
thanks
Last edited by c00kiemon5ter (2012-02-05 17:18:15)
.:[ git me! ] :.
Offline
But unfortunately, there's no way to tell xcompmgr to only act on floating windows.
In fact, there is a way to tell xcompmgr (or compton) not to act on a window: its _NET_WM_WINDOW_TYPE property must be _NET_WM_WINDOW_TYPE_DESKTOP.
Could you add that feature?
Offline
I don't think monsterwm has anything to do with that.
_NET_WM_WINDOW_TYPE should be set by the clients to indicate a predefined "type" of window it represents. All the wm has to do is check that property and depending on its value, appropriately set some properties for the window. monsterwm does not check that value, and I don't think it ever will in master.
_NET_WM_WINDOW_TYPE_* is something the client must set for itself, and not something the wm would do.
btw: I refixed the st bug, not closing when using the killclient function.
Last edited by c00kiemon5ter (2012-02-06 17:33:00)
.:[ git me! ] :.
Offline
btw: I refixed the st bug, not closing when using the killclient function.
https://github.com/Cloudef/monsterwm-xc … a8cb838419
Heh, seems like my earlier merge does not need the fix then. It's pretty awful how much more SLOC the xcb port has.
Offline
Thanks for the bugfix c00kiemon5ter!
Using the core branch now, it's great.
Offline
thanks c00kiemn5ter. I was having problems with urxvtd after your first patch to fix st, but it's all good now 8D
Offline
yep, should be good now, I was doing a wrong calculation in a loop
Using the core branch now, it's great.
ha! the core branch is hardcore x)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
C 1 97 265 603
C/C++ Header 1 8 8 50
-------------------------------------------------------------------------------
SUM: 2 105 273 653
-------------------------------------------------------------------------------
Last edited by c00kiemon5ter (2012-02-06 23:05:02)
.:[ git me! ] :.
Offline
Hmm... really odd behavior from the new core-branch on my end... can not rotate desktops, some type of race condition with F-key usage as well (that's the feel it seems to impart at any rate). Stepping back a version or two
Offline
the core branch is not the master branch! the core branch is just the very core, it's very limited (no rotation and no many things).
the master branch has rotation, but the default keys changed to vim like ones
XK_l in place of XK_right, XK_h in place of XK_left
Mod1-F[keys] are used to change desktop by default
what is the problem you're getting ? (or do you mean XK_f ?)
Last edited by c00kiemon5ter (2012-02-07 00:01:38)
.:[ git me! ] :.
Offline
cookie, I'm not sure just yet: thinking it may be a problem with core-branch on FreeBSD with a customized ~/.Xdefaults somehow... I'll get it whipped its no biggie
Offline
Having problems with the master branch too... Seems I've fallen out of the loop here. Master defaults to uxterm?
https://github.com/c00kiemon5ter/monste … nfig.def.h
I'm now totally confused.
Offline
oh dah, yeah I changed that locally, but seems it got upstream
uxtrem comes with xterm package, but probably not every other distro has or builds xterm with unicode.
I'll revert that to xterm. I've also remove the default entry to dmenu.
hmm maybe I'll keep dmenu in master, but not in core.
Last edited by c00kiemon5ter (2012-02-07 01:37:57)
.:[ git me! ] :.
Offline
Offline
I don't think monsterwm has anything to do with that.
_NET_WM_WINDOW_TYPE should be set by the clients to indicate a predefined "type" of window it represents. All the wm has to do is check that property and depending on its value, appropriately set some properties for the window. monsterwm does not check that value, and I don't think it ever will in master.
_NET_WM_WINDOW_TYPE_* is something the client must set for itself, and not something the wm would do.
Ok, this a bad example.
Would a custom WM_WINDOW_LAYOUT property be more appropriate?
Offline
Thanks cookie.
re: dmenu
I don't use it here.
re: only go to desktops which contain at least one client
-1 here. I use root-tail to pipe logs from /var, & an empty desktop is very much needed...
But I also understand folks have differing thoughts on these subjects... That's the beauty of *nix IMO:
We can celebrate our differences rather than disparage them
Offline
Ok, this a bad example.
Would a custom WM_WINDOW_LAYOUT property be more appropriate?
no no, I already do not like the standard, having a custom property would make things worse.
re: only go to desktops which contain at least one client
-1 here. I use root-tail to pipe logs from /var, & an empty desktop is very much needed...
It's on master as a new function (rotate_filled), so the old rotate is still there
the new one is handy for people with lots of intermediate empty desktops,
or people that don't use a panel and so don't know or don't remember which desktops have clients.
.:[ git me! ] :.
Offline
Thank you, c00kiemon5ter, this is truly monstruous wm!
I decided to switch from dwm when I realised that everything I need (and have to patch dwm for), monster gives me right out of the box. A bit smaller box.
But this is holding me back:
Thank you c00kiemon5ter! Another satisfied costumer!
I: When a window pops-up in [M] mode, if follow-mouse is enabled, and I move the mouse to the window that gave origin to the pop-up (a save as dialog for example), it get's sent to the back. In dwm the pop-up is "always on front".
If FOLLOW_MOUSE and/or CLICK_TO_FOCUS is enabled, floating client gets sent to background if any other client gets focused. I'm using touchpad to change focus and this is a real deal breaker.
I hope you will look into this. If you need help debugging, just tell me what to do.
Another soon-to-be-satisfied customer
Offline
Thank you, c00kiemon5ter, this is truly monstruous wm!
I decided to switch from dwm when I realised that everything I need (and have to patch dwm for), monster gives me right out of the box. A bit smaller box.But this is holding me back:
el mariachi wrote:Thank you c00kiemon5ter! Another satisfied costumer!
I: When a window pops-up in [M] mode, if follow-mouse is enabled, and I move the mouse to the window that gave origin to the pop-up (a save as dialog for example), it get's sent to the back. In dwm the pop-up is "always on front".If FOLLOW_MOUSE and/or CLICK_TO_FOCUS is enabled, floating client gets sent to background if any other client gets focused. I'm using touchpad to change focus and this is a real deal breaker.
I hope you will look into this. If you need help debugging, just tell me what to do.Another soon-to-be-satisfied customer
@c00kiemon5ter, I just fixed this in dminiwm. Since you have the transient windows already marked it should be 3 or 4 lines to do.
in update_current() it'll be something like
if(there's no transient window) XSetInputFocus(on the current->win)
XRaiseWindow(the current window)
if(there is a transient window) {
XSetInputFocus(on the transient window)
XRaiseWindow(the transient window)
}
I'm too lazy to make a patch
Cheers
You're just jealous because the voices only talk to me.
Offline