monsterwm! ~ yet another tiny wm

mhertz · 2011-12-29 16:01:46

Latest dwm-hg-tip and monsterwm-git ps_mem.py comparison on Arch64:

 Private  +   Shared  =  RAM used	Program 

224.0 KiB + 150.5 KiB = 374.5 KiB	monsterwm
376.0 KiB + 233.5 KiB = 609.5 KiB	dwm

Nice work indeed!

Last edited by mhertz (2011-12-29 16:07:21)

jasonwryan · 2011-12-29 21:06:34

c00kiemon5ter wrote:

thank you people for your words cookies for all!
jasonwryan wrote:
there is one feature that would be helpful: sending urgency hints to the status bar.
done

You are the monster!.

Thanks

c00kiemon5ter · 2011-12-29 22:09:19

jasonwryan wrote:

Sure; you start vimprobable, or any app, by attaching it to the xid of tabbed. So in my monster config.h I have:
SHCMD("$(tabbed -d > /tmp/tabbed.xid); vimprobable2 -e $(</tmp/tabbed.xid)")
Then, to reproduce the error, open a couple of instances of your browser in tabbed. Kill all of the with Ctrl-q and you should be back to the empty tabbed container (the grey box). Kill that with Ctrl-c and that's when I see the lock-up.

alright, I couldn't actually run 'tabbed -d >/tmp/tabbed.xid' as tabbed complained that it expects a command. I did however run this:

$ tabbed -d vimprobable2 -e

and seems to work fine - I got vimprobable2 inside tabbed and I created a couple of tabs, tried different things like killing all instances with Ctrl-Q or some, and then killing the grey box with Alt-Ctrl-C (kill client of monsterwm) but I got nothing wrong back.
I saw there's a diff in your repo with a patch, that I haven't applied here. Could that have anything to do with your problem ? or would the different command that I run make any difference ?
also note that I got tabbed from hg, so it's the latest version for sure.

edit:
I managed to reproduce this This happens when tabbed is the only window, regardless of the mode. Will look deeper tomorrow.

Last edited by c00kiemon5ter (2011-12-29 22:18:00)

trvjillo · 2011-12-30 02:10:48

Little bug: desktopinfo() is missing from client_to_desktop

PS: Keep up the good work!

c00kiemon5ter · 2011-12-30 09:17:05

trvjillo wrote:

Little bug: desktopinfo() is missing from client_to_desktop

Fixed, I follow windows when moved so I hadn't noticed that

redhalo wrote:

Ha, I just saw that announcement today, thinking "I wonder what the suckless guys think of monsterwm?". Apparently they don't think much. It's a shame, I figure'd it be right along thier interest.

ah, well, that's alrght. From what I see, they'd like tagging support, which I have in my todo list. When I started this, I did it mostly to learn more about wm's and xlib, and I'm also thinking on translating this to (and along the way learn) xcb.
As I said on my first post, rant accepted. The harsh critic is the best way to make something better.

Army · 2011-12-30 09:40:35

c00kiemon5ter wrote:

[...] and I'm also thinking on translating this to (and along the way learn) xcb.

That would be awesome! That's the only thing I don't like about dwm, because awesome shows how it has to be done. Unfortunately awesome is too complicated for me, so a minimalistic dwm fork like yours using xcb would be highly ranted in the community, I'm sure about that!

For now I stay with dwm, but I'll definitely follow your development.

moetunes · 2011-12-30 18:41:29

c00kiemon5ter wrote:

snip
and I'm also thinking on translating this to (and along the way learn) xcb.
snip

A while ago I made a port of catwm to xcb here . Xcb is not complete, is lower level than xlib so is harder to program with and is still evolving. That wm doesn't build anymore 'cause xcb dropped some stuff and it's hackish, but should help get you started.

Cheers

c00kiemon5ter · 2011-12-30 18:48:15

moetunes wrote:

