| sorear | jcreigh: yes. |
| sjanssen | 2. write the status bar as a separate process |
| action | sorear finds 'x' and 'y' extremely unhelpful names for indexing variables |
| sorear | finds 'x' and 'y' extremely unhelpful names for indexing variables |
| sjanssen | 2 probably means we won't be able to do workspace switching on statusbar clicks (like dwm does) |
| jcreigh | There's also awkward IPC issues. (How does xmonad know, eg, how high the status bar is?) and the statusbar process would have to know about Xinerama, or we would have to spawn one per screen. probably the former would be easier. |
| sjanssen | xinerama is okay -- X11-extras makes that easy and shouldn't the status bar be a constant height in pixels? |
| jcreigh | sjanssen: people keep mentioning XCB...how long do you think it will be before we can port xmonad to it? |
| action | sorear reminds jcreigh that sjanssen has $5k of incentive to finish xhsb before September |
| sorear | reminds jcreigh that sjanssen has $5k of incentive to finish xhsb before September |
| dons | jcreigh: i'd imagine a fe months away yet. |
| jcreigh | okay...I'm just trying to get a feel for how practical it actually is to say "we'll fix that in the XCB version" I'm trying to avoid wrapping the XModifierKeymap struct. :) |
| dylan | xcb-xmonad could be v2. ;) |
| sorear | wow, two major versions away... |
| dylan | pssh, it could be one version away |
| sorear | we're at version 0 now |
| dylan | v0 to v2 then. skip 1 |
| sorear | well, 0.1 to be precise |
| jcreigh | when we do switch to XCB, it probably should be a major version bump. So xcb-xmonad might indeed end up being xmonad 2.0 |
| thoughtpolice | what exactly are the advantages of XCB compared to just standard Xlib. i mean, I know, xlib is kind of ew, but i'm simply wondering. |
| sorear | xlib is very ew. |
| jcreigh | supposedly, we could actually do threading the xcb. |
| sorear | that's the reason. for quite a few values of ew... it's 20x larger than it needs to be, it is thread unsafe, it is synchronous, it has a huge api, ... |
| gravity_ | 20 years of cruft |
| thoughtpolice | delicious |
| sorear | xcb/xmonad will use far less ram than xlib/dwm, even after you factor in the GHC RTS |
| jcreigh | For example, since this is the most recent thing that ticked me off: The XModifierKeymap structure: http://tronche.com/gui/x/xlib/input/keyboard-encoding.html#XModifierKeymap |
| lambdabot | Title: Xlib Programming Manual: Keyboard Encoding, http://tinyurl.com/2dxpco |
| jcreigh | int max_keypermod; /* This server's max number of keys per modifier */ KeyCode *modifiermap; /* An 8 by max_keypermod array of the modifiers */ |
| sorear | only 2 fields is that bad? |
| jcreigh | Well, other functions take this struct. So it's hard to do meaningful FFI with something like that. That's more of C gripe, though. "Data structures? We don't need to stinkin' data structures." |