Musca (Tiling Window Manager)

cmlr · 2011-08-16 14:24:53

nem wrote:

i'm thinking a lot about the way of applicationmapping to certain frames/groups but still couldn't come up with an overall satisfying solution. what i try to avoid is redundancy - thus new functions should provide meta-functionality (such as mapping them not only to groups but to groups and/or frames chosen by parameters) but also avoid interference with already implemented functionality (and of course it has to fit into musca internal workings). another example is the request for 'focus last focussed' of which i'm still thinking of a way to get done nicely and not restricted to a very specific case.
the function to bring up an empty group (as mentioned in a previous post) is a step in the direction of getting apps spawned in a new group. there's a new muscacommand 'gnew' which spawns a new group and focusses it. then 'hook on ^gnew shell' and 'bind Mod1+b gnew' creates a new group and spawns dmenu to choose an app to launch. if i don't come up with a different method, this is a nice way in the next patch to spawn new apps on new groups without moving them around.
i also strongly consider removing groupnames, since they are somewhat pointless in my opinion (unless someone brings up a good reason to keep them). appmapping will most probably be similar to dwm's method (having an array in config.h with apps->groups, but also providing a .musca_start 'frontend' for it).
so that was some insight in my 'future plans' (none of what i mentioned is implemented in the AUR version yet). i'm not blindly putting stuff in but try to keep the structure of musca coherent and (over time) try to simplify/optimize some stuff. beware that it might take some time to get all of this done. those really are raw ideas of which just a minor part is implemented in a testingstage. i'm not yet familiar with 100% of the musca-structure which also slows the development down besides my small timeframe available to do this. but it's getting there
regards,
nem
edit: actually i just saw, that the muscacommand 'add' provides the 'gnew' functionality already - so if i'm going to drop groupnames you'll be able to simply create a new group with 'add' (which only works with a given new groupname at the moment).

One reason to keep names is that it's easy to select groups using dmenu.

mhertz · 2011-08-16 15:57:36

Imho, then making a new group with whatever name and then opening an app in it, shouldn't need to be added in a patch, since people should simply set their config file up with keybinds themselves for making a new group, and then they can just open the app afterwards, with keybinds, dmenu or whatever, or use the dmenu hook themselves...

bind on Mod4+1 use 1
bind on Mod4+2 use 2
bind on Mod4+3 use 3
bind on Mod4+4 use 4
bind on Mod4+5 use 5
bind on Mod4+6 use 6
bind on Mod4+7 use 7
bind on Mod4+8 use 8
bind on Mod4+9 use 9
bind on Mod4+0 use 0

('use' will also make the group and focus it, if it dosen't exist allready...)

...And I also "vote" for keeping group names, like in the above, then if you need a new group and don't care what it's named, you just hit Mod4+[0-9]... No need to remove group names for that...

Last edited by mhertz (2011-08-16 16:03:47)

gorilla · 2011-08-16 19:20:10

Thats exactly what I have in my .musca_start... It works better with "group_close_empty 0". Otherwise it could be confusing sometimes...

mhertz · 2011-08-18 10:53:47

I've found that personally I now preffer this:

name one
bind on Mod4+1 use one 
bind on Mod4+2 use two
bind on Mod4+3 use three
bind on Mod4+4 use four
bind on Mod4+5 use five
bind on Mod4+6 use six
bind on Mod4+7 use seven
bind on Mod4+8 use eight
bind on Mod4+9 use nine
bind on Mod4+Shift+1 move one 
bind on Mod4+Shift+2 move two
bind on Mod4+Shift+3 move three
bind on Mod4+Shift+4 move four
bind on Mod4+Shift+5 move five
bind on Mod4+Shift+6 move six
bind on Mod4+Shift+7 move seven
bind on Mod4+Shift+8 move eight
bind on Mod4+Shift+9 move nine

Then you can now e.g. press mod4+shift+n to move currently focused app into a new non existing group, which you cannot when using 0-9. This also fixes another issue, where when you want to move an app into e.g. group named 3, then the app is moved into the group with index number 3, and which dosen't necceserailly needs to also be named 3... Finally it also fixes the "3 groups with same name but different index, which is gotten after pressing e.g. mod4+2 three times and using 0-9 groups", but which can also be bypassed with 'set group_close_empty 1'...

Personally, i'm not a big fan of the index numbers of groups, and wouldn't mind them gone and then just keeping/sticking to the name, which also would make the above workaround redundant...

Last edited by mhertz (2011-08-19 15:50:27)

Wintervenom · 2011-08-23 05:54:27

If anyone happens to (still) be looking for a nice way of displaying Musca's windows and groups in a bar, [I have re-written my old cyclic Xmobar output script in Python]. It now feeds directly to Xmobar via StdinReader and, unlike the Bash version, is very light on CPU.

[Here is a screenshot] of what it looks like.

mhertz · 2011-08-24 17:57:29

..I don't like having statusbars to take up screen real-estate, but as I do like to be able to monitor battery level, volume and time once in a while, but without wasting my precious pixels, then I just bind this key-combo:

bind on Mod4+F3 exec echo "$(date | cut -d " " -f4) | $(acpi | cut -d " " -f4-5 | tr -d ",") | Vol.$(amixer get Master | tr -d "\n" | cut -d " " -f26 |
 tr -d "[]")" | dmenu