c00kiemon5ter wrote:
snip
and I'm also thinking on translating this to (and along the way learn) xcb.
snip
A while ago I made a port of catwm to xcb here . Xcb is not complete, is lower level than xlib so is harder to program with and is still evolving. That wm doesn't build anymore 'cause xcb dropped some stuff and it's hackish, but should help get you started.
Cheers

that's great moetunes, thanks!

Cloudef · 2011-12-30 19:26:23

c00kiemon5ter wrote:

cms07 wrote:
I know that this isn't exactly important, but are you expecting to implement configuration files that can be changed without recompiling? That would make it much easier to customize while using a package manager, I would think. If that's not something you are interested in, I am going to make it happen anyway.
no, I won't be doing that, I don't think it's in the spirit of this wm.
Having a config.h as a configuration is easy enough to manage. Using an external configuration that wouldn't need to be compiled, can be unsafe and needs lots of parsing code. I think there are more interesting things to be done at the moment.
However, give us a heads up, if you go forward with that This can actually be done without affecting any of the current code, just adding a new method and a shortcut to re-read the configuration. All it would do is get the new/default values and reset them internally. If you have it working, this can be maintained as a patch, for anyone that would like it.

I beg to differ the lot of "parsing code" part, thought setter functions for each parameter will take quite bit of space.
Anyways, I'm with you. This is _minimal_ WM and config.h fits the kiss perfect.

If he wants to go with the patch way, maybe look at this configuration code I wrote for verynice-fork
https://github.com/Cloudef/verynice-for … r/config.c

The actual parsing is in 3 functions, and all the code below it is unrelated, above are the setter functions.
Thought, you might want to get rid of the ugly LENGTH macro, and instead NULL terminate the setter list.

Bleh, did I just quote something from previous pages? Well sucks to be me I guess

Last edited by Cloudef (2011-12-30 19:27:25)

guelfi · 2011-12-30 21:28:14

I followed this thread for quite some time now, but didn't actually try out
monsterwm because I have a dual-head setup at my desktop PC. Is there any chance
you will add support for multiple monitors? If you do, I will definetly give it
a try.

c00kiemon5ter · 2011-12-30 22:25:29

guelfi wrote:

I followed this thread for quite some time now, but didn't actually try out
monsterwm because I have a dual-head setup at my desktop PC. Is there any chance
you will add support for multiple monitors? If you do, I will definetly give it
a try.

c00kiemon5ter wrote:

Ypnose wrote:
Hum. This WM is tempting. I really like light WM as dwm. I will take a look. It could be good to implement a good multi-monitor setup.
Cheers.
I don't have a second screen actually, so that would be difficult for me to try and test, but I can assign this to a friend of mine Currently I will be working on the two bugs reported above, and then the list of 3 items above

it's on my list, but not in high priority right now

c00kiemon5ter · 2011-12-31 12:49:35

a while ago I fixed a bug with toggling the panel, that affect the size of the windows in other desktops

in other news

metre wrote:

c00kiemon5ter wrote:
No, not currently, but I think that'd be easy to implement. Its 5am here, so I'll get some sleep, and think about it tomorrow. Will probably need to find a generic way to add the option on the config.
This can also be done with `wmctrl` and a bit of bash.
Thank you for your answer, but please don't be in hurry and don't feel obligated to implement that idea: you know, real life and sleep deserve more time than you think

I was thinking about this, and I'm not sure what would be best.
There are two approaches as I can see.

------------------------------------------------------------------------------------------------

case 1) add a variable on the rules array

static const AppRule rules[] = { \ 
    /*  class    desktop   follow   single */
    { "app1",     1,       True,    True  },
    { "app2",     2,       True,    Flase },
    { "app3",     3,       False,   True  },
    { "app4",     4,       False,   False },
};

desktop is the desktop in which the app should be spawned
follow means that when the app is opened, the desktop should change to the specified desktop.
single means that there should be only one instance of that app.

