Musca (Tiling Window Manager)

aerosuidae · 2009-03-21 04:17:04

Inxsible wrote:

For all those using the musca from AUR, would it be better to not provide the config.h along with the PKGBUILD in the tarball?
I ask because, you can either change the config.h or create a .musca_start file to create keybindings and other things. So if everyone is using the .musca_start method, then there is no need for a config.h to be supplied in the tarball.
Let me know, and I will update accordingly.

Er, what happens when config.h is changed in a release? You yourself tried to use an old config.h with one release and it broke :-)

Please do not remove any source files from the package.

Inxsible · 2009-03-21 04:34:32

Initially I had the following in my .xinitrc

eval `cat $HOME/.fehbg` &
 exec musca

and everything worked fine. This is how it should be at boot:

Now after having added a .musca_start in my /home, I get this behavior.

This is my .musca_start

manage off stalonetray
manage off Conky
manage off Skype
manage off Pidgin

pad 0 0 0 24
exec stalonetray
exec conky
exec skype
exec pidgin
set notify notify-send -t 3000 Musca "%s"

Why is my wallpaper covered with a black screen? I have read about exec being asynchronous, but I haven't changed my .xinitrc so I am setting my wallpaper before starting musca. Also, If I open and close an app this is what I get:

Once I start a full screen app -- everything is as it should be.

Is there a way to be able to get the wallpaper to display correctly?

I even tried adding

exec eval `cat $HOME/.fehbg` &

in .musca_start, but it gives me the same result.

Last edited by Inxsible (2009-03-21 04:38:48)

Inxsible · 2009-03-21 04:41:34

aerosuidae wrote:

Inxsible wrote:
For all those using the musca from AUR, would it be better to not provide the config.h along with the PKGBUILD in the tarball?
I ask because, you can either change the config.h or create a .musca_start file to create keybindings and other things. So if everyone is using the .musca_start method, then there is no need for a config.h to be supplied in the tarball.
Let me know, and I will update accordingly.
Er, what happens when config.h is changed in a release? You yourself tried to use an old config.h with one release and it broke :-)
Please do not remove any source files from the package.

Oh I update the config.h file with the new one each time. I am not removing the config.h from the source file at all. Just allowing users to have a separate copy so that they can edit it to their needs and then use that file while compiling - similar to dwm builds.

aerosuidae · 2009-03-21 05:11:56

Inxsible wrote:

Now after having added a .musca_start in my /home, I get this behavior...Why is my wallpaper covered with a black screen?

If you remove .musca_start, does the behavior change back? Ie, is this a .musca_start bug or a 0.9.9 bug...

Also, does it change if you do a brief sleep in .xinitrc after feh and before musca?

aerosuidae · 2009-03-21 05:21:35

Inxsible wrote:

Oh I update the config.h file with the new one each time. I am not removing the config.h from the source file at all. Just allowing users to have a separate copy so that they can edit it to their needs and then use that file while compiling - similar to dwm builds.

Ok, I guess I don't really know what you mean then So long as the package is always built using a config.h from the same version (in case of struct changes), that is fine.

Inxsible · 2009-03-21 05:22:05

If I remove, musca_start, I only get a black screen even though I am setting the wallpaper in xinitrc.

If I add a sleep between feh and exec musca everything works fine with or without musca_start

aerosuidae · 2009-03-21 05:34:28

Inxsible wrote:

If I remove, musca_start, I only get a black screen even though I am setting the wallpaper in xinitrc. If I add a sleep between feh and exec musca everything works fine with or without musca_start

I think Musca 0.9.9 might be starting up faster than previous versions (I did do some small optimizations to setup()), and therefore the eval feh is not getting the root background set in time for the first frame creation. When you run a full screen app, the frame updates and the background pixmap is refreshed.

X doesn't do real transparency and we are not a compositing window manager, so frames actually simulate it by copying the content of the root window every time they refresh (where move/resize/refocus/app-display triggers the refresh).

Inxsible · 2009-03-21 05:44:07

aerosuidae wrote:

