Musca (Tiling Window Manager)

stryder · 2009-03-17 15:57:18

aerosuidae wrote:

I havn't yet figured out how to get the best of both worlds. One possible solution is to have a setting like open_frame=<current|empty> where current would mean all new windows open in the focused frame and empty would mean all new windows first try to find an empty frame and only use the current frame as a last resort.

Yes, choice is good! :-)

For me "empty" behaviour makes more sense because existing windows are in their chosen frames (I put them there!) so where a new window goes is the only question. "Current" behaviour rearranges the existing layout which cannot be what the user wants. Someone else might have a different idea though.

Inxsible · 2009-03-17 18:37:51

stryder wrote:

aerosuidae wrote:
I havn't yet figured out how to get the best of both worlds. One possible solution is to have a setting like open_frame=<current|empty> where current would mean all new windows open in the focused frame and empty would mean all new windows first try to find an empty frame and only use the current frame as a last resort.
Yes, choice is good! :-)
For me "empty" behaviour makes more sense because existing windows are in their chosen frames (I put them there!) so where a new window goes is the only question. "Current" behaviour rearranges the existing layout which cannot be what the user wants. Someone else might have a different idea though.

+1 to that.

aerosuidae · 2009-03-17 23:42:47

Procyon wrote:

Can you check for dialog windows?

Care to clarify this suggestion? We already cater for transient windows by letting them float above their parent.

Procyon · 2009-03-17 23:57:07

Ah, I misunderstood.

stryder · 2009-03-18 00:47:18

aerosuidae wrote:

However, the same behavior is desirable when you're initially dividing up the screen, when you probably want apps to just get on with making themselves visible instead of having to go to each new frame and manually display an app.

Had a good sleep and had a thought this morning which I thought I'd share before I go offline for the next few days: how about limiting this behaviour to when frames are being formed/divided, not when new windows are created?

aerosuidae · 2009-03-18 01:43:08

stryder wrote:

Had a good sleep and had a thought this morning which I thought I'd share before I go offline for the next few days: how about limiting this behaviour to when frames are being formed/divided, not when new windows are created?

I think if we're going to have different behaviors, it is better to be consistently one or the other and let the user decide.

So, try out Musca 0.9.6. It has:

set window_open_frame current|active

.. where current means new windows open in the current frame, and empty means new windows first look for an empty frame failing back to the current frame as a last resort. Default is current.

set window_open_focus 1|0

.. where 1 means new windows take focus in whichever frame they appear, and 0 means focus does not change until the user does it manually. Default is 1.

Inxsible · 2009-03-18 01:49:37

Wow !

you are fast man ! I just updated the package in AUR to 0.9.5 about a couple hours back and it seems I will have to update again to 0.9.6

Good Stuff !!

bgc1954 · 2009-03-19 15:49:31

You're going to be a busy boy Inxsible. He's at 0.9.7 now.

Inxsible · 2009-03-19 16:36:42

bgc1954 wrote:

You're going to be a busy boy Inxsible. He's at 0.9.7 now.

I guess he went up one more. I see a 0.9.8 now.

I will skip 0.9.7 and go directly to 0.9.8 in AUR

Runiq · 2009-03-19 20:19:30

Whoa, two days not following this thread and I'm a mile behind. aerosuidae, when do you sleep?

By the way, I somehow can't map the minus key to a command, as well as the return and space keys (Mod4+return, Mod4+space, Mod4+minus don't work, neither do Return/Enter/enter, Space or Minus/-).
Also, I'd like to know if there's a way to map Multimedia Keys (like XF86AudioMute, XF86AudioPlay etc.) to anything - I didn't get them to work. (I tried to map them to things like 'exec mpc toggle', which works when I call it from the Musca commands dmenu.)

adamlau · 2009-03-19 20:48:23

So how are apps started using dmenu? I built musca and dmenu, added both to xinitrc, musca starts with blue border, now how to launch app? Coming from JWM and dwm w/o dmenu. That is all I need I suppose, how to launch apps with dmenu...

Runiq · 2009-03-19 21:05:14

adamlau wrote:

So how are apps started using dmenu? I built musca and dmenu, added both to xinitrc, musca starts with blue border, now how to launch app? Coming from JWM and dwm w/o dmenu. That is all I need I suppose, how to launch apps with dmenu...

Press windows+x to start a standard dmenu, windows+m tu start a dmenu with available musca commands.