This sounds good and all, but lets see how those two vars can coexist.

for app1: single is set, so we should scan all desktops looking for that app,
if it's found then it should be transfered to desktop 1
follow is set, so focus should change to that desktop.

for app2: single is not set, so app2 just spawns on desktop 2 and focus should also change to that desktop (follow is set)

for app3: single is set, so we scan every desktop for that app,
if it's found we transfer it to desktop 3
follow is not set so focus isn't changed from the current desktop

for app4: single is not set, so we spawn the app on desktop 4
follow is not set, so focus isn't changed from the current desktop

now, this doesn't actually do what metre wants, but it kinda close.
so I've dropped this behavior (after implementing it duh).

------------------------------------------------------------------------------------------------

case 2) add a method that would fetch the app with the given class/classname

however this has the drawback one would need a new keybind for each app
though, the app would probably have a command too.

static const char *foocmd[] = { "foo", NULL };

static key keys[] = {
    /* modifier          key            function           argument */
    {  MOD1,             XK_f,          fetchwindow,       {.s = "fooclass"}},
};

this is a bit weird, and, the app should also be already open to be fetched.

another choice could be

static const char *foocmd[] = { "foo", NULL };

static key keys[] = {
    /* modifier          key            function           argument */
    {  MOD1,             XK_f,          fetchwindow,       {.com = foocmd}},
};

passing the command, I'd have to spawn the app, get the class name, check if another window with that class name is already open, if found fetch it and close the new app, else just open it. this is harder that it seems

------------------------------------------------------------------------------------------------

another option would be to translate the rules for the apps differently. that is:

static const AppRule rules[] = { \ 
    /*  class    desktop   follow   fetch */
    { "app1",     1,       True,    True  },
    { "app2",     2,       True,    Flase },
    { "app3",     3,       False,   True  },
    { "app4",     4,       False,   False },
};

desktop is the desktop in which the app should be spawned if follow is set or fetch is not set
follow means that when the app is opened, the desktop should change to the specified desktop
fetch means that if an app with that class name is found in any desktop it should be fetched to the current if follow is not set, or to the specified desktop if follow is set

Fetch would do what metre wants. Lets see, again, how those two vars can coexist.

for app1: fetch is set, so we should scan all desktops looking for that app,
if it's found then it should be transfered to desktop 1
and follow is set so focus would also change to desktop 1

for app2: fetch is not set, so app2 just spawns on desktop 2 and focus should also change to that desktop as follow is set

for app3: fetch is set, so we scan every desktop for that app,
if it's found we transfer it to the current desktop
follow is not set so focus isn't changed from the current desktop

for app4: fetch is not set, so we spawn the app on desktop 4
follow is not set, so focus isn't changed from the current desktop

for those that don't want to use fetch:
setting it to False would ignore it and the behavior is the same as if fetch wasn't there.
for that want to use it:
setting fetch to True would mean that
if follow is True the app would be transfered if already exists or opened if it didn't exist to the specified desktop,
else if follow is False, the app would be fetched/opened in the current desktop (what metre asked)

------------------------------------------------------------------------------------------------

I think I choose the last option, I'll implement it today probably, or tommorow, and see how that goes.
It's funny how this turned to be so much more complicated than I expected

Last edited by c00kiemon5ter (2011-12-31 12:53:23)

metre · 2011-12-31 13:41:16

