#haskell - Tue 24 Apr 2007 between 02:56 and 00:28

NY Lost Funds



sorearjcreigh: yes.
sjanssen2. write the status bar as a separate process
actionsorear finds 'x' and 'y' extremely unhelpful names for indexing variables
sorearfinds 'x' and 'y' extremely unhelpful names for indexing variables
sjanssen2 probably means we won't be able to do workspace switching on statusbar clicks (like dwm does)
jcreighThere'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.
sjanssenxinerama is okay -- X11-extras makes that easy
and shouldn't the status bar be a constant height in pixels?
jcreighsjanssen: people keep mentioning XCB...how long do you think it will be before we can port xmonad to it?
actionsorear reminds jcreigh that sjanssen has $5k of incentive to finish xhsb before September
sorearreminds jcreigh that sjanssen has $5k of incentive to finish xhsb before September
donsjcreigh: i'd imagine a fe months away yet.
jcreighokay...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. :)
dylanxcb-xmonad could be v2. ;)
sorearwow, two major versions away...
dylanpssh, it could be one version away
sorearwe're at version 0 now
dylanv0 to v2 then.
skip 1
sorearwell, 0.1 to be precise
jcreighwhen we do switch to XCB, it probably should be a major version bump. So xcb-xmonad might indeed end up being xmonad 2.0
thoughtpolicewhat 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.
sorearxlib is very ew.
jcreighsupposedly, we could actually do threading the xcb.
sorearthat'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
thoughtpolicedelicious
sorearxcb/xmonad will use far less ram than xlib/dwm, even after you factor in the GHC RTS
jcreighFor 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
lambdabotTitle: Xlib Programming Manual: Keyboard Encoding, http://tinyurl.com/2dxpco
jcreighint max_keypermod; /* This server's max number of keys per modifier */
KeyCode *modifiermap; /* An 8 by max_keypermod array of the modifiers */
sorearonly 2 fields
is that bad?
jcreighWell, 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."

Page: 2 9 16 23 30 37 44 51 58 65 72 

IrcArchive

NY Lost Funds