Musca (Tiling Window Manager)

Inxsible · 2009-04-07 07:09:18

aerosuidae wrote:

1. Is Musca memory usage stable, or increasing, for you? I've been using valgrind --leak-check=full so I'm rather hoping it is stable.

Its stable -- it has been in earlier versions as well. stays steady at/or around the same figures.

aerosuidae wrote:

2. What are you checking here? Virtual or resident memory usage?

I just used the ps_mem.py values. If you want, I can re-install 0.9.14 and get the individual values for shared or resident memory and do that for 0.9.15 as well.

aerosuidae wrote:

3. 32 or 64 bit system?

32 bit

Procyon · 2009-04-07 08:28:42

I noticed the rtorrent problem too. It happened when I used dtach to open the same session on two monitors and resized one of them.

I just switched to .15 and the memory usage went up from 1400 to 2000 kb(?) in the same settings. 32 bit, and that is rss memory. I don't mind though.

Frots · 2009-04-07 11:05:06

Anyone knows how to solve this terminal-background-gap problem?

I am using urxvt as terminal emulator but i have the same problem with xterm too...

I tried different utilities to set my background image on the root window

bender02 · 2009-04-07 11:38:52

Well it's not a problem with musca but with the fact that terminal emulators (notably xterm and urxvt, I don't know about the more fancy ones) resize only with multiples of the font size. People had the same problem with ratpoison and dwm:
http://bbs.archlinux.org/viewtopic.php? … 46#p438046

Wra!th · 2009-04-07 11:53:07

@bender: Dwm fixed that problem with adding an option in the config file to ignore size hints. *hint* Maybe musca will add that too? *hint*

@Frots: 3 ways of removing that behaviour:
1. Make your terminal fully transparent, and set bordersize to 0
2. Make your terminal's background have the same color as your desktop's (would require a wallpaperless desktop) and set bordersize to 0
3. Experiment with different fonts and font sizes until you get one right.
The last 2 are obviouslly kind of hard to get used to. I dont use musca, I use Ratpoison, but I went for the first option since Ratpoison has the same behaviour.

Last edited by Wra!th (2009-04-07 11:55:03)

aerosuidae · 2009-04-07 12:58:44

Frots wrote:

Anyone knows how to solve this terminal-background-gap problem?

To be clear, the terminal apps (and for example, gvim) are behaving perfectly legally here. Applications can specify resize hints and the window manager is meant to respect them. Musca makes the window size the largest possible multiple of the resize hint while still being smaller than the frame.

Yes, we can add a setting to turn this off. It will be a mixed blessing as some apps that do specify resize hints don't handle arbitrary sizes gracefully, leading to visual artifacts either way. Six of one, half a dozen of the other... :\

EnvoyRising · 2009-04-07 13:03:12

Thanks for clearing that up for me aerosuidae. I look forward to playing with the new hooks.

aerosuidae · 2009-04-07 13:12:09

Procyon wrote:

I just switched to .15 and the memory usage went up from 1400 to 2000 kb(?) in the same settings. 32 bit, and that is rss memory. I don't mind though.

Sounds roughly similar to .15 rss usage on my 32 bit machine, based on top output. I note Inxisible used ps_mem.py, which tries to get a more "accurate" (no idea what it means though) idea of an app's actual memory usage; there .15 apparently returns around 900kb "ram used", with no mention of rss/virt. Yet lxtask says only 490kb rss. *shrug*.. take your pick.

Frots · 2009-04-07 16:29:54

Wra!th wrote:

@bender: Dwm fixed that problem with adding an option in the config file to ignore size hints. *hint* Maybe musca will add that too? *hint*
@Frots: 3 ways of removing that behaviour:
1. Make your terminal fully transparent, and set bordersize to 0
2. Make your terminal's background have the same color as your desktop's (would require a wallpaperless desktop) and set bordersize to 0
3. Experiment with different fonts and font sizes until you get one right.
The last 2 are obviouslly kind of hard to get used to. I dont use musca, I use Ratpoison, but I went for the first option since Ratpoison has the same behaviour.

Well thanks, I allready did that first option.
The problem is just that I was used to having my background image shine thru with Awesome...

