You are not logged in.
What man pages exactly? I compiled from source.
Offline
Ok, not such a big deal, I think I'll be able to force that behavior I want to have. Thanks for the link, thats quite interesting as well
@Army: how to do that behavior ? I read the blog but still dont figure it out. your musca_start plz.
Offline
Army wrote:Ok, not such a big deal, I think I'll be able to force that behavior I want to have. Thanks for the link, thats quite interesting as well
@Army: how to do that behavior ? I read the blog but still dont figure it out. your musca_start plz.
I haven't tried it yet, sorry.
Offline
Wow, I just noticed now, that there are a package on aur called: musca-mm-git, with the description: "Musca with Procylon patch, future improvements to come."
It's made by wintervenom and pulls from a non-official musca repository on github, so it seems to be forked!
Github: http://github.com/joeDeuce/musca--
Very cool indeed imho!!!
Offline
Sadly there haven't been any further improvements so far, I hope this promise isn't gonna be an empty one.
Offline
It seems the musca-website is online again. Does anyone know if somebody is also continue in developing it?
btw: Here is a little script I want to share, maybe it's useful for someone. I use it almost everyday.
With the script you can see all windows with one keystroke in your favourite layout:
#!/usr/bin/ruby
system "musca -c 'show windows' > ~/.musca/layouts/lines"
WINDOWS = Integer(`ruby -e 'while gets; end; puts $.' < ~/.musca/layouts/lines`)
def musca_run f
system "musca -c \"#{f}\""
end
def showall
if WINDOWS == 1
musca_run "only"
elsif WINDOWS == 2
musca_run "load #{Dir.home}/.musca/layouts/2w"
elsif WINDOWS == 3
musca_run "load #{Dir.home}/.musca/layouts/3w"
elsif WINDOWS == 4
musca_run "load #{Dir.home}/.musca/layouts/4w"
elsif WINDOWS >= 5
musca_run "load #{Dir.home}/.musca/layouts/5w"
end
end
showall
In your homedirectory create a directory called ".musca/layouts/" and dump your layouts into it.
2w - for the two-windows-layout
3w - for 3
...
Hope you understand my poor english...
Last edited by gorilla (2011-02-09 14:30:13)
Offline
Yeah, I saw the homepage is up again and I hope that have some meaning in terms of new development also?
Anyway, personally then the only thing that i'm currently "missing" in musca, is to get the border disabled in fullscreen/maximized mode and then to auto-enable the border whenever splitting the view/tiling, as it's annoying to see movies with the border on. Of course I can define shortcuts to enable/disable the border, but nonetheless...
I have tried disabling borders while adding a hook to enable borders whenever hsplit/vsplit is utilized, and this almost works, except the split pane of the original window still will be borderless unfortunetly.
If not auto-enabling/disabling the border, then something like ratpoison would be nice, where a little pop-up is shown shortly on the focused pane when navigating through them, which could be enabled whenever borders where set to disabled.
I'm just beginning to learn C with no programming knowledge of other languages before-hand, so unfortunetly I am not knowledgeble enough to be able to do it myself..
Still though, even with the development stalled like this, then Musca still is the most awesome lighweight manual tiling WM I have ever tried!
Purelly subjective of course, but just simply my humble opinion!
Last edited by mhertz (2011-02-08 09:25:27)
Offline
Anyway, personally then the only thing that i'm currently "missing" in musca, is to get the border disabled in fullscreen/maximized mode and then to auto-enable the border whenever splitting the view/tiling, as it's annoying to see movies with the border on. Of course I can define shortcuts to enable/disable the border, but nonetheless...
I use mplayer for watching movies and when I used musca, I had created an alias which would "borderoff & mplayer $1" (or something to that effect), but switching them back on was through a key stroke.
I have since moved on to i3, for better dual head support.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Hey that's a great tip, mate! Thank you for that...
I was thinking something along your line with added "&& musca -c border on" or whatever it's called(gotta check)...
Yeah, I knew you where using i3 for some time now and I actually also shortly checked it out when i read you had changed to it, and if I ever get a showstopping problem with musca, then that's also where i'll be heading...
CU, Martin.
Offline
or you can create a patch for mplayer so that when you hit "q or Esc" - for quitting mplayer or when playback ends, you can have your borders re-enabled.
Of course this patch can only be used if your WM is musca and this is obviously not good, since you will have to keep multiple installs of mplayer for every WM you have installed (or at least 2).
Not to mention, that this is in itself a huge hassle simply to avoid hitting a keybinding for re-enabling the borders
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
@Inxsible: That's a good idea and there is a very simple alternative implementation:
#! /bin/bash
/usr/bin/mplayer "$@"
musca -c "border on"
Depending on if mhertz uses a filemanager or not, you could use just a bash function, but the catch-all solution is adjusting your $PATH and putting the above script in.
Offline
@Procyon : That's an even better and simpler idea
#! /bin/bash
/usr/bin/mplayer "$@"
if [ running_wm = musca]
musca -c "border on"
fi
My bash skills are probably closer to zilch, but if you can add a check to see what the current wm is running, then you won't get errors while executing "musca -c" either (in case you have a different WM running). This way, you can have different wms and still use the same shell script to start mplayer.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Good point, I just ran it from compiz and it just freezes.
pgrep musca &>/dev/null && musca -c "border on"
Offline
That's awesome! Thanks alot mates, really appreciated!
I don't use a filemanager, just coreutils, and also only use Musca as my WM, so as suggested, i'll just make a function to my .bashrc:
mplayer()
{
musca -c "border off"
mplayer "$@"
musca -c "border on"
}
Thanks again mates, you guys rock!
(I must be some kind of moron for not having thought in those same lines myself... )
Last edited by mhertz (2011-02-09 09:16:28)
Offline
Yeah, I know musca is currently un-developed, but just in case someone in the know with C/x11 knowledge had some free time(like the great cycle patch provided kindly by procyon), then one of the things i've just discovered im missing in musca, is the comparable of ratpoison's execf command.
That's an exec version which lets you define upon which frame you want your app launched in. Another great thing would be if such a command supported an additional argumant for which group to use also...
I'm having the problem that if I through .musca_start wants to split the screen horizontally 70% and launch jumanji on the left and urxvtc on the right, then that's impossible for me to do from .musca_start i.e. jumanji gets on the right and urxvtc on the left...
With some other app combos, then there's no prob upon which frame you want things to show up at, but I guess it has to do with how long an app takes to load, like also explained by Sean in the musca docs:
Note that lanuching apps from the startup file is OK, but can be of limited use if you want to do it in more than one group. The exec command runs asynchronously, and if apps are slow to create their windows, they may not necessarily appear in the group you expect. In this case, try launching apps from .xinitrc and just moving them around here.
No matter how many rswap/lswap I place and change the order of commands, then I couldn't get jumanji on the left!
Then I could do it by loading the apps from .xinitrc instead and placing a sleep command in between them, and then split the screen from musca, but the problem is that this only works most of the time, but maybe 1 time out of 5, then it dosen't, and that also if i set the sleep to whole 5 secs!
Besides a patch, which is dreamfull thinking I know, then if someone had any tips for making this issue of mine work better, then I would much appreciate it!
Last edited by mhertz (2011-04-29 17:41:12)
Offline
Musca's commands "dump" and "load" work most of time , try that .
"Dump" remembers catch-all(ed) and dedicated frames too .
Offline
Thanks for your reply!
Unfortunetly, it has the same issue, i.e. first time it worked, but second time it didn't... (using a dumped/saved framelayout with dedicated frames from .musca_start)
I find it strange that the dumped file include application information i.e. which app belongs where and which is dedicated or not, and then it still dosen't use it for anything??? I mean, of course I get that it's just the frame-layout thats saved/restored, but then I don't get why musca bothers saving info about which app is loaded where, when it dosen't do anything with that info!
Good idea anyway
CU, Martin.
Last edited by mhertz (2011-04-29 18:18:30)
Offline
Maybe all you need is a delay:
jumani &
while ! wmctrl -l | grep -qi jumanji; do sleep 0.5; done
musca -c 'load ~/.musca_layout'
Offline
@mhertz: try musca's setting "window_open_frame empty"
Offline
@tum
Thanks alot for your help, but unfortunetly it's still the same; in my test then first time it worked, but second time it failed... Thanks anyways, mate...
@Procyon
That's a great idea to utilice wmctrl for that i.e. making sure jumanji has loaded fully!
Unfortunetly, then I tried your example, and it didn't worked, i.e. musca never started, and then I tried to run wmctrl from a new musca session with jumanji opened, and it saw jumanji as iGoogle, since that's my homepage, so I changed it to that, but it still wouldn't start musca?
I then checked VT1 doing the stalled while loop and saw wmctrl output that it couldnt detect any client windows?
Offline
I don't know how it works exactly, I think wmctrl needs EWMH hints and those are provided by the WM, so you'd have to start musca first.
It would also be better to run the code in a sub shell.
{ jumani & while ! wmctrl -l | grep -qi igoogle; do sleep 0.5; done; musca -c "load ~/.musca_layout"; } &
Another problem is that jumanji might start with a dummy window.
You could measure the time after jumanji starts until the window appears.
{ jumanji & sleep 5s; musca -c "load ~/.musca_layout"; } &
Offline
Thanks again for your help, mate!
Yeah, I actually went back to this thread to write that I had remembered that wmctrl is a ewmh tool and hence wont work without a wm running first...
Anyway, I only thought that it was a problem with jumanji and so I had originally placed a 5 sec sleep in between jumanji and urxvtc, and that only worked sometimes, but now i've just tried to change the sleep to 1 sec and also add a 1 sec sleep after urxvtc and then running musca with a hsplit command from .musca_start, and now it works perfectly, or atleast the last 20 times ive tested it!
Thanks again for your helpfullness mate!
CU, Martin.
Offline
I got the idea of getting shown a short notification message during the execution of some of my keybinds, like e.g. I have defined hotkeys for changing/muting the volume, but it was annoying that I couldn't see at what level it was specifically set on, i.e. when finished listening to something, then I want to set the volume back to some default level, and then a notification popup would be nice, instead of having to run alsamixer to set it...
I then decided to use dzen2, as it's lighter than libnotify(notify-send) and dosen't need a daemon running all the time to work...
Also, since I don't use any kind of bars or panels etc., as I don't like to waste any screen-space, then I like the idea of defining hotkeys to shortly show a notification message for the output of e.g. date and acpi and such.
Now, i've gotten almost everything I wanted implemented with dzen2 notifications, like e.g. volume up:
bind on XF86AudioRaiseVolume exec amixer set Master 5%+ | dzen2 -p 3 -w 300 -x 535
..But there's one thing i'm having problems with, and where I would much appreciate some guidance, thanks, and that's to get dzen2 notifications upon the command: musca -c "show groups".
The idea is that whenever I press Mod4+PgUP/PgDn to go up/down in the group list, then a short dzen2 notification should be shown to indicate which group i'm now specifically in!
The output of: musca -c "show groups", is the list of groups, one on a new line and a mark stating the current group.
However, when this is piped into dzen2, then only the last line is shown, so then I removed newlines from the musca output and piped that into dzen2, but then dzen2 just shows an empty notification message?
This is the keybind im using:
bind on Mod4+Next exec musca -c "use (next)" && musca -c "show groups" | tr "\n" " " | dzen2 -p 3 -w 300 -x 535
I also want to do the same with the cycle command(Mod4+c) i.e. to show a short dzen2 notification message about which windows is next in line, whenever cycling windows, but musca also output's "newline'd" output with that command, which like the groups, I cannot pipe correctly into dzen2?
Thanks in advance!
Last edited by mhertz (2011-05-04 20:18:30)
Offline
It looks like dzen2 needs at least one newline, while tr removes all.
The simplest way is to just wrap it in echo:
echo $(musca -c .... | tr ...)
You can also do it with sed or awk etc, e.g. sed ':a;$!{N;ba};s/\n/ /g'
Offline
Yes!!! It works perfectly now!
I really like that I can see in a popup at which group/window im in and which is left and where! Simply awesome!
Yeah, I know there's allready dmenu defined binds, but then I have to switch between using both Mod4+g/w, right/left, and return, instead of just continuelly pressing Mod4+PgDn/PgUP!
Thanks alot Procyon again for coming to my rescue, I really appreciate it, mate!
CU, Martin!
Offline