Then when pressing mod4+f3, then dmenu shows e.g.:

19:49:05 | 81% 03:22:02 | Vol.16%

I do have to press esc though, to remove the "statusbar" again, but i'd rather do that, and reuse the allready provided dmenu, than having to install e.g. dzen2 just for this one thing...

Nothing revolutionary with this at all, but just nonetheless...

Last edited by mhertz (2011-08-24 22:21:35)

cmlr · 2011-08-31 01:43:59

In the last few days I've started having a problem with firefox on Musca. Even though I've limited the display with pad, firefox maximizes to take over the whole screen. F11 doesn't work to make it smaller, and I can't switch to another group. Logging out works, and that's all I can do.

nem · 2011-08-31 08:53:46

cmlr wrote:

In the last few days I've started having a problem with firefox on Musca. Even though I've limited the display with pad, firefox maximizes to take over the whole screen. F11 doesn't work to make it smaller, and I can't switch to another group. Logging out works, and that's all I can do.

i don't have a problem with firefox and padding. do you use the current version of musca from aur? any fancy firefox addons or other uncommon stuff? does it immediately switch to fullscreen? or how and when does it happen? any way to reproduce it?

cmlr · 2011-08-31 14:20:20

nem wrote:

cmlr wrote:
In the last few days I've started having a problem with firefox on Musca. Even though I've limited the display with pad, firefox maximizes to take over the whole screen. F11 doesn't work to make it smaller, and I can't switch to another group. Logging out works, and that's all I can do.
i don't have a problem with firefox and padding. do you use the current version of musca from aur? any fancy firefox addons or other uncommon stuff? does it immediately switch to fullscreen? or how and when does it happen? any way to reproduce it?

Yes, I'm using the current Musca from AUR, the one discussed on this thread. I have a few Firefox addons, but only flashblock and a few others which shouldn't cause a problem. Yes, it immediately switches to full screen without any action on my part. Strangely, it happens on my laptop at home but not on my office computer.

cmlr · 2011-08-31 23:24:45

cmlr wrote:

nem wrote:
cmlr wrote:
In the last few days I've started having a problem with firefox on Musca. Even though I've limited the display with pad, firefox maximizes to take over the whole screen. F11 doesn't work to make it smaller, and I can't switch to another group. Logging out works, and that's all I can do.
i don't have a problem with firefox and padding. do you use the current version of musca from aur? any fancy firefox addons or other uncommon stuff? does it immediately switch to fullscreen? or how and when does it happen? any way to reproduce it?
Yes, I'm using the current Musca from AUR, the one discussed on this thread. I have a few Firefox addons, but only flashblock and a few others which shouldn't cause a problem. Yes, it immediately switches to full screen without any action on my part. Strangely, it happens on my laptop at home but not on my office computer.

I started with a fresh .mozilla folder, and all was well. So it must have been some configurations from an old version. Still I'm puzzled that it disabled musca that way.

Last edited by cmlr (2011-08-31 23:25:19)

mhertz · 2011-09-01 00:22:44

I noticed a bug which also is on the musca bugtracker, about when dumping a frame layout and latter loading it into the current group, then the current group's name gets overwritten with the dump files originally defined groupname...

Second, I have previously asked for support for defining upon which frame/group an app should be opened in from .musca_start, but I now see that in v0.9.23, then the exec command where made to open apps in the current open group i.e. "use one; exec foobar", so now the only issue is the frames, since the exec command run asynchroniously and so could open in whatever frame focused at the time the app finishes loading.