EDIT: Oh yeah, you might want to look into the config.h file for keybindings - they're all explained there. Read a bit through it and you'll understand.

Last edited by Runiq (2009-03-19 21:06:18)

Inxsible · 2009-03-19 21:32:14

adamlau wrote:

So how are apps started using dmenu? I built musca and dmenu, added both to xinitrc, musca starts with blue border, now how to launch app? Coming from JWM and dwm w/o dmenu. That is all I need I suppose, how to launch apps with dmenu...

So you are starting up dmenu via .xinitrc? There is no need to do that. Mod+x starts dmenu -- to launch your apps - simply type in the first few characters and you should see the list changing accordingly

Musca commands can be used via Mod+m as already mentioned by Runiq

Inxsible · 2009-03-19 21:34:46

Runiq wrote:

Whoa, two days not following this thread and I'm a mile behind. aerosuidae, when do you sleep?
By the way, I somehow can't map the minus key to a command, as well as the return and space keys (Mod4+return, Mod4+space, Mod4+minus don't work, neither do Return/Enter/enter, Space or Minus/-).
Also, I'd like to know if there's a way to map Multimedia Keys (like XF86AudioMute, XF86AudioPlay etc.) to anything - I didn't get them to work. (I tried to map them to things like 'exec mpc toggle', which works when I call it from the Musca commands dmenu.)

Yeah, there is not a lot of support for mapping keys to musca commands - unless they are mapped by default. I wanted to map the quit and add and drop so that I could create multiple groups quickly. aerosuidae mentioned that could not be done currently.

Maybe he will add support soon enough.

Last edited by Inxsible (2009-03-19 21:35:07)

Runiq · 2009-03-19 21:55:47

Inxsible wrote:

Yeah, there is not a lot of support for mapping keys to musca commands - unless they are mapped by default. I wanted to map the quit and add and drop so that I could create multiple groups quickly. aerosuidae mentioned that could not be done currently.
Maybe he will add support soon enough.

Yeah, probably... yesterday.

In all seriousness, maybe I can have a look at it at the weekend, need to look into standard and X libraries anyways.

aerosuidae · 2009-03-20 00:34:50

Runiq wrote:

By the way, I somehow can't map the minus key to a command, as well as the return and space keys (Mod4+return, Mod4+space, Mod4+minus don't work, neither do Return/Enter/enter, Space or Minus/-). Also, I'd like to know if there's a way to map Multimedia Keys (like XF86AudioMute, XF86AudioPlay etc.) to anything - I didn't get them to work. (I tried to map them to things like 'exec mpc toggle', which works when I call it from the Musca commands dmenu.)

What exact commands are you using to bind the return/space/minus keys? For example if I M+m and run:

bind on Mod4+space exec xterm
bind on Mod4+minus exec firefox
bind on Mod4+Return exec pcmanfm

.. they all work. The name of the key after + is passed directly to XStringToKeysym(), so the key names you use (including case sensitivity) must match whatever your X environment wants. For example, "return" doesn't work on my system, but "Return" does.

As for the extended keys, I've never tried :-)

aerosuidae · 2009-03-20 00:54:06

Inxsible wrote:

Yeah, there is not a lot of support for mapping keys to musca commands - unless they are mapped by default. I wanted to map the quit and add and drop so that I could create multiple groups quickly. aerosuidae mentioned that could not be done currently. Maybe he will add support soon enough.

The problem here is that the add/drop commands need an argument. There is currently no built in way to capture the argument except for using the M+m command normally. But with Musca's exec you can run any external script or code you like! So hack it up :-)

Eg, say this is ~/test.sh:

#!/bin/sh
name=`echo "" | dmenu` && musca -c "add $name"

Then:

bind on Mod4+F1 exec ~/.test.sh

Xdialog or something would probably work better than dmenu here for grabbing input, but the principle is simple.

Inxsible · 2009-03-20 02:18:28

Well, I normally just create another group for rtorrent and my music player...and I like to have a keybinding for a quit. So I just did this for the keybindings

{ "Mod4+r",             "exec musca -c 'add rTorrent' && exec urxvt -bg black -fg white -name rTorrent -e screen -S rtorrent rtorrent"    },

{ "Mod4+Shift+q",       "exec musca -c quit"    },

Last edited by Inxsible (2009-03-20 05:33:42)

stryder · 2009-03-20 13:35:01

I prefer using .musca_start. I set up my groups and their layouts and then open the few programs I usually use. I also set key bindings there.

