monsterwm! ~ yet another tiny wm

c00kiemon5ter · 2012-03-09 03:18:52

bah, my bad, I'll fix it in the morning, it's 5.30am here. I'll get some sleep and fix it once I'm awake
thanks for reporting, and sorry for breaking it

Cloudef · 2012-03-09 07:18:40

Will merge the changes whenever I'm off from my holidays.

c00kiemon5ter · 2012-03-09 22:54:06

I've pushed some changes. This should fix the problem with the invisible borders ( )

Also changed is the focusing behavior. That is when you close a window focus is transfered to the previously focused window. If you close two windows in a row, that means you haven't focus another window, so that, that window can be used as a "previously focused", so focus is now taken to the previous window, of the one that close.

Hope all is good. If you find any problems tell me
thanks!

edit: also just pushed a small fix for fullscreen clients

Last edited by c00kiemon5ter (2012-03-09 23:44:42)

kuraku · 2012-03-10 01:50:04

@c00kiemon5ter
Not sure what you changed but we got borders in monocleborders patch. Now we got new issues.

I will explain this with one, very bad, example:
2nd workspace is my default one (it will be selected when i start monsterwm). If i launch from there firefox, it will spawn on 1st workspace. Now i launch terminal at 2nd workspace and use newsbeuter app for reading feeds. I send any link to firefox and i transfer back to 1st workspace. There should be firefox but there is no client on that workspace. Now i revert back to 2nd workspace where terminal app is. I revert back to 1st one to see if firefox is back but there is no firefox there. Weird. Then i go to 3rd/4th/5th workspace and firefox is back but on 2nd workspace.

Things to have in mind:
- firefox is set to start on 1st and only 1st workspace in config.h (it is set as default tiled window, not float one);
- terminal is started on 2nd workspace by keyboard shortcuts (shift+alt+return);
- on 1st workspace, i can start new clients (terminal in this case) but they are arranged in bstack mode. That means that monsterwm is displaying firefox on bad workspace but it still binds somehow that window to original one (in this case, 1st where firefox should spawn) so on 1st workspace we got one missing client (as master) and others in bstack mode (displayed on that workspace).

I'm not sure what it is but it must have something to do with the new focusing behavior.

p.s. Sorry for really confusing description, i'm not sure how to describe my problem with simpler words.

Last edited by kuraku (2012-03-10 01:54:06)

c00kiemon5ter · 2012-03-10 02:46:24