I gues I'll just have to stick with a black background for the time being and hope for some fix like they did with dwm (and awesome??)

Except for this ugly behaviour I fell in love with this WM :-p

Good job and many thanks for this great project!!

Wra!th · 2009-04-07 18:01:43

Frots wrote:

Wra!th wrote:
@bender: Dwm fixed that problem with adding an option in the config file to ignore size hints. *hint* Maybe musca will add that too? *hint*
@Frots: 3 ways of removing that behaviour:
1. Make your terminal fully transparent, and set bordersize to 0
2. Make your terminal's background have the same color as your desktop's (would require a wallpaperless desktop) and set bordersize to 0
3. Experiment with different fonts and font sizes until you get one right.
The last 2 are obviouslly kind of hard to get used to. I dont use musca, I use Ratpoison, but I went for the first option since Ratpoison has the same behaviour.
Well thanks, I allready did that first option.
The problem is just that I was used to having my background image shine thru with Awesome...
I gues I'll just have to stick with a black background for the time being and hope for some fix like they did with dwm (and awesome??)
Except for this ugly behaviour I fell in love with this WM :-p
Good job and many thanks for this great project!!

You don't need to stick with a black background. Make your urxvt 100% pseudo-transparent and you can see the image behind it.That's how I keep it

Inxsible · 2009-04-07 18:07:32

I use .Xdefaults and Xft to have a fading effect. so the desktop looks as if you are seeing thru a translucent sheet of paper while in a terminal.

Inxsible · 2009-04-08 05:46:26

For what its worth. Here's the ps_mem.py output for musca .15

╔═[01:41]═[inxs @ arch]
╚═══===═══[~]>> sudo python ps_mem.py 
Password: 
 Private  +   Shared  =  RAM used    Program 

  4.0 KiB +  37.0 KiB =  41.0 KiB    xinit
  4.0 KiB +  76.5 KiB =  80.5 KiB    login
 60.0 KiB +  24.0 KiB =  84.0 KiB    init
 24.0 KiB +  64.5 KiB =  88.5 KiB    hald-addon-dell-backlight
 80.0 KiB +  30.5 KiB = 110.5 KiB    crond
 92.0 KiB +  32.5 KiB = 124.5 KiB    acpid
 20.0 KiB + 135.0 KiB = 155.0 KiB    agetty (5)
136.0 KiB +  24.0 KiB = 160.0 KiB    dhcpcd
 96.0 KiB +  65.0 KiB = 161.0 KiB    hald-addon-acpi
 96.0 KiB +  70.5 KiB = 166.5 KiB    hald-addon-storage
128.0 KiB +  72.5 KiB = 200.5 KiB    hald-addon-input
132.0 KiB +  70.5 KiB = 202.5 KiB    xbindkeys
184.0 KiB +  22.5 KiB = 206.5 KiB    udevd
140.0 KiB +  86.0 KiB = 226.0 KiB    hald-runner
212.0 KiB +  38.5 KiB = 250.5 KiB    dbus-launch
396.0 KiB +  76.5 KiB = 472.5 KiB    syslog-ng (2)
360.0 KiB + 113.0 KiB = 473.0 KiB    stalonetray
272.0 KiB + 207.0 KiB = 479.0 KiB    console-kit-daemon
292.0 KiB + 264.0 KiB = 556.0 KiB    dbus-daemon (2)
448.0 KiB + 231.5 KiB = 679.5 KiB    conky
668.0 KiB + 128.5 KiB = 796.5 KiB    musca
680.0 KiB + 632.0 KiB =   1.3 MiB    bash (2)
  1.1 MiB + 173.5 KiB =   1.3 MiB    hald
  5.6 MiB + 330.0 KiB =   5.9 MiB    urxvt
 23.7 MiB + 158.0 KiB =  23.8 MiB    Xorg
---------------------------------
                         37.9 MiB
=================================

 Private  +   Shared  =  RAM used    Program 


╔═[01:41]═[inxs @ arch]
╚═══===═══[~]>>

musca is using about 800KB at this time.

And here's the result from htop - at about the same time

Last edited by Inxsible (2009-04-08 05:50:50)

