monsterwm! ~ yet another tiny wm

Cloudef · 2012-02-05 11:02:16

Army wrote:

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)

TheLemonMan · 2012-02-05 13:05:24

Here's a patch!
But please dont make this the default behaviour, i like staring at my wallpaper sometimes.

Last edited by TheLemonMan (2012-02-05 13:51:27)

el mariachi · 2012-02-05 13:25:57

TheLemonMan wrote:

Here's a patch!
But please dont make this the default behaviour, i like staring at my wallpaper sometimes.

Agreed

kuraku · 2012-02-05 14:50:47

TheLemonMan wrote:

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

c00kiemon5ter · 2012-02-05 15:01:02

Yep, it's good and that's a nice idea. I will add it as a new function

Army · 2012-02-05 16:37:58

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)

c00kiemon5ter · 2012-02-05 17:16:53

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)

bloom · 2012-02-06 11:39:36

bloom wrote:

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?

c00kiemon5ter · 2012-02-06 17:32:03

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)

Cloudef · 2012-02-06 18:03:59

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.

whooper · 2012-02-06 22:02:08

Thanks for the bugfix c00kiemon5ter!

Using the core branch now, it's great.

el mariachi · 2012-02-06 22:32:11

thanks c00kiemn5ter. I was having problems with urxvtd after your first patch to fix st, but it's all good now 8D

c00kiemon5ter · 2012-02-06 23:00:34

yep, should be good now, I was doing a wrong calculation in a loop

whooper wrote:

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)

topcat-software · 2012-02-06 23:47:38

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

c00kiemon5ter · 2012-02-06 23:53:38

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)

topcat-software · 2012-02-07 00:26:23

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

topcat-software · 2012-02-07 01:06:31

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.

c00kiemon5ter · 2012-02-07 01:34:30

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)

c00kiemon5ter · 2012-02-07 01:47:39

Ok, pushed the changes.
default terminal is xterm. core has no menu command.
master has menucmd which defaults to dmenu.

if you have any problem topcat please report

bloom · 2012-02-07 10:37:19

c00kiemon5ter wrote:

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?

topcat-software · 2012-02-07 11:26:38

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

c00kiemon5ter · 2012-02-07 11:42:52

bloom wrote:

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.

topcat-software wrote:

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.

Šaran · 2012-02-07 17:31:26

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

moetunes · 2012-02-07 20:24:19

Šaran wrote:

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

c00kiemon5ter · 2012-02-07 21:57:06

alright, pushed a fix for this
transient windows are always on top
unless obscured by a floating window

Arch Linux

#301 2012-02-05 11:02:16

Re: monsterwm! ~ yet another tiny wm

#302 2012-02-05 13:05:24

Re: monsterwm! ~ yet another tiny wm

#303 2012-02-05 13:25:57

Re: monsterwm! ~ yet another tiny wm

#304 2012-02-05 14:50:47

Re: monsterwm! ~ yet another tiny wm

#305 2012-02-05 15:01:02

Re: monsterwm! ~ yet another tiny wm

#306 2012-02-05 16:37:58

Re: monsterwm! ~ yet another tiny wm

#307 2012-02-05 17:16:53

Re: monsterwm! ~ yet another tiny wm

#308 2012-02-06 11:39:36

Re: monsterwm! ~ yet another tiny wm

#309 2012-02-06 17:32:03

Re: monsterwm! ~ yet another tiny wm

#310 2012-02-06 18:03:59

Re: monsterwm! ~ yet another tiny wm

#311 2012-02-06 22:02:08

Re: monsterwm! ~ yet another tiny wm

#312 2012-02-06 22:32:11

Re: monsterwm! ~ yet another tiny wm

#313 2012-02-06 23:00:34

Re: monsterwm! ~ yet another tiny wm

#314 2012-02-06 23:47:38

Re: monsterwm! ~ yet another tiny wm

#315 2012-02-06 23:53:38

Re: monsterwm! ~ yet another tiny wm

#316 2012-02-07 00:26:23

Re: monsterwm! ~ yet another tiny wm

#317 2012-02-07 01:06:31

Re: monsterwm! ~ yet another tiny wm

#318 2012-02-07 01:34:30

Re: monsterwm! ~ yet another tiny wm

#319 2012-02-07 01:47:39

Re: monsterwm! ~ yet another tiny wm

#320 2012-02-07 10:37:19

Re: monsterwm! ~ yet another tiny wm

#321 2012-02-07 11:26:38

Re: monsterwm! ~ yet another tiny wm

#322 2012-02-07 11:42:52

Re: monsterwm! ~ yet another tiny wm

#323 2012-02-07 17:31:26

Re: monsterwm! ~ yet another tiny wm

#324 2012-02-07 20:24:19

Re: monsterwm! ~ yet another tiny wm

#325 2012-02-07 21:57:06

Re: monsterwm! ~ yet another tiny wm

Board footer