Re: [dwm] dvtm suggestion
hmm... i sometimes use dvtm in dwm well am sticking to using thangs i can get from ubuntu's packages but this way of combining dvtm dwm is not smart? yes i also think that the key-bindings of dvtm is a bit tidious but if it becomes the same with dwm i cannot use dvtm in dwm .. right? if there could be an interactive mode switcher for dvtm that would be great On Tue, Sep 16, 2008 at 06:16:41PM +0200, [EMAIL PROTECTED] wrote: Hi, Just a question inspired by this thread: * Donald Chai [EMAIL PROTECTED] [2008-08-29 14:10]: Another thing is that since I use dvtm when I can't use dwm, I have ALT-j cycle through windows, rather than CTRL-g j. So I don't ever have to punch in CTRL-g j CTRL-g j :) I use both dwm and dvtm. And when I am forced to use windoze I use cygwin+dwm too, so I almost always use dvtm from within dwm -- when I log to other remote machines of mine. (That's why I like the Status bar of dvtm too). I slowly get used to type C-g-whatever but often it is still a bit confusing when I'm not aware that I'm inside dvtm, and expect to move around with MOD-whatever... The best way to cope with this seems to me to be a key binding for switching on/off grabbing MOD in dwm. Say, MOD-g, like in - MOD-3 // goto tag 3, where the dvtm terminal is running - MOD-G // stop grabbing MOD - MOD-j,k,... // do what I want in dvtm with the dwm/dvtm key bindings - MOD-G // (uppercase G!=g dvtm grid layout) start grabbing MOD - MOD-. // back in dwm world Well, _not grab_ is perhaps better said _pass through_, I don't know ... Does this sound meaningful? Is it doable without much overhead? Thanks! -- cheers stanio_ -- '2+ http://sarigama.namaste.jp/ is podcasting his microtuned music http://www002.upp.so-net.ne.jp/buyobuyo/micro/rss.xml
Re: [dwm] dvtm suggestion
On Sep 16, 2008, at 9:16 AM, [EMAIL PROTECTED] wrote: --snip-- The best way to cope with this seems to me to be a key binding for switching on/off grabbing MOD in dwm. Say, MOD-g, like in - MOD-3 // goto tag 3, where the dvtm terminal is running - MOD-G // stop grabbing MOD - MOD-j,k,... // do what I want in dvtm with the dwm/dvtm key bindings - MOD-G // (uppercase G!=g dvtm grid layout) start grabbing MOD - MOD-. // back in dwm world Well, _not grab_ is perhaps better said _pass through_, I don't know ... Does this sound meaningful? Is it doable without much overhead? Probably, but it's most likely unnecessary. All you really need to do is set dwm up to use Mod4 and MODKEY, and add two keybindings: Mod4+G - xmodmap -e remove mod4 = Alt_L -e add mod1 = Alt_L Mod1+G - xmodmap -e remove mod1 = Alt_L -e add mod4 = Alt_L Replace Alt_L with whatever key(s) you want to multiplex.
Re: [dwm] dvtm suggestion
Donald Chai wrote: - tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') Why had you to rip out these things? There is a git branch which should mostly work but i so far failed to find acceptable keybindings for all the tag actions. http://repo.or.cz/w/dvtm.git?a=shortlog;h=refs/heads/tagging I didn't see the git branch when I made that comment. But now that I've seen it, I've got to say, I don't like it. I use dvtm when I can't use dwm, and for various reasons prefer that they share as much code as possible. - The ability to minimize windows is mostly useless when you have tags and workspaces. The exception is if one is using the window title as another status bar. I find the window title as status bar functionality especially useful when dealing with long running tasks which don't need my attention. - The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ I agree, however this is because the various functions take char* arrays instead of an Arg union. This makes it impossible to specify bit masks. We could of course change this but it would break the new command interface[1]. - The focusn procedure takes away valuable key bindings that I use for tagging. I personally find this fast selection quite useful, but it's probably true that when your working with tags you have less windows per view and the quick selection is no longer that important. An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c). Does this mean the keypad works for you within putty? Regards, Marc [1] http://lists.suckless.org/dwm/0806/6114.html -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] dvtm suggestion
- The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ I agree, however this is because the various functions take char* arrays instead of an Arg union. This makes it impossible to specify bit masks. We could of course change this but it would break the new command interface[1]. umm...atoi()? :) - The focusn procedure takes away valuable key bindings that I use for tagging. I personally find this fast selection quite useful, but it's probably true that when your working with tags you have less windows per view and the quick selection is no longer that important. Another thing is that since I use dvtm when I can't use dwm, I have ALT-j cycle through windows, rather than CTRL-g j. So I don't ever have to punch in CTRL-g j CTRL-g j :) An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c). Does this mean the keypad works for you within putty? The keypad works just fine without any hacks in dvtm. PuTTY just happens to be set up incorrectly by default. TERM is set to xterm, so one should just go to Terminal - Keyboard and set The Function keys and keypad to Xterm R6.
Re: [dwm] dvtm suggestion
Donald Chai wrote: - The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ I agree, however this is because the various functions take char* arrays instead of an Arg union. This makes it impossible to specify bit masks. We could of course change this but it would break the new command interface[1]. umm...atoi()? :) This won't work, because we don't know the type of the arguments. echo focus $DVTM_WINDOW_ID $DVTM_CMD_FIFO echo create \'irssi -c irc.freenode.net\' $DVTM_CMD_FIFO In the first case the focus command takes an integer, however create expects a string. Storing the the argument data type in the Cmd struct would be ugly and inflexible. - The focusn procedure takes away valuable key bindings that I use for tagging. I personally find this fast selection quite useful, but it's probably true that when your working with tags you have less windows per view and the quick selection is no longer that important. Another thing is that since I use dvtm when I can't use dwm, I have ALT-j cycle through windows, rather than CTRL-g j. So I don't ever have to punch in CTRL-g j CTRL-g j :) Ah I see. An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c). Does this mean the keypad works for you within putty? The keypad works just fine without any hacks in dvtm. PuTTY just happens to be set up incorrectly by default. TERM is set to xterm, so one should just go to Terminal - Keyboard and set The Function keys and keypad to Xterm R6. Yes indeed, the handling of \e0[n] isn't needed. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] dvtm suggestion
On Sun, Aug 17, 2008 at 04:28:47AM -0700, Donald Chai wrote: What about the ability to run different dvtm instances on different virtual terminals that share a common session? This could be seen as the tag/workspace concept. You could detach a window on /dev/tty1 and reattach it in your other dvtm on /dev/tty3. The only thing that comes to my mind is that in order to get six workspaces you'd have to log in manually six times on different consoles. Or perhaps there is a getty out there that supports multi-logins... Are you simply looking for a tag/workspace mechanism, or do you want the ability to detach and reattach sessions? - tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') Why had you to rip out these things? There is a git branch which should mostly work but i so far failed to find acceptable keybindings for all the tag actions. http://repo.or.cz/w/dvtm.git?a=shortlog;h=refs/heads/tagging - GNU Screen does detach/reattach. dtach provides only detach/reattach functionality without the bloat of GNU Screen. Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [dwm] dvtm suggestion
- tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') Why had you to rip out these things? There is a git branch which should mostly work but i so far failed to find acceptable keybindings for all the tag actions. http://repo.or.cz/w/dvtm.git?a=shortlog;h=refs/heads/tagging I didn't see the git branch when I made that comment. But now that I've seen it, I've got to say, I don't like it. I use dvtm when I can't use dwm, and for various reasons prefer that they share as much code as possible. - The ability to minimize windows is mostly useless when you have tags and workspaces. The exception is if one is using the window title as another status bar. - The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ - The focusn procedure takes away valuable key bindings that I use for tagging. An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c).
Re: [dwm] dvtm suggestion
What about the ability to run different dvtm instances on different virtual terminals that share a common session? This could be seen as the tag/workspace concept. You could detach a window on /dev/tty1 and reattach it in your other dvtm on /dev/tty3. The only thing that comes to my mind is that in order to get six workspaces you'd have to log in manually six times on different consoles. Or perhaps there is a getty out there that supports multi-logins... Are you simply looking for a tag/workspace mechanism, or do you want the ability to detach and reattach sessions? - tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') - GNU Screen does detach/reattach.