Frots · 2009-04-08 10:29:01

Wra!th wrote:

You don't need to stick with a black background. Make your urxvt 100% pseudo-transparent and you can see the image behind it.That's how I keep it

Wouldn't the text be a bit hard to read? Ofcourse this depends on what kind of wallpaper is chosen I gues...
I used to have the same thing as Inxsible has (a fading effect) maybee someone can show his .Xdefaults? I think i'm doing something wrong somewhere but I don't know what :-p

Thanks anyway!

Wra!th · 2009-04-08 11:38:02

Frots wrote:

Wra!th wrote:
You don't need to stick with a black background. Make your urxvt 100% pseudo-transparent and you can see the image behind it.That's how I keep it
Wouldn't the text be a bit hard to read? Ofcourse this depends on what kind of wallpaper is chosen I gues...

My current setup

Last edited by Wra!th (2009-04-08 11:38:27)

theringmaster · 2009-04-08 18:21:57

Wra!th wrote:

Frots wrote:
Wra!th wrote:
You don't need to stick with a black background. Make your urxvt 100% pseudo-transparent and you can see the image behind it.That's how I keep it
Wouldn't the text be a bit hard to read? Ofcourse this depends on what kind of wallpaper is chosen I gues...
http://omploader.org/tMWhzdw
My current setup

could you post your ps1, I'm sort of liking how you've got that set up.

Last edited by theringmaster (2009-04-08 18:22:12)

problemkenner · 2009-04-09 14:44:52

Hello guys,

what would be the best way for integrating a screenlock into musca in case I'm not at the pc and want to bar my notebook?

The big DE's like Gnome or Kde have such screenlocks but it must be also possible in Musca isn't it?

aerosuidae · 2009-04-09 14:46:44

@problemkenner - Musca does not have a screen lock built in. Use something external like xscreensaver.

rson451 · 2009-04-09 14:57:35

problemkenner wrote:

Hello guys,
what would be the best way for integrating a screenlock into musca in case I'm not at the pc and want to bar my notebook?
The big DE's like Gnome or Kde have such screenlocks but it must be also possible in Musca isn't it?

For a simple approach, check out slock on suckless.org.

problemkenner · 2009-04-09 15:07:38

Both are nice, but slock is exactly what I was looking for.

thanks

Procyon · 2009-04-09 23:51:22

I found a crashing bug.

Step 1: make a binding (I haven't tried with directly using musca -c 'exec ..') that runs a program for a while, like sleep 60. So musca -c 'bind on F9 exec sleep 60'
Step 2: run a window that will end without intervention, like mplayer. Skip it to the last few seconds.
Step 3: cycle to make the window invisible

mplayer stops, musca crashes.

aerosuidae · 2009-04-10 07:13:16

Procyon wrote:

I found a crashing bug.

Thanks for the bug report. I'll do some digging.

(Btw... *hint* https://bugs.launchpad.net/musca *hint* ... )

Procyon · 2009-04-10 18:01:22

I noticed another odd behavior. In firefox when you double click in a flash application, something odd happens where the window seems to turn border on and then back off because I can see some border color on the left side. It happens with border on too though. The address and tab bar (edit: and the flash application) seem to shake a single pixel.

Last edited by Procyon (2009-04-10 18:02:20)

Procyon · 2009-04-11 22:43:03

And I have some problems with an exec keybinding. Sometimes it takes a few seconds to accept it, and it says "timed out" in the log, but I'm not sure where that came from. So I have been using xbindkeys for those bindings that exec.

I also made another script, this time it is much simpler. It is for if you like to use one big frame and sometimes want to use two frames. I like this one a lot because it allows you to scan around the windows or make another window main, while not losing sight of the window you were originally watching.

#! /bin/dash
m() { musca -c "$*"; }

[ $# -ne 1 ] && exit
# possible argument:
# cyclebottom = on 1 frame, split and focus bottom. On two frames, focus and cycle the bottom
# cycletop = on 1 frame, split and put the original focused window in it (using swap) and focus the top. On two frames, focus and cycle top
# uponly = on 1 frame, cycle. On two frames, ufocus and only
# downonly = dfocus and only (and restore the settings you want in the main frame)

cd
m dump .musca_dump
mfact='5/7'
framecount=$(grep ^frame .musca_dump | wc -l)

if [ $framecount -eq 1 -a $1 = cyclebottom ]; then
 m vsplit $mfact
 m dfocus
elif [ $1 = cyclebottom ]; then
 m dfocus
 m cycle
elif [ $framecount -eq 1 -a $1 = uponly ]; then
 m cycle
elif [ $1 = uponly ]; then
 m ufocus
 m only
elif [ $framecount -eq 1 -a $1 = cycletop ]; then
 m vsplit $mfact
 m dswap
 m ufocus
elif [ $1 = cycletop ]; then
 m ufocus
 m cycle
elif [ $1 = downonly ]; then
 m dfocus
 m only
 m catchall on
 m border off
fi

Procyon · 2009-04-12 16:07:02

I had a weird problem after I switched to .16. I thought I'd try out what would happen with a program was in another group when you kill musca. So I killed .15 and started up .16.

But what happened was that wine, firefox and that application (aterm) got lost. No way to raise them again. Only urxvt and mplayer survived, and those were the only visible ones.

And when I move the mouse now from one screen to another the cursor stays where it is, but that may be because of the new Xorg, I started using both at the same time.

Inxsible · 2009-04-12 16:10:39

Procyon wrote:

I had a weird problem after I switched to .16. I thought I'd try out what would happen with a program was in another group when you kill musca. So I killed .15 and started up .16.
But what happened was that wine, firefox and that application (aterm) got lost. No way to raise them again. Only urxvt and mplayer survived, and those were the only visible ones.
And when I move the mouse now from one screen to another the cursor stays where it is, but that may be because of the new Xorg, I started using both at the same time.

I have a similar issue. I lost screen (the app) and there was no way to raise it. Although I could see it running in htop. I haven't tried it with .15 again.

Last edited by Inxsible (2009-04-12 16:12:07)

Arch Linux

#226 2009-04-07 07:09:18

Re: Musca (Tiling Window Manager)

#227 2009-04-07 08:28:42

Re: Musca (Tiling Window Manager)

#228 2009-04-07 11:05:06

Re: Musca (Tiling Window Manager)

#229 2009-04-07 11:38:52

Re: Musca (Tiling Window Manager)

#230 2009-04-07 11:53:07

Re: Musca (Tiling Window Manager)

#231 2009-04-07 12:58:44

Re: Musca (Tiling Window Manager)

#232 2009-04-07 13:03:12

Re: Musca (Tiling Window Manager)

#233 2009-04-07 13:12:09

Re: Musca (Tiling Window Manager)

#234 2009-04-07 16:29:54

Re: Musca (Tiling Window Manager)

#235 2009-04-07 18:01:43

Re: Musca (Tiling Window Manager)

#236 2009-04-07 18:07:32

Re: Musca (Tiling Window Manager)

#237 2009-04-08 05:46:26

Re: Musca (Tiling Window Manager)

#238 2009-04-08 10:29:01

Re: Musca (Tiling Window Manager)

#239 2009-04-08 11:38:02

Re: Musca (Tiling Window Manager)

#240 2009-04-08 18:21:57

Re: Musca (Tiling Window Manager)

#241 2009-04-09 14:44:52

Re: Musca (Tiling Window Manager)

#242 2009-04-09 14:46:44

Re: Musca (Tiling Window Manager)

#243 2009-04-09 14:57:35

Re: Musca (Tiling Window Manager)

#244 2009-04-09 15:07:38

Re: Musca (Tiling Window Manager)

#245 2009-04-09 23:51:22

Re: Musca (Tiling Window Manager)

#246 2009-04-10 07:13:16

Re: Musca (Tiling Window Manager)

#247 2009-04-10 18:01:22

Re: Musca (Tiling Window Manager)

#248 2009-04-11 22:43:03

Re: Musca (Tiling Window Manager)

#249 2009-04-12 16:07:02

Re: Musca (Tiling Window Manager)

#250 2009-04-12 16:10:39

Re: Musca (Tiling Window Manager)

Board footer