You are not logged in.
@Cloudef yeah, I was trying to fix chromium in particular, that when you click the space where tabs go
and drag it, it wants to move, but immediately gets tiled. The commit fixed that, but introduced some
artifacts than @Shinryuu is seeing.
I restored it, to work as it did before. So xdotool windowmove should work and the bug reported should be fixed.
@bslackr
I used to want the same thing You'd need a panel that is xinerama-aware.
I think bar could be easily hacked to provide that, but you'd still need some
mechanism to differentiate what goes on which monitor.
With the existing tools (those that I know of) you still have some choices:
1) use one instances of 'bar' (or any panel that allow to set offset/width) for each monitor
2) use one instance of 'bar' and place the info for the 2 monitors (will not work for more)
in the corners; that is, the info for the right monitor will go to the right corner etc.
I can probably make a quick script for those cases - in a while (I'll edit this post).
Last edited by c00kiemon5ter (2012-09-21 23:05:45)
.:[ git me! ] :.
Offline
@c00kiemonster,
I can confirm stuff working now.
What would you say adding support for simpleswitcher in monsterwm?
Switching windows with dmenu like menu, makes much more sense to me.
Especially if monsterwm can automatically switch to the desktop/monitor the raised window is.
Looking at the code here https://github.com/seanpringle/simplesw … switcher.c
seems to show that only _NET_CLIENT_LIST_STACKING in particular needs to be implemented to have it working, unless I'm missing something.
If not, no worries I can do this myself as well.
Last edited by Cloudef (2012-09-21 16:45:35)
Offline
@bslackr
I used to want the same thingYou'd need a panel that is xinerama-aware.
I think bar could be easily hacked to provide that, but you'd still need some
mechanism to differentiate what goes on which monitor.With the existing tools (those that I know of) you still have some choices:
1) use one instances of 'bar' (or any panel that allow to set offset/width) for each monitor
2) use one instance of 'bar' and place the info for the 2 monitors (will not work for more)
in the corners; that is, the info for the right monitor will go to the right corner etc.I can probably make a quick script for those cases - in a while (I'll edit this post).
for both you need a script to differentiate monsterwm's output for each monitor.
the idea is to separate the info for each monitor and
either feed that info in separate panel instances,
or format it in such a way that appears 'correctly' on each monitor
---------------------------------------------------------------------------------------------------------------------
for (1) you'd have a fifo for each monitor, which the script feeds with the appropriate lines.
the script reads monsterwm's output,
splits it in separate lines for each monitor,
generates/formats/renders the wanted information to display
and redirects that info in the appropriate fifo.
each bar reads the appropriate fifo and is configured to be displayed only in the appropriate monitor.
mkfifo -m 600 /tmp/mon # monsterwm's output
mkfifo -m 600 /tmp/lmon # for the left monitor
mkfifo -m 600 /tmp/rmon # for the right monitor
lmonbar < /tmp/lmon & # should be configured to start at the beginning of the 1st monitor and have the same width as the 1st monitor
rmonbar < /tmp/rmon & # should be configured to start at the beginning of the 2nd monitor and have the same width as the 2nd monitor
while read -ra desktops
do
for desk in "${desktops[@]}"
do
# the first digit corresponds to the monitor
# the rest of the token provides info about
# collect the info for each monitor
if (( ${desk%%:*} == 0 ))
then lmon+=( $desk )
elif (( ${desk%%:*} == 1 ))
then rmon+=( $desk )
fi
done
# create the appropriate string for each monitor
# same as what the gist scripts do, but
# instead of printing, store in a var
....
l="...."; # left status line, based on lmon
r="...."; # right status line, based on rmon
....
# feed the info to a dedicated pipe that
# the panel/bar listens to and presents it
[[ -n $l ]] && echo "$l" > /tmp/lmon
[[ -n $r ]] && echo "$r" > /tmp/rmon
# clean up for next loop
unset lmon rmon l r
done < /tmp/mon &
monsterwm > /tmp/mon
---------------------------------------------------------------------------------------------------------------------
for (2) you'd have to separate the output and output it in bar
in such a way that the left monitor's output is on the left,
while the right monitor's output is on the right.
mkfifo -m 600 /tmp/mon # monsterwm's output
while read -ra desktops
do
for desk in "${desktops[@]}"
do
# the first digit corresponds to the monitor
# the rest of the token provides info about
# collect the info for each monitor
if (( ${desk%%:*} == 0 ))
then lmon+=( $desk )
elif (( ${desk%%:*} == 1 ))
then rmon+=( $desk )
fi
done
# create the appropriate string for each monitor
# same as what the gist scripts do, but
# instead of printing, store in a var
....
l="...."; # left status line, based on lmon
r="...."; # right status line, based on rmon
....
# print the info to feed the bar
printf "%s %s\n" "\l$l" "\r$r"
# clean up for next loop
unset lmon rmon l r
done < /tmp/mon | bar &
monsterwm > /tmp/mon
---------------------------------------------------------------------------------------------------------------------
You also have a 3rd choice. Assuming you use a fixed width font, two monitors
and the monitors' width and resolution is the same, you can
split the output for each monitor, place the output of the first monitor on the left,
place the output of the second monitor on the center and adjust it so that it starts on the second monitor
mkfifo -m 600 /tmp/mon # monsterwm's output
while read -ra desktops
do
for desk in "${desktops[@]}"
do
# the first digit corresponds to the monitor
# the rest of the token provides info about
# collect the info for each monitor
if (( ${desk%%:*} == 0 ))
then lmon+=( $desk )
elif (( ${desk%%:*} == 1 ))
then rmon+=( $desk )
fi
done
# create the appropriate string for each monitor
# same as what the gist scripts do, but
# instead of printing, store in a var
....
l="...."; # left status line, based on lmon
r="...."; # right status line, based on rmon
....
# print the info to feed the bar
# the info for the right monitor is centered
# and pushed to the right using leading spaces
# so that it finally matches the beginning of the right monitor
printf "%s %s\n" "\l$l" " \c$r"
# clean up for next loop
unset lmon rmon l r
done < /tmp/mon | bar &
monsterwm > /tmp/mon
---------------------------------------------------------------------------------------------------------------------
@c00kiemonster,
I can confirm stuff working now.What would you say adding support for simpleswitcher in monsterwm?
Switching windows with dmenu like menu, makes much more sense to me.
Especially if monsterwm can automatically switch to the desktop/monitor the raised window is.Looking at the code here https://github.com/seanpringle/simplesw … switcher.c
seems to show that only _NET_CLIENT_LIST_STACKING in particular needs to be implemented to have it working, unless I'm missing something.
If not, no worries I can do this myself as well.
I cant promise anything atm, I will look into it tomorrow
.:[ git me! ] :.
Offline
Awesome, thanks so much. I'll try them all out in the morning to see which one suits me best (far too tired right now, can barely read ). I really do appreciate it.
Offline
@bslackr: i use dzen2 for my bar on a xinerama setup, works well for me.
Desktop/Laptop - DWM :: VM - screen
Registered Linux User Number 483137 :: Victory! :: GitHub
Offline
Is there a way to have a scratchpad? If so, please share the snippet that makes that possible
Offline
from the previous page
I created this (posix/sh) script to make a scratchpad available.
It depends on xdotool, but should work with any terminal that allows to set the instance name.Setup for the script (optional if you specify full path below):
1. add it to your PATH,
2. preferably make it executableSetup for monsterwm:
update to the latest version on git pushed today
edit config.h and1. add a scratchpad rule on the 'rules[]' array
{ "scratchpad", -1, -1, False, True },
2. add a new command -- if you specify full path to scratchpad.sh it doesn't have to be executable.
static const char *dropterm[] = { "/bin/sh", "-c", "scratchpad.sh", NULL };
3. add a keybind
{ MOD1, XK_grave, spawn, {.com = dropterm}},
and that's it. now using ' Alt+` ' brings up a terminal, floating and centered.
the same combination hides the terminal keeping its state.
If one exits that terminal (ie presses 'Ctrl+d') the terminal is closed and the state
is lost, but the same combination will bring up a new terminal when pressed again.
.:[ git me! ] :.
Offline
Oh, you sir, deserve a BEER!
Offline
Nope, something went wrong. I mapped it to F12, and tried to map it Alt+`' too. That worked, but scratchpad is not hidig when I press F12, it creates a new instance. Any thoughts?
Offline
is anything else binded to F12 ?
It certainly works as expected here. I tested with
{ MOD1, XK_grave, spawn, {.com = dropterm}},
{ 0, XK_F12, spawn, {.com = dropterm}},
and both 'Alt+`' and 'F12' work as expected.
running 'scratchpad.sh' on your terminal or dmenu or w/e should work the same.
If an instance is there it is toggled once the script is called, no matter how you invoke it.
.:[ git me! ] :.
Offline
Nope. Still no cigarr.
My startup for urxvtd:
/usr/bin/urxvtd -q -f -o &
Where my files are located:
/home/gholen/bin/
How my scratchpad is written in to config.h:
static const char *dropterm[] = { "/bin/sh", "-c", "$HOME/bin/scratchpad.sh", NULL };
...
{ 0, XK_F12, spawn, {.com = dropterm}},
The script you provided for this;
#!/bin/sh
name="scratchpad"
class="URxvt"
# print the window id of the window with the given
# instance name as the first argument '$1' and
# class name as the second argument '$2'
get_win_id() {
xwininfo -root -children -int | awk -v n="$1" -v c="$2" '$3 == "(\""n"\"" && $4 == "\""c"\")" {
print $1 }'
}
# get the window id
winid="$(get_win_id "$name" "$class")"
# if the window was not found
if [ -z "$winid" ]
then
# spawn it
urxvtc -name "$name"
# get the window id again
winid="$(get_win_id)"
# if the window was not found then something is really wrong. give up.
[ -z "$winid" ] && exit 1
fi
# if the window is hidden show it, else hide it
if ! xwininfo -id "$winid" | awk '$1 == "Map" && $2 == "State:" { exit ($3 == "IsUnMapped") }'
then xdotool windowmap "$winid"
else xdotool windowunmap "$winid"
fi
Still nothing. I DO get a terminal by pressing F12, but prissing it again gives me only but a new terminal, however, not making it go away. I realise something is wrong here, but I dont know what.
Offline
if you open a terminal and run
$ sh $HOME/bin/scratchpad.sh
the scratchpad should appear (and it does as you say)
if you run the same command again, the scratchpad should disappear.
if that does not happen, then I'm guessing you don't have xdotool installed
I created this (posix/sh) script to make a scratchpad available.
It depends on xdotool, but should work with any terminal that allows to set the instance name.
otherwise posting the output of this command would help
$ sh -x $HOME/bin/scratchpad.sh ; sh -x $HOME/bin/scratchpad.sh
(yep, that is twice the same command with the '-x' switch)
Last edited by c00kiemon5ter (2012-09-22 19:50:32)
.:[ git me! ] :.
Offline
It says, as I have nothing to copy-paste with, that wminfo deos not exist.
Offline
you probably mean 'xwininfo'
xwininfo is part of xorg. For Archlinux install 'xorg-apps' group or directly 'xorg-xwininfo'.
xorg-apps includes xprop, xkill, xrandr, xset and other such useful apps
.:[ git me! ] :.
Offline
Maybe it's that simple
Yup. Thats it!
Now, I owe you a beer, or maybe some two beers THANKS!
Offline
for (1) you'd have a fifo for each monitor, which the script feeds with the appropriate lines.
the script reads monsterwm's output,
splits it in separate lines for each monitor,
generates/formats/renders the wanted information to display
and redirects that info in the appropriate fifo.
each bar reads the appropriate fifo and is configured to be displayed only in the appropriate monitor.
I decided to try and use this one with dzen, but ran into an error or two that I don't quite understand (my bash-fu isn't great). Here is the full script I put together.
#!/bin/sh
mkfifo -m 600 /tmp/mon # monsterwm's output
mkfifo -m 600 /tmp/lmon # for the left monitor
mkfifo -m 600 /tmp/rmon # for the right monitor
dzen2 -w 320 -h 18 -ta l -e -p -xs 1 < /tmp/lmon & # should be configured to start at the beginning of the 1st monitor and have the same width as the 1st monitor
dzen2 -w 320 -h 18 -ta l -e -p -xs 2 < /tmp/rmon & # should be configured to start at the beginning of the 2nd monitor and have the same width as the 2nd monitor
ltags=("main" "web" "dev" "vm" "null")
rtags=("video" "pdf" "dev" "vm" "null")
layouts=("[]" "[|]" "[#]" "[G]" "[P]")
while read -ra desktops
do
for desk in "${desktops[@]}"
do
# the first digit corresponds to the monitor
# the rest of the token provides info about
# collect the info for each monitor
if (( ${desk%%:*} == 0 ))
then lmon+=( $desk )
elif (( ${desk%%:*} == 1 ))
then rmon+=( $desk )
fi
done
# Get the information from the left monitor
for ldesktop in "${lmon[@]}"; do
IFS=':' read -r d w m c u <<< "$ldesktop"
label="${ltags[$d]}"
((w)) && fg="#f85708" || fg="#a8a8a8"
((c)) && fg="#65ac35" bg="#282a2b" layout="${layouts[$m]}" bsep="<" asep=">" || bsep=" " asep=" " bg="#282a2b"
((u)) && fg="#7b41ff"
l+="^fg($fg)^bg($bg)$bsep$label$asep^bg()^fg()"
done
for rdesktop in "${rmon[@]}"; do
IFS=':' read -r d w m c u <<< "$rdesktop"
label="${rtags[$d]}"
((w)) && fg="#f85708" || fg="#a8a8a8"
((c)) && fg="#65ac35" bg="#282a2b" layout="${layouts[$m]}" bsep="<" asep=">" || bsep=" " asep=" " bg="#282a2b"
((u)) && fg="#7b41ff"
r+="^fg($fg)^bg($bg)$bsep$label$asep^bg()^fg()"
done
[[ -n $l ]] && echo "$l" > /tmp/lmon
[[ -n $r ]] && echo "$r" > /tmp/rmon
# clean up for next loop
unset lmon rmon l r
done < /tmp/mon &
monsterwm > /tmp/mon
And the errors that it generated:
scripts/multi-monster: line 23: : == 0 : syntax error: operand expected (error token is "== 0 ")
scripts/multi-monster: line 25: Ou: == 1 : syntax error: operand expected (error token is "== 1 ")
scripts/multi-monster: line 45: ((: 010:0:0:0: syntax error in expression (error token is ":0:0:0")
scripts/multi-monster: line 45: ((: 0:0:0: syntax error in expression (error token is ":0:0")
Last edited by bslackr (2012-09-23 09:21:33)
Offline
first of all '((' '[[' and arrays, are Bash's features. So you better change '#!/bin/sh' to '#!/usr/bin/env bash'
then this:
IFS=':' read -r d w m c u <<< "$ldesktop"
the xinerama-* branches output more info, specifically they output two more elements at the start of the output string, to indicate on which monitor the following info is about, and if that, is the current active monitor.
so you need:
IFS=':' read -r x y d w m c u <<< "$ldesktop" # also change rdesktop
where 'x' is the monitor id, and 'y' is '1' if that monitor is the active monitor.
I usually call them 'm' and 'n' and have the previous 'm' that denoted the mode as 'l'
so
IFS=':' read -r m n d w l c u <<< "$ldesktop"
but that's just my preference.
so you can use those to, say, change the bg color of the panel if the monitor is inactive, etc
.:[ git me! ] :.
Offline
Okay, everything almost works now. The only problem I am still running into is that dzen isn't being updated on anything so when I change workspaces, etc. nothing is happening on it. Am I using the fifos wrong or something? My updated script is below:
#!/usr/bin/env bash
ff="/tmp/monsterwm.fifo"
lmonff="/tmp/monsterwm_l.fifo"
rmonff="/tmp/monsterwm_r.fifo"
[[ -p $ff ]] || mkfifo -m 600 $ff # monsterwm's output
[[ -p $lmonff ]] || mkfifo -m 600 $lmonff # for the left monitor
[[ -p $rmonff ]] || mkfifo -m 600 $rmonff # for the right monitor
dzen2 -w 320 -h 18 -ta l -xs 1 -p < $lmonff &
dzen2 -w 320 -h 18 -ta l -xs 2 -p < $rmonff &
ltags=("main" "web" "dev" "vm" "null")
rtags=("video" "pdf" "dev" "vm" "null")
layouts=("[]" "[|]" "[#]" "[G]" "[P]")
while read -ra desktops
do
for desk in "${desktops[@]}"
do
if (( ${desk%%:*} == 0 ))
then lmon+=( $desk )
elif (( ${desk%%:*} == 1 ))
then rmon+=( $desk )
fi
done
# Get the information from the left monitor
for ldesktop in "${lmon[@]}"; do
IFS=':' read -r x y d w m c u <<< "$ldesktop"
label="${ltags[$d]}"
((w)) && fg="#f85708" || fg="#a8a8a8"
((c)) && fg="#65ac35" bg="#282a2b" layout="${layouts[$m]}" bsep="<" asep=">" || bsep=" " asep=" " bg="#282a2b"
((u)) && fg="#7b41ff"
l+="^fg($fg)^bg($bg)$bsep$label$asep^bg()^fg()"
done
for rdesktop in "${rmon[@]}"; do
IFS=':' read -r x y d w m c u <<< "$rdesktop"
label="${rtags[$d]}"
((w)) && fg="#f85708" || fg="#a8a8a8"
((c)) && fg="#65ac35" bg="#282a2b" layout="${layouts[$m]}" bsep="<" asep=">" || bsep=" " asep=" " bg="#282a2b"
((u)) && fg="#7b41ff"
r+="^fg($fg)^bg($bg)$bsep$label$asep^bg()^fg()"
done
[[ -n $l ]] && echo "$l" > "$lmonff"
[[ -n $r ]] && echo "$r" > "$rmonff"
# clean up for next loop
unset lmon rmon l r
done < "$ff" &
monsterwm > "$ff"
Offline
I want to report bug with focus and newsbeuter.
How to produce it:
1. Start "newsbeuter", terminal program for reading feeds, and firefox;
2. Try to open any feed in firefox (by default, use "o" on desired link to open it in browser defined in $BROWSER);
3. Link will open but terminal with "newsbeuter" will loose focus and you wil have to change workspaces again to be able to regain focus on terminal with newsbeutter.
I believe that this has to do something with this. Here is what you should know about newsbeuter:
- If you press "o" and try to open $BROWSER for the first time (like new istance), newsbeuter will focus on sendind command to start $BROWSER and view feed. That means that newsbeuter is not usable while you watch desired feed;
- If you have one istance of $BROWSER (for example: firefox, which supports tabs), newsbeuter will send command to open it in new tab in $BROWSER (if browser supports tabs). After that you can use newsbeuter right away and not focus on $BROWSER.
I wrote this since maybe there is a reason why i get this bug.
Offline
Offline
@kuraku
hmm, it works as expected here.
Opening a feed item with 'o' in newsbeuter invoking firefox,
opens a new tab on firefox and focus remains on newsbeuter.
what I did:
0.a. installed newsbeuter
0.b. added archlinux.org news feed to 'urls' file
0.c. added 'browser "firefox %u"' on config file
1. started firefox and placed it in another desktop
2. started newsbeuter and refreshed feed list to fetch items
3. opened the feed, and pressed 'o' to open the item on firefox
4. on the other desktop a new tab opened on firefox with the item
5. on the current desktop newsbeuter remained focus and active
same thing happens if firefox is on the same desktop as newsbeuter
or even if firefox is on the same or other desktop in another monitor.
@Šaran
yeap, same thing happens with Open/Libre Office's splash screen
and I dont think there is a sane way around it w/o adding useless code.
if you set gimp to floating, then the splash screen will be normal.
it might be useful to have a check for _NET_WM_WINDOW_TYPE_SPLASH
and have splash screen floating, but imo it's not worth it.
@bslackr
yep, the problem is that dzen2 will stop reading the pipe, once it reads the first line
so replace
dzen2 -w 320 -h 18 -ta l -xs 1 -p < $lmonff &
dzen2 -w 320 -h 18 -ta l -xs 2 -p < $rmonff &
with
while true; do cat < "$lmonff" ; done | dzen2 -w 320 -h 18 -ta l -xs 1 -p &
while true; do cat < "$rmonff" ; done | dzen2 -w 320 -h 18 -ta l -xs 2 -p &
Last edited by c00kiemon5ter (2012-09-23 15:30:26)
.:[ git me! ] :.
Offline
Thank you for clarification. I just found out that Gimp's splash can be disabled with -s switch.
Bugs!
1. gtk-youtube-viewer spawns mplayer in floating fullscreen, even if mplayer is set not to float in config.h.
2. That same mplayer can't be tiled.
I thought this was caused by window hiding approach, but other bugs got squashed and this is still present.
And one more thing.
If there are two floating windows, smaller A on top of the bigger B, only B will be visible if it gets focused.
This makes using settings dialogs that spawn floating windows on top of each other almost impossible (I use mouse follow focus, it's really practical with toucpad).
In DWM focus has nothing to do with which window is in foreground and which gets sent to background and small windows are always vissible.
For me, that approach to floating feels more natural.
I brought this up long time ago, but you said MWM's design had to be changed (there was no floating mode at the time). I'd like to know if this is possible now.
Thanks.
Offline
Bugs!
1. gtk-youtube-viewer spawns mplayer in floating fullscreen, even if mplayer is set not to float in config.h.
2. That same mplayer can't be tiled.
Can you post the output of 'xprop' selecting the mplayer window, and probably your config rules ?
Here, gtk-youtube-viewer seems to work just as expected.
mplayer is tiled if it is set to not be tiled in config.h and
if it is floating pressing the tiling layout keybind will tile it.
also check you havent added a relevant setting in mplayer's configuration file
~/.mplayer/config
MPlayer user settings
~/.mplayer/gui.conf
GUI configuration file
~/.mplayer/gui.pl
GUI playlist
~/.mplayer/gui.url
GUI URL list
If there are two floating windows, smaller A on top of the bigger B, only B will be visible if it gets focused.
This makes using settings dialogs that spawn floating windows on top of each other almost impossible (I use mouse follow focus, it's really practical with toucpad).
In DWM focus has nothing to do with which window is in foreground and which gets sent to background and small windows are always vissible.
I'm not sure I understand.
If you have two floating windows, A and B, and A is smaller than B, then focusing B will completely hide A.
In other words, the focused window always gets on top. This happens on both monsterwm and dwm.
In dwm the last focused floating window will be on top of the other floating and tiled windows.
On monsterwm the ordering of the windows matters.
Windows are placed on top of each other in the order they are spawned, from bottom to top.
That means, the last spawned floating window will be on top of the other windows if a non-floating window is focused,
even if the previously focused floating window was another one - this is where the floating windows behaviour differs.
So having the smaller window spawn last or moving to the end of the stack will leave it on top.
This is done this way because the focus needs to take into account that the windows present single borders (ie border overlap)
and because the restacking (which window is on top of which) code is minimized
Last edited by c00kiemon5ter (2012-09-23 16:53:30)
.:[ git me! ] :.
Offline