Maybe it could help to look in ratpoisons code, which has a command called 'execf <frame-nr.> <command>', which imho would be a great addition to musca...

About the group names, then I again vote to keep them(+ the index numbers), and if the only problem is that e.g. the add command needs a group name, then the add command could be changed so as if no group name given, then just use e.g. 'undefined' or something...

Also, I think it could be nice to have an option for when moving a window into a group, then also change to that group, just like there is a dwm patch that does on suckless's patch section.

Finally, to have no borders on maximized windows, then I tried to do e.g. this:

set border_width 0
border off
hook on ^(vsplit|hsplit) set border_width 1
hook on ^only set border_width 0

The reason I add 'border off' additionally, is because I have to do that, to update the display to reflect the 'set xxx' change(no, 'refresh' dosen't work), but this then also makes this to not work right, since when I e.g. do hsplit, then the borders dosen't come up, but first after I hsplit again! So it could be nice if the set command could be defined to update musca immidiatelly, so e.g. this workaround would work..

I've also tried to on the above hooks instead use e.g.

hook on ^(vsplit|hsplit) exec echo "set border_width 1\nborder on" | musca -i
hook on ^only exec echo "set border_width 0\nborder off" | musca -i

But still it happens first upon second keypress and not the first as it should...

..Just some thoughts

Last edited by mhertz (2011-09-01 22:51:19)

mhertz · 2011-09-03 21:44:52

Ok, I finally figured out a solution for getting automatic borderless-fullscreen

Place the following into your .musca_start:

border off
hook on ^(hsplit|vsplit) border on
hook on ^(only|add) border off
hook on ^(use|remove) exec [ `musca -c "show frames" | wc -l` -eq 1 ] && musca -c "border off"

This will then give you a borderless window upon startup(unless of-course if you split the screen in .musca_start), and also new groups added with 'add' will be borderless.

Then when spliting the screen, the borders will reappear, and when using 'only', then the borders will go away. The borders will also go away if using 'remove' when there's only one "split" to remove, but not if there's more than one "split" to remove.

Finally, when using 'use' to make new groups('use' will make a new group if the given groupname dosen't allready exist), then the borders are removed, and if it's an allready existing group, then it's just switched to and it's border on/off state(i.e. split/non-split) is just retained.

Btw, i've just made my volume keybinds, dzen2 enabled, with a 1 sec. notification message:

bind on XF86AudioRaiseVolume exec amixer set Master 5%+ unmute | tail -n1 | cut -d " " -f6 | tr -d "[]" | dzen2 -p 1 -w 300 -x 535 -fg white
bind on XF86AudioLowerVolume exec amixer set Master 5%- unmute | tail -n1 | cut -d " " -f6 | tr -d "[]" | dzen2 -p 1 -w 300 -x 535 -fg white
bind on XF86AudioMute exec amixer set Master toggle | tail -n1 | cut -d " " -f8 | tr -d "[]" |dzen2 -p 1 -w 300 -x 535 -fg white

And this is my dzen2 5 sec. notification of time, battery and current vol. level:

bind on Mod4+F3 exec echo "$(date | cut -d " " -f5) | $(acpi | cut -d " " -f4-5 | tr -d ",") | Vol.$(amixer get Master | tail -n1 | cut -d " " -f6 | tr
 -d "[]") $(amixer get Master | tail -n1 | cut -d " " -f8 | tr -d "[]")" | dzen2 -p 5 -w 300 -x 535 -fg white

This is imho nicer than wasting screen real-estate/cpu-cycles on having a static statusbar which polls every x seconds...

Last edited by mhertz (2011-09-04 00:51:26)

mhertz · 2011-09-05 21:55:15

..Just wanted to add that my feature-request about getting an equavilent for ratpoisons 'execf' command, which lets you define in which frame to start an app, actually isn't needed, since musca's 'exec' command allready remembers current frame and pairs that with the app-to-run's _NET_WM_PID, so please disregard that... (I must have done something wrong in the past, when I had problems with musca's 'exec' command through .musca_start, or maybe some of the apps I tested with didn't support _NET_WM_PID...).

I stumpled upon this quote about it, when browsing through the revision commits history at the launchpad musca code repo:

Started by
Sean Pringle on 2009-05-16
Related branches
Related bugs
Sprints
Feedback requests
Sean Pringle requested feedback from zmyrgel:
Revision 210 of the Musca dev tree checks _NET_WM_PID to associate new windows with process ids. It also tracks child pids when launching apps with Musca's exec command, along with the group and frame focussed at the time of launch. These two features allow us to map new windows on the group and frame from which they were launched, even if groups or have since been switched.
Important to note that this will only work for:
- apps that support _NET_WM_PID (many modern apps, most of gnome, not old X apps etc)
- apps launched with Musca's exec command (via M+x or musca -c "exec ...")
Could use some testing if you're keen ;-)
cheers

Sorry about that...

Edit: Crap! I just tested it again, and even though 'wmctrl -l -p' shows that the two apps i've tested with: jumanji and urxvtc, does have pids, then the 'exec' command sometimes places the apps into right frames and sometimes dosent, which means that it dosen't work as it should!

Oh well, it can be workaround with running the apps from .xinitrc while placing sleeps in between each app and also musca, but would've been nice to have imho nonetheless...

For groups it does work though, strangelly...

Last edited by mhertz (2011-09-05 22:54:00)

diabol · 2011-09-13 11:10:41

*cough*
also, there's still the issues with audacious for which there is currently no perfect workaround
*cough*

mhertz · 2011-09-13 12:00:23

Btw, I found out a good way to control "program loading flow", without having to resort to using numerous 'sleep x' in between each app and musca...

Instead of using e.g:

hsplit 1/2
exec jumanji
exec urxvtc

Which depending on load-speed opens up in different frames from time to time, then instead just use a single 'exec', with the apps listed in the frameorder you want, e.g.:

hsplit 1/2
exec jumanji && urxvtc

This way I don't miss a 'execf' kinda functionality from ratpoison anymore...

Lastly, i've thought of a feature-request, which imho really would be nice...

Lets say you have splitted your screen up in four frames, but the frames arent aligned perfectly, i.e. they dont have the exact same size.

In both musca and ratpoison, it's really nice that we have not only a next/prev movement between frames(often j/k in other wm's), but both up,down,left,right movement+swapping! However, if the frames arent perfectly alligned, then many times the direction you're trying to go/swap dosen't match up right, like also if you e.g. go to the next frame, and then back again, you end up elsewhere...

