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.

Re: monsterwm! ~ yet another tiny wm

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.

Re: monsterwm! ~ yet another tiny wm

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!

Re: monsterwm! ~ yet another tiny wm

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.

Re: monsterwm! ~ yet another tiny wm

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.

Re: monsterwm! ~ yet another tiny wm

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.

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

Re: monsterwm! ~ yet another tiny wm

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

Re: monsterwm! ~ yet another tiny wm

guelfi wrote:

I followed this thread for quite some time now, but didn't actually try outmonsterwm because I have a dual-head setup at my desktop PC. Is there any chanceyou will add support for multiple monitors? If you do, I will definetly give ita 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

Re: monsterwm! ~ yet another tiny wm

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.

desktop is the desktop in which the app should be spawnedfollow 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 3follow 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 4follow 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).

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

desktop is the desktop in which the app should be spawned if follow is set or fetch is not setfollow means that when the app is opened, the desktop should change to the specified desktopfetch 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 1and 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 desktopfollow 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 4follow 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)

Re: monsterwm! ~ yet another tiny wm

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.

Re: monsterwm! ~ yet another tiny wm

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

Re: monsterwm! ~ yet another tiny wm

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

Re: monsterwm! ~ yet another tiny wm

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.