You are not logged in.
I tested the new floating mode. Works great, except of one thing: If I hold Mod4 (that's how I configured it), press button 1 on the mouse and then move the mouse on a _selected_ window, nothing happens. It only works for windows, which are not selected. Might be no bug but a feature, but I don't see it
hmm, if the shortcut is caught, then the window under the mouse should be highlighted. I change my config to test, and works as expected.
{ MOD4, Button1, mousemotion, {.i = MOVE}},
.:[ git me! ] :.
Offline
Tested with 4 open xterms, works once then cant seem to move anything (in float mode) after that...
Only changes to config.h below
#define FOLLOW_WINDOW True /* Follow the window when moved to a different desktop */
#define CLICK_TO_FOCUS True /* Focus an unfocused window when clicked */
Offline
Really, really, close cookie, but now _CLICK_TO_FOCUS doesn't work... no sweat you always come through, crack on.
Offline
No prob Question... is the mouse being released after a grab? Monsterwm works perfectly, but after a move/resize, further mouse input is being withheld. For instance, I can move & resize a given window, yet cant seem to (say) click a hyperlink in firefox...
Last edited by topcat-software (2012-01-14 14:11:10)
Offline
Chuckle, sounds good. I'll test it right now... btw cookie: I think I've uncovered a side-effect of floating mode only now just discovered...
if a window is resized to a ridiculously small rectangle, monsterwm segfaults...
Offline
Yep, I just pushed a fix for this, window width and height is now checked to not be less than MINWSZ as is done with master window resizing. This can now be exploited only when resizing the first stack window, where no such check exists, or if the MINWSZ value is set too low.
.:[ git me! ] :.
Offline
You nailed it. Hats off to you - you're very quick on your feet I gotta admit. I'm really impressed with monsterwm, you've done an outstanding job of keeping on-top of things & believe me cookie, I don't give out compliments lightly. Crack on.
Offline
https://github.com/Cloudef/monsterwm-xcb
I just finished porting monsterwm to xcb. It might still have issues that do not appear on upstream monsterwm.
So testers are welcome. If you caught any issues that only appear on -xcb please report them @ github page.
I'll keep maintaining and merging upstream to -xcb for now.
Last edited by Cloudef (2012-01-14 20:06:49)
Offline
Thanks for the Monterous WM I just compiled it and set it up on my ubuntu 12.04 Adding my dzen2 looking forward to this windows manager as I have a c++ background! Thanks I was going to pull my hair out if I had to deal with unity much longer!
gj Hope this get maintained
Archlinx + DWM I love Wingo-WM Bring it back!!
Offline
It's been a rainy Sunday here so I've been at the keyboard most the day and have made some_sorta_bar alot friendlier. Now the source can be edited, the bar rebuilt, the running one killed and a new one started which should be on all desktops and up the top, showing the same info if you have set the root window name right. Thanks to everyone that gave it a go as it was just a quick hack to see how light a simple bar could be. Mhertz asked for a simple, light bar so I hacked one together from what I had done with snapwm and was suprised at how much extra mem was used when something needed its' own pid. But if you have a simple output to show and like using something light there's a little bit to gain.
Cheers
Last edited by moetunes (2012-01-15 07:30:31)
You're just jealous because the voices only talk to me.
Offline
I just compiled it and set it up on my ubuntu 12.04
Nice to know it, I really appreciate that you can use it on another distro
Offline
Thanks alot cookie, Cloudef and moetunes!
Now some_sorta_bar appears upon all workspaces, so that's great!
I've taken monsterwm-xcb for a spin, and it seems to work great for the few minuttes i've tested it!
Note that you need two extra packages to build the xcb-port: xcb-util-wm and xcb-util-keysyms...
Here's the latest ps_mem.py values on arch64 for monsterwm, monsterwm-xcb and some_sorta_bar, and with latest dwm-hg-tip thrown in for good messure(vanilla, unpatched version + another patched with 7 patches; pertag2, push, cycle, gaplessgrid, monocle_count, monocle_no_borders and viewontag):
Private + Shared = RAM used Program
236.0 KiB + 151.5 KiB = 387.5 KiB monsterwm
15.1 MiB + 515.0 KiB = 15.6 MiB Xorg
---------------------------------
Private + Shared = RAM used Program
200.0 KiB + 54.0 KiB = 254.0 KiB monsterwm-xcb
13.4 MiB + 515.0 KiB = 13.9 MiB Xorg
---------------------------------
Private + Shared = RAM used Program
372.0 KiB + 231.5 KiB = 603.5 KiB dwm
13.2 MiB + 957.0 KiB = 14.2 MiB Xorg
---------------------------------
Private + Shared = RAM used Program
368.0 KiB + 233.5 KiB = 601.5 KiB dwm-patched
13.2 MiB + 959.0 KiB = 14.2 MiB Xorg
---------------------------------
Private + Shared = RAM used Program
248.0 KiB + 146.5 KiB = 394.5 KiB some_sorta_bar
I've added the xorg processes to the comparisons, since ps_mem.py dosen't count memory used by one app in another app, and if you notice, then the xcb port of monterwm, uses about 1.7mb less in the xorg process than with the x11 monsterwm, besides the about 150kb less in the main app process...
Also, of note, is that in this comparisson, then while allthough dwm is using more memory in the main process than the others, then it uses about 1.4mb less memory in the xorg process than monsterwm, but about 300kb more than monsterwm-xcb...
Last edited by mhertz (2012-01-16 01:07:00)
Offline
I've taken monsterwm-xcb for a spin, and it seems to work great for the few minuttes i've tested it!
Note that you need two extra packages to build the xcb-port: xcb-util-wm and xcb-util-keysyms..
Thank you for testing. I had the full list of packages there before, but took them out for some reason.
I put them back now at github page.
The memory usage reads look interesting as well.
I think the dwm usage in Xorg shows up less because it requests less wm/net atoms by default (as in vanilla) or something along that.
I guess, I could investigate using xcb and see what increases the usage there that much.
(My dwm fork is quite bloated as it uses 2mb~ by itself)
You could prob win over some ram from the simple bar, if it were done in xcb as well.
Though I will write patches for bar inside monsterwm whenever we get dualhead support (I might even work on that too, if I have time)
Last edited by Cloudef (2012-01-15 18:49:18)
Offline
Would it be possible to move and resize floating windows with the keyboard? Right now that's the only thing that has to be done with the mouse, would be awesome if the mouse wouldn't be needed at all!
Also, there's a bit a strange behavior with easytag with the new floating capabilities. The master area stays empty after startup, I have to do a "swap_master", so it uses the whole screen. Why is the master area empty? It's no biggie, working with monsterwm + easytag works just fine, I'm just wondering if there's some space for improvements left. So far I like the floating in monsterwm a lot! Great job cookie, just like every day in the past weeks!
I'll check out the xcb fork, ran it once, had a lot of trouble with fullscreen apps, so I'll have to collect data for a bugreport. Still, Cloudef, it's SO cool that you ported monsterwm to xcb!
Last edited by Army (2012-01-15 22:53:52)
Offline
I'll check out the xcb fork, ran it once, had a lot of trouble with fullscreen apps, so I'll have to collect data for a bugreport. Still, Cloudef, it's SO cool that you ported monsterwm to xcb!
Sounds good, I'll be back today later, So I can check it out myself too
Offline
Ok, now mplayer doesn't disappear anymore after hitting "f". I tested a few other applications. I don't have that many which support a fullscreen mode, but I have problems with luakit (hitting "F11" makes it go fullscreen) and libreoffice-impress. Luakit just doesn't go back from fullscreen anymore and libreoffice-impress (hitting "F5") opens a new window which doesn't show up fullscreen in monsterwm-xcb-git (I already created a PKGBUILD, mind if I upload it to the AUR?). Monsterwm by cookie had this problem as well, but he solved it, see here.
The last problem I see is, after working with monsterwm-xcb-git for a few minutes, the cpu usage of monsterwm freaks out. I don't know yet which action causes this, but I'll find out and tell you. The cpu usage doesn't go back to normal after restarting the whole X session!
Sorry for writing this here, I can post it as a bug report if you want me to, I have an account on github. And I also don't want to hijack this thread of course.
Last edited by Army (2012-01-16 10:04:53)
Offline
I think the main loop might be cause of CPU usage going crazy, now that I look at it Late night coding FTW. Anyways, the full screen bugs sound like I still handle atoms wrongly with xcb. I'll check these bugs out when I get home.
AUR package is fine, however still it isn't yet stable port it seems.
Last edited by Cloudef (2012-01-16 10:27:35)
Offline
Ok, I'll update the package this evening and if those issues are solved, I think it's stable enough, especially since there don't seem to be other bug reports, right?
Offline
Ok, I'll update the package this evening and if those issues are solved, I think it's stable enough, especially since there don't seem to be other bug reports, right?
I guess so, I'm too scared to declare anything as stable
Anyways, just keep in mind that I'm not using monsterwm as my main WM yet as I need dual head support.
So it's not unlikely that there might be bugs crawling out that I don't know about. I'm doing all the testing inside Xephyr.
Also on the bug reporting, I guess it's ok to report -xcb bugs here as well if c00kiemon5ter is okay with it. But keep in mind that I might not notice them always.
Github page allows me to keep track of them easily and see, if they are -xcb only bugs.
Last edited by Cloudef (2012-01-16 11:53:22)
Offline