I'm not very good at explaining this, but just try for yourself and make a grid layout not alligned perfectly and try to move around up and down and back and forward... It sometimes works like you want but other times not...

Edit: Doh! Sorry i'm an idiot! The app loading flow tip in the beginning of my post obviously will not work for most apps, since they will each stall untill terminated untill progressing to the next in line!

The only reason that it worked the time I tested it, was because I used: 'exec urxvtc && jumanji', and where urxvtc dosen't stall for some reason(urxvt does, though)!

Sorry again about that!

Last edited by mhertz (2011-09-15 08:11:02)

ivoarch · 2011-09-27 20:17:07

Hi, I have little problem with one script for displaying Musca's groups in a Dzen2

the problem is this:

Not shows the window selected name,displays onli the files in my home.

Here the script:

musca-groups

#!/bin/sh
XPOS=0
WIDTH=870
HEIGHT=16
FONT="-xos4-terminus-*-*-*-*-12-*-*-*-*-*-*-*"
FG="#676767"
BG="#000000"

CLEAN="^fg()^bg()"

while true; do

WORKSPACES=`musca -c "show groups"`
echo "$WORKSPACES" |
while read name; do
    if [[ "$name" =~ "*" ]]
    then
        selected=`echo $name |cut -c 5-` 
        echo -n "^fg(#000000)^bg(#8292B2) $selected $CLEAN"
    else
        notselected=`echo $name | cut -c 5-` 
        echo -n " $notselected "
    fi
done
echo "`~/.scripts/musca-windows`"
#this displays the title of the selected window

sleep 1

done | dzen2 -h $HEIGHT -ta l -x $XPOS -w $WIDTH -h 14 -fg $FG -bg $BG -fn $FONT

Thanks;

Last edited by ivoarch (2011-09-27 20:20:29)

hellomynameisphil · 2011-10-08 18:46:15

Anyone here tried herbstluftwm? Aside from having a cool and strange name, it has pretty much everything I like from musca and i3 and then some. Git package exists in AUR.