Inxsible wrote:
If I remove, musca_start, I only get a black screen even though I am setting the wallpaper in xinitrc. If I add a sleep between feh and exec musca everything works fine with or without musca_start
I think Musca 0.9.9 might be starting up faster than previous versions (I did do some small optimizations to setup()), and therefore the eval feh is not getting the root background set in time for the first frame creation. When you run a full screen app, the frame updates and the background pixmap is refreshed.
X doesn't do real transparency and we are not a compositing window manager, so frames actually simulate it by copying the content of the root window every time they refresh (where move/resize/refocus/app-display triggers the refresh).

Ok ..Its not a big deal ! I can live with that.

Btw.. I cannot use any of the keybindings for unmanaged apps. For eg. I cannot use Mod+k to kill it. When I do, the window(managed) that is behind it gets killed. Is that a feature?

For eg. I start a pidgin conversation. Once I go to any other app window, like firefox or pcmanfm, I cannot raise the conversation window again. Cannot cycle (Mod+c), nor can I raise the conversation window even if I kill all the other apps.

This means that setting manage off on any app would be pretty much useless for me.

Last edited by Inxsible (2009-03-21 05:45:03)

aerosuidae · 2009-03-21 06:02:22

Inxsible wrote:

Btw.. I cannot use any of the keybindings for unmanaged apps. For eg. I cannot use Mod+k to kill it. When I do, the window(managed) that is behind it gets killed. Is that a feature?

Yes, unmanaged means... unmanaged.

