You are not logged in.
My bad. AltSuper was being taken as Alt so you ended up with Alt+t spawning your altxtermcmd instaed of Alt+Super+t. Sorry about that. Using Linus' philosophy on patches where if it builds push it didn't work this time. Changed it to ALTSuper and actually checked it worked before pushing it...
Just a heads up, you can spawn the same command with different keys if you want, no need to make a seperate command for a test.
I don't know if there's a way to catch when a window crashes in X, I've never looked into it. I'll see if I can come up with something for that.
Cheers
You're just jealous because the voices only talk to me.
Offline
Changed it to ALTSuper and actually checked it worked before pushing it...
Tanks. Works great now that I figured out the correct capitalization.
Offline
O hai. Me again.
I am noticing that in dminiwm & snapwm, if I am in fullscreen, I have one window open, the statusbar gap is off, I open one or more new windows and then toggle the statusbar gap on, the window(s) underneath the current window do not have their gaps toggled and they obscure the bar from being seen. That might seem like a pretty obscure set of conditions, but I spend a lot of time in fullscreen with the statusbar gap off on my netbook, so I notice this once in a while.
I have also been wondering, on the topic of statusbar gap toggling, whether you would have any interest in adding an option to {dmini,snap}wm to have the toggling of the statusbar and/or gap be done on a per-workspace basis.
Offline
Phil, not 'a pretty obscure set of conditions' at all. That shows a flaw in the basic functioning of fullscreen mode which I'm sure I covered ages ago but I copy/paste to/from lots of different things so that was lost. Thanks for pointing that out, fixes have been pushed.
I had a cup of coffe and a think about having the bar toggled on a per desktop basis and the code as it is makes that a bit hard to do. Then I had another coffe and thought about how I use toggling the bar and mostly that's just for one desktop while e.g. watching a movie. I'll have another coffee and see if I can come up with a simple method for that, thanks for mentioning it.
Cheers
You're just jealous because the voices only talk to me.
Offline
Phil, not 'a pretty obscure set of conditions' at all. That shows a flaw in the basic functioning of fullscreen mode which I'm sure I covered ages ago but I copy/paste to/from lots of different things so that was lost. Thanks for pointing that out, fixes have been pushed.
Tanks, I'll try this out. :-)
I had a cup of coffe and a think about having the bar toggled on a per desktop basis and the code as it is makes that a bit hard to do. Then I had another coffe and thought about how I use toggling the bar and mostly that's just for one desktop while e.g. watching a movie. I'll have another coffee and see if I can come up with a simple method for that, thanks for mentioning it.
Geez, I hope it's decaf! ;-)
Maybe check either monsterwm or dwm code, as I believe they can both do this. Not totally sure, though.
Offline
Decaf is for pussies! I drink espresso !
Toggling the bar is now done on a per desktop basis in dminiwm, snapwm and larrythewindowmanager. It wasn't that hard to do, coming up with the right, simple way to do it was the 'hard' bit.
If there's any issues with it let me know, seems fine here with the testing I've done.
Cheers
You're just jealous because the voices only talk to me.
Offline
Testing it now. Seems to work well on snapwm, but might need a bit more work on dminiwm.
With my config (https://github.com/philthomson/archimed … m/config.h), in which the statusbar gap is off by default, I get some weird behaviour. When I start my session, the statusbar gap is off on only the first workspace by default, but on by default on all the others. However, when I switch back to the first workspace, the statusbar gap is on again. The behaviour I expect with this config is to have the statusbar gap off by default on all workspaces and to be able to toggle it on and off on a per-workspace basis.
I'll keep testing for a bit to confirm this behaviour, but this is how it seems to me.
Other than that, the per-workspace toggling seems to work well so far. Looks like your espresso turned into some good code! :-) Thanks!
EDIT: Just noticing some strange behaviour in the panel when moving windows across workspaces in dminiwm. See the following two screenshots; notice the panel at the bottom:
http://ompldr.org/vZm00cg (before moving the window via keyboard shortcut)
http://ompldr.org/vZm00dA (after)
Last edited by hellomynameisphil (2012-09-24 06:18:53)
Offline
I'm getting some weird behavior in dminiwm too when moving windows between workspaces. It seems to work fine in snapwm. I think it's a good idea too. Thanks.
Offline
Phil, I fixed the initial state of the bar on startup - it should be the same for all desktops now.
I've been moving windows between desktops like a madman for about a half hour and I can't reproduce what's in the screenshot.
Is there a particular scenario when it happens? Like moving a window to an empty desktop, following it etc. Any app running that outputs lots of info to tty?
stlarch is the weird behaviour your getting the same as in Phil's screenshot?
Edit: does changing desktops return the bar to how it shoulld be?
I'm guessing the .xinitrc being used is similar to the one I posted earlier but I'll repost mine again for comparison:
starter="exec ck-launch-session dbus-launch --sh-syntax --exit-with-session "
numlockx &
xsetroot -cursor_name left_ptr &
fbsetbg -l &
#turn of the caps lock key !!
xmodmap -e 'keycode 66 ='
#xterm &
conky -c ~/build/status_conky.ssb | while read -r; do xsetroot -name "$REPLY"; done &
ff="/tmp/dminiwm.fifo.$DISPLAY"
[[ -p $ff ]] || mkfifo -m 600 "$ff"
ds=(" Ë" " ¾" " ´" " ©" " Ê" " à")
ms=("" "" "" "" "")
while read -r wmout || true; do
if [[ $wmout == [[:digit:]]:[[:digit:]]:[[:digit:]]* ]]; then
unset r
read -ra desktops <<< "$wmout"
for desktop in "${desktops[@]}"; do
IFS=':' read -r d n c <<< "$desktop"
fg="&B0&5"
[[ $n -gt 0 ]] && fg="&B2&6"
[[ $c -gt 0 ]] && fg="&B3&9" && num=" &1:&5$n"
[[ "$c" != "" ]] && r+="$fg${ds[$d]} &5&B0\u19"
done
[[ "$desktop" = "1" ]] || num=""
mode="${ms[$desktop]}"
printf "$r&B0$num &1$mode \n"
fi
done < $ff | ~/progs/c.files/bipolarbar/bipolarbar &
$starter ~/build/dminiwm-0.4.2/src/dminiwm > $ff
I'll keep playing around with it and see what happens.
Last edited by moetunes (2012-09-24 08:01:58)
You're just jealous because the voices only talk to me.
Offline
Phil, I fixed the initial state of the bar on startup - it should be the same for all desktops now.
Tanks; I'll try it out.
Edit: does changing desktops return the bar to how it shoulld be?
Yes.
I'm guessing the .xinitrc being used is similar to the one I posted earlier[...]
My startup script, which is called by my .xinitrc, is here: https://github.com/philthomson/archimed … rt_dminiwm
Offline
It's kind of hard to explain. When I have two windows open on a workspace (terminal and firefox) and move firefox to another desktop, sometimes I get two instances of firefox on both workspaces. Or if I move the terminal to another workspace, firefox will sometimes disappear altogether. The open windows indicator usually still shows 2 open windows (sometimes it doesn't though) and will kind of lock the bar up. Switching desktops can kind of reset the bar (I think) but the missing or extra window doesn't seem to get closed and I get an error like it wasn't shut down properly when logging out of X. I hope that makes some sense at all? I'll keep playing with it when I have some time and try to give a more accurate description.
Offline
It's kind of hard to explain. When I have two windows open on a workspace (terminal and firefox) and move firefox to another desktop, sometimes I get two instances of firefox on both workspaces.
Yes, This happened to me with emacs, and I thought I was crazy. I don't remember the exact circumstances in which this happened though... Sorry...
Or if I move the terminal to another workspace, firefox will sometimes disappear altogether.
This happened to me with dwb.
The open windows indicator usually still shows 2 open windows (sometimes it doesn't though) and will kind of lock the bar up. Switching desktops can kind of reset the bar (I think) but the missing or extra window doesn't seem to get closed...
When dwb disappeared, it still showed up in xlsclients and I seem to remember it still showed up in the bar.
Bummer of a bug to fix, Moe. Sorry I don't have more thorough test cases that you can use for debugging. Hope your espresso maker is plugged in. ;-)
Offline
I can also confirm that this bug exists and can rarely be reproduced. For me, it seems to only happen with gVim and luakit.
"Unix is basically a simple operating system, but you have to be a genius to understand the simplicity." (Dennis Ritchie)
Offline
Random disappearing windows, not what i was going for at all. I guess this is in fullscreen mode? If it is and it happens again can you check if changing modes to, say, vertical has the window showing again? If it's not it'll be a hard bugger to track down, but I'm powered by coffee!
You're just jealous because the voices only talk to me.
Offline
Yes, the dissapearing and more than one instance seems to be related to fullscreen (here at least). I am still having problems with the bar in other tiling modes though but it seems to get reset when changing workspaces or modes after a few seconds if that helps?
Last edited by stlarch (2012-09-24 20:02:55)
Offline
Any clues help I haven't had any of those errors yet in dminiwm (window errors are just in dminiwm right?) but I'll stay in dminiwm in fullscreen mode until it's sorted. I pushed a fix for window positioning in vertical mode and removed an unneeded XUnmapWindow from the client_to_desktop function, which I'd be suprised if it fixes the issue but you never know...
Thanks for your patience everyone.
Edit: It just occurred to me I've been using a locally built dminiwm not a PKGBUILD one, maybe that makes a difference..
Cheers
Last edited by moetunes (2012-09-24 21:12:20)
You're just jealous because the voices only talk to me.
Offline
Well, after the last update, when I try to open anything, the wm crashes. It is just dminiwm. I haven't noticed anything in snapwm. Maybe it's because I have
static const Convenience convenience[] = { \
/* class desktop follow */
{ "None", 0, 0 },
};
in my config.h? Just a guess. For some reason, I thought it was something to do with that but I really don't know. I have to leave for a while but I'll check it better later tonight. Thanks.
Offline
Nope, won't be because of that. I changed the config.h for the PKGBUILD here to that and it built and ran fine. The last changes were just to remove extra borderwidths and a line that was repeated in the client_to_desktop function so it won't affect the wm running at all.
I've been running dminiwm for hours this morning and last night and it's been rock solid here, I can't get it to do anything unpredictable at all. The client_to_desktop function is the same in dminiwm, snapwm and larrythewindowmanager so the problem should be the same in all of them but it's not happening here. The desktop info part of dminiwm is the same as what's in larrythewindowmanager and I've been running that constantly for weeks and never had an issue. So either I'm running that part differently, which doesn't seem to be the case, or the issue is somewhere else.
I'll keep exploring to see if I can come up with something.
You're just jealous because the voices only talk to me.
Offline
stlarch, try an update again and I think the starting issue should be gone, I keep forgetting to start in fullscreen mode to check things... apologies for that.
You're just jealous because the voices only talk to me.
Offline
It does seem related to fullscreen. I can open one window but when I try to open a second one in fullscreen, the wm crashes. I can open more than one in another mode and then switch to fullscreen. I'll post my config.h and the relevant part of my .xinitrc:
https://docs.google.com/file/d/0ByfkpBn … ZRaDQ/edit
ff="/tmp/dminiwm.fifo.$DISPLAY"
[[ -p $ff ]] || mkfifo -m 600 "$ff"
ds=(" 1 " " 2 " " 3 " " 4 ")
ms=(" " " " " " " " " ")
while read -r wmout || true; do
if [[ $wmout == [[:digit:]]:[[:digit:]]:[[:digit:]]* ]]; then
unset r
read -ra desktops <<< "$wmout"
for desktop in "${desktops[@]}"; do
IFS=':' read -r d n c <<< "$desktop"
fg="&7" bg="&B0"
[[ $n -gt 0 ]] && fg="&3" bg="&B6"
[[ $c -gt 0 ]] && fg="&0" bg="&B3" && num=" &1[&3$n&1]"
[[ "$c" != "" ]] && r+="$fg$bg${ds[$d]}"
done
[[ "$desktop" = "1" ]] || num=""
mode="${ms[$desktop]}"
printf "$r&B0$num &3$mode \n"
fi
done < $ff | bipolarbar &
dminiwm > $ff
rm $ff
Last edited by stlarch (2012-09-25 03:34:45)
Offline
stlarch, the error was at my end. I really have to find a way to organize myself between locally built and PKGBUILD executables.
And not rush to push things. Maybe less coffee will help there... Should be fixed on git, I made sure I checked the right executable this time.
With a day of using dminiwm in fullscreen mode I still haven't had a disappearing/multiple window issue or any errors from the desktop info. At this stage I still don't know what to do about that.
You're just jealous because the voices only talk to me.
Offline
No worries. We know you're a one man team. I wish I could help more. We appreciate everything you do. I can open multiple windows now. I'll keep playing with it and see if I can stumble on to something. Thanks again.
Offline
With the latest git pull of snapwm, the fifth colour in STATUSTHEME in rc.conf doesn't seem to do anything. The fourth colour seems to set the colour for both 'unfocused desktop with opened windows font in switcher' and 'the focused window name font in the status bar'.
Offline
Yep, didn't bump the number up when adding the background to that line. Fixed and pushed.
Cheers
You're just jealous because the voices only talk to me.
Offline
Tanks. Dat seems to do it.
Offline