15:44:28Demosthenexplus since all the groups (virtual screens) are created dynamically... i have plenty of room!

16:21:41Demosthenexok, i still can't get conky right. i have tried it's own_window_type settings several times with dock, panel, and desktop. it's alwyas hidden instead of being a persistent left window

17:26:04Misha_Bhello, is there a way to make all the menus centered on the screen?

17:26:04ColleenMisha_B: mood said 20 hours, 36 minutes ago: I see it's not documented, but you can set the width using set-frame-outline-width

17:26:48Misha_Berr, thanks, although I think the problem was with compton, since It doesn't happen now that I turned it off

17:36:13sjl_Misha_B: not sure which menus you mean, but maybe *message-window-gravity* and *input-window-gravity* are what you're looking for

18:57:01scottjDemosthenex: yeah, that's what I tried initially. thought it might be nice to be able to move spatially though, instead of thinking about the numbers. this is a start http://dpaste.com/1NYP90E

19:01:50Demosthenexi added a "reset to origin" key in my latest, and a "pop" key to goto last for toggles

19:02:08Demosthenexgiven the number is in the top left of my screen ,it's not hard

19:02:25Demosthenexit'd be nice to say, mark window, navigate to destination... pull marked window to group

19:06:39scottjthat's kind of how my command works, but instead of marking a window, you hold meta while navigating and it brings the window along. one downside of mine is the window covers the existing windows as you're navigating, which is more of a problem if you tend to have one frame per group.

19:11:37Demosthenexwhat i wanted was each screen to be a view around the cursor, so if i used control right, basically the screens would slide left across monitors

19:12:05scottjit's an interesting approach. I'd like to support the per-project aspect of it, but I think I prefer "organizing" by program (keybinding to jump to common apps) vs spatially. can you think of advantages of yours over say having a bindings that give your project always jumps you to firefox/xterm/vm/emacs/etc?

19:14:20Demosthenexscottj: i have emacs running in daemon mode, and i may have 15 frames with different files open on different desktops. i have tons of urxvt's open. i may have firefox windows opened everywhere too in order to make the content adjacent to what i'm working on

19:15:04Demosthenexscottj: i could see a shortcut to the origin of each of 10 taskplanes

19:15:13MichaelRaskinIn StumpWM that would be reasonably easy to scripts if you never want to change the frame splits (or if you use unsplit monitors)

19:15:18Demosthenexthat gives you 10 core tasks to switch to instantly

19:15:41scottjDemosthenex: no, I mean at any point you can create a new group/set of groups that represent a project, and inside those the emacs binding takes you to the emacs window/instance for that project

19:15:48DemosthenexMichaelRaskin: i'm back down to one monitor, so multimonitor isn't a big deal atm. but i'm confident it could be done with stump

19:17:28Demosthenexscottj: i use xbindkeys to launch things because i've changed wm's a few times

19:17:56Demosthenexreally i use right alt-shift-enter to spawn urxvt, right alt E for emacs, right alt F for firefox, and that's about it

19:18:09Demosthenexthough i do have ncmpc and mpd fully integrated with my numpad for changing music ;]

19:18:52scottjDemosthenex: I much prefer app bindings bc emacs is always s-e whereas spatially emacs might be C-left C-left or any combination of directions (though it may be the same direction if your main window is almost always the one you are in when you decide to go to emacs)

19:19:30Demosthenexi think that's the argument. emacs is commonly my core task, so it's centered. i already made a hotkey to return to origin (0,0) on the current taskplane (z)

19:20:16Demosthenexthe xmonad folks want to make all terminals goto one workspace, all firefox goto another workspace, all editors goto another workspace, and gee whiz you get 10 workspaces and alt-# bindings to swap.

19:20:30Demosthenexit was really confining and completely opposite what i wnated to do, and haskell is a pita to learn

19:21:06scottjSo in awesome, you have it displaying on three screens, one per (what stumpwm calls a) group?

19:28:30Demosthenexmy ideal would be a 3d space of virtual screens, and every monitor/head would be like a cursor in that space. if you have 3x3 monitors connected, they could display the 3x3 under them, or pan around as a unit.

19:29:20MichaelRaskinAnd the virtual screens have nonintersecting sets of windows?

19:29:38MichaelRaskinAnd each virtual screen fits a monitor without sub-panning?

19:31:46Demosthenexagain, i got used to this in Enlightenment v14. they let you have multiple virtual screens in a 2d array which was your "desktop". then you had 10 virtual desktops in that configuraiton.

19:41:36MichaelRaskinDemosthenex: WSE might become useful in case of two monitors

19:41:48DemosthenexMichaelRaskin: yeah, if i had to generate a new group dynamically

19:42:09MichaelRaskinAnother option is just to keep the same group and refill the frames

19:42:21Demosthenexone of awesome's issues was they could have each monitor in a group, BUT no group could ever be on two monitors at the same time. so i was trying to get it to swap, and it was slow :P

19:43:32MichaelRaskinI think the trick in StumpWM was to do fclear for every frame where you play with the window set — if a frame has multiple windows and you remove them all, there is a lot of flicker and a lot of slowdown

19:44:11MichaelRaskinFor conky maybe you could reserve some space in each group, and redefine the binding to do a group switch then pull conky

19:44:17Demosthenexwell, atm i'm using just my laptop screen (or a single monitor when docked), and stump is fast as hell