bind on mod4+space shell (to follow the trigger for quicksilver in OS X)
bind on mod4+q command (so I can easily bring up the commands with 1 hand) which gives me a simple mod4-q q enter sequence for quit.

Runiq · 2009-03-20 16:11:34

aerosuidae wrote:

[…]If I M+m and run:
bind on Mod4+space exec xterm
bind on Mod4+minus exec firefox
bind on Mod4+Return exec pcmanfm
.. they all work. The name of the key after + is passed directly to XStringToKeysym(), so the key names you use (including case sensitivity) must match whatever your X environment wants. For example, "return" doesn't work on my system, but "Return" does.
As for the extended keys, I've never tried :-)

Okay, maybe I just didn't look hard enough. I'll try again this evening.

Procyon · 2009-03-20 18:48:31

I wasn't able to bind a key without also using a modifier, can you make it so that is possible?

Procyon · 2009-03-20 23:28:42

When I use border off, the window doesn't resize to use that pixel. I like to thrust the mouse left and with this I can't scroll when it's not on the window. It's not really a big deal though.

EDIT:

Actually, I noticed, when the window was created when border was off, then it will use the pixel.
This also means that turning border on will not give windows made during border off a border (I see one facing another window, but I guess it depends)
So it may be a bit more important than I first said.

Last edited by Procyon (2009-03-20 23:33:17)

Inxsible · 2009-03-20 23:33:37

Procyon wrote:

When I use border off, the window doesn't resize to use that pixel. I like to thrust the mouse left and with this I can't scroll when it's not on the window. It's not really a big deal though.

Yeah I have seen that too. I see my desktop wallpaper. But I use a dark wallpaper so it doesn't bother me much and the only time I get rid of the border is while watching a movie.

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

Procyon wrote:

When I use border off, the window doesn't resize to use that pixel. I like to thrust the mouse left and with this I can't scroll when it's not on the window. It's not really a big deal though.

Bug. Try 0.9.9.

Procyon wrote:

I wasn't able to bind a key without also using a modifier, can you make it so that is possible?

Hmm.. yeah, bug. Try 0.9.9. Note that xbindkeys is an alternative for binding keys, especially if you want the same key combinations for multiple window managers.

Inxsible · 2009-03-21 04:04:50

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.

Arch Linux

#51 2009-03-17 15:57:18

Re: Musca (Tiling Window Manager)

#52 2009-03-17 18:37:51

Re: Musca (Tiling Window Manager)

#53 2009-03-17 23:42:47

Re: Musca (Tiling Window Manager)

#54 2009-03-17 23:57:07

Re: Musca (Tiling Window Manager)

#55 2009-03-18 00:47:18

Re: Musca (Tiling Window Manager)

#56 2009-03-18 01:43:08

Re: Musca (Tiling Window Manager)

#57 2009-03-18 01:49:37

Re: Musca (Tiling Window Manager)

#58 2009-03-19 15:49:31

Re: Musca (Tiling Window Manager)

#59 2009-03-19 16:36:42

Re: Musca (Tiling Window Manager)

#60 2009-03-19 20:19:30

Re: Musca (Tiling Window Manager)

#61 2009-03-19 20:48:23

Re: Musca (Tiling Window Manager)

#62 2009-03-19 21:05:14

Re: Musca (Tiling Window Manager)

#63 2009-03-19 21:32:14

Re: Musca (Tiling Window Manager)

#64 2009-03-19 21:34:46

Re: Musca (Tiling Window Manager)

#65 2009-03-19 21:55:47

Re: Musca (Tiling Window Manager)

#66 2009-03-20 00:34:50

Re: Musca (Tiling Window Manager)

#67 2009-03-20 00:54:06

Re: Musca (Tiling Window Manager)

#68 2009-03-20 02:18:28

Re: Musca (Tiling Window Manager)

#69 2009-03-20 13:35:01

Re: Musca (Tiling Window Manager)

#70 2009-03-20 16:11:34

Re: Musca (Tiling Window Manager)

#71 2009-03-20 18:48:31

Re: Musca (Tiling Window Manager)

#72 2009-03-20 23:28:42

Re: Musca (Tiling Window Manager)

#73 2009-03-20 23:33:37

Re: Musca (Tiling Window Manager)

#74 2009-03-21 03:12:04

Re: Musca (Tiling Window Manager)

#75 2009-03-21 04:04:50

Re: Musca (Tiling Window Manager)

Board footer