Thank you for the time you dedicated to it. I think this is an interesting feature, and I use it on a regular basis but this fact is not important of course.
As far as I know (to be honest, I know a bit more than nothing), awesome ( http://awesome.naquadah.org/ ) and Stumpwm ( http://stumpwm.org/ ) have this feature but I don't know which other window managers have it.

Last edited by metre (2011-12-31 13:41:55)

c00kiemon5ter · 2011-12-31 20:12:00

I pushed an experimental version of this, on branch 'fetch'. It works, but has a bug, and sometimes fetches the wrong window (:P), misses by one. Will have to look into that.

edit:
figured it out! will push working code now. if anyone already got the previous code for 'fetch' branch, this won't merge. please delete and re-pull the branch.

Last edited by c00kiemon5ter (2011-12-31 20:34:57)

metre · 2012-01-01 17:03:39

Thank you so much, I will try it

ivan22 · 2012-01-01 17:25:42

I tried to run monsterwm today but it doesn't work. No mouse cursor, none of the keyboard shortcut defined in config.h works. No errors in X log. I compiled it from sources downloaded from github.

c00kiemon5ter · 2012-01-01 18:11:26

ivan22 wrote:

I tried to run monsterwm today but it doesn't work. No mouse cursor, none of the keyboard shortcut defined in config.h works. No errors in X log. I compiled it from sources downloaded from github.

by default the only things in the config are dmenu and xterm
so if you got neither, you can't launch any window.

c00kiemon5ter wrote:

the default cursor is the "X" cursor.
To get a common cursor you would need to
xsetroot -cursor_name left_ptr &
in ~/.xinitrc

ivan22 · 2012-01-01 18:16:55

c00kiemon5ter wrote:

ivan22 wrote:
I tried to run monsterwm today but it doesn't work. No mouse cursor, none of the keyboard shortcut defined in config.h works. No errors in X log. I compiled it from sources downloaded from github.
by default the only things in the config are dmenu and xterm
so if you got neither, you can't launch any window.
c00kiemon5ter wrote:
the default cursor is the "X" cursor.
To get a common cursor you would need to
xsetroot -cursor_name left_ptr &
in ~/.xinitrc

Hi cOOkiemon5ter I have xterm installed but alt+shift+enter doesn't run it.

metre · 2012-01-01 21:17:04

c00kiemon5ter wrote:

I pushed an experimental version of this, on branch 'fetch'. It works, but has a bug, and sometimes fetches the wrong window (:P), misses by one. Will have to look into that.
edit:
figured it out! will push working code now. if anyone already got the previous code for 'fetch' branch, this won't merge. please delete and re-pull the branch.

I beg your pardon: have I to use the code from the fetch branch?

c00kiemon5ter · 2012-01-01 21:26:54

Yes, the fetch branch implements that, and works well here. You'll have to change the rules array in the config. see the new config.def.h. I use

{ "Chromium",  0,  False,  True },

and have chromium binded to Win+W, so chromium follows me when I press Win+W

ivan22 wrote:

Hi cOOkiemon5ter I have xterm installed but alt+shift+enter doesn't run it.

It works here and for others, it should work for you. Make sure xterm spawns and doesn't produce any error (usually a font problem)

Last edited by c00kiemon5ter (2012-01-01 21:33:06)

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

some changes on git, I saved 12lines by changing the window list to a singly linked list (and thus saved a tinytiny amount of memory). I rebased the changes to 'fetch' and rebased the whole 'personal' branch to master, which means that if you're following any of those two, you'll need to delete them and repull, or pull with '-X theirs' (I guess).

currently fetch(.c:600 .h:64 sum:664) is 15lines more than master(.c: 587 .h:62 sum:649 -- just 6 lines up from where this was announced from which only 1 goes to .c) and works nicely atm. I'm thinking of pulling it to master. Will wait for metre's responce first.

edit: also fixed some flickering issues reported on irc, when changing windows on fullscreen mode

Last edited by c00kiemon5ter (2012-01-02 04:13:29)

metre · 2012-01-02 13:58:46

I just tried the feature. Maybe it's just me, but it seems to me that Firefox keeps only one istance running as planned, but every time I use its shortcut it goes to the home page. So, I went back to Ratpoison, and when I launched Firefox it asks me about 4 sessions closed badly (I suppose during the utilization of monsterwm). Anyway, Ratpoison is doing the work, so it's not Firefox to blame: I think that the problem is in my configuration, but I don't know C/C++ at all so I don't get it

/* see LICENSE for copyright and license */

#ifndef CONFIG_H
#define CONFIG_H

#define CLEANMASK(mask) (mask & ~(numlockmask | LockMask))

/** buttons **/
#define MOD1            Mod1Mask    /* ALT key */
#define MOD4            Mod4Mask    /* Super/Windows key */
#define CONTROL         ControlMask /* Control key */
#define SHIFT           ShiftMask   /* Shift key */

/** generic settings **/
#define MASTER_SIZE     0.52
#define SHOW_PANEL      False      /* show panel by default on exec */
#define TOP_PANEL       True      /* False mean panel is on bottom */
#define PANEL_HEIGHT    0        /* 0 for no space for panel, thus no panel */
#define DEFAULT_MODE    MONOCLE      /* TILE MONOCLE BSTACK GRID */
#define ATTACH_ASIDE    True      /* False means new window is master */
#define FOLLOW_MOUSE    False     /* Focus the window the mouse just entered */
#define FOLLOW_WINDOW   False     /* Follow the window when moved to a different desktop */
#define CLICK_TO_FOCUS  False     /* Focus an unfocused window when clicked */
#define BORDER_WIDTH    0         /* window border width */
#define FOCUS           "#ff950e" /* focused window border color   */
#define UNFOCUS         "#444444" /* unfocused window border color */
#define DESKTOPS        0         /* number of desktops - edit DESKTOPCHANGE keys to suit */
#define DEFAULT_DESKTOP 0         /* the desktop to focus on exec */
#define MINWSZ          50        /* minimum window size in pixels */

/** open applications to specified desktop **/
/*
 * desktop is the desktop in which the application with the given class/classname will be spawned,
 *         if follow is set or fetch is not set. if fetch is set then the current desktop is used.
 *         desktop index starts from 0.
 * follow  means that the application with the given class will be spawned on the given desktop,
 *         and desktop focus will change to that desktop.
 * fetch   means that if an application with the given class is already open, it will be moved to
 *         the specified desktop, if follow is set, otherwise to the current desktop
 *
 * in the example below:
 *   if app1 isn't opened, it will open on desktop 0 and desktop focus will change to that desktop
 *   if app1 is open, then it will be moved to desktop 0 and the focus will change to that desktop
 *   app2 will open on desktop 1, and desktop focus will change to that desktop
 *   if app3 isn't opened, it will be opened on the current desktop
 *   if app3 is open, then, it will be moved to the current desktop
 *   app4 will open on desktop 3, and focus will stay on current desktop
 */
static const AppRule rules[] = { \
    /* class    desktop   follow   fetch  */
    { "firefox",      0,     False,    True,  }, -----------------------> I tried 'True, True' too, same behavior
};

/* helper for spawning shell commands */
#define SHCMD(cmd) {.com = (const char*[]){"/bin/sh", "-c", cmd, NULL}}

/** commands **/
static const char *termcmd[]  = { "sakura", NULL };
static const char *dmenucmd[] = { "dmenu_run", NULL };
static const char *firefox[] = { "firefox", NULL };


#define DESKTOPCHANGE(K,N) \
    {  MOD1,             K,              change_desktop, {.i = N}}, \
    {  MOD1|ShiftMask,   K,              client_to_desktop, {.i = N}},

/** Shortcuts **/
static key keys[] = {
    /* modifier          key            function           argument */
    {  MOD1|SHIFT,       XK_c,          killclient,        {NULL}},
    {  MOD1,             XK_j,          next_win,          {NULL}},
    {  MOD1,             XK_k,          prev_win,          {NULL}},
    {  MOD1|CONTROL,     XK_r,          quit,              {.i = 0}}, /* quit with exit value 0 */
    {  MOD1|CONTROL,     XK_q,          quit,              {.i = 1}}, /* quit with exit value 1 */
    {  MOD4,       XK_s,     spawn,             {.com = termcmd}},
    {  MOD4,             XK_d,          spawn,             {.com = dmenucmd}},
    {  MOD4,             XK_f,          spawn,             {.com = firefox}},
};

#endif

Last edited by metre (2012-01-02 14:03:15)

c00kiemon5ter · 2012-01-02 14:13:57

metre wrote:

Firefox keeps only one istance running as planned, but every time I use its shortcut it goes to the home page

that's weird

metre wrote:

when I launched Firefox it asks me about 4 sessions closed badly

what happens, is a windows is about to spawn, I get its class and search across all desktops with a window with same class. If I find one, I don't allow the new window to spawn, but close it (should be graceful) and bring the already existent window to the current desktop.

metre wrote:

    { "firefox",      0,     False,    True,  }, // ----> I tried 'True, True' too, same behavior

'False, True' should do it, it works well here for ncmpcpp and chromium
'True, True' would fetch the instance and place it on the given desktop, and then focus that desktop

I will install firefox and test, I may try some different ideas too, and see what's best.
Thanks for testing

Army · 2012-01-02 14:17:19

I'm not completely up to date with the development, but do you have plans on allowing windows to go fullscreen? Like mplayer with "f" or several other applications with F11.

metre · 2012-01-02 14:22:49

c00kiemon5ter wrote:

Thanks for testing

You're welcome.
Anyway, I read this thread http://lists.suckless.org/dev/1112/10475.html , and I thought that maybe you would want to reply to some opinions there.

Last edited by metre (2012-01-02 14:23:09)

Arch Linux

#51 2011-12-29 16:01:46

Re: monsterwm! ~ yet another tiny wm

#52 2011-12-29 21:06:34

Re: monsterwm! ~ yet another tiny wm

#53 2011-12-29 22:09:19

Re: monsterwm! ~ yet another tiny wm

#54 2011-12-30 02:10:48

Re: monsterwm! ~ yet another tiny wm

#55 2011-12-30 09:17:05

Re: monsterwm! ~ yet another tiny wm

#56 2011-12-30 09:40:35

Re: monsterwm! ~ yet another tiny wm

#57 2011-12-30 18:41:29

Re: monsterwm! ~ yet another tiny wm

#58 2011-12-30 18:48:15

Re: monsterwm! ~ yet another tiny wm

#59 2011-12-30 19:26:23

Re: monsterwm! ~ yet another tiny wm

#60 2011-12-30 21:28:14

Re: monsterwm! ~ yet another tiny wm

#61 2011-12-30 22:25:29

Re: monsterwm! ~ yet another tiny wm

#62 2011-12-31 12:49:35

Re: monsterwm! ~ yet another tiny wm

#63 2011-12-31 13:41:16

Re: monsterwm! ~ yet another tiny wm

#64 2011-12-31 20:12:00

Re: monsterwm! ~ yet another tiny wm

#65 2012-01-01 17:03:39

Re: monsterwm! ~ yet another tiny wm

#66 2012-01-01 17:25:42

Re: monsterwm! ~ yet another tiny wm

#67 2012-01-01 18:11:26

Re: monsterwm! ~ yet another tiny wm

#68 2012-01-01 18:16:55

Re: monsterwm! ~ yet another tiny wm

#69 2012-01-01 21:17:04

Re: monsterwm! ~ yet another tiny wm

#70 2012-01-01 21:26:54

Re: monsterwm! ~ yet another tiny wm

#71 2012-01-02 01:05:06

Re: monsterwm! ~ yet another tiny wm

#72 2012-01-02 13:58:46

Re: monsterwm! ~ yet another tiny wm

#73 2012-01-02 14:13:57

Re: monsterwm! ~ yet another tiny wm

#74 2012-01-02 14:17:19

Re: monsterwm! ~ yet another tiny wm

#75 2012-01-02 14:22:49

Re: monsterwm! ~ yet another tiny wm

Board footer