monsterwm! ~ yet another tiny wm

TheLemonMan · 2012-04-19 19:32:13

Seems that its fixed now Many thanks \o/

kuraku · 2012-04-19 20:39:50

c00kiemon5ter wrote:

On other news, I'm thinking and keen on merging moveresize into core.
I think it provides a nice functionality; moving windows with the kbd.

+1 on this one

c00kiemon5ter · 2012-04-19 22:49:40

so, moveresize is there by default
note that the config.def.h has changed to include the move/resize shortcuts

now there's core, master and 10 patches, hf

Last edited by c00kiemon5ter (2012-04-19 23:22:21)

kuraku · 2012-04-20 00:40:29

Yeah, it is working good. And finally i have a reason to use "win" key

Thank you c00kiemon5ter.

Biowaste · 2012-04-21 06:57:40

Why should I switch to this from dwm? I'm curious.

c00kiemon5ter · 2012-04-21 09:26:05

none says you should

compared to dwm, monsterwm is smaller,
imo it has a simpler codebase
includes more layouts by default (grid, bstack)
with more functionality (ie pertag, moveresize, no monocle borders etc)

on the other hand dwm uses tags, while monsterwm has desktops/workspaces,
includes nmaster by default, while that's a patch for monsterwm (see the branches on the git repo),
incorporates its own panel/bar, while monsterwm lets the user decide what panel to use
(ie you can even use the stripped down dwm panel/bar, although, I'd recommend some_sorta_bar by moetunes)

so, it's up to you to decide what you need and what you want to use
usually the choice of which free software to use depends on:
- covering your needs (it does what you want)
- its support by the devs
- how its community behaves

hf o/

Army · 2012-04-21 10:32:19

+ dwm supports dualhead (even multihead?), which monsterwm doesn't. That's MY dealbreaker with monsterwm (Cloudef's dualhead branch just doesn't work here and right now I don't have time to help debugging it)

Cloudef · 2012-04-21 11:17:45

Army wrote:

+ dwm supports dualhead (even multihead?), which monsterwm doesn't. That's MY dealbreaker with monsterwm (Cloudef's dualhead branch just doesn't work here and right now I don't have time to help debugging it)

Yeah, the dualhead branch took a bit wrong approach to the code. I should rewrite it so it isn't a maintain hell, also yeah. Not using monsterwm yet on my desktop either so it's propably riddled with bugs atm.

mhertz · 2012-04-21 17:56:57

I personally changed to monsterwm from dwm, because it allready incudes all the nice patches that dwm needs to be patched with while still using about 30% less memory. In monsterwm's standard master branch there by default includes extra functionality of about 10 dwm patches!

Also, c00kiemon5ter is extremelly responsive about listening to it's users for requests and fixing bugs imidiately!

Yeah, multi-head and tagging isn't there, but I don't really care as I only have one screen, and since simple workspaces are just as effecient as tags for my workflow anyway(also dwm people often goes against the tagging paradigm anyway with pertag patches etc.)

Actually, there's even functionality in monsterwm which I haven't seen a dwm-patch for yet, like e.g. autofocusing selected apps from the rules section on config.h and hotkeys to switch between not only all workspaces, but just the occupied ones, and to have a hotkey for going to a workspace which has gotten an urgency hint, and to only show border when over 1 client in all modes(ok, that one has recently come to dwm by the help of jokerboy and army on army's github).

Btw, i've just registered to the arch-wiki so that I could fix the commands needed to merge branches together, as the original example would fail...

Last edited by mhertz (2012-04-21 21:13:50)

Ypnose · 2012-04-22 11:20:43

A great thing about dwm is the cpu usage. It's very light and I really love to see my cpu saved when I'm using my computer.
I can use all the resources for my work (compile kernel for example).
Does monsterwm consume more cpu compared to dwm? I remember one month ago, the load average was higher than dwm.

Actually, I am almost ready to switch on monsterwm. This project is getting really awesome, and you're very fast to answer us.

mhertz · 2012-04-22 14:54:32

The cpu usage of either dwm or monsterwm is incredible low and both of them shows 0.0% used even when doing repeated wm tasks like opening windows and closing them etc.

As for memory usage, then ive just measured latest dwm vanilla(not patched) and the master branch of monsterwm with ps_mem.py on arch64:

 Private  +   Shared  =  RAM used	Program 
224.0 KiB + 127.0 KiB = 351.0 KiB	monsterwm
436.0 KiB + 285.5 KiB = 721.5 KiB	dwm

So, dwm is acually using about twice the amount of memory as monsterwm does!

Last edited by mhertz (2012-04-22 15:00:47)

stlarch · 2012-04-22 15:00:13

@Ypnose, the extra cpu usage might be from running multiple instances of dzen, if you're using that. You could maybe try moetunes' some_sorta_bar?
I was using dwm, monsterwm, and snapwm, as they are similar but have since just went to snapwm only. It was getting tough trying to keep up with all three for me. I like the tagging in dwm, but I also like pertag, so I'm kinda torn between the two strategies. I like monster a lot too. I like the idea of not having a bar because it give you more flexibility to use what you want. Unfortunately, it does seem to use a few more resources, but it's still very light. I was mostly concerned with my bash skills not being up to snuff, which could be problematic? For me, snapwm seems to come closest to what I want, so I decided to go with that for now. It's good to have choices! It's also good to have the developers on the forum too! (Snapwm and Subtle's developers are here too) It's good to be an Arch user

Unia · 2012-04-22 15:23:23

tl;dr

stlarch wrote:

It's good to be an Arch user

mhertz · 2012-04-22 15:24:28

Yeah, moetunes some_sorta_bar rocks, and it even includes parsing positioning symbols, so as we only need one instance of the bar and still can have left + right aligned status-info to show, whereas with dzen we need to bars merged into one; one for left and one for rightside status info...

With two dzen instances it used 1.1mb total memory, but now with a single instance of some_sorta_bar it takes:

 Private  +   Shared  =  RAM used	Program 

224.0 KiB + 127.0 KiB = 351.0 KiB	monsterwm
260.0 KiB + 141.0 KiB = 401.0 KiB	some_sorta_bar

we owe alot to moetunes, not only for the great bar, but also for all the groundwork he did for improving pyknite's nice litte catwm into dminiwm(and now snapwm additionally), before c00kiemon5ter ported it to monsterwm

Shinryuu · 2012-04-22 16:55:13

Didn't expect to see an option to move and resize windows through keyboard, I find it useful if I want to make something to float. Say no to mouse!

kuraku · 2012-04-22 19:29:49

About resource usage and monsterwm and dwm comparation:

I started firefox (14a1), screen (with rtorrent, mocp, irssi, re-alpine, htop and one shell prompt) in separated terminal on separated workspace and here is what i got:

Private   +  Shared   = RAM used   Program 

188.0 KiB +  83.0 KiB = 271.0 KiB  monsterwm (monocleborders branch, no bar)
328.0 KiB + 157.5 KiB = 485.5 KiB  dwm (without anything on dwm bar)
324.0 KiB + 155.5 KiB = 479.5 KiB  dwm (with homemade script that loads info to bar)

As for psgrep, here are the results:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

1000     15359  0.0  0.3   3276   944 tty1     S    21:10   0:00 monsterwm (no dzen nor any bar)
1000      5496  0.0  0.5   4976  1432 tty1     S    20:21   0:00 dwm (with script loaded into bar)

Have in mind that i tried to load more clients, delete them etc and during that process, there was no cpu usage by monsterwm nor dwm. I tried this on my machine: AMD Athlon 2200+ (~1.8GHz, 32bit single core from 2002 i think) and 256MB of cheap RAM memory.

I noticed that monsterwm is a little different when it comes to recovering from almost fully used RAM memory. Let me elaborate a little on that: If you use firefox or any other program and try to fill up RAM memory, you pc will work very slowly and many stuff will be harder to start (like opening terminal etc.). Monsterwm is acting a little different when you load up to 245MB of ram on machine, where you have 256MB. It allows you to do anything and the functionality of monsterwm is not affected at all but it is kinda sluggish when you start first app or two (like starting terminal, firefox etc.). This stuff is less present in dwm so when you fill up your RAM (in my case, you fill up to 245MB and total memory is 256MB) and you free it up, dwm ill act a little faster when starting apps. Have in mind that this is not monsterwm issue and there is something other that is doing this. Also i must say that i use script that starts apps only once (i parse them trough small script and add those shortcuts to monsterwm). Maybe i will find out why is this happening in future.

All in all, i use monsterwm on my pc (256MB ram is kinda low for today) and i have no issues with it at all.

And yes, i wanna share some cookies with you:

Last edited by kuraku (2012-04-22 19:34:37)

c00kiemon5ter · 2012-04-23 23:19:54

nice shot kuraku

I added a FLOAT layout. It's in master by default (not in core) binded to Alt-Shift-F by default.
If you're using Fibonacci too, the default shortcut for fibonacci is Alt-Shift-i now.

You can actually set floating layout now, and all windows spawining, will be floating. I guess that's handy if you're using initlayouts too (otherwise it doesnt make much sense to use a tiling wm with a floating layout ).
Anyway, it was way easy and "cheap" (no additional lines ) to add, so why not.

imo it's pretty useless, I don't really have floating windows at all, but some had asked this in the past.

hf o/

kuraku · 2012-04-24 00:26:08

c00kiemon5ter wrote:

nice shot kuraku
I added a FLOAT layout. It's in master by default (not in core) binded to Alt-Shift-F by default.
If you're using Fibonacci too, the default shortcut for fibonacci is Alt-Shift-i now.
You can actually set floating layout now, and all windows spawining, will be floating. I guess that's handy if you're using initlayouts too (otherwise it doesnt make much sense to use a tiling wm with a floating layout ).
Anyway, it was way easy and "cheap" (no additional lines ) to add, so why not.
imo it's pretty useless, I don't really have floating windows at all, but some had asked this in the past.
hf o/

Thank you. btw FLOAT look s okay and it is good to have it. I say that monsterwm is really rocking when we count all the options by default

Anyway, i wanna report something weird and i'm not sure if it is a bug. I noticed it the day you introduced moveresize patch in master but i was unable to produce it until now.

How to produce it:
- Start any client in monocle layout (monocle is example, it can be any layout);
- Move that client with keyboard (MOD4 + right for example) to see part of your wallpaper (if any);
- Use keyboard to change to bstack/grid;

You will have to use keyboard shortcuts for the last step twice. So, you will have to repeat your command to change from starting to last layout (bstack/grid in this case). Have in mind that this shows up if you have more clients on workspace. Then we can notice that keyboard shortcut for any layout, other than the one used on start, firstly arranges non floating clients and then floating ones. Maybe this should be done at once but i'm not sure how will it stack float client then: to the end of client list or...?

Reasons to change layouts like this can be desire to make moved client to go to tiled mode and use all available screen space.

c00kiemon5ter · 2012-04-24 01:22:11

this is normal. this is how it used to be.
reseting floating clients to tiled is done by re-choosing the tiling mode, not by changing the layout.

in your case you first change the layout - floating clients are not affected by this, floating clients in grid layout, will still be floating in bstack layout
and then (2nd keypress to change mode) you re-select the current mode, which makes floating clients become tiled.

btw, I updated the man page. it should cover most things monsterwm can do now along with the new keybindings.
also updated argument parsing and the usage message (some lines saved)

Last edited by c00kiemon5ter (2012-04-24 12:32:13)

prasinoulhs · 2012-04-26 14:05:50

c00kiemon5ter wrote:

I added a FLOAT layout. ....

Thanks for that, i think it's quite useful if you use a laptop plus some apps don't look "good" if they take the whole screen.

Also i think that CLICK_TO_FOCUS is broken (Can anyone else confirm this?).

kuraku · 2012-04-26 14:12:14

prasinoulhs wrote:

Also i think that CLICK_TO_FOCUS is broken (Can anyone else confirm this?).

Yeah, i can confirm this (just recompiled and tried with gtk and terminal apps).

c00kiemon5ter · 2012-04-26 14:23:53

dah, sorry for that, I deleted a line by mistake at some point, it's fixed now

Cloudef · 2012-04-26 16:22:52

@c00kiemonster
I've forked your repo and started doing code for multi monitor support.
The code should do few if any changes to original code and keep out of the way, basically nothing like the one in the -xcb branch.

After it's done, I'll propably do major refactoring to the -xcb and switch over to the monsterwm on my desktop.
Just asking would you accept pull request for this?

Cloudef · 2012-04-26 18:13:41

Ok, sorry for double posting.
Here is the branch for multi-monitor support: https://github.com/Cloudef/monsterwm/co … ti-monitor

There is basic support currently:
- You need to have all monitors plugged when you start monsterwm
- Currently only way to switch monitor is the change_monitor function
- You can't have own bar on monitor

People with multiple monitors are encouraged to test it and report bugs if there is any.
I could not find any bugs from the testing I did.

@c00kiemonster
I will not develop this code further until I get feedback && reaction from you.
As you see, the major change I need to do your code is to wrap the XMoveResizeWindow , so that windows stay on their own monitor.

Other places where I touch your code:
- Client struct has monitor member
- Addwindow function inserts current_monitor to client's monitor member
- XINERMA is definied in makefile, if it's undefinied the code will use fallback for 1 monitor.
- setup() function calls xinerama_magic() which initializes everything

All the functions are provided at bottom of the code to avoid conflicts in merge.
The global variables and headers are somewhat tried to keep in one place as well for the same reason.

The only things I would see conflicting with mergin a lot is the _XMoveResizeWindow wrapper,
if you can provide function similar to this in your git, that would be neat.

It's much better and cleaner method than the -xcb's multi-monitor implentation that was similar to dwm.
Anyways, tell me what you think. For example I really would like a suggestion in what format to provide desktopinfo() for all monitors.

Last edited by Cloudef (2012-04-27 08:26:15)

c00kiemon5ter · 2012-04-27 09:30:00

Cloudef wrote:

Here is the branch for multi-monitor support: https://github.com/Cloudef/monsterwm/co … ti-monitor

hey, great

Cloudef wrote:

As you see, the major change I need to do your code is to wrap the XMoveResizeWindow , so that windows stay on their own monitor.
[..]
The only things I would see conflicting with mergin a lot is the _XMoveResizeWindow wrapper,
if you can provide function similar to this in your git, that would be neat.

I can do that, sure. If I dont get to it in a bit, I'll do it tonight (it's 12pm right now).
Anyway you'll see the push in github

Also can I name that, to XMVRSZ or something more macro'ish ?
and are XMoveWindow and XResizeWindow affected (see mousemontion) ?
Should they switch to use the macro too ?

Cloudef wrote:

All the functions are provided at bottom of the code to avoid conflicts in merge.
The global variables and headers are somewhat tried to keep in one place as well for the same reason.

that's good, although it won't be much problematic to have those mixed.
If the branch will be kept in sync with the master using rebase, then if you
resolve the conflict once, it is remembered will be resolved automatically
on updates (future rebases).

Cloudef wrote:

I really would like a suggestion in what format to provide desktopinfo() for all monitors.

I guess the simplest thing for desktopinfo() would be to wrap it in a for loop,
over all the monitors and provide one more number, that would indicate the
monitor (fprintf got one more %d and the corresponding 'm' var).
(this is editing the desktopinfo() function):

    for (m in monitors) {
        for (client *c; d<DESKTOPS; d++) {
            fprintf(stdout, "%d:%d:%d:%d:%d:%d%c", m, d, n, mode, ...);
                           /* ^                    ^ monitor id {0..MONITORS-1} */
        }
    }

that would also make really easy to adopt the change in the scripts,
just one more variable in read to represent the monitor id and based
on that, one can make decisions about what to include/print where.

aside from that, MONITORS looks like a #define, while it's not,
and I think it's not needed (use LENGTH(&monitors) ?)
I also think you can drop the fallback function and merge it to xine_magic().
On the Makefile, you may want to add -g on LDFLAGS too

I can grab the code and merge it to my repo, will try to tinker a bit with
it and tell you. Also, as I've said before, I don't have a second screen
so, I can't test this, but the logic is in the code.

I will also update the README for your repo/multi-monitor branch
if you want to, ask anything thanks once more!

Last edited by c00kiemon5ter (2012-04-27 09:32:46)

Arch Linux

#576 2012-04-19 19:32:13

Re: monsterwm! ~ yet another tiny wm

#577 2012-04-19 20:39:50

Re: monsterwm! ~ yet another tiny wm

#578 2012-04-19 22:49:40

Re: monsterwm! ~ yet another tiny wm

#579 2012-04-20 00:40:29

Re: monsterwm! ~ yet another tiny wm

#580 2012-04-21 06:57:40

Re: monsterwm! ~ yet another tiny wm

#581 2012-04-21 09:26:05

Re: monsterwm! ~ yet another tiny wm

#582 2012-04-21 10:32:19

Re: monsterwm! ~ yet another tiny wm

#583 2012-04-21 11:17:45

Re: monsterwm! ~ yet another tiny wm

#584 2012-04-21 17:56:57

Re: monsterwm! ~ yet another tiny wm

#585 2012-04-22 11:20:43

Re: monsterwm! ~ yet another tiny wm

#586 2012-04-22 14:54:32

Re: monsterwm! ~ yet another tiny wm

#587 2012-04-22 15:00:13

Re: monsterwm! ~ yet another tiny wm

#588 2012-04-22 15:23:23

Re: monsterwm! ~ yet another tiny wm

#589 2012-04-22 15:24:28

Re: monsterwm! ~ yet another tiny wm

#590 2012-04-22 16:55:13

Re: monsterwm! ~ yet another tiny wm

#591 2012-04-22 19:29:49

Re: monsterwm! ~ yet another tiny wm

#592 2012-04-23 23:19:54

Re: monsterwm! ~ yet another tiny wm

#593 2012-04-24 00:26:08

Re: monsterwm! ~ yet another tiny wm

#594 2012-04-24 01:22:11

Re: monsterwm! ~ yet another tiny wm

#595 2012-04-26 14:05:50

Re: monsterwm! ~ yet another tiny wm

#596 2012-04-26 14:12:14

Re: monsterwm! ~ yet another tiny wm

#597 2012-04-26 14:23:53

Re: monsterwm! ~ yet another tiny wm

#598 2012-04-26 16:22:52

Re: monsterwm! ~ yet another tiny wm

#599 2012-04-26 18:13:41

Re: monsterwm! ~ yet another tiny wm

#600 2012-04-27 09:30:00

Re: monsterwm! ~ yet another tiny wm

Board footer