Musca ignores unmanaged apps completely. What is your reason for unmanaging pidgin (I've never used this app so assume I know nothing )?

Inxsible · 2009-03-21 06:09:36

aerosuidae wrote:

Inxsible wrote:
Btw.. I cannot use any of the keybindings for unmanaged apps. For eg. I cannot use Mod+k to kill it. When I do, the window(managed) that is behind it gets killed. Is that a feature?
Yes, unmanaged means... unmanaged.
Musca ignores unmanaged apps completely. What is your reason for unmanaging pidgin (I've never used this app so assume I know nothing )?

I unmanaged pidgin, because I dislike it taking up half the screen. I like it being a small window that I can see for a few seconds...start up a conversation..and close the window while keeping the chat window open.

I might have to start managing skype and pidgin

aerosuidae · 2009-03-21 06:14:49

Inxsible wrote:

I unmanaged pidgin, because I dislike it taking up half the screen. I like it being a small window that I can see for a few seconds...start up a conversation..and close the window while keeping the chat window open.

As you have found, that is not what the unmanage ability is meant for It is meant for stuff like conky and panels.

When I use skype chat, I place it on a separate window group (usually with media player and other background type stuff, all in small frames). Then I run a system tray just visible somewhere on screen with padding on groups so I can see the chat tray icon flashing when someone has something to say.

Inxsible · 2009-03-21 06:16:51

aerosuidae wrote:

Inxsible wrote:
I unmanaged pidgin, because I dislike it taking up half the screen. I like it being a small window that I can see for a few seconds...start up a conversation..and close the window while keeping the chat window open.
As you have found, that is not what the unmanage ability is meant for It is meant for stuff like conky and panels.
When I use skype chat, I place it on a separate window group (usually with media player and other background type stuff, all in small frames). Then I run a system tray just visible somewhere on screen with padding on groups so I can see the chat tray icon flashing when someone has something to say.

Cool. I will have to implement that as well.

Inxsible · 2009-03-21 07:03:53

Hi aerosuidae,

I noticed that you have listed that Mod+Shift+Left would swap the window to the frame in the left and so on for Top, Bottom and Right. But currently these keybindings do not work for me. I checked the config.h file and I do not see the keybindings in the array as well.

Could you add those please?

Last edited by Inxsible (2009-03-21 07:04:22)

Procyon · 2009-03-21 12:12:23

I wrote a script that does what I asked earlier. I haven't tested it thoroughly and I'm not sure exactly how useful it is, but here it is anyway.

It is a bottom stack script, with one large frame at the top, 4 smaller frames of which 1 frame always holds a garbage window (its window will never be selected)
So when you have single window, perform these commands:
vsplit 2/3
dfocus
hsplit 1/4
rfocus
hsplit 1/3
rfocus
hsplit 1/2

Next, when you have populated the frames, make sure the first smaller frames has the garbage window or empty frame and call the script with "init", alternatively you can echo "3" > ~/.musca_select, to set 3.

Then you call the script with "next" or "prev" and it will move the garbage window to main, "minimizing" the main window to its proper frame and then move the prev/next window to main, putting the garbage window in its frame.

#! /bin/bash
# bottom tiling for musca

function m() { musca -c "$*"; }

[ $# -ne 1 ] && exit #call with "next"/"prev"/"init"
[ ! -f ~/.musca_select -o $1 = init ] && echo 0 > ~/.musca_select
[ $1 = init ] && exit

current=$(cat ~/.musca_select) # this is 0, 1, 2, 3

m ufocus # make sure we are at the top

m dfocus # we are now at the right most window (3)

if [ $current = 3 ]; then m uswap
else m lfocus; fi
if [ $current = 2 ]; then m uswap
else m lfocus; fi
if [ $current = 1 ]; then m uswap
else m lfocus; fi
if [ $current = 0 ]; then m uswap; fi

if [ $1 = next ]; then next=$((current+1));
elif [ $1 = prev ]; then next=$((current-1)); fi

if [ $next -eq -1 ]; then next=3
elif [ $next -eq 4 ]; then next=0; fi

m dfocus # at right most window again

if [ $next = 3 ]; then m uswap
else m lfocus; fi
if [ $next = 2 ]; then m uswap
else m lfocus; fi
if [ $next = 1 ]; then m uswap
else m lfocus; fi
if [ $next = 0 ]; then m uswap; fi

echo $next > ~/.musca_select

Here is a version that uses dedicate on on the garbage frame, so you can see more easily which one it is. I dunno whether that is smart/wanted/sane.

#! /bin/bash
# bottom tiling for musca

function m() { musca -c "$*"; }

[ $# -ne 1 ] && exit #call with "next"/"prev"
[ ! -f ~/.musca_select -o $1 = init ] && echo 0 > ~/.musca_select
[ $1 = init ] && exit

current=$(cat ~/.musca_select) # this is 0, 1, 2, 3

m ufocus # make sure we are at the top

m dfocus # we are now at the right most window (3)

if [ $current = 3 ]; then m dedicate off; m uswap
else m lfocus; fi
if [ $current = 2 ]; then m dedicate off; m uswap
else m lfocus; fi
if [ $current = 1 ]; then m dedicate off; m uswap
else m lfocus; fi
if [ $current = 0 ]; then m dedicate off; m uswap; fi

if [ $1 = next ]; then next=$((current+1));
elif [ $1 = prev ]; then next=$((current-1)); fi

if [ $next -eq -1 ]; then next=3
elif [ $next -eq 4 ]; then next=0; fi

m dfocus # at right most window again

if [ $next = 3 ]; then m dedicate on; m uswap
else m lfocus; fi
if [ $next = 2 ]; then m dedicate on; m uswap
else m lfocus; fi
if [ $next = 1 ]; then m dedicate on; m uswap
else m lfocus; fi
if [ $next = 0 ]; then m dedicate on; m uswap; fi

echo $next > ~/.musca_select

aerosuidae · 2009-03-21 13:39:16

Inxsible wrote:

I noticed that you have listed that Mod+Shift+Left would swap the window to the frame in the left and so on for Top, Bottom and Right. But currently these keybindings do not work for me. I checked the config.h file and I do not see the keybindings in the array as well. Could you add those please?

These are in the 0.9.9 config.h.... ?

$ cat musca-0.9.9/config.h | head -n 114 | tail -n 4
    { "Mod4+Shift+Left",    "swap left"     },
    { "Mod4+Shift+Right",   "swap right"    },
    { "Mod4+Shift+Up",      "swap up"       },
    { "Mod4+Shift+Down",    "swap down"     },

aerosuidae · 2009-03-21 13:42:41

Procyon wrote:

I wrote a script that does what I asked earlier. I haven't tested it thoroughly and I'm not sure exactly how useful it is, but here it is anyway.

lol, nice. I stand corrected. I guess we are scriptable enough I suppose we could build scripts to clone all the dwm layouts and behaviors. One thing I'm considering adding are event hooks, which would make this sort of scripting easier.

Hessiess · 2009-03-21 14:23:53

Haven't used Musca yet, Guess I'l try it out sometime. How did you learn to write window managers? I was trying to write one myself, basically that emulates the behaviour of Blender's tiling interface, but without all of the GUI. I put the project to one side simply because I couldn't find any information on how to actually write window managers besides digging through the source code of existing ones, which seam to be totally comment free, so hard and time consuming to learn from.

Currently im using a version of DWM with all the `useless features' (panel and mouse support) taken out.

bavardage · 2009-03-21 14:39:28

Hessiess wrote:

Haven't used Musca yet, Guess I'l try it out sometime. How did you learn to write window managers? I was trying to write one myself, basically that emulates the behaviour of Blender's tiling interface, but without all of the GUI. I put the project to one side simply because I couldn't find any information on how to actually write window managers besides digging through the source code of existing ones, which seam to be totally comment free, so hard and time consuming to learn from.
Currently im using a version of DWM with all the `useless features' (panel and mouse support) taken out.

I'm curently developing for qtile: http://github.com/bavardage/qtile and initially found exactly what you described - WMs are kinda tricky to get your head around. My advice is to just stick at it. Take an existing wm and change it a little, change it a little more, etc.

Allthough the source of wms aren't always properly commented, reading them does help loads and as you become more confident/familiar with writing wms, reading becomes much easier. The xlib manual: http://tronche.com/gui/x/xlib/ is useful.

Procyon · 2009-03-21 16:26:53

I have a feature request, could you add next to cycle, reverse order cycle?

I also made a better script than the bottomstack one, because that one was a bit buggy. I also called it cycle, but it cycles the tiled windows that are visible.

It only works with a bottom stack layout of 1 window at the top and 3 windows at the bottom. But it shouldn't be too hard to change that, but it takes a bit of puzzling.

You get that layout with:

only
vsplit 2/3
dfocus
hsplit 1/3
rfocus
hsplit 1/2
ufocus

And then call the script with clockwise or anticlockwise.

#! /bin/bash
# cycle tiled windows for musca with bottom stack with 4 total window, 1 top, 3 bottom
#Main: win0
#Bottom: win1 | win2 | win3

function m() { musca -c "$*"; }

[ $# -ne 1 ] && exit #call with clockwise/anticlockwise

m ufocus

if [ $1 = clockwise ]; then
m dfocus #win3
m lfocus #win2
m lswap #win1
m rfocus #w2
m rswap #w3
m uswap #main
fi

if [ $1 = anticlockwise ]; then
m dswap #w3
m lswap #w2
m lswap #w1
m ufocus
fi

Runiq · 2009-03-21 22:13:05

Inxsible wrote:

For all those using the musca from AUR, would it be better to not provide the config.h along with the PKGBUILD in the tarball?
I ask because, you can either change the config.h or create a .musca_start file to create keybindings and other things. So if everyone is using the .musca_start method, then there is no need for a config.h to be supplied in the tarball.
Let me know, and I will update accordingly.

Hm... Coming from dwm, I'm still using the config.h method. Using .musca_start never even crossed my mind... *scratches head* Guess it's time to change that.

Inxsible · 2009-03-21 22:39:40

Runiq wrote:

Hm... Coming from dwm, I'm still using the config.h method. Using .musca_start never even crossed my mind... *scratches head* Guess it's time to change that.

Me too. But I am thinking of slowly moving to musca_start. The only thing that I am wondering is that the more keybindings and other musca commands we put in, the slower it will be to start the WM. When its compiled in config.h you don't have to do it everytime.

I have about 40+ keybindings (for apps and I have changed the default ones too), so that would be a huge deal given that I also try to set up my groups.

So I have come to a compromise where all my shortcuts are in config.h and only the setting of groups etc and starting of some apps is in musca_start.

Last edited by Inxsible (2009-03-21 22:41:15)

Procyon · 2009-03-21 22:50:34

@Inxsible: you should try out xbindkeys

aerosuidae · 2009-03-21 23:50:37

Procyon wrote:

I have a feature request, could you add next to cycle, reverse order cycle?

Someone on the mailing list has actually contributed a patch to do exactly this. It will appear in the next release.

aerosuidae · 2009-03-21 23:55:29

Inxsible wrote:

Me too. But I am thinking of slowly moving to musca_start. The only thing that I am wondering is that the more keybindings and other musca commands we put in, the slower it will be to start the WM. When its compiled in config.h you don't have to do it everytime. I have about 40+ keybindings (for apps and I have changed the default ones too), so that would be a huge deal given that I also try to set up my groups.

Actually, there will be very little difference. config.h has the defaults listed as text strings like "Mod4+h" which is the same as you would use in your musca_start anyway. Key bindings get parsed the same way at startup no matter what. Also, I doubt there are enough keys on your keyboard to stress a modern machine since this is really very little text to parse. Any commands like hsplit or exec will be an order of magnitude slower than 100 key bindings.

Runiq · 2009-03-22 00:27:51

aerosuidae wrote:

Inxsible wrote:
Me too. But I am thinking of slowly moving to musca_start. The only thing that I am wondering is that the more keybindings and other musca commands we put in, the slower it will be to start the WM. When its compiled in config.h you don't have to do it everytime. I have about 40+ keybindings (for apps and I have changed the default ones too), so that would be a huge deal given that I also try to set up my groups.
Actually, there will be very little difference. config.h has the defaults listed as text strings like "Mod4+h" which is the same as you would use in your musca_start anyway. Key bindings get parsed the same way at startup no matter what. Also, I doubt there are enough keys on your keyboard to stress a modern machine since this is really very little text to parse. Any commands like hsplit or exec will be an order of magnitude slower than 100 key bindings.

Cool, I'll switch. *waves good-bye to frequent recompilation* It was fun while it lasted. Kinda.

Arch Linux

#76 2009-03-21 04:17:04

Re: Musca (Tiling Window Manager)

#77 2009-03-21 04:34:32

Re: Musca (Tiling Window Manager)

#78 2009-03-21 04:41:34

Re: Musca (Tiling Window Manager)

#79 2009-03-21 05:11:56

Re: Musca (Tiling Window Manager)

#80 2009-03-21 05:21:35

Re: Musca (Tiling Window Manager)

#81 2009-03-21 05:22:05

Re: Musca (Tiling Window Manager)

#82 2009-03-21 05:34:28

Re: Musca (Tiling Window Manager)

#83 2009-03-21 05:44:07

Re: Musca (Tiling Window Manager)

#84 2009-03-21 06:02:22

Re: Musca (Tiling Window Manager)

#85 2009-03-21 06:09:36

Re: Musca (Tiling Window Manager)

#86 2009-03-21 06:14:49

Re: Musca (Tiling Window Manager)

#87 2009-03-21 06:16:51

Re: Musca (Tiling Window Manager)

#88 2009-03-21 07:03:53

Re: Musca (Tiling Window Manager)

#89 2009-03-21 12:12:23

Re: Musca (Tiling Window Manager)

#90 2009-03-21 13:39:16

Re: Musca (Tiling Window Manager)

#91 2009-03-21 13:42:41

Re: Musca (Tiling Window Manager)

#92 2009-03-21 14:23:53

Re: Musca (Tiling Window Manager)

#93 2009-03-21 14:39:28

Re: Musca (Tiling Window Manager)

#94 2009-03-21 16:26:53

Re: Musca (Tiling Window Manager)

#95 2009-03-21 22:13:05

Re: Musca (Tiling Window Manager)

#96 2009-03-21 22:39:40

Re: Musca (Tiling Window Manager)

#97 2009-03-21 22:50:34

Re: Musca (Tiling Window Manager)

#98 2009-03-21 23:50:37

Re: Musca (Tiling Window Manager)

#99 2009-03-21 23:55:29

Re: Musca (Tiling Window Manager)

#100 2009-03-22 00:27:51

Re: Musca (Tiling Window Manager)

Board footer