this shouldn't happen, this occured to me at some point when playing with the code, but it shouldn't be there.
Neither the code nor the test I did show that (or I'm too tired to see it).

I set my browser to start on desk1, set default desktop desk2 and set default mode bstack, on monocle branch.

#define DEFAULT_MODE    BSTACK
..
#define DEFAULT_DESKTOP 1
..
{ "Dwb", 0, False, False },
..

starting on desk2 I launch a terminal, and type 'dwb', which spawns dwb on desk1, I can see that from the statusbar (follow is set to False on the rules). I then open a second terminal, and fire up irc. I have some links there, so I open a couple, and switch to desk1, where the browser is. I can see it fine, with the links opened and correct input.

Are you sure you're using latest code ?
I'm getting firefox to try with it, but it shouldn't happen.

Thanks, I'll report back what I get with firefox.

Edit:

#define DEFAULT_MODE    BSTACK
..
#define DEFAULT_DESKTOP 1
..
{ "Firefox", 0, False, False },
..

firefox works fine too.
Please make sure you cloned the repo.

Last edited by c00kiemon5ter (2012-03-10 02:50:54)

kuraku · 2012-03-10 11:58:33

@c00kiemon5ter

I'm sure that i cloned repo before compiling last night. Anyway, i did this:

git clone https://github.com/c00kiemon5ter/monsterwm
cd monsterwm && git checkout monocleborders

I still get the same error but i managed to find out something new (i will continue on my example above):
Firefox and terminal with newsbeuter are on 2nd workspace. Now, if i start additional terminal on 2nd workspace, firefox goes to 1st worskpace (as it should). Maybe this is some error with focusing default workspace? I tend to use 1 app per workspace so this is very annoying.

This is very weird, i'm not sure what could be the issue. Everything worked 2 days ago but now it is not so pleasant to run it.

c00kiemon5ter · 2012-03-10 12:26:12

could you post your config and .c or some pastebin ? post the links of

$ cat config.h | curl -sF 'sprunge=<-' http://sprunge.us
$ grep -A40 "maprequest(XE.*{" monsterwm.c | curl -sF 'sprunge=<-' http://sprunge.us

Last edited by c00kiemon5ter (2012-03-10 12:26:21)

kuraku · 2012-03-10 12:54:29

@c00kiemon5ter
config.h: http://sprunge.us/iSbJ
monsterwm.c: http://sprunge.us/BUeZ

Also, i would like to add one feature request:
Make monsterwm save size of clients if we change modes. So if i resize master area in bstack and then change to tile (and even then revert back to bstack), make it save clients ratio. It could be nice to have it

Last edited by kuraku (2012-03-10 13:52:58)

c00kiemon5ter · 2012-03-10 13:55:33

I'm writting this from firefox on desktop1, which I spawned with a terminal from desktop2, with your config.
I actually opened three terminals, and wrote 'firefox archlinux.org' , switched to desktop1 and firefox was there waiting with the site.
I can't reproduce, neithrer from the tests, nor the code logic, and I can't think what could be wrong.
The only thing that comes to mind, but I don't consider much possible, is not having installed the new binary correctly, (ie it was not overwritten on make install), but unless you've messed up thing with permissions, this is unlikely. The other thing that I don't know how it works is "app_lancher.sh" but I don't think that could cause something like that.

The problem seems to be that firefox is linked to the wrong client list; the list of clients of another desktop.
But I can't see how that could happen in the code.

EDIT: ah! I managed something, I'm on it!
I have no idea how I did it :S
things are looking good, I think I got it

Last edited by c00kiemon5ter (2012-03-10 15:04:57)

c00kiemon5ter · 2012-03-10 15:19:23

Alright, I think it's good now.
Good catch btw, this was revealed by firefox, as dwb doesn't behave that way.

A similar thing can happen if a window gets fullscreen in a non-focused desktop. This would only happen with a tool like 'wmctrl' ('xdotool' can't make windows fullscreen).
One has to know in which desktop the client that received that message is (eg message 'go fullscreen', or 'open a new tab'). This is fixable, and I will fix it later today or tomorrow.

bloom · 2012-03-10 19:57:01

I just tried monsterwm to see how Gimp would behave and I found a few problems:

Initially, the focus should be given to the main window and not to one of the toolbar windows.
If the focus is on the main window, pressing 'Tab' hides the toolbar windows, pressing 'Tab' again re-enables them but also gives the focus to one of them, at that point, the border of the main window is filled with the focused color no matter what.

I've used the default configuration and the master branch.

Army · 2012-03-10 20:53:23

It's best to use gimp-devel, which supports the one-window-mode. It's pretty stable (never had an issue with it) and works better with tiling window managers imho

c00kiemon5ter · 2012-03-10 21:54:38

bloom wrote:

Initially, the focus should be given to the main window and not to one of the toolbar windows.

this happens, because mosterwm gives focus to the window that appeared last, and that seems to be a toolbar-window

bloom wrote:

If the focus is on the main window, pressing 'Tab' hides the toolbar windows, pressing 'Tab' again re-enables them but also gives the focus to one of them,

same as above

bloom wrote:

... at that point, the border of the main window is filled with the focused color no matter what.

mm, I'm not sure what that means, you mean you have two focused clients at the same time (the main window and the toolbar-window) ?

gimp wasn't designed to work with in a tiling wm,
having said that, it's better to set gimp spawn floating, or
use the 2.7x version that correctly handles gimp as one window.

this however got me into thoughts about a potential bug.. mm

Last edited by c00kiemon5ter (2012-03-10 22:16:30)

kuraku · 2012-03-11 00:09:07

@c00kiemon5ter
Thank you. The bug that i expirienced is fixed now

c00kiemon5ter · 2012-03-11 00:27:27

Great, thanks for reporting

There's another bug I've fixed locally, found on testing gimp (thanks to bloom) that might leave clients unfocused.

I'll push the fix along with some more changes (more breakage ) later or tomorrow.
I'll report when that's done.

bloom · 2012-03-11 09:43:13

Maybe you could use XStringToKeysym and use strings instead of keysyms in the key array (i.e. "foo" instead of XK_foo) ? It would allow non standard keys (e.g. XF86AudioPlay) to work out of the box.
To have regular useless gaps of size GAP, there must be gaps of size GAP/2 around every windows and top/bottom/left/right paddings of size GAP/2: to accomplish that, it seems I would have to modify every layout function to handle left/right padding, am I right?

c00kiemon5ter · 2012-03-11 10:03:34

The way it is now, specified keys (XK_?) is checked on compile time. I don't think I want to change that. To use multimedia keys/non-standard keys just add '#include <XF86kesym.h>' anywhere before the keys[] array, or in mosterwm.c along with the other header includes.

The useless gaps branch should have regular gaps. Check that first.
The bloat branch adds useless gaps to fibonacci layout too.

Last edited by c00kiemon5ter (2012-03-11 10:04:16)

c00kiemon5ter · 2012-03-11 14:11:15

Some changes pushed. I took care and had in mind the recent reports, and I think all is good.

A note, for any future update: if the current state of monsterwm works for you, you can keep the executable (ie mv /usr/local/bin/monsterwm{,.old}) and try the new one. If you find a bug, report and roll back.
Also, note that you dont have to update every time I say I pushed something. If you got work to do, wait a bit to see if anyone reports any bugs introduced and if after 3-4 days there's no report, and you got time, go for it.
I mean, most of the changes aren't major. If there's a big change or bugfix, I'll say so here

I only have one problem now. For tools that need the _NET_ACTIVE_WINDOW to focus a new window (like 'xdotool'), monsterwm, at the moment will not respond. However _NET_ACTIVE_WINDOW is set correctly, so any other operations (but not focusing) should still work. Focusing a new window with xdotool is done with: xdotool windowactivate <window-id>
This will get fixed, I already have a solution, but I don't like it.

Last edited by c00kiemon5ter (2012-03-11 14:12:09)

mhertz · 2012-03-11 16:17:24

.. Just changed over from dwm to monsterwm and so just wanted to say thanks alot to c00kiemon5ter for this great wm!

CU, Martin.

kuraku · 2012-03-11 16:47:08

c00kiemon5ter wrote:

A note, for any future update: if the current state of monsterwm works for you, you can keep the executable (ie mv /usr/local/bin/monsterwm{,.old}) and try the new one. If you find a bug, report and roll back.
Also, note that you dont have to update every time I say I pushed something. If you got work to do, wait a bit to see if anyone reports any bugs introduced and if after 3-4 days there's no report, and you got time, go for it.
I mean, most of the changes aren't major. If there's a big change or bugfix, I'll say so here

We like to help and test new things. That is why, we are making this easier to test and help you build a better software. Speaking of that, i assembled really simple and bad script that will clone monsterwm git repo, with desired branch, backup and compile it. It will make easier to compile monsterwm after every change (i used it, it is working for a few days).

p.s. Yes, it will be simplified (only one git command for cloning desired branch) and enchanced (no .git files in archive) but i'm lazy to do that now.

Last edited by kuraku (2012-03-11 23:28:29)

bloom · 2012-03-12 10:08:04

c00kiemon5ter wrote:

The useless gaps branch should have regular gaps. Check that first.

Yes indeed.

Seems to work fine, although, I wasn't expecting gaps in MONOCLE mode.

firecat53 · 2012-03-13 01:01:58

Ok, I'm admitting defeat here. I'm trying to get my existing statusline.sh that I use with dwm piped together with the monsterwm output into a single dzen2 statusbar instance using dmplex. Here is the script I hacked together from c00keimon5ter's scripts and the dmplex site. I can only ever get the statusline.sh information to appear, plus something is also blocking the monsterwm keybindings preventing any program launching or desktop switching. I tested dmplex on it's own according to their site and it works fine. However, when I add extra statements into the startwm.sh, only the first one is visible in the dzen bar. Dmplex seems to ignore any further inputs. Can anyone see what I'm missing here?

Thanks!
Scott

c00kiemon5ter · 2012-03-13 02:03:21

$ tail -f $fifo | dmplex | dzen2 &

tail will not work here, that's what's blocking anything else.

It's better to give the pipe directly to dmplex

$ dmplex < $fifo | dzen2 &

note, I have no idea how dmplex works, but if it accepts input through a pipe, that should work too.

btw; I tried making monsterwm respect resize hints, but it's not as easy as I thought. There many things I must change to make it work for apps that do not complain if they don't get the requested size. For the apps that do complain (gvim for example) a very simple solution exists (patch below). But I haven't seen any other app, except gvim, do that, so don't expect much from this.

diff --git a/config.h b/config.h
index 69ed697..9e9cef4 100644
--- a/config.h
+++ b/config.h
@@ -26,6 +26,7 @@
 //#define DEFAULT_DESKTOP 0         /* the desktop to focus on exec */
 #define MINWSZ          50        /* minimum window size in pixels */
 //#define USELESSGAP      8         /* the amount of the useless gap in pixels */
+#define RESIZE_HINTS    True
 
 /** open applications to specified desktop **/
 static const AppRule rules[] = { \
diff --git a/monsterwm.c b/monsterwm.c
index 4ec6bae..ecc2a07 100644
--- a/monsterwm.c
+++ b/monsterwm.c
@@ -296,12 +296,9 @@ void clientmessage(XEvent *e) {
 void configurerequest(XEvent *e) {
     XConfigureRequestEvent *ev = &e->xconfigurerequest;
     client *c = wintoclient(ev->window);
-    if (!c || !c->isfullscrn) {
-        XConfigureWindow(dis, ev->window, ev->value_mask, &(XWindowChanges){ev->x,
-            ev->y, ev->width, ev->height, ev->border_width, ev->above, ev->detail});
-        XSync(dis, False);
-    } else setfullscreen(c, True);
-    tile();
+    XConfigureWindow(dis, ev->window, ev->value_mask, &(XWindowChanges){ ev->x,
+        ev->y, ev->width, ev->height, ev->border_width, ev->above,ev->detail });
+    if (c && RESIZE_HINTS) tile();
 }
 
 /* close the window */

also, I got a semi-working nmaster in 10 lines x)

however I'm busy this week, and I might not push anything before friday. time will show. I'll report when things are done

Last edited by c00kiemon5ter (2012-03-13 02:11:41)

firecat53 · 2012-03-13 04:41:23

c00kiemon5ter wrote:

$ tail -f $fifo | dmplex | dzen2 &
tail will not work here, that's what's blocking anything else.
It's better to give the pipe directly to dmplex
$ dmplex < $fifo | dzen2 & 
note, I have no idea how dmplex works, but if it accepts input through a pipe, that should work too.

Still doesn't work. I also tried it by moving the tail -f command into ~/.xinitrc prior to launching startwm.sh, but that didn't work either. It seems like dmplex just won't accept more than 1 input at a time when run this way. But even so, it still won't print out my monsterwm desktop info regardless. I think I'll just go back and create 2 separate dzen instances instead since this seems so difficult! Unless someone wants to tackle this purely to see if it can be done! I've spent waaaay too many hours on this already.

Thanks!
Scott

c00kiemon5ter · 2012-03-13 09:54:37

using dmplex:

fifo="/tmp/dmpipe"
[[ -p $fifo ]] || mkfifo "$fifo"
dmplex < $fifo | dzen2 &

# 2 for the statusline, should show up after monsterwm's output
while sleep 2; do (echo -n "2 "; statusline.sh;); done > $fifo &

monsterwm | while read ..; do
    .
    .
    .
    # 1 for monsterwm, should show up first
    # also some spaces at the end, to separate from statusline
    printf "1 %s%s\n" "$r" "$i  " && unset r
done > $fifo

notice that the dmplex line and statusline both need to be backgrounded ('&')

Last edited by c00kiemon5ter (2012-03-13 09:56:24)

Arch Linux

#401 2012-03-09 03:18:52

Re: monsterwm! ~ yet another tiny wm

#402 2012-03-09 07:18:40

Re: monsterwm! ~ yet another tiny wm

#403 2012-03-09 22:54:06

Re: monsterwm! ~ yet another tiny wm

#404 2012-03-10 01:50:04

Re: monsterwm! ~ yet another tiny wm

#405 2012-03-10 02:46:24

Re: monsterwm! ~ yet another tiny wm

#406 2012-03-10 11:58:33

Re: monsterwm! ~ yet another tiny wm

#407 2012-03-10 12:26:12

Re: monsterwm! ~ yet another tiny wm

#408 2012-03-10 12:54:29

Re: monsterwm! ~ yet another tiny wm

#409 2012-03-10 13:55:33

Re: monsterwm! ~ yet another tiny wm

#410 2012-03-10 15:19:23

Re: monsterwm! ~ yet another tiny wm

#411 2012-03-10 19:57:01

Re: monsterwm! ~ yet another tiny wm

#412 2012-03-10 20:53:23

Re: monsterwm! ~ yet another tiny wm

#413 2012-03-10 21:54:38

Re: monsterwm! ~ yet another tiny wm

#414 2012-03-11 00:09:07

Re: monsterwm! ~ yet another tiny wm

#415 2012-03-11 00:27:27

Re: monsterwm! ~ yet another tiny wm

#416 2012-03-11 09:43:13

Re: monsterwm! ~ yet another tiny wm

#417 2012-03-11 10:03:34

Re: monsterwm! ~ yet another tiny wm

#418 2012-03-11 14:11:15

Re: monsterwm! ~ yet another tiny wm

#419 2012-03-11 16:17:24

Re: monsterwm! ~ yet another tiny wm

#420 2012-03-11 16:47:08

Re: monsterwm! ~ yet another tiny wm

#421 2012-03-12 10:08:04

Re: monsterwm! ~ yet another tiny wm

#422 2012-03-13 01:01:58

Re: monsterwm! ~ yet another tiny wm

#423 2012-03-13 02:03:21

Re: monsterwm! ~ yet another tiny wm

#424 2012-03-13 04:41:23

Re: monsterwm! ~ yet another tiny wm

#425 2012-03-13 09:54:37

Re: monsterwm! ~ yet another tiny wm

Board footer