ivoarch · 2011-10-09 11:33:12

hellomynameisphil wrote:

Anyone here tried herbstluftwm? Aside from having a cool and strange name, it has pretty much everything I like from musca and i3 and then some. Git package exists in AUR.

herbstluftwm-git
https://aur.archlinux.org/packages.php? … _Search=Ir

and Herbstluftwm thread

http://crunchbanglinux.org/forums/topic … wm-thread/

bootleg · 2011-10-12 17:07:20

ivoarch wrote:

Hi, I have little problem with one script for displaying Musca's groups in a Dzen2
[...]

you must put quotes around $name here:

selected=`echo "$name" |cut -c 4-`

because 'echo *' works like ls.

ivoarch · 2011-10-13 11:09:58

@bootleg

WOW MUCHISIMAS GRACIAS MAN!
very easy : )

THANKS AGAIN!

WORKS!!!

nem · 2011-11-03 19:21:32

good day.

for two reasons i'm going to stop patching musca: lack of time (thus progress lately) and herbstluftwm.

for what i wanted musca to be, hlwm already is - so my personal choice goes there. if you liked musca, i recommend you try hlwm, too. it's awesome!
i'll keep the aur-package of musca maintained.

regards,
nem

Hiram · 2012-01-05 04:14:56

I'm having a bit of trouble with Chromium in Musca - the "status bar" at the bottom doesn't display, e.g. for downloads, or installation of extensions. Is there anything I can do to get the status bar back?

tum · 2012-02-16 20:19:03

Hiram wrote:

I'm having a bit of trouble with Chromium in Musca - the "status bar" at the bottom doesn't display, e.g. for downloads, or installation of extensions. Is there anything I can do to get the status bar back?

I have tried Chromium on musca and on openbox , there are too many bugs in both window managers.

hcaulfield · 2012-03-05 22:00:10

Has anyone had a problem with windows becoming unresponsive in Musca having moving them around?

sant527 · 2012-04-16 10:10:28

I am looking for how to do toggleDesktopWindows. Like the Win-D in the windows you can minimize all the windows and also using the same key you can get it back

Also some app like smplayer or mplayer I want to open them in a small frame. instead of only type.

Arch Linux

#601 2011-08-16 14:24:53

Re: Musca (Tiling Window Manager)

#602 2011-08-16 15:57:36

Re: Musca (Tiling Window Manager)

#603 2011-08-16 19:20:10

Re: Musca (Tiling Window Manager)

#604 2011-08-18 10:53:47

Re: Musca (Tiling Window Manager)

#605 2011-08-23 05:54:27

Re: Musca (Tiling Window Manager)

#606 2011-08-24 17:57:29

Re: Musca (Tiling Window Manager)

#607 2011-08-31 01:43:59

Re: Musca (Tiling Window Manager)

#608 2011-08-31 08:53:46

Re: Musca (Tiling Window Manager)

#609 2011-08-31 14:20:20

Re: Musca (Tiling Window Manager)

#610 2011-08-31 23:24:45

Re: Musca (Tiling Window Manager)

#611 2011-09-01 00:22:44

Re: Musca (Tiling Window Manager)

#612 2011-09-03 21:44:52

Re: Musca (Tiling Window Manager)

#613 2011-09-05 21:55:15

Re: Musca (Tiling Window Manager)

#614 2011-09-13 11:10:41

Re: Musca (Tiling Window Manager)

#615 2011-09-13 12:00:23

Re: Musca (Tiling Window Manager)

#616 2011-09-27 20:17:07

Re: Musca (Tiling Window Manager)

#617 2011-10-08 18:46:15

Re: Musca (Tiling Window Manager)

#618 2011-10-09 11:33:12

Re: Musca (Tiling Window Manager)

#619 2011-10-12 17:07:20

Re: Musca (Tiling Window Manager)

#620 2011-10-13 11:09:58

Re: Musca (Tiling Window Manager)

#621 2011-11-03 19:21:32

Re: Musca (Tiling Window Manager)

#622 2012-01-05 04:14:56

Re: Musca (Tiling Window Manager)

#623 2012-02-16 20:19:03

Re: Musca (Tiling Window Manager)

#624 2012-03-05 22:00:10

Re: Musca (Tiling Window Manager)

#625 2012-04-16 10:10:28

Re: Musca (Tiling Window Manager)

Board footer