|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.|